Re: [PATCH v2 RESEND] pwm: Add CLPS711X PWM support
On Wed, 26 Feb 2014 16:00:46 + Mark Rutland wrote: > On Tue, Feb 25, 2014 at 03:50:32PM +, Arnd Bergmann wrote: > > On Tuesday 25 February 2014 19:47:57 Alexander Shiyan wrote: > > > Вторник, 25 февраля 2014, 16:33 +01:00 от Arnd Bergmann : > > > > On Tuesday 25 February 2014 19:27:47 Alexander Shiyan wrote: > > => > > > > > We really want to avoid wildcards in compatible strings. Can you call > > > > this > > > > "cirrus,cs89712-pwm" to match the first SoC that came with this > > > > hardware? > > > > Obviously if there was some chip before that (I'm not familiar with the > > > > model numbers), use that instead. > > > > > > > > You can either list all chips you know that have this in the driver, > > > > or you use "cirrus,cs89712-pwm" as the fallback, and use the name of > > > > the SoC you have as the more specific string. > > > > > > It seems that in this case we will need to modify the compatibility string > > > for other drivers that are already available in the kernel... > > > > Ah, right. I missed the binding for gpio and serial going in. > > > > DT maintainers, any suggestion on how we should proceed here? > > > > AFAICT, clps711x platform support is still work-in-progress, so we don't > > have any upstream users to worry about yet, but changing them is still > > going to be slightly messy. > > When allocating any new compatible strings, as Arnd says, we should > avoid wildcards as they're usually far too encompassing and end up > causing more trouble than they're worth. > > In this case how problematic are the wildcard strings? > > I assume we still have specific strings earlier in any compatible list > in any case? If not, and there are possible differences, that should be > fixed right away. > > We have a few options: > > a) Update the docs only. > >Note in the docs that "cirrus,clps711x-$UNIT" means anything >compatible with the $UNIT in the cs89712. This may be >counter-intuitive, and if a new clps711x platform comes out with an >incompatible $UNIT it should omit "cirrus,clps711x-$UNIT" from its >compatible list, but otherwise no harm done. > > b) Deprecate the existing string. > >Add "cirrus,cs89712-$UNIT" to the binding docs and driver. Mark >"cirrus,clps711x-$UNIT" as deprecated in the binding document. >Replace "cirrus,clps711x-$UNIT" with "cirrus,cs89712-$UNIT" in all >DTs. > >This will mean new DTBs won't work with an older kernel, but as >support is a work in progress that might not matter. Old DTBs will >continue to function. > >Iff you can guarantee that the old string is not possibly being used >by anyone, it can be dropped from the driver. If not it has to remain >(though can be commented to be deprecated), so that old DTBs >function. It's probably best to leave it there. > > c) Deprecate, maintaining (forwards) compatibility. > >As above, but rather than replacing "cirrus,clps711x-$UNIT" with >"cirrus,cs89712-$UNIT" in DTs, place "cirrus,cs89712-$UNIT" before >"cirrus,clps711x-$UNIT" in DTs. This allows new DTBs to work with >older kernels too. Depending on what level of support you have in >mainline currently this may or may not be an important consideration. Hello. I want to elaborate on the current CLPS711X lineup: PS7110 - EOL October 30, 2001 PS7111 - EOL October 30, 2001 EP7209 - EOL April 25, 2003 EP7211 - EOL April 25, 2003 EP7212 - EOL April 25, 2003 CS89712 - EOL August 15, 2005 EP7309 - Production EP7311 - Production EP7312 - Production So at the moment, and long enough, produced only three models of CPUs. I am sure that the hardware with old CPUs will not be able to use the new kernel due to memory limitations, low CPU frequency, etc. My suggestion is to always use a compatibility string for platform entirely, ie "cirrus,clps711x-$UNIT", otherwise it may result in misleading. In any case, I would like to hear the final decision on this issue, since there are several drivers already using this scheme and some drivers awaiting applying into the kernel. I do not insist on its position, but just want to clarify to make changes to existing drivers and use the approved compatibility string in the future. At the current stage, these changes will not lead to anything terrible. Thanks. -- Alexander Shiyan -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/3] dt: palmas: support IRQ inversion at the board level
On Fri, Feb 28, 2014 at 09:34:33AM -0700, Stephen Warren wrote: > On 02/27/2014 10:58 PM, Mark Brown wrote: > > I'm not sure that renaming the property really deals with the concerns > > though since drivers still all need to manually add support for this, > > shouldn't there be an interrupt controller described in the DT which > > just chains on to the parent with the polarity inverted to do the > > impedence match? > I had thought of that when first dealing with this a couple years ago, > but Olof suggested that was too complicated. It's not obvious to me that it should be especially hard but I've not thought about it too deeply. > Another alternative might be to add an extra IRQ bit in the IRQ > specifier (and something similar would be needed for GPIO specifiers) > that indicates "inversion between source and destination". This could be > queried by drivers in exactly the same way as the existing polarity/type > IRQ flags. We'd need to update each individual IRQ controller binding to > enable that flag, since each binding defines its own definition of such > flags. (although in practice since most use the same centrally suggested > flags, this wouldn't be any more than just saying yes, this binding > allows that new flag to be used). Yes, doing something on the controller side seems more obvious here. signature.asc Description: Digital signature
Re: [PATCH 1/2] i2c: Add driver for Cadence I2C controller
On Fri, 2014-02-28 at 04:00PM -0800, Soren Brinkmann wrote: > Add a driver for the Cadence I2C controller. This controller is for > example found in Xilinx Zynq. > > Signed-off-by: Soren Brinkmann > --- > .../devicetree/bindings/i2c/i2c-cadence.txt| 21 + > MAINTAINERS| 1 + > drivers/i2c/busses/Kconfig | 7 + > drivers/i2c/busses/Makefile| 1 + > drivers/i2c/busses/i2c-cadence.c | 901 > + > 5 files changed, 931 insertions(+) > create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cadence.txt > create mode 100644 drivers/i2c/busses/i2c-cadence.c > [...] > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > index f5ed03164d86..7806c1654068 100644 > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > @@ -375,6 +375,13 @@ config I2C_BLACKFIN_TWI_CLK_KHZ > help > The unit of the TWI clock is kHz. > > +config I2C_CADENCE > + tristate "Cadence I2C Controller" > + depends on ARCH_ZYNQ This can be reduced to a dependency on COMMON_CLK only, I think. Sören -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] dmaengine: sirf: enable generic dt binding for dma channels
2014-01-20 17:35 GMT+08:00 Barry Song <21cn...@gmail.com>: > 2014/1/20 Vinod Koul : >> On Wed, Jan 08, 2014 at 10:12:49PM +0800, Barry Song wrote: >>> From: Barry Song >>> >>> move to support of_dma_request_slave_channel() and >>> dma_request_slave_channel. >>> we add a xlate() to let dma clients be able to find right dma_chan by >>> generic >>> "dmas" properties in dts. >>> >>> Cc: Mark Rutland >>> Cc: Lars-Peter Clausen >>> Signed-off-by: Barry Song >> Look okay, need an ACk from DT maintainers before I can apply... Hi Vinod, v5 is sent to devicetree list and there is no object. http://www.spinics.net/lists/devicetree/msg19677.html this patch is using general dt-binding for dma completely same with other dma drivers, there is no special binding here. so i think there is no reason to wait for merging since now updates for its clients e.g. SPI, UART have been in 3.14-rc. -barry -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] pci: Add support for creating a generic host_bridge from device tree
On Fri, Feb 28, 2014 at 06:07:05PM -0800, Tanmay Inamdar wrote: > Earlier email did not deliver to mailing lists because of plain text > setting problem on my side. Apologies for spamming. Sending it again. > > Hello Liviu, > Hello Tanmay, > While porting X-Gene PCIe driver to v2 series, following problems were > observed. Thanks for trying it out. > > 1. In 'of_create_pci_host_bridge' function, bus_range is defined > locally. So, while walking over list of resources in bridge->windows > later, during X-Gene controller related setup, garbage values are > found in the resource. Please allocate it dynamically. Bah, sorry for that. Will fix. > > 2. 'domain_nr' problem is partially solved. There are still some > places where functions are getting invalid domain_nr. For example, > 'pci_alloc_child_bus' tries to get domain_nr when bridge is not > assigned to bus. You may want to look for all the places where > pci_domain_nr is used. Please see below dump --> > > pci 0001:00:00.0: scanning [bus 00-00] behind bridge, pass 1 > [ cut here ] > WARNING: CPU: 0 PID: 1 at > /home/tinamdar/work/open-source/linux/fs/sysfs/dir.c:52 > sysfs_warn_dup+0x80/0xc0() > sysfs: cannot create duplicate filename '/class/pci_bus/:01' > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #37 > Call trace: > [] dump_backtrace+0x0/0x140 > [] show_stack+0x14/0x20 > [] dump_stack+0x78/0xc4 > [] warn_slowpath_common+0x88/0xc0 > [] warn_slowpath_fmt+0x50/0x60 > [] sysfs_warn_dup+0x80/0xc0 > [] sysfs_do_create_link_sd.isra.2+0xf8/0x100 > [] sysfs_create_link+0x20/0x40 > [] device_add+0x41c/0x520 > [] device_register+0x1c/0x40 > [] pci_add_new_bus+0x284/0x380 > [] pci_scan_bridge+0x4e0/0x540 > [] pci_scan_child_bus+0xb4/0x140 > [] pci_rescan_bus+0x14/0x40 > [] xgene_pcie_probe_bridge+0x688/0x750 > [] platform_drv_probe+0x24/0x60 > [] really_probe+0xf4/0x220 > [] __driver_attach+0xa4/0xc0 > [] bus_for_each_dev+0x58/0xa0 > [] driver_attach+0x20/0x40 > [] bus_add_driver+0x150/0x220 > [] driver_register+0x60/0x120 > [] __platform_driver_register+0x60/0x80 > [] xgene_pcie_driver_init+0x18/0x20 > [] do_one_initcall+0xe4/0x160 do you have your xgene_pcie_driver_init being called out of some subsys_initcall? If so, remove it and let the generic DT parsing code match your driver. The bridge should've been associated with the root bus by the time the child busses are scanned and allocated, unless I'm missing something obvious. Also, can you share your version of your driver with me? Best regards, Liviu > [] kernel_init_freeable+0x138/0x1d8 > [] kernel_init+0x10/0xe0 > ---[ end trace 53db1c3a7fbdeb88 ]--- > [ cut here ] > WARNING: CPU: 0 PID: 1 at > /home/tinamdar/work/open-source/linux/drivers/pci/probe.c:711 > pci_add_new_bus+0x36c/0x380() > > Thanks, > Tanmay > > On Fri, Feb 28, 2014 at 6:01 PM, Tanmay Inamdar wrote: > > Hello Liviu, > > > > While porting X-Gene PCIe driver to v2 series, following problems were > > observed. > > > > 1. In 'of_create_pci_host_bridge' function, bus_range is defined locally. > > So, while walking over list of resources in bridge->windows later, during > > X-Gene controller related setup, garbage values are found in the resource. > > Please allocate it dynamically. > > > > 2. 'domain_nr' problem is partially solved. There are still some places > > where functions are getting invalid domain_nr. For example, > > 'pci_alloc_child_bus' tries to get domain_nr when bridge is not assigned to > > bus. You may want to look for all the places where pci_domain_nr is used. > > Please see below dump --> > > > > pci 0001:00:00.0: scanning [bus 00-00] behind bridge, pass 1 > > [ cut here ] > > WARNING: CPU: 0 PID: 1 at > > /home/tinamdar/work/open-source/linux/fs/sysfs/dir.c:52 > > sysfs_warn_dup+0x80/0xc0() > > sysfs: cannot create duplicate filename '/class/pci_bus/:01' > > Modules linked in: > > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #37 > > Call trace: > > [] dump_backtrace+0x0/0x140 > > [] show_stack+0x14/0x20 > > [] dump_stack+0x78/0xc4 > > [] warn_slowpath_common+0x88/0xc0 > > [] warn_slowpath_fmt+0x50/0x60 > > [] sysfs_warn_dup+0x80/0xc0 > > [] sysfs_do_create_link_sd.isra.2+0xf8/0x100 > > [] sysfs_create_link+0x20/0x40 > > [] device_add+0x41c/0x520 > > [] device_register+0x1c/0x40 > > [] pci_add_new_bus+0x284/0x380 > > [] pci_scan_bridge+0x4e0/0x540 > > [] pci_scan_child_bus+0xb4/0x140 > > [] pci_rescan_bus+0x14/0x40 > > [] xgene_pcie_probe_bridge+0x688/0x750 > > [] platform_drv_probe+0x24/0x60 > > [] really_probe+0xf4/0x220 > > [] __driver_attach+0xa4/0xc0 > > [] bus_for_each_dev+0x58/0xa0 > > [] driver_attach+0x20/0x40 > > [] bus_add_driver+0x150/0x220 > > [] driver_register+0x60/0x120 > > [] __platform_driver_register+0x60/0x80 > > [] xgene_pcie_driver_init+0x18/0x20 > > [] do_one_initcall+0xe4/0x160 > > [] kernel_init_freeable+0x138/0x1d8 > > [] kernel_init+0x10/0xe0 > > ---[ end trace
Re: [PATCH 2/2] ARM: zynq: dt: Add I2C nodes to Zynq device tree
On Fri, 2014-02-28 at 04:00PM -0800, Soren Brinkmann wrote:
> Signed-off-by: Soren Brinkmann
> ---
> arch/arm/boot/dts/zynq-7000.dtsi | 22
> arch/arm/boot/dts/zynq-zc702.dts | 76
>
> arch/arm/boot/dts/zynq-zc706.dts | 68 +++
> 3 files changed, 166 insertions(+)
>
[...]
> diff --git a/arch/arm/boot/dts/zynq-zc702.dts
> b/arch/arm/boot/dts/zynq-zc702.dts
> index c913f77a21eb..91a3a560f03b 100644
> --- a/arch/arm/boot/dts/zynq-zc702.dts
> +++ b/arch/arm/boot/dts/zynq-zc702.dts
[...]
> +
> + i2c@7 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <7>;
> + hwmon@52 {
> + compatible = "pmbus,ucd9248";
> + reg = <52>;
> + };
> + hwmon@53 {
> + compatible = "pmbus,ucd9248";
> + reg = <53>;
> + };
> + hwmon@54 {
> + compatible = "pmbus,ucd9248";
All these occurrences of 'pmbus' should rather be replaced with 'ti'.
I wasn't aware of how this DT node to I2C probing works - and still
haven't fully understood it - but the vendor prefix is apparently a
don't care and we could simply use the correct one here.
I have no idea how I came up with the description using 'pmbus' (we
carry this in our vendor tree for quite a while already).
Is there any document describing how a DT node is matched to an
appropriate driver? These I2C drivers usually don't have the common
'struct of_device_id'. Hence my preferred way of simply grepping through
the kernel for the compatibility string does not work.
[...]
> diff --git a/arch/arm/boot/dts/zynq-zc706.dts
> b/arch/arm/boot/dts/zynq-zc706.dts
> index 88f62c50382e..dab30f80d5b0 100644
> --- a/arch/arm/boot/dts/zynq-zc706.dts
> +++ b/arch/arm/boot/dts/zynq-zc706.dts
[...]
> + i2c@7 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <7>;
> + ucd90120@65 {
> + compatible = "pmbus,ucd90120";
same here
Sören
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] pci: Add support for creating a generic host_bridge from device tree
Earlier email did not deliver to mailing lists because of plain text setting problem on my side. Apologies for spamming. Sending it again. Hello Liviu, While porting X-Gene PCIe driver to v2 series, following problems were observed. 1. In 'of_create_pci_host_bridge' function, bus_range is defined locally. So, while walking over list of resources in bridge->windows later, during X-Gene controller related setup, garbage values are found in the resource. Please allocate it dynamically. 2. 'domain_nr' problem is partially solved. There are still some places where functions are getting invalid domain_nr. For example, 'pci_alloc_child_bus' tries to get domain_nr when bridge is not assigned to bus. You may want to look for all the places where pci_domain_nr is used. Please see below dump --> pci 0001:00:00.0: scanning [bus 00-00] behind bridge, pass 1 [ cut here ] WARNING: CPU: 0 PID: 1 at /home/tinamdar/work/open-source/linux/fs/sysfs/dir.c:52 sysfs_warn_dup+0x80/0xc0() sysfs: cannot create duplicate filename '/class/pci_bus/:01' Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #37 Call trace: [] dump_backtrace+0x0/0x140 [] show_stack+0x14/0x20 [] dump_stack+0x78/0xc4 [] warn_slowpath_common+0x88/0xc0 [] warn_slowpath_fmt+0x50/0x60 [] sysfs_warn_dup+0x80/0xc0 [] sysfs_do_create_link_sd.isra.2+0xf8/0x100 [] sysfs_create_link+0x20/0x40 [] device_add+0x41c/0x520 [] device_register+0x1c/0x40 [] pci_add_new_bus+0x284/0x380 [] pci_scan_bridge+0x4e0/0x540 [] pci_scan_child_bus+0xb4/0x140 [] pci_rescan_bus+0x14/0x40 [] xgene_pcie_probe_bridge+0x688/0x750 [] platform_drv_probe+0x24/0x60 [] really_probe+0xf4/0x220 [] __driver_attach+0xa4/0xc0 [] bus_for_each_dev+0x58/0xa0 [] driver_attach+0x20/0x40 [] bus_add_driver+0x150/0x220 [] driver_register+0x60/0x120 [] __platform_driver_register+0x60/0x80 [] xgene_pcie_driver_init+0x18/0x20 [] do_one_initcall+0xe4/0x160 [] kernel_init_freeable+0x138/0x1d8 [] kernel_init+0x10/0xe0 ---[ end trace 53db1c3a7fbdeb88 ]--- [ cut here ] WARNING: CPU: 0 PID: 1 at /home/tinamdar/work/open-source/linux/drivers/pci/probe.c:711 pci_add_new_bus+0x36c/0x380() Thanks, Tanmay On Fri, Feb 28, 2014 at 6:01 PM, Tanmay Inamdar wrote: > Hello Liviu, > > While porting X-Gene PCIe driver to v2 series, following problems were > observed. > > 1. In 'of_create_pci_host_bridge' function, bus_range is defined locally. > So, while walking over list of resources in bridge->windows later, during > X-Gene controller related setup, garbage values are found in the resource. > Please allocate it dynamically. > > 2. 'domain_nr' problem is partially solved. There are still some places > where functions are getting invalid domain_nr. For example, > 'pci_alloc_child_bus' tries to get domain_nr when bridge is not assigned to > bus. You may want to look for all the places where pci_domain_nr is used. > Please see below dump --> > > pci 0001:00:00.0: scanning [bus 00-00] behind bridge, pass 1 > [ cut here ] > WARNING: CPU: 0 PID: 1 at > /home/tinamdar/work/open-source/linux/fs/sysfs/dir.c:52 > sysfs_warn_dup+0x80/0xc0() > sysfs: cannot create duplicate filename '/class/pci_bus/:01' > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc4+ #37 > Call trace: > [] dump_backtrace+0x0/0x140 > [] show_stack+0x14/0x20 > [] dump_stack+0x78/0xc4 > [] warn_slowpath_common+0x88/0xc0 > [] warn_slowpath_fmt+0x50/0x60 > [] sysfs_warn_dup+0x80/0xc0 > [] sysfs_do_create_link_sd.isra.2+0xf8/0x100 > [] sysfs_create_link+0x20/0x40 > [] device_add+0x41c/0x520 > [] device_register+0x1c/0x40 > [] pci_add_new_bus+0x284/0x380 > [] pci_scan_bridge+0x4e0/0x540 > [] pci_scan_child_bus+0xb4/0x140 > [] pci_rescan_bus+0x14/0x40 > [] xgene_pcie_probe_bridge+0x688/0x750 > [] platform_drv_probe+0x24/0x60 > [] really_probe+0xf4/0x220 > [] __driver_attach+0xa4/0xc0 > [] bus_for_each_dev+0x58/0xa0 > [] driver_attach+0x20/0x40 > [] bus_add_driver+0x150/0x220 > [] driver_register+0x60/0x120 > [] __platform_driver_register+0x60/0x80 > [] xgene_pcie_driver_init+0x18/0x20 > [] do_one_initcall+0xe4/0x160 > [] kernel_init_freeable+0x138/0x1d8 > [] kernel_init+0x10/0xe0 > ---[ end trace 53db1c3a7fbdeb88 ]--- > [ cut here ] > WARNING: CPU: 0 PID: 1 at > /home/tinamdar/work/open-source/linux/drivers/pci/probe.c:711 > pci_add_new_bus+0x36c/0x380() > > Thanks, > Tanmay > > > > On Fri, Feb 28, 2014 at 5:08 AM, Liviu Dudau wrote: >> >> Several platforms use a rather generic version of parsing >> the device tree to find the host bridge ranges. Move the common code >> into the generic PCI code and use it to create a pci_host_bridge >> structure that can be used by arch code. >> >> Based on early attempts by Andrew Murray to unify the code. >> Used powerpc and microblaze PCI code as starting point. >> >> Signed-off-by: Liviu Dudau >> >> diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c >> index 06ace62
Re: [PATCH 0/7] PCI irq mapping fixes and cleanups
On Fri, Feb 28, 2014 at 9:28 AM, Lucas Stach wrote: > This series cleans up the PCI irq mapping for all > the ARM PCI host drivers, so they handle it in the > way defined in the common PCI bindings. > > Testing appreciated. > > Lucas Stach (7): > ARM: dts: tegra: add PCIe interrupt mapping properties > PCI: tegra: use new OF interrupt mapping when possible > PCI: rcar: use new OF interrupt mapping when possible > ARM: dts: exynos5440: fix PCIe interrupt mapping > ARM: dts: imx6: add PCIe interrupt mapping properties > PCI: designware: use new OF interrupt mapping when possible > PCI: designware: split samsung and fsl bindings > > .../devicetree/bindings/pci/designware-pcie.txt| 69 + > .../devicetree/bindings/pci/fsl,imx6q-pcie.txt | 48 +++ > .../bindings/pci/nvidia,tegra20-pcie.txt | 8 +++ > .../bindings/pci/samsung,exynos5440-pcie.txt | 70 > ++ > arch/arm/boot/dts/exynos5440.dtsi | 4 +- > arch/arm/boot/dts/imx6qdl.dtsi | 11 > arch/arm/boot/dts/tegra20.dtsi | 4 ++ > arch/arm/boot/dts/tegra30.dtsi | 4 ++ > drivers/pci/host/pci-rcar-gen2.c | 8 ++- > drivers/pci/host/pci-tegra.c | 7 ++- > drivers/pci/host/pcie-designware.c | 8 ++- > 11 files changed, 168 insertions(+), 73 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt > create mode 100644 > Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt > > -- > 1.8.5.3 > Lucas, In testing this on IMX6 I'm finding that 'of_irq_parse_and_map_pci()' always returns -EINVAL because it can't find a dt node for the host bridge: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/of/of_pci_irq.c#n60. So it seems there is still something missing in the imx6 devicetree regarding a 'host bridge'? Is this solution expecting the range/interrupt data from the PCI host controller to be encapsulated in a host-bridge node such as http://lxr.missinglinkelectronics.com/linux/Documentation/devicetree/bindings/pci/ralink,rt3883-pci.txt#L124? If so, thats not how the imx6 host controller node is currently defined. In my particular test case I have a baseboard with a socket on it and a PLX PEX860x PCIe switch on an add-in card. So I don't think it makes sense to me to describe the add-in card in the baseboard DT - that wouldn't be very plug-n-play. By the way, I'm not referring to the add-in card with the TI-XIO2001 PCIe-to-PCI bridge with the mismapped IRQ's - I'm aware that I would need to deal with that somehow in devicetree (still trying to understand how). Thanks, Tim -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
contact me
contact me for details of $21.4m transfer. The information contained in this electronic communication is intended solely for the individual(s) or entity to which it is addressed. It may contain proprietary, confidential and/or legally privileged information. Any review, retransmission, dissemination, printing, copying or other use of, or taking any action in reliance on the contents of this information by person(s) or entities other than the intended recipient is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us by responding to this email or telephone and immediately and permanently delete all copies of this message and any attachments from your system(s). The contents of this message do not necessarily represent the views or policies of Aditya Birla Group. Computer viruses can be transmitted via email. Aditya Birla Group Companies attempts to sweep e-mails and attachments for viruses, it does not guarantee that either are virus free. The recipient should check this email and any attachments for the presence of viruses. Aditya Birla Group does not accept any liability for any damage sustained as a result of viruses. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] phy-rcar-gen2-usb: add device tree support
Add support of the device tree probing for the Renesas R-Car generation 2 SoCs
documenting the device tree binding as necessary.
Signed-off-by: Sergei Shtylyov
---
This patch is against the 'next' branch of Felipe Balbi's 'usb.git' repo.
Changes in version 2:
- restored devm_clk_get() call and the error handling logic in the probe()
method, removed clk_put() call in the remove() method.
Documentation/devicetree/bindings/usb/rcar-gen2-phy.txt | 29 +++
drivers/usb/phy/phy-rcar-gen2-usb.c | 42 ++--
2 files changed, 68 insertions(+), 3 deletions(-)
Index: usb/Documentation/devicetree/bindings/usb/rcar-gen2-phy.txt
===
--- /dev/null
+++ usb/Documentation/devicetree/bindings/usb/rcar-gen2-phy.txt
@@ -0,0 +1,29 @@
+* Renesas R-Car generation 2 USB PHY
+
+This file provides information on what the device node for the R-Car generation
+2 USB PHY contains.
+
+Required properties:
+- compatible: "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC.
+ "renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC.
+- reg: offset and length of the register block.
+- clocks: clock phandle and specifier pair.
+- clock-names: string, clock input name, must be "usbhs".
+
+Optional properties:
+- renesas,channel0-pci: boolean, specify when USB channel 0 should be connected
+ to PCI EHCI/OHCI; otherwise, it will be connected to the
+ USBHS controller.
+- renesas,channel2-pci: boolean, specify when USB channel 2 should be connected
+ to PCI EHCI/OHCI; otherwise, it will be connected to the
+ USBSS controller (xHCI).
+
+Example (Lager board):
+
+ usb-phy@e6590100 {
+ compatible = "renesas,usb-phy-r8a7790";
+ reg = <0 0xe6590100 0 0x100>;
+ clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
+ clock-names = "usbhs";
+ renesas,channel2-pci;
+ };
Index: usb/drivers/usb/phy/phy-rcar-gen2-usb.c
===
--- usb.orig/drivers/usb/phy/phy-rcar-gen2-usb.c
+++ usb/drivers/usb/phy/phy-rcar-gen2-usb.c
@@ -1,8 +1,8 @@
/*
* Renesas R-Car Gen2 USB phy driver
*
- * Copyright (C) 2013 Renesas Solutions Corp.
- * Copyright (C) 2013 Cogent Embedded, Inc.
+ * Copyright (C) 2013-2014 Renesas Solutions Corp.
+ * Copyright (C) 2013-2014 Cogent Embedded, Inc.
*
* 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
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -167,6 +168,37 @@ out:
spin_unlock_irqrestore(&priv->lock, flags);
}
+#ifdef CONFIG_OF
+static struct rcar_gen2_phy_platform_data *
+rcar_gen2_usb_phy_parse_dt(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ struct rcar_gen2_phy_platform_data *pdata;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL;
+
+ pdata->chan0_pci = of_property_read_bool(np, "renesas,channel0-pci");
+ pdata->chan2_pci = of_property_read_bool(np, "renesas,channel2-pci");
+
+ return pdata;
+}
+
+static const struct of_device_id rcar_gen2_usb_phy_match_table[] = {
+ { .compatible = "renesas,usb-phy-r8a7790" },
+ { .compatible = "renesas,usb-phy-r8a7791" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, rcar_gen2_usb_phy_match_table);
+#else
+static inline struct rcar_gen2_phy_platform_data *
+rcar_gen2_usb_phy_parse_dt(struct device *dev)
+{
+ return NULL;
+}
+#endif
+
static int rcar_gen2_usb_phy_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -177,7 +209,10 @@ static int rcar_gen2_usb_phy_probe(struc
struct clk *clk;
int retval;
- pdata = dev_get_platdata(dev);
+ if (dev->of_node)
+ pdata = rcar_gen2_usb_phy_parse_dt(dev);
+ else
+ pdata = dev_get_platdata(dev);
if (!pdata) {
dev_err(dev, "No platform data\n");
return -EINVAL;
@@ -236,6 +271,7 @@ static int rcar_gen2_usb_phy_remove(stru
static struct platform_driver rcar_gen2_usb_phy_driver = {
.driver = {
.name = "usb_phy_rcar_gen2",
+ .of_match_table = of_match_ptr(rcar_gen2_usb_phy_match_table),
},
.probe = rcar_gen2_usb_phy_probe,
.remove = rcar_gen2_usb_phy_remove,
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: zynq: dt: Add I2C nodes to Zynq device tree
Signed-off-by: Soren Brinkmann
---
arch/arm/boot/dts/zynq-7000.dtsi | 22
arch/arm/boot/dts/zynq-zc702.dts | 76
arch/arm/boot/dts/zynq-zc706.dts | 68 +++
3 files changed, 166 insertions(+)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 8b67b19392ec..fb1e1e7cae8f 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -48,6 +48,28 @@
interrupt-parent = <&intc>;
ranges;
+ i2c0: zynq-i2c@e0004000 {
+ compatible = "cdns,i2c-r1p10";
+ status = "disabled";
+ clocks = <&clkc 38>;
+ interrupt-parent = <&intc>;
+ interrupts = <0 25 4>;
+ reg = <0xE0004000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ i2c1: zynq-i2c@e0005000 {
+ compatible = "cdns,i2c-r1p10";
+ status = "disabled";
+ clocks = <&clkc 39>;
+ interrupt-parent = <&intc>;
+ interrupts = <0 48 4>;
+ reg = <0xE0005000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
intc: interrupt-controller@f8f01000 {
compatible = "arm,cortex-a9-gic";
#interrupt-cells = <3>;
diff --git a/arch/arm/boot/dts/zynq-zc702.dts b/arch/arm/boot/dts/zynq-zc702.dts
index c913f77a21eb..91a3a560f03b 100644
--- a/arch/arm/boot/dts/zynq-zc702.dts
+++ b/arch/arm/boot/dts/zynq-zc702.dts
@@ -34,6 +34,82 @@
phy-mode = "rgmii";
};
+&i2c0 {
+ status = "okay";
+ clock-frequency = <40>;
+
+ i2cswitch@74 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x74>;
+
+ i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ si570: clock-generator@5d {
+ #clock-cells = <0>;
+ compatible = "silabs,si570";
+ temperature-stability = <50>;
+ reg = <0x5d>;
+ factory-fout = <15625>;
+ clock-frequency = <14850>;
+ };
+ };
+
+ i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ eeprom@54 {
+ compatible = "at,24c08";
+ reg = <0x54>;
+ };
+ };
+
+ i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ gpio@21 {
+ compatible = "ti,tca6416";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
+ i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+ };
+
+ i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ hwmon@52 {
+ compatible = "pmbus,ucd9248";
+ reg = <52>;
+ };
+ hwmon@53 {
+ compatible = "pmbus,ucd9248";
+ reg = <53>;
+ };
+ hwmon@54 {
+ compatible = "pmbus,ucd9248";
+ reg = <54>;
+ };
+ };
+ };
+};
+
&sdhci0 {
status = "okay";
};
diff --git a/arch/arm/boot/dts/zynq-zc706.dts b/arch/arm/boot/dts/zynq-zc706.dts
index 88f62c50382e..dab30f80d5b0 100644
--- a/arch/arm/boot/dts/zynq-zc706.dts
+++ b/arch/arm/boot/dts/zynq-zc706.dts
@@ -35,6 +35,74 @@
phy-mode = "rgmii";
};
+&i2c0 {
+ status = "okay";
+ clock-frequency = <40>;
+
+ i2cswitch@74 {
+ compatible = "nxp,pca9548";
+ #address-cells = <1>;
+ #size-cells
[PATCH 1/2] i2c: Add driver for Cadence I2C controller
Add a driver for the Cadence I2C controller. This controller is for
example found in Xilinx Zynq.
Signed-off-by: Soren Brinkmann
---
.../devicetree/bindings/i2c/i2c-cadence.txt| 21 +
MAINTAINERS| 1 +
drivers/i2c/busses/Kconfig | 7 +
drivers/i2c/busses/Makefile| 1 +
drivers/i2c/busses/i2c-cadence.c | 901 +
5 files changed, 931 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-cadence.txt
create mode 100644 drivers/i2c/busses/i2c-cadence.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-cadence.txt
b/Documentation/devicetree/bindings/i2c/i2c-cadence.txt
new file mode 100644
index ..685adf513111
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-cadence.txt
@@ -0,0 +1,21 @@
+Binding for the Cadence I2C controller
+
+Required properties:
+ compatible: Compatibility string. Must be 'cdns,i2c-r1p10'.
+ clocks: From common clock bindings. Phandle to input clock.
+
+Optional properties:
+ clock-frequency: Desired operating frequency, in Hz, of the bus (actual may
+ be lower). Defaults to 40 if not specified.
+
+Example:
+
+ i2c@e0004000 {
+ compatible = "cdns,i2c-r1p10";
+ clocks = <&clkc 38>;
+ interrupts = <0 25 4>;
+ reg = <0xE0004000 0x1000>;
+ clock-frequency = <40>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index df8869d49c3f..cd1ce0d53ff0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1402,6 +1402,7 @@ F:drivers/cpuidle/cpuidle-zynq.c
N: zynq
N: xilinx
F: drivers/clocksource/cadence_ttc_timer.c
+F: drivers/i2c/busses/i2c-cadence.c
F: drivers/mmc/host/sdhci-of-arasan.c
ARM SMMU DRIVER
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index f5ed03164d86..7806c1654068 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -375,6 +375,13 @@ config I2C_BLACKFIN_TWI_CLK_KHZ
help
The unit of the TWI clock is kHz.
+config I2C_CADENCE
+ tristate "Cadence I2C Controller"
+ depends on ARCH_ZYNQ
+ help
+ Say yes here to select Cadence I2C Host Controller. This controller is
+ e.g. used by Xilinx Zynq.
+
config I2C_CBUS_GPIO
tristate "CBUS I2C driver"
depends on GPIOLIB
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index a08931fe73e1..f9ebb8c6cdc1 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_I2C_AT91)+= i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_BCM2835) += i2c-bcm2835.o
obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
+obj-$(CONFIG_I2C_CADENCE) += i2c-cadence.o
obj-$(CONFIG_I2C_CBUS_GPIO)+= i2c-cbus-gpio.o
obj-$(CONFIG_I2C_CPM) += i2c-cpm.o
obj-$(CONFIG_I2C_DAVINCI) += i2c-davinci.o
diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
new file mode 100644
index ..5ce1bba6402b
--- /dev/null
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -0,0 +1,901 @@
+/*
+ * I2C bus driver for the Cadence I2C controller.
+ *
+ * Copyright (C) 2009 - 2014 Xilinx, Inc.
+ *
+ * This program is free software; you can redistribute it
+ * and/or modify it under the terms of the GNU General Public
+ * License as published by the Free Software Foundation;
+ * either version 2 of the License, or (at your option) any
+ * later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Register offsets for the I2C device. */
+#define CDNS_I2C_CR_OFFSET 0x00 /* Control Register, RW */
+#define CDNS_I2C_SR_OFFSET 0x04 /* Status Register, RO */
+#define CDNS_I2C_ADDR_OFFSET 0x08 /* I2C Address Register, RW */
+#define CDNS_I2C_DATA_OFFSET 0x0C /* I2C Data Register, RW */
+#define CDNS_I2C_ISR_OFFSET0x10 /* Interrupt Status Register, RW */
+#define CDNS_I2C_XFER_SIZE_OFFSET 0x14 /* Transfer Size Register, RW */
+#define CDNS_I2C_TIME_OUT_OFFSET 0x1C /* Time Out Register, RW */
+#define CDNS_I2C_IER_OFFSET0x24 /* Interrupt Enable Register, WO */
+#define CDNS_I2C_IDR_OFFSET0x28 /* Interrupt Disable Register, WO */
+
+/* Control Register Bit mask definitions */
+#define CDNS_I2C_CR_HOLD BIT(4) /* Hold Bus bit */
+#define CDNS_I2C_CR_NEABIT(2)
+/* Read or Write Master transfer 0 = Transmitter, 1 = Receiver */
+#define CDNS_I2C_CR_RW BIT(0)
+/* 1 = Auto init FIFO to zeroes */
+#define CDNS_I2C_CR_CLR_FIFO BIT(6)
+#define CDNS_I2C_CR_DIVA_SHIFT 14
+#define CDNS_I2C_CR_DIVA_MASK (3 << CDNS_I2C_CR_DIVA_SHIFT)
+#define CDNS_I2C_CR_DIVB_SHIFT 8
+#define CDNS_I2C_CR_DIVB_
Re: [PATCH] dma: Add Keystone Packet DMA Engine driver
On Friday 28 February 2014 06:14 PM, Arnd Bergmann wrote:
> On Friday 28 February 2014 17:56:40 Santosh Shilimkar wrote:
>> The Packet DMA driver sets up the dma channels and flows for the
>> QMSS(Queue Manager SubSystem) who triggers the actual data movements
>> across clients using destination queues. Every client modules like
>> NETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTO
>> Engines has its own instance of packet dma hardware. QMSS has also
>> an internal packet DMA module which is used as an infrastructure
>> DMA with zero copy.
>>
>> Patch adds DMAEngine driver for Keystone Packet DMA hardware.
>> The specifics on the device tree bindings for Packet DMA can be
>> found in:
>> Documentation/devicetree/bindings/dma/keystone-pktdma.txt
>>
>> The driver implements the configuration functions using standard DMAEngine
>> apis. The data movement is managed by QMSS device driver.
>
> The description of this sounds a bit like the x-gene queue manager/tag
> manager, rather than a traditional DMA engine. For that driver, we
> decided to use the mailbox subsystem instead of the DMA subsystem.
>
> Can you explain what kind of data is actually getting transferred
> in by your hardware here? You say the DMA is performed by the QMSS,
> so do you use the pktdma driver to drive the data transfers of the
> QMSS or do you just use it for flow control by passing short (a few
> bytes) messages and also have to program the pktdma?
>
I don't know what x-gene stuff is, but the keystone packet dma
is hardware DMA controller(per client subystem) which has all
the traditional DMA controller properties. The packet DMA needs
to be setup just like any slave dma configuration. The actual
data transfers are triggered by operations on Queue Manager
SubSystem.
I just posted the QMSS driver as well which explains how the system
work.
>> +
>> +bool dma_keystone_filter_fn(struct dma_chan *chan, void *param)
>> +{
>> + if (chan->device->dev->driver == &keystone_dma_driver.driver) {
>> + struct keystone_dma_chan *kdma_chan = from_achan(chan);
>> + unsigned chan_id = *(u32 *)param & KEYSTONE_DMA_CHAN_ID_MASK;
>> + unsigned chan_type = *(u32 *)param >>
>> KEYSTONE_DMA_TYPE_SHIFT;
>> +
>> + if (chan_type == KEYSTONE_DMA_TX_CHAN_TYPE &&
>> + kdma_chan->direction == DMA_MEM_TO_DEV)
>> + return chan_id == kdma_chan->channel;
>> +
>> + if (chan_type == KEYSTONE_DMA_RX_FLOW_TYPE &&
>> + kdma_chan->direction == DMA_DEV_TO_MEM)
>> + return chan_id == kdma_chan->flow;
>> + }
>> + return false;
>> +}
>> +EXPORT_SYMBOL_GPL(dma_keystone_filter_fn);
>
> The filter function should be removed here and replaced with a simpler
> custom xlate function calling dma_get_slave_chan() on the matching
> channel.
>
Can you please expand your comment please ? I though the filter function
is the one should implement for specific channel allocations.
>> diff --git a/include/linux/keystone-pktdma.h
>> b/include/linux/keystone-pktdma.h
>> new file mode 100644
>> index 000..e6a66c8
>> --- /dev/null
>> +++ b/include/linux/keystone-pktdma.h
>> @@ -0,0 +1,168 @@
>
> A DMA engine driver should not have a public API. Please move all the
> contents of the two header files into the driver itself to ensure none
> of this is visible to slave drivers. If it turns out that you use
> declarations from this header in slave drivers at the moment, please
> explain what they are so we can discuss alternative solutions.
>
Yes the slave drivers make use of these. The dt-binding header is created
because some the macro's are shared between DTS and code.
keystone-pktdma.h carriers information about the packet dma config
which is done by slave drivers. It also contains the dma descriptor
format and its associate macro's used by slave drivers. Since
the hardware perspective, the descriptor represent the packet
format dma expects and hence its left in the dma header header.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 01/10] dt: binding: add binding for ImgTec IR block
Add device tree binding for ImgTec Consumer Infrared block, specifically
major revision 1 of the hardware.
Signed-off-by: James Hogan
Acked-by: Rob Herring
Cc: Mauro Carvalho Chehab
Cc: linux-me...@vger.kernel.org
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Cc: devicetree@vger.kernel.org
Cc: Rob Landley
Cc: linux-...@vger.kernel.org
Cc: Tomasz Figa
---
v3:
- Rename compatible string to "img,ir-rev1" (Rob Herring).
- Specify ordering of clocks explicitly (Rob Herring).
v2:
- Future proof compatible string from "img,ir" to "img,ir1", where the 1
corresponds to the major revision number of the hardware (Tomasz
Figa).
- Added clock-names property and three specific clock names described in
the manual, only one of which is used by the current driver (Tomasz
Figa).
---
.../devicetree/bindings/media/img-ir-rev1.txt | 34 ++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/img-ir-rev1.txt
diff --git a/Documentation/devicetree/bindings/media/img-ir-rev1.txt
b/Documentation/devicetree/bindings/media/img-ir-rev1.txt
new file mode 100644
index 000..5434ce6
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/img-ir-rev1.txt
@@ -0,0 +1,34 @@
+* ImgTec Infrared (IR) decoder version 1
+
+This binding is for Imagination Technologies' Infrared decoder block,
+specifically major revision 1.
+
+Required properties:
+- compatible: Should be "img,ir-rev1"
+- reg: Physical base address of the controller and length of
+ memory mapped region.
+- interrupts: The interrupt specifier to the cpu.
+
+Optional properties:
+- clocks: List of clock specifiers as described in standard
+ clock bindings.
+ Up to 3 clocks may be specified in the following order:
+ 1st:Core clock (defaults to 32.768KHz if omitted).
+ 2nd:System side (fast) clock.
+ 3rd:Power modulation clock.
+- clock-names: List of clock names corresponding to the clocks
+ specified in the clocks property.
+ Accepted clock names are:
+ "core": Core clock.
+ "sys": System clock.
+ "mod": Power modulation clock.
+
+Example:
+
+ ir@02006200 {
+ compatible = "img,ir-rev1";
+ reg = <0x02006200 0x100>;
+ interrupts = <29 4>;
+ clocks = <&clk_32khz>;
+ clock-names = "core";
+ };
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 02/10] rc: img-ir: add base driver
Add base driver for the ImgTec Infrared decoder block. The driver is
split into separate components for raw (software) decode and hardware
decoder which are in following commits.
Signed-off-by: James Hogan
Cc: Mauro Carvalho Chehab
Cc: linux-me...@vger.kernel.org
Cc: Grant Likely
Cc: Rob Herring
Cc: devicetree@vger.kernel.org
---
v3:
- Use new compatible string "img,ir-rev1".
v2:
- Use new DT binding, with a different compatibility string and get core
clock by name.
- Remove next pointer from struct img_ir_priv. This is related to the
removal of dynamic registration/unregistration of protocol decode
timings from later patches.
- Add io.h include to img-ir.h.
---
drivers/media/rc/img-ir/img-ir-core.c | 176 ++
drivers/media/rc/img-ir/img-ir.h | 166
2 files changed, 342 insertions(+)
create mode 100644 drivers/media/rc/img-ir/img-ir-core.c
create mode 100644 drivers/media/rc/img-ir/img-ir.h
diff --git a/drivers/media/rc/img-ir/img-ir-core.c
b/drivers/media/rc/img-ir/img-ir-core.c
new file mode 100644
index 000..6b78348
--- /dev/null
+++ b/drivers/media/rc/img-ir/img-ir-core.c
@@ -0,0 +1,176 @@
+/*
+ * ImgTec IR Decoder found in PowerDown Controller.
+ *
+ * Copyright 2010-2014 Imagination Technologies Ltd.
+ *
+ * This contains core img-ir code for setting up the driver. The two interfaces
+ * (raw and hardware decode) are handled separately.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "img-ir.h"
+
+static irqreturn_t img_ir_isr(int irq, void *dev_id)
+{
+ struct img_ir_priv *priv = dev_id;
+ u32 irq_status;
+
+ spin_lock(&priv->lock);
+ /* we have to clear irqs before reading */
+ irq_status = img_ir_read(priv, IMG_IR_IRQ_STATUS);
+ img_ir_write(priv, IMG_IR_IRQ_CLEAR, irq_status);
+
+ /* don't handle valid data irqs if we're only interested in matches */
+ irq_status &= img_ir_read(priv, IMG_IR_IRQ_ENABLE);
+
+ /* hand off edge interrupts to raw decode handler */
+ if (irq_status & IMG_IR_IRQ_EDGE && img_ir_raw_enabled(&priv->raw))
+ img_ir_isr_raw(priv, irq_status);
+
+ /* hand off hardware match interrupts to hardware decode handler */
+ if (irq_status & (IMG_IR_IRQ_DATA_MATCH |
+ IMG_IR_IRQ_DATA_VALID |
+ IMG_IR_IRQ_DATA2_VALID) &&
+ img_ir_hw_enabled(&priv->hw))
+ img_ir_isr_hw(priv, irq_status);
+
+ spin_unlock(&priv->lock);
+ return IRQ_HANDLED;
+}
+
+static void img_ir_setup(struct img_ir_priv *priv)
+{
+ /* start off with interrupts disabled */
+ img_ir_write(priv, IMG_IR_IRQ_ENABLE, 0);
+
+ img_ir_setup_raw(priv);
+ img_ir_setup_hw(priv);
+
+ if (!IS_ERR(priv->clk))
+ clk_prepare_enable(priv->clk);
+}
+
+static void img_ir_ident(struct img_ir_priv *priv)
+{
+ u32 core_rev = img_ir_read(priv, IMG_IR_CORE_REV);
+
+ dev_info(priv->dev,
+"IMG IR Decoder (%d.%d.%d.%d) probed successfully\n",
+(core_rev & IMG_IR_DESIGNER) >> IMG_IR_DESIGNER_SHIFT,
+(core_rev & IMG_IR_MAJOR_REV) >> IMG_IR_MAJOR_REV_SHIFT,
+(core_rev & IMG_IR_MINOR_REV) >> IMG_IR_MINOR_REV_SHIFT,
+(core_rev & IMG_IR_MAINT_REV) >> IMG_IR_MAINT_REV_SHIFT);
+ dev_info(priv->dev, "Modes:%s%s\n",
+img_ir_hw_enabled(&priv->hw) ? " hardware" : "",
+img_ir_raw_enabled(&priv->raw) ? " raw" : "");
+}
+
+static int img_ir_probe(struct platform_device *pdev)
+{
+ struct img_ir_priv *priv;
+ struct resource *res_regs;
+ int irq, error, error2;
+
+ /* Get resources from platform device */
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(&pdev->dev, "cannot find IRQ resource\n");
+ return irq;
+ }
+
+ /* Private driver data */
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv) {
+ dev_err(&pdev->dev, "cannot allocate device data\n");
+ return -ENOMEM;
+ }
+ platform_set_drvdata(pdev, priv);
+ priv->dev = &pdev->dev;
+ spin_lock_init(&priv->lock);
+
+ /* Ioremap the registers */
+ res_regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ priv->reg_base = devm_ioremap_resource(&pdev->dev, res_regs);
+ if (IS_ERR(priv->reg_base))
+ return PTR_ERR(priv->reg_base);
+
+ /* Get core clock */
+ priv->clk = devm_clk_get(&pdev->dev, "core");
+ if (IS_ERR(priv->clk))
+ dev_warn(&pdev->dev, "cannot get core clock resource\n");
+ /*
+* The driver doesn't need to know about the system ("sys") or power
+* modulation ("mod") clocks yet
+*/
+
+ /* Set up raw & hw decoder */
+ error = img_ir_probe
[PATCH v4 00/10] media: rc: ImgTec IR decoder driver
Add a driver for the ImgTec Infrared decoder block. Two separate rc input devices are exposed depending on kernel configuration. One uses the hardware decoder which is set up with timings for a specific protocol and supports mask/value filtering and wake events. The other uses raw edge interrupts and the generic software protocol decoders to allow multiple protocols to be supported, including those not supported by the hardware decoder. The hardware decoder timing values, raw data to scan code conversion function and scan code filter to raw data filter conversion function are provided in separate files for each protocol which the main driver can use. The new generic scan code filter interface is made use of to reduce interrupts and control wake events. This patchset depends on the "rc: scancode filtering improvements" patchset. Changes in v4: Patchset: - Rebase on RC filtering improvements patchset, and fix to use new allowed/enabled protocol abstractions. - Drop first 5 patches for generic scancode filtering, which have already been applied. Hardware Decoder: - Depend on generic code to update normal filter on a protocol change. - Minimal support for wakeup_protocols by setting allowed and enabled wakeup protocols to match the enabled normal protocol on a protocol change (but only if the protocol has filtering support in the driver). Supporting a different wakeup protocol to the normal protocol is left as a task for another day. Changes in v3: DT bindings: - Rename compatible string to "img,ir-rev1" (Rob Herring). - Specify ordering of clocks explicitly (Rob Herring). Changes in v2: DT bindings: - Future proof compatible string from "img,ir" to "img,ir1", where the 1 corresponds to the major revision number of the hardware (Tomasz Figa). - Added clock-names property and three specific clock names described in the manual, only one of which is used by the current driver (Tomasz Figa). Misc: - Use spin_lock_irq() instead of spin_lock_irqsave() in various bits of code that aren't accessible from hard interrupt context. - Add io.h include to img-ir.h. Raw Decoder: - Echo the last sample after 150ms if no edges have been detected. This allows the soft decoder state machines to recognise the final space when no repeat code is received. - Avoid removal race by checking for RC device in ISR. Hardware Decoder: - Remove the dynamic registration and unregistration of protocol decoder timings. It didn't really get us much and it complicated locking and load ordering. - Simplify locking of decoders, they're now only modified when preprocessed, and all other use is after that, so preprocessing is the only place locking is required. - Use the new generic filtering interface rather than creating the sysfs files in the driver. This rearranges the code a bit, so as to use an array of 2 filters (normal and wake) rather than separate struct members for each, and passes the array index around between functions rather than the pointer to the filter. - Extend the scancode() decoder callback to handle full 32bit scancodes. Previously negative scancodes were treated specially, and indicated repeat codes or invalid raw data, but 32bit NEC may result in a scancode with the top bit set. Therefore change the scancode() return value to simply indicate success/fail/repeat, and add an extra scancode output pointer parameter that must have been written by the callback if it returns IMG_IR_SCANCODE. - Separate clock rate specific data in the decoder timings structure so that it can be more easily shared between instantiations of the driver. A new struct img_ir_reg_timings stores the calculated clock rate specific register values for the timings. This allows us to make more widespread use of const on decoder timings. - Make tolerance of hardware decoder timings configurable per protocol rather than being fixed at 10% for all protocols. This allows the tolerance of the Sharp protocol timings in particular to be increased. - Fix typo in img_ir_enable_wake (s/RC_FILTER_WAKUP/RC_FILTER_WAKEUP/). - Fix change_protocol to accept a zero protocol mask (for when "none" is written to /sys/class/rc/rcX/protocols). - Stop the end_timer (for keyups after repeat code timeout) safely on removal and protocol switch. - Fix rc_map.rc_type initialisation to use __ffs64(proto_mask). - Fix img_ir_allowed_protos() to return a protocol mask in a u64 rather than an unsigned long. - Use setup_timer() macro for the end timer rather than using init_timer() and setting function pointer and data explicitly. - Add a debug message for when the scancode() callback rejects the data. - Minor cosmetic changes (variable naming e.g. s/ir_dev/rdev/ in img_ir_set_protocol). NEC decoder: - Update scancode and filter callbacks to handle 32-bit NEC as used by Apple and TiVo remotes (the new 32-bit NEC scancode format is used, with the correct bit orientation). - Make it possible to set the
[PATCH 3/3] firmware: add Keystone QMSS PDSP accumulator firmware blob
From: Sandeep Nair QMSS(Queue Manager Sub System) uses PDSPs to implement various QM related functions like packet accumulation, QoS or event management. Patch adds firmware blob for the QMSS accumulator functionality. Cc: Greg Kroah-Hartman Cc: Kumar Gala Cc: Olof Johansson Cc: Arnd Bergmann Signed-off-by: Sandeep Nair Signed-off-by: Santosh Shilimkar --- firmware/Makefile |1 + .../keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw.ihex | 110 2 files changed, 111 insertions(+) create mode 100644 firmware/keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw.ihex diff --git a/firmware/Makefile b/firmware/Makefile index cbb09ce..c63df76 100644 --- a/firmware/Makefile +++ b/firmware/Makefile @@ -29,6 +29,7 @@ endif fw-shipped-$(CONFIG_ACENIC) += $(acenic-objs) fw-shipped-$(CONFIG_ADAPTEC_STARFIRE) += adaptec/starfire_rx.bin \ adaptec/starfire_tx.bin +fw-shipped-$(CONFIG_ARCH_KEYSTONE) += keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw fw-shipped-$(CONFIG_ATARI_DSP56K) += dsp56k/bootstrap.bin fw-shipped-$(CONFIG_ATM_AMBASSADOR) += atmsar11.fw fw-shipped-$(CONFIG_BNX2X) += bnx2x/bnx2x-e1-6.2.9.0.fw \ diff --git a/firmware/keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw.ihex b/firmware/keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw.ihex new file mode 100644 index 000..52a9c61 --- /dev/null +++ b/firmware/keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw.ihex @@ -0,0 +1,110 @@ +:1000210003008001310824E00E +:1000100081002280241117E081042280248003E0E3 +:10002000810022802EFF8B822400FF072400FF27FF +:100030002400FF472400FF6724002F2691182A8000 +:1000400024040082240002C25101E01B24440082E7 +:10005000240002C25102E01824840082240002C25B +:100060005103E01524C40082240002C25104E012AE +:1000700024040082240003C25105E00F24440082BE +:10008000240003C25106E00C24840082240003C231 +:100090005107E00924C40082240003C25108E0068D +:1000A00024DE008024FEE1C0240018E180E12A80E3 +:1000B00021002C002466244000E024E120 +:1000C504E0E080E02A816F00E0FE243000813A +:1000D000248001C1240018E080E02A810104E0E0CE +:1000E00024000881240100C180E02A811D004646C9 +:1000F000C91FFF031F1F1F00464601012626E1 +:1001693026022400202693002A88C907284B3C +:1001100069802818613008032400036821008C00DE +:1001200061200807052008E0D0E08403240004686B +:1001300021008C001CE0848421005100CE08E3FCE7 +:100140001C08E3E310080806090406E0090206E1BA +:100150E1E0E00140E0E092E02A89117F4646BC +:1001600051008D0223016C9E2400016821008C0047 +:100170006981281E244000E060E08B0324000668AB +:1001800021008C00613008032400036821008C00EA +:1001900061200807052008E0C8E084032400056802 +:1001A00021008C001EE0848421006D00D608E3FC51 +:1001B0001E08E3E3246C248D24CD21 +:1001C000D1014C03C9004C021F016C6C090408E00A +:1001D90208E100E1E0E00140E0E082E02A8974 +:1001E0002400016821008C006982280924E0B5 +:1001F000810022801F1F81042289248003E0E9 +:1002810022802400016821008C006983280479 +:1002100010E9E9C42400016821008C0069842804E5 +:1002200010E9E9E52400016821008C00240002683F +:10023000242881002A885100C4022301859EE1 +:10024000510085022301A19E23013D9E24064A +:10025000110F66E0690FE00323013D9E2100940029 +:1002600061200604052006E0C8E0843421009D00DA +:10027000C806E332117F4646090406E0090206E19A +:100280E1E0E00140E0F192F12A89D1026C2B1B +:100291018DE050CBE0200B058BE00902E0E08E +:1002A00090E02581D1054C07C88BE10F108B8B8E18 +:1002B0002300D69E01018DE050CBE0172100B9004C +:1002C00010E9E1EF2701EF8E51208E071C8EEFEF32 +:1002D08B8E8E2300D69E01018DE06ECBE0FA5E +:1002E0002100C500C9074606C9014C05D1004C02D2 +:1002F000D1016C03108C8CCD1F016C6CC9016C0E8C +:10035100CD04C900460C0501CDCD6900CD0AD0 +:1003100051008D09010006E16120E1040520E1E1C1 +:10032000910C23802100CB0091082380D0E1E002D2 +:1003300023011C9E82F12A894F1F066D511F06045E +:100341010606673006C321003B001026260681 +:10035000673006C021003B0010E2E2F0090206E02F +:10036006E0E00906E0E000E0F0F001018DCEDB +:100374CECBCE5100CE3E110C4C005104001CDB +:100380005108002F1904CECE09048EE0010CE0E0E4 +:1003900090E026925100F2367101CE0C90E0269347 +:1003A0006900F302240001CE7102CE0890E0269489 +:1003B0006900F402240002CE7103CE0490E0269579 +:1003C0006900F502240003CE09028DE1C9044C0244 +:1003D104E1E10902CE00EEE1D01200CE8D8DE4 +:1003E0001F0746465704CEE221011B001902CECE5C +:1003F9048EE00108E0E090E066925100F31CF1 +:1004108E8ED25101CE0490E066946900F50200 +:10041000240001CE108E8ED409038DE1C9044C0254 +:10042108E1E10903CE00EEE1D01200CE8D8D8E +:100430001F0746465702CECE21011B001901CECE22 +:100449048EE090E0E6925100F509108E8ED4FA +:100459048DE1C9044C020110E1E1E0E1F092F0 +:100461018D8D1F0746462100DB00209E04 +:1004700010E2E2F6090206E6E0E00906E0E02C +:100480E0F6F60B024CE01103E0E00102E0E1CF +:10049000C9044C04108D8DE0E100368021012D004F +:1004A0002EFF87922400010008E108E18DC0C2 +:1004B000EEC0D61210EAEAF7C9006C0308E1CBE0FF +:1004C0E0F7F701018DE008E1E098249030D8D2 +:1004D00013F0660027E00906E0E180E1A8963D +:1004E0001F026C
[PATCH 0/3] soc: Introduce drivers/soc and add Keystone QMSS driver
Based on earlier thread "https://lkml.org/lkml/2013/10/7/662"; and further discussion at Kernel Summit'2013, series creates 'driver/soc' for drivers which are very SOC specific. Then we add the Keystone QMSS (Queue Manager SubSystem) driver. The QMSS found on Keystone SOCs is one of the main hardware sub system which forms the backbone of the Keystone Multi-core Navigator. QMSS consist of queue managers, packed-data structure processors(PDSP), linking RAM, descriptor pools and infrastructure DMA. Sandeep Nair (2): soc: keystone: add QMSS driver firmware: add Keystone QMSS PDSP accumulator firmware blob Santosh Shilimkar (1): soc: Introduce drivers/soc place-holder for SOC specific drivers Cc: Greg Kroah-Hartman Cc: Kumar Gala Cc: Olof Johansson Cc: Arnd Bergmann Cc: Sandeep Nair Cc: Paul Walmsley .../devicetree/bindings/soc/keystone-qmss.txt | 209 +++ drivers/Kconfig|4 + drivers/Makefile |7 + drivers/soc/Kconfig|5 + drivers/soc/Makefile |5 + drivers/soc/keystone/Kconfig | 15 + drivers/soc/keystone/Makefile |5 + drivers/soc/keystone/qmss_acc.c| 591 drivers/soc/keystone/qmss_queue.c | 1533 drivers/soc/keystone/qmss_queue.h | 236 +++ firmware/Makefile |1 + .../keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw.ihex | 110 ++ include/linux/soc/keystone_qmss.h | 390 + 13 files changed, 3111 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/keystone-qmss.txt create mode 100644 drivers/soc/Kconfig create mode 100644 drivers/soc/Makefile create mode 100644 drivers/soc/keystone/Kconfig create mode 100644 drivers/soc/keystone/Makefile create mode 100644 drivers/soc/keystone/qmss_acc.c create mode 100644 drivers/soc/keystone/qmss_queue.c create mode 100644 drivers/soc/keystone/qmss_queue.h create mode 100644 firmware/keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw.ihex create mode 100644 include/linux/soc/keystone_qmss.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] soc: Introduce drivers/soc place-holder for SOC specific drivers
Based on earlier thread "https://lkml.org/lkml/2013/10/7/662"; and further discussion at Kernel Summit'2013, it was agreed to create 'driver/soc' for drivers which are quite SOC specific. Lets take the discussion forward with this patch. Cc: Greg Kroah-Hartman Cc: Kumar Gala Cc: Paul Walmsley Cc: Olof Johansson Cc: Arnd Bergmann Signed-off-by: Sandeep Nair Signed-off-by: Santosh Shilimkar --- drivers/Kconfig |2 ++ drivers/Makefile|4 drivers/soc/Kconfig |3 +++ 3 files changed, 9 insertions(+) create mode 100644 drivers/soc/Kconfig diff --git a/drivers/Kconfig b/drivers/Kconfig index b3138fb..37f955f 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -130,6 +130,8 @@ source "drivers/staging/Kconfig" source "drivers/platform/Kconfig" +source "drivers/soc/Kconfig" + source "drivers/clk/Kconfig" source "drivers/hwspinlock/Kconfig" diff --git a/drivers/Makefile b/drivers/Makefile index 8e3b8b0..0d8e2a4 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -132,6 +132,10 @@ obj-$(CONFIG_VHOST_RING) += vhost/ obj-$(CONFIG_VLYNQ)+= vlynq/ obj-$(CONFIG_STAGING) += staging/ obj-y += platform/ + +# SOC specific drivers +obj-y += soc/ + #common clk code obj-y += clk/ diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig new file mode 100644 index 000..2f9d7d0 --- /dev/null +++ b/drivers/soc/Kconfig @@ -0,0 +1,3 @@ +menu "SOC specific Drivers" + +endmenu -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma: Add Keystone Packet DMA Engine driver
On Friday 28 February 2014 17:56:40 Santosh Shilimkar wrote:
> The Packet DMA driver sets up the dma channels and flows for the
> QMSS(Queue Manager SubSystem) who triggers the actual data movements
> across clients using destination queues. Every client modules like
> NETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTO
> Engines has its own instance of packet dma hardware. QMSS has also
> an internal packet DMA module which is used as an infrastructure
> DMA with zero copy.
>
> Patch adds DMAEngine driver for Keystone Packet DMA hardware.
> The specifics on the device tree bindings for Packet DMA can be
> found in:
> Documentation/devicetree/bindings/dma/keystone-pktdma.txt
>
> The driver implements the configuration functions using standard DMAEngine
> apis. The data movement is managed by QMSS device driver.
The description of this sounds a bit like the x-gene queue manager/tag
manager, rather than a traditional DMA engine. For that driver, we
decided to use the mailbox subsystem instead of the DMA subsystem.
Can you explain what kind of data is actually getting transferred
in by your hardware here? You say the DMA is performed by the QMSS,
so do you use the pktdma driver to drive the data transfers of the
QMSS or do you just use it for flow control by passing short (a few
bytes) messages and also have to program the pktdma?
> +
> +bool dma_keystone_filter_fn(struct dma_chan *chan, void *param)
> +{
> + if (chan->device->dev->driver == &keystone_dma_driver.driver) {
> + struct keystone_dma_chan *kdma_chan = from_achan(chan);
> + unsigned chan_id = *(u32 *)param & KEYSTONE_DMA_CHAN_ID_MASK;
> + unsigned chan_type = *(u32 *)param >> KEYSTONE_DMA_TYPE_SHIFT;
> +
> + if (chan_type == KEYSTONE_DMA_TX_CHAN_TYPE &&
> + kdma_chan->direction == DMA_MEM_TO_DEV)
> + return chan_id == kdma_chan->channel;
> +
> + if (chan_type == KEYSTONE_DMA_RX_FLOW_TYPE &&
> + kdma_chan->direction == DMA_DEV_TO_MEM)
> + return chan_id == kdma_chan->flow;
> + }
> + return false;
> +}
> +EXPORT_SYMBOL_GPL(dma_keystone_filter_fn);
The filter function should be removed here and replaced with a simpler
custom xlate function calling dma_get_slave_chan() on the matching
channel.
> diff --git a/include/linux/keystone-pktdma.h b/include/linux/keystone-pktdma.h
> new file mode 100644
> index 000..e6a66c8
> --- /dev/null
> +++ b/include/linux/keystone-pktdma.h
> @@ -0,0 +1,168 @@
A DMA engine driver should not have a public API. Please move all the
contents of the two header files into the driver itself to ensure none
of this is visible to slave drivers. If it turns out that you use
declarations from this header in slave drivers at the moment, please
explain what they are so we can discuss alternative solutions.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 00/13] OMAP IOMMU DT adaptation for 3.15
* Suman Anna [140228 12:46]: > Hi Joerg, Tony, > > This is an updated series of the OMAP IOMMU DT adaptation intended > for 3.15 merge window, addressing the comments from the v2 series. > This series is rebased onto 3.14-rc4, and the only change to bindings > is to drop the dma-window property. > > The first 7 patches in the series are in drivers/iommu, with the first > 3 patches performing some cleanup. The DT bindings and adaptation are > done in patches 4 and 5. > > Tony, > Patches 8 through 13 are in arch/arm/mach-omap2 layer, so I am guessing > these would have to go through your tree. Of these, patches 8 and 9 are > cleanup fixes to get OMAP3 IVA MMU working, patches 10 & 11 are fixes > required with DT-boot for OMAP3/4, patches 12 & 13 add the OMAP5 support. Are patches 8 to 13 OK to apply separately from the iommu patches or do they need to wait for the iommu patches to get merged first? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dma: Add Keystone Packet DMA Engine driver
From: Sandeep Nair
The Packet DMA driver sets up the dma channels and flows for the
QMSS(Queue Manager SubSystem) who triggers the actual data movements
across clients using destination queues. Every client modules like
NETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTO
Engines has its own instance of packet dma hardware. QMSS has also
an internal packet DMA module which is used as an infrastructure
DMA with zero copy.
Patch adds DMAEngine driver for Keystone Packet DMA hardware.
The specifics on the device tree bindings for Packet DMA can be
found in:
Documentation/devicetree/bindings/dma/keystone-pktdma.txt
The driver implements the configuration functions using standard DMAEngine
apis. The data movement is managed by QMSS device driver.
Cc: Vinod Koul
Cc: Russell King
Cc: Grant Likely
Cc: Rob Herring
Cc: Mark Rutland
Signed-off-by: Sandeep Nair
Signed-off-by: Santosh Shilimkar
---
.../devicetree/bindings/dma/keystone-pktdma.txt| 72 ++
drivers/dma/Kconfig|8 +
drivers/dma/Makefile |1 +
drivers/dma/keystone-pktdma.c | 795
include/dt-bindings/dma/keystone.h | 33 +
include/linux/keystone-pktdma.h| 168 +
6 files changed, 1077 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/keystone-pktdma.txt
create mode 100644 drivers/dma/keystone-pktdma.c
create mode 100644 include/dt-bindings/dma/keystone.h
create mode 100644 include/linux/keystone-pktdma.h
diff --git a/Documentation/devicetree/bindings/dma/keystone-pktdma.txt
b/Documentation/devicetree/bindings/dma/keystone-pktdma.txt
new file mode 100644
index 000..ea061d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/keystone-pktdma.txt
@@ -0,0 +1,72 @@
+Keystone Packet DMA Controller
+
+This document explains the device tree bindings for the packet dma
+on keystone devices. The the Network coprocessor, Cypto engines
+and the SRIO on Keystone devices all have their own packet dma modules.
+Each individual packet dma has a certain number of RX channels,
+RX flows and TX channels. Each instance of the packet DMA is being
+initialized through device specific bindings.
+
+* DMA controller
+
+Required properties:
+ - compatible: Should be "ti,keystone-pktdma"
+ - reg: Should contain register location and length of the following pktdma
+ register regions. The value for "reg-names" property of the respective
+ region is specified in parenthesis.
+ - Global control register region (global).
+ - Tx DMA channel configuration register region (txchan).
+ - Rx DMA channel configuration register region (rxchan).
+ - Tx DMA channel Scheduler configuration register region (txsched).
+ - Rx DMA flow configuration register region (rxflow).
+ - reg-names: Names for the above regions. The name to be used is specified in
+ the above description of "reg" property.
+ - qm-base-address: Base address of the logical queue managers for pktdma.
+ - #dma-cells: Has to be 1. Keystone-pktdma doesn't support anything else.
+
+Optional properties:
+ - enable-all: Enable all DMA channels.
+ - loop-back: To loopback Tx streaming I/F to Rx streaming I/F. Used for
+ infrastructure transfers.
+ - rx-retry-timeout: Number of pktdma cycles to wait before retry on buffer
+starvation.
+
+Example:
+ netcp-dma: pktdma@2004000 {
+ compatible = "ti,keystone-pktdma";
+ reg = <0x2004000 0x100>,
+ <0x2004400 0x120>,
+ <0x2004800 0x300>,
+ <0x2004c00 0x120>,
+ <0x2005000 0x400>;
+ reg-names = "global", "txchan", "rxchan", "txsched",
+"rxflow";
+ qm-base-address = <0x23a8 0x23a9
+ 0x23aa 0x23ab>;
+ #dma-cells = <1>;
+ /* enable-all; */
+ rx-retry-timeout = <3500>;
+ /* loop-back; */
+ };
+
+
+* DMA client
+
+Required properties:
+- dmas: One DMA request specifier consisting of a phandle to the DMA controller
+ followed by the integer specifying the channel identifier. The channel
+ identifier is encoded as follows:
+ - bits 7-0: Tx DMA channel number or the Rx flow number.
+ - bits 31-24: Channel type. 0xff for Tx DMA channel & 0xfe for Rx flow.
+- dma-names: List of string identifiers for the DMA requests.
+
+Example:
+
+ netcp: netcp@209 {
+ ...
+ dmas = <&netcpdma KEYSTONE_DMA_RX_FLOW(22)>,
+ <&netcpdma KEYSTONE_DMA_RX_FLOW(23)>,
+ <&netcpdma KEYSTONE_DMA_TX_CHAN(8)>;
+ dma-names = "netrx0", "netrx1", "nettx";
+ ...
+ };
diff --git a/drivers/dma/Kconfig b/driver
Re: [PATCH] ARM: dts: am335x-evmsk: enable USB1
* yegorsli...@googlemail.com [140227 23:22]:
> From: Yegor Yefremov
>
> Enable second USB channel and set it into 'host' mode.
>
> Signed-off-by: Yegor Yefremov
Thanks applying into omap-for-v3.15/dt.
Tony
> ---
> arch/arm/boot/dts/am335x-evmsk.dts |9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
> b/arch/arm/boot/dts/am335x-evmsk.dts
> index 486880b..40a66bd 100644
> --- a/arch/arm/boot/dts/am335x-evmsk.dts
> +++ b/arch/arm/boot/dts/am335x-evmsk.dts
> @@ -342,9 +342,18 @@
> status = "okay";
> };
>
> + usb-phy@47401b00 {
> + status = "okay";
> + };
> +
> usb@47401000 {
> status = "okay";
> };
> +
> + usb@47401800 {
> + status = "okay";
> + dr_mode = "host";
> + };
> };
>
> &epwmss2 {
> --
> 1.7.7
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 0/9] USB Host support for OMAP5 uEVM
* Roger Quadros [140227 06:21]: > Hi, > > This patchset brings up USB Host ports and Ethernet port on > the OMAP5 uEVM board. > > It also does some cleanup with respect to DT clock binding > for the mfd/omap-usb-host driver. > > Please queue these for -next. > > Lee, > > I've folded some platform data dependent patches with mfd patches > so that they don't break functionality when applied individually. > You can safely pull in all MFD patches (1 to 6). > > Tony & Benoit, > > Can you please accept patches 7, 8 and 9? Are 7, 8 and 9 safe to queue separately from the MFD changes or do they need to wait for the MFD changes to get merged first? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] clk: ti: add support for default-rate property from DT
* Tero Kristo [140213 01:04]:
> default-rate property can now be used to define default rates for clocks,
> which get configured during boot.
>
> Signed-off-by: Tero Kristo
This can go with the drivers/clk patches as far as I'm concerned:
Acked-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/prm_common.c |2 ++
> drivers/clk/ti/clk.c |1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/prm_common.c
> b/arch/arm/mach-omap2/prm_common.c
> index b4c4ab9..4703545 100644
> --- a/arch/arm/mach-omap2/prm_common.c
> +++ b/arch/arm/mach-omap2/prm_common.c
> @@ -528,5 +528,7 @@ int __init of_prcm_init(void)
>
> ti_dt_clockdomains_setup();
>
> + of_clk_set_init_rates();
> +
> return 0;
> }
> diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
> index b1a6f71..23998b7 100644
> --- a/drivers/clk/ti/clk.c
> +++ b/drivers/clk/ti/clk.c
> @@ -156,6 +156,7 @@ void ti_dt_clk_init_provider(struct device_node *parent,
> int index)
> clk_init_cb = (of_clk_init_cb_t)match->data;
> pr_debug("%s: initializing: %s\n", __func__, np->name);
> clk_init_cb(np);
> + of_clk_parse_init_rate(np, NULL);
> }
>
> list_for_each_entry_safe(retry, tmp, &retry_list, link) {
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] ARM: dts: omap3-gta04: Add basic sound support.
* Marek Belisko [140125 13:31]:
Hmm care to add descriptions and repost the remaining patches
that I did not yet pick up for the fixes?
> Signed-off-by: NeilBrown
Hmm should this also have From: NeilBrown ?
Also, while at it, maybe change your long time habit of adding
a period to the end of the subject line? That is of course
if you don't insist on having it, it's not usually used if
you look at git log --pretty=oneline :)
Regards,
Tony
> ---
> arch/arm/boot/dts/omap3-gta04.dts | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-gta04.dts
> b/arch/arm/boot/dts/omap3-gta04.dts
> index 7e09410..a924a843 100644
> --- a/arch/arm/boot/dts/omap3-gta04.dts
> +++ b/arch/arm/boot/dts/omap3-gta04.dts
> @@ -36,6 +36,14 @@
> gpio-key,wakeup;
> };
> };
> +
> + sound {
> + compatible = "ti,omap-twl4030";
> + ti,model = "gta04";
> +
> + ti,mcbsp = <&mcbsp2>;
> + ti,codec = <&twl_audio>;
> + };
> };
>
> &omap3_pmx_core {
> @@ -79,6 +87,13 @@
> reg = <0x48>;
> interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> interrupt-parent = <&intc>;
> +
> + twl_audio: audio {
> + compatible = "ti,twl4030-audio";
> + codec {
> + };
> + };
> +
> vaux4: regulator-vaux4 {
> compatible = "ti,twl4030-vaux4";
> regulator-min-microvolt = <280>;
> --
> 1.8.3.2
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] ARM: dts: omap3-gta04: Add basic sound support.
* Belisko Marek [140228 14:42]: > Sure . Thanks for notice ;). It there possibility that missing patches > go to 3.15? Sure if you update them over next few days. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] ARM: dts: AM33XX: Add ecap interrupt properties
* Matt Porter [140129 13:02]: > Add missing interrupt properties to the ecap0, ecap1, and ecap2 > nodes. > > Signed-off-by: Matt Porter Thanks taking this patch only into omap-for-v3.15/dt, the rest should go via the driver mailing lists. Regards, Tony > --- > arch/arm/boot/dts/am33xx.dtsi | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi > index 6d95d3d..b4139ba 100644 > --- a/arch/arm/boot/dts/am33xx.dtsi > +++ b/arch/arm/boot/dts/am33xx.dtsi > @@ -582,6 +582,8 @@ > compatible = "ti,am33xx-ecap"; > #pwm-cells = <3>; > reg = <0x48300100 0x80>; > + interrupts = <31>; > + interrupt-names = "ecap0"; > ti,hwmods = "ecap0"; > status = "disabled"; > }; > @@ -610,6 +612,8 @@ > compatible = "ti,am33xx-ecap"; > #pwm-cells = <3>; > reg = <0x48302100 0x80>; > + interrupts = <47>; > + interrupt-names = "ecap1"; > ti,hwmods = "ecap1"; > status = "disabled"; > }; > @@ -638,6 +642,8 @@ > compatible = "ti,am33xx-ecap"; > #pwm-cells = <3>; > reg = <0x48304100 0x80>; > + interrupts = <61>; > + interrupt-names = "ecap2"; > ti,hwmods = "ecap2"; > status = "disabled"; > }; > -- > 1.8.4 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: OMAP3+: add clock nodes for CPU
* Tero Kristo [140220 09:00]:
> On 01/29/2014 08:19 PM, Nishanth Menon wrote:
> >OMAP34xx, AM3517 and OMAP36xx platforms use dpll1 clock.
> >
> >OMAP443x, OMAP446x, OMAP447x, OMAP5, DRA7, AM43xx platforms use
> >dpll_mpu clock.
> >
> >Latency used is the generic latency defined in omap-cpufreq
> >driver.
> >
> >Signed-off-by: Nishanth Menon
>
> Looks good to me.
>
> Acked-by: Tero Kristo
Thanks applying into omap-for-v3.15/dt.
Regards,
Tony
>
> >---
> > arch/arm/boot/dts/am33xx.dtsi |4
> > arch/arm/boot/dts/am4372.dtsi |5 +
> > arch/arm/boot/dts/dra7.dtsi |5 +
> > arch/arm/boot/dts/omap3.dtsi |5 +
> > arch/arm/boot/dts/omap4.dtsi |5 +
> > arch/arm/boot/dts/omap5.dtsi |6 ++
> > 6 files changed, 30 insertions(+)
> >
> >diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> >index 6d95d3d..4bbba26 100644
> >--- a/arch/arm/boot/dts/am33xx.dtsi
> >+++ b/arch/arm/boot/dts/am33xx.dtsi
> >@@ -58,6 +58,10 @@
> > 275000 1125000
> > >;
> > voltage-tolerance = <2>; /* 2 percentage */
> >+
> >+clocks = <&dpll_mpu_ck>;
> >+clock-names = "cpu";
> >+
> > clock-latency = <30>; /* From omap-cpufreq driver */
> > };
> > };
> >diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> >index c6bd4d9..33798d9 100644
> >--- a/arch/arm/boot/dts/am4372.dtsi
> >+++ b/arch/arm/boot/dts/am4372.dtsi
> >@@ -33,6 +33,11 @@
> > compatible = "arm,cortex-a9";
> > device_type = "cpu";
> > reg = <0>;
> >+
> >+clocks = <&dpll_mpu_ck>;
> >+clock-names = "cpu";
> >+
> >+clock-latency = <30>; /* From omap-cpufreq driver */
> > };
> > };
> >
> >diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> >index 1fd75aa..ce591e5 100644
> >--- a/arch/arm/boot/dts/dra7.dtsi
> >+++ b/arch/arm/boot/dts/dra7.dtsi
> >@@ -47,6 +47,11 @@
> > 100 106
> > 1176000 116
> > >;
> >+
> >+clocks = <&dpll_mpu_ck>;
> >+clock-names = "cpu";
> >+
> >+clock-latency = <30>; /* From omap-cpufreq driver */
> > };
> > cpu@1 {
> > device_type = "cpu";
> >diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> >index a5fc83b..01f2b3b 100644
> >--- a/arch/arm/boot/dts/omap3.dtsi
> >+++ b/arch/arm/boot/dts/omap3.dtsi
> >@@ -35,6 +35,11 @@
> > compatible = "arm,cortex-a8";
> > device_type = "cpu";
> > reg = <0x0>;
> >+
> >+clocks = <&dpll1_ck>;
> >+clock-names = "cpu";
> >+
> >+clock-latency = <30>; /* From omap-cpufreq driver */
> > };
> > };
> >
> >diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> >index d3f8a6e..ce87996 100644
> >--- a/arch/arm/boot/dts/omap4.dtsi
> >+++ b/arch/arm/boot/dts/omap4.dtsi
> >@@ -36,6 +36,11 @@
> > device_type = "cpu";
> > next-level-cache = <&L2>;
> > reg = <0x0>;
> >+
> >+clocks = <&dpll_mpu_ck>;
> >+clock-names = "cpu";
> >+
> >+clock-latency = <30>; /* From omap-cpufreq driver */
> > };
> > cpu@1 {
> > compatible = "arm,cortex-a9";
> >diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> >index a72813a..8bb4134 100644
> >--- a/arch/arm/boot/dts/omap5.dtsi
> >+++ b/arch/arm/boot/dts/omap5.dtsi
> >@@ -49,6 +49,12 @@
> > 100 106
> > 150 125
> > >;
> >+
> >+clocks = <&dpll_mpu_ck>;
> >+clock-names = "cpu";
> >+
> >+clock-latency = <30>; /* From omap-cpufreq driver */
> >+
> > /* cooling options */
> > cooling-min-level = <0>;
> > cooling-max-level = <2>;
> >
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/9] ARM: dts: omap3-gta04: Add basic sound support.
Hi Tony,
On Fri, Feb 28, 2014 at 11:25 PM, Tony Lindgren wrote:
> * Marek Belisko [140125 13:31]:
>
> Hmm care to add descriptions and repost the remaining patches
> that I did not yet pick up for the fixes?
Sure I'll do.
>
>> Signed-off-by: NeilBrown
>
> Hmm should this also have From: NeilBrown ?
Maybe I did some changes and forgot add my Signed-off-by? I'll recheck.
>
> Also, while at it, maybe change your long time habit of adding
> a period to the end of the subject line? That is of course
> if you don't insist on having it, it's not usually used if
> you look at git log --pretty=oneline :)
Sure . Thanks for notice ;). It there possibility that missing patches
go to 3.15?
>
> Regards,
>
> Tony
>
>> ---
>> arch/arm/boot/dts/omap3-gta04.dts | 15 +++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap3-gta04.dts
>> b/arch/arm/boot/dts/omap3-gta04.dts
>> index 7e09410..a924a843 100644
>> --- a/arch/arm/boot/dts/omap3-gta04.dts
>> +++ b/arch/arm/boot/dts/omap3-gta04.dts
>> @@ -36,6 +36,14 @@
>> gpio-key,wakeup;
>> };
>> };
>> +
>> + sound {
>> + compatible = "ti,omap-twl4030";
>> + ti,model = "gta04";
>> +
>> + ti,mcbsp = <&mcbsp2>;
>> + ti,codec = <&twl_audio>;
>> + };
>> };
>>
>> &omap3_pmx_core {
>> @@ -79,6 +87,13 @@
>> reg = <0x48>;
>> interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>> interrupt-parent = <&intc>;
>> +
>> + twl_audio: audio {
>> + compatible = "ti,twl4030-audio";
>> + codec {
>> + };
>> + };
>> +
>> vaux4: regulator-vaux4 {
>> compatible = "ti,twl4030-vaux4";
>> regulator-min-microvolt = <280>;
>> --
>> 1.8.3.2
>>
BR,
marek
--
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 3/3] mmc: sdhci-msm: Add platform_execute_tunning implementation
On 28.02.14, 22:51, Josh Cartwright wrote:
[..]
>> +sg_init_one(&sg, data_buf, sizeof(data_buf));
>> +memset(data_buf, 0, sizeof(data_buf));
>> +mmc_wait_for_req(mmc, &mrq);
>> +
>> +if (!cmd.error && !data.error &&
>> +!memcmp(data_buf, tuning_block_pattern, sizeof(data_buf))) {
>
> This memcmp is broken, sizeof(data_buf) is likely not what you want,
> maybe you want 'size'? Same thing for sg_init_one()/memset() above.
>
> From sparse:
>
> drivers/mmc/host/sdhci-msm.c: In function ‘sdhci_msm_execute_tuning’:
> drivers/mmc/host/sdhci-msm.c:461:53: warning: argument to ‘sizeof’ in
> ‘memcmp’ call is the same expression as the first source; did you mean to
> provide an explicit length? [-Wsizeof-pointer-memaccess]
>!memcmp(data_buf, tuning_block_pattern, sizeof(data_buf))) {
>
Nice catch, Josh! Thanks for reviewing!
BR,
Georgi
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/4] ARM: OMAP2+: add legacy display for omap3 DBB056
* Tomi Valkeinen [140214 06:38]: > Hi, > > On 14/02/14 16:20, Christoph Fritz wrote: > > Full device tree support for omapdss is not yet accomplished. Until > > then, init display by legacy platform code. > > > > Signed-off-by: Christoph Fritz > > --- > > arch/arm/mach-omap2/dss-common.c | 49 > > > > arch/arm/mach-omap2/dss-common.h |1 + > > arch/arm/mach-omap2/pdata-quirks.c |8 +- > > 3 files changed, 57 insertions(+), 1 deletion(-) > > I'm not nack'ing this, but I'm again hoping to get DSS DT support for > 3.15. I haven't done any bigger changes to my branch for some time now, > and I'm just waiting to get some comments/acks for the bindings. > > So I suggest to also try out DSS DT for your board, based on the latest > DSS DT branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt > > That way you have it ready and tested if DSS DT goes forward. Applying only patches 1 & 2 into omap-for-v3.15/dt thanks. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] ARM: OMAP2+: Add pdata quirk for sys_clkout2 for omap3 DBB056
* Christoph Fritz [140214 06:24]:
> Full device tree support for clock control, especially to set frequencies,
> is not yet accomplished. Until then, configure the 24Mhz of sys_clkout2 to
> feed an USB-Hub here.
Hmm would like to see Tero's comments on this, I wonder if we should
wait on this to avoid extra churn?
Regards,
Tony
> Signed-off-by: Christoph Fritz
> ---
> arch/arm/mach-omap2/pdata-quirks.c | 37
>
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/pdata-quirks.c
> b/arch/arm/mach-omap2/pdata-quirks.c
> index 435a823..e36ac3f 100644
> --- a/arch/arm/mach-omap2/pdata-quirks.c
> +++ b/arch/arm/mach-omap2/pdata-quirks.c
> @@ -172,6 +172,43 @@ static void __init am3517_evm_legacy_init(void)
>
> static void __init omap3_dbb056_legacy_init(void)
> {
> + struct clk *clkout2;
> + struct clk *cm96fck;
> +
> + /* Reparent clkout2 to 96M_FCK */
> + pr_info("%s: Late Reparent clkout2 to 96M_FCK\n", __func__);
> + clkout2 = clk_get(NULL, "clkout2_src_ck");
> + if (clkout2 < 0) {
> + pr_err("a83x-quirk: couldn't get clkout2_src_ck\n");
> + return;
> + }
> + cm96fck = clk_get(NULL, "cm_96m_fck");
> + if (cm96fck < 0) {
> + pr_err("a83x-quirk: couldn't get cm_96m_fck\n");
> + return;
> + }
> + if (clk_set_parent(clkout2, cm96fck) < 0) {
> + pr_err("a83x-quirk: couldn't reparent clkout2_src_ck\n");
> + return;
> + }
> +
> + /* Set clkout2 to 24MHz for internal usb hub*/
> + pr_info("%s: Set clkout2 to 24MHz for internal usb hub\n", __func__);
> + clkout2 = clk_get(NULL, "sys_clkout2");
> + if (clkout2 < 0) {
> + pr_err("%s: couldn't get sys_clkout2\n", __func__);
> + return;
> + }
> + if (clk_set_rate(clkout2, 2400) < 0) {
> + pr_err("%s: couldn't set sys_clkout2 rate\n", __func__);
> + return;
> + }
> + if (clk_prepare_enable(clkout2) < 0) {
> + pr_err("%s: couldn't enable sys_clkout2\n", __func__);
> + return;
> + }
> +
> + /* Initialize display */
> omap3_dbb056_display_init_of();
> }
> #endif /* CONFIG_ARCH_OMAP3 */
> --
> 1.7.10.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/9] ARM: DTS: OMAP: Audio related cleanups for dtsi and dts files
* Peter Ujfalusi [140124 00:21]: > Hi Benoit, > > OMAP: Put the audio nodes to disabled styate by default and board dts files > should > enable the nodes which is used on the board. > > am335x: correct the audio mclk clock. This patch has been marked to go to 3.13 > stable as well. Looks like these should get merged, assuming Benoit did not pick them up yet so applying into omap-for-v3.15/dt. Regards, Tony > Peter Ujfalusi (9): > ARM: DTS: omap4-panda-common: Move audio related pinmux to respective > nodes > ARM: DTS: omap4-sdp: Move audio related pinmux to respective nodes > ARM: DTS: omap4: Set all audio related IP's status to disabled as > default > ARM: DTS: omap4-panda-common: No need to disable the unused audio > nodes > ARM: DTS: omap4-sdp: No need to disable mcbsp3 node > ARM: DTS: omap5: Set all audio related IP's status to disabled as > default > ARM: DTS: omap3: Set disabled status for McBSP instances as default > state > ARM: DTS: omap2: Set disabled status for McBSP instances as default > state > ARM: DTS: am335x-evmsk: Correct audio clock frequency > > arch/arm/boot/dts/am335x-evmsk.dts| 2 +- > arch/arm/boot/dts/omap2420.dtsi | 2 ++ > arch/arm/boot/dts/omap2430.dtsi | 5 + > arch/arm/boot/dts/omap3-beagle-xm.dts | 4 > arch/arm/boot/dts/omap3-beagle.dts| 4 > arch/arm/boot/dts/omap3-devkit8000.dts| 16 ++- > arch/arm/boot/dts/omap3-igep.dtsi | 1 + > arch/arm/boot/dts/omap3-overo.dtsi| 4 > arch/arm/boot/dts/omap3.dtsi | 5 + > arch/arm/boot/dts/omap4-panda-common.dtsi | 23 ++--- > arch/arm/boot/dts/omap4-sdp.dts | 33 > --- > arch/arm/boot/dts/omap4.dtsi | 6 ++ > arch/arm/boot/dts/omap5.dtsi | 5 + > 13 files changed, 77 insertions(+), 33 deletions(-) > > -- > 1.8.5.3 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: add BeagleBone Audio Cape (Rev A) dtsi
* Jack Mitchell [140122 03:09]:
> From: Jack Mitchell
>
> Devicetree include file for setting up the am335x mcasp bus, i2c-2
> bus, and audio codec required for a functioning BeagleBone Audio Cape.
>
> Signed-off-by: Jack Mitchell
> Signed-off-by: Matt Porter
> ---
> arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi | 124
> +
> arch/arm/boot/dts/am335x-bone-common.dtsi | 14 +++
> 2 files changed, 138 insertions(+)
> create mode 100644 arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
>
> diff --git a/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
> b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
> new file mode 100644
> index 000..b8ec3dc
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-bone-audio-cape-reva.dtsi
> @@ -0,0 +1,124 @@
> +/*
> + * Copyright (C) 2014 Jack Mitchell
> + *
> + * 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.
> + *
> + * In order to enable the BeagleBone Audio Cape this dtsi must be
> + * incuded in the top level dts. On BeagleBone Black hardware the
> + * status of the HDMI dts node must also be set to "disabled".
Seems like this is unsafe to merge then? This probably also needs
comments from Peter Ujfalusi, added him to Cc.
Regards,
Tony
> + * --- a/arch/arm/boot/dts/am335x-bone.dts
> + * +++ b/arch/arm/boot/dts/am335x-bone.dts
> + * @@ -9,6 +9,7 @@
> + *
> + * #include "am33xx.dtsi"
> + * #include "am335x-bone-common.dtsi"
> + * +#include "am335x-bone-audio-cape-reva.dtsi"
> + *
> + * &ldo3_reg {
> + * regulator-min-microvolt = <180>;
> + *
> + * On BeagleBone Black hardware the status of the HDMI dts node must
> + * also be set to "disabled"
> + *
> + * --- a/arch/arm/boot/dts/am335x-boneblack.dts
> + * +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> + * @@ -73,6 +74,6 @@
> + * pinctrl-names = "default", "off";
> + * pinctrl-0 = <&nxp_hdmi_bonelt_pins>;
> + * pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>;
> + * - status = "okay";
> + * + status = "disabled";
> + * };
> + * };
> + */
> +
> +/ {
> + sound {
> + compatible = "ti,da830-evm-audio";
> + ti,model = "AM335x BeagleBone Audio Cape Rev. A";
> + ti,audio-codec = <&tlv320aic3106>;
> + ti,mcasp-controller = <&mcasp0>;
> + ti,codec-clock-rate = <1200>;
> + ti,audio-routing =
> + "Headphone Jack", "HPLOUT",
> + "Headphone Jack", "HPROUT",
> + "LINE1L", "Line In",
> + "LINE1R", "Line In";
> + };
> +
> + audio-cape-gpio-leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&bone_audio_cape_led_pins>;
> +
> + audio-led0 {
> + label = "audio:green:usr0";
> + gpios = <&gpio1 18 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + default-state = "off";
> + };
> +
> + audio-led1 {
> + label = "audio:green:usr1";
> + gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "mmc0";
> + default-state = "off";
> + };
> + };
> +};
> +
> +&am33xx_pinmux {
> + bone_audio_cape_led_pins: pinmux_bone_audio_cape_led_pins {
> + pinctrl-single,pins = <
> + 0x48 (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
> gpmc_a2.gpio1_18 */
> + 0x4c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
> gpmc_a3.gpio1_19 */
> + >;
> + };
> +
> + bone_audio_cape_pins: bone_audio_cape_pins {
> + pinctrl-single,pins = <
> + 0x190 (PIN_INPUT_PULLUP | MUX_MODE0)/*
> mcasp0_aclkx.mcasp0_aclkx */
> + 0x194 (PIN_INPUT_PULLUP | MUX_MODE0)/*
> mcasp0_fsx.mcasp0_fsx */
> + 0x19c (PIN_INPUT_PULLUP | MUX_MODE2)/*
> mcasp0_ahclkr.mcasp0_axr2 */
> + 0x1ac (PIN_INPUT_PULLUP | MUX_MODE2)/*
> mcasp0_ahclkx.mcasp0_axr3 */
> + >;
> + };
> +};
> +
> +&i2c2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c2_pins>;
> +
> + status = "okay";
> + clock-frequency = <10>;
> +
> + tlv320aic3106: tlv320aic3106@1b {
> + compatible = "ti,tlv320aic3106";
> + reg = <0x1b>;
> + status = "okay";
> +
> + /* Regulators */
> + AVDD-supply = <&vmmcsd_fixed>;
> + IOVDD-supply = <&vmmcsd_fixed>;
> + DRVDD-supply = <&vmmcsd_fixed>;
> + DVDD-supply = <&vdd1v8_fixed>;
> + };
> +};
> +
> +&mcasp0 {
> + pinctrl-names = "default";
> + pinctrl-0
Re: [PATCH 0/3] OMAP hwspinlock DT updates
* Suman Anna [140113 16:29]: > Hi, > > This series updates the existing OMAP hwspinlock DT nodes to have a > #hwlock-cells property as suggested by Mark Rutland [1], and adds the > hwspinlock nodes for two other newer SoCs - DRA7xx and AM43xx. > > Posting the series separately from the driver DT adapation changes [2] > to avoid maintainer confusion. Thanks applying into omap-for-v3.15/dt. Tony > [1] http://marc.info/?l=linux-omap&m=138433541420926&w=2 > [2] http://marc.info/?l=linux-omap&m=138965904015225&w=2 > > Suman Anna (3): > ARM: dts: OMAP: Add #hwlock-cells property to hwspinlock nodes > ARM: dts: DRA7: Add hwspinlock node > ARM: dts: AM4372: Add hwspinlock node > > arch/arm/boot/dts/am33xx.dtsi | 1 + > arch/arm/boot/dts/am4372.dtsi | 7 +++ > arch/arm/boot/dts/dra7.dtsi | 7 +++ > arch/arm/boot/dts/omap4.dtsi | 1 + > arch/arm/boot/dts/omap5.dtsi | 1 + > 5 files changed, 17 insertions(+) > > -- > 1.8.4.3 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 3/3] mmc: sdhci-msm: Add platform_execute_tunning implementation
On 28.02.14, 18:51, Kumar Gala wrote: > > On Feb 28, 2014, at 5:24 AM, Georgi Djakov wrote: > >> This patch adds implementation for platform specific tuning in order to >> support >> HS200 bus speed mode on Qualcomm SDHCI controller. >> >> Signed-off-by: Asutosh Das >> Signed-off-by: Venkat Gopalakrishnan >> Signed-off-by: Georgi Djakov >> --- >> drivers/mmc/host/sdhci-msm.c | 424 >> +- >> 1 file changed, 418 insertions(+), 6 deletions(-) > > minor nit, in subject (platform_execute_tuning, with one ’n’). > > - k Oh, of course! Thanks! BR, Georgi -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Add more device nodes for am43x-epos-evm
* Sourav Poddar [131205 01:50]: > On Wednesday 27 November 2013 01:00 PM, Sourav Poddar wrote: > >The patch series adds support for enabling pwm backlight, i2c2, spi and > >matrix gpio keys on am43x-gp-evm. > > > >Done on top of 3.13-rc1 + tero clock series(1) > > > >[1]: https://patchwork.kernel.org/patch/3009541/ > > > >Tested on am43x-gp-evm. > > > >There is a some bug while using regulators through backlight > >driver on 3.13-rc1. So, tested pwm part with this temporary patch[2]. > > > >[2]: http://www.spinics.net/lists/arm-kernel/msg288215.html > > > >Darren Etheridge (1): > > pinctrl: am43xx: dt-bindings: add MUX_MODE8 > > > >Sourav Poddar (4): > > arm: dts: am4372: Add pwm-cellsproperty for ecap device. > > arm: dts: am43x-epos-evm: Add I2C data. > > arm: dts: am43x-epos-evm: Add SPI data. > > ARM: dts: am43x-epos-evm: Add pwm backlight support. > > > > arch/arm/boot/dts/am4372.dtsi|9 + > > arch/arm/boot/dts/am43x-epos-evm.dts | 67 > > ++ > > include/dt-bindings/pinctrl/am43xx.h |1 + > > 3 files changed, 77 insertions(+), 0 deletions(-) > > > gentle ping on this.. FYI at least I don't even have these patches in my inbox any longer, so hopefully Benoit queues them. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: omap3 clocks: simplify ssi aliases
* Tero Kristo [140214 05:50]: > On 02/14/2014 03:25 AM, Sebastian Reichel wrote: > >On Thu, Feb 13, 2014 at 02:49:14PM -0800, Tony Lindgren wrote: > >>* Sebastian Reichel [140121 06:39]: > >>>update aliases for the ssi clocks ssi_ssr_fck, ssi_sst_fck and ssi_ick > >>>to make them consistent for omap34xx and omap36xx. This makes it > >>>possible to reference the clocks from generic omap3 dts files. > >> > >>Is this needed as a fix for v3.14-rc? If so, please let me know > >>and ack if you want me to take it. > > > >The SSI driver will not arrive before 3.15 and 3.14 dts files do not > >contain any SSI nodes. > > > >Thus it should be enough to queue it for 3.15 if it goes via the > >same tree as the SSI dts patches. > > > >-- Sebastian > > > > The patch itself looks good to me, so acked. Thanks applying into omap-for-v3.15/dt with Tero's ack. Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 2/4] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
* Sricharan R [140205 06:13]: > Tony, > > On Wednesday 05 February 2014 06:41 PM, Sricharan R wrote: > > On Tuesday 04 February 2014 09:44 PM, Thomas Gleixner wrote: > >> On Mon, 3 Feb 2014, Sricharan R wrote: > I already have your reviewed-by tag for the first patch in this series. > > Kevin was pointing out that irqchip maintainer tag is needed for this > patch as well > to be merged. We are planning to take this series through arm-soc tree. > > Can i please have your tag for this patch as well ? > >> > >> Acked-by-me > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in > >> the body of a message to majord...@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > Thanks Thomas. > > > > Kevin, > > I will re-send a branch based on rc1 for this. > > > > I have pushed a branch based on mainline, >git://github.com/Sricharanti/sricharan.git >branch: crossbar_3.14_rc1 OK pulling into omap-for-v3.15/crossbar thanks. Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: DTS: AM43x: Add DSS node
* Sathya Prakash M R [131203 00:35]:
> Add device node for DSS module for AM4372. Both the
> AM437x-Gp evm and Am43x-Epos evm use the same LCD panel.
> The lcd timings are added in respective dts files.
> Adds display pinctrl and enables required gpio.
> Also set the right parent clock to the DSS clock.
This seems to depend on Tomi's patches for the bindings, so it seems
like we need to wait on this a bit. I'll untag this for now, please
repost when the dependencies are merged.
Regards,
Tony
> Signed-off-by: Sathya Prakash M R
> ---
> arch/arm/boot/dts/am4372.dtsi| 28 ++
> arch/arm/boot/dts/am437x-gp-evm.dts | 68
> ++
> arch/arm/boot/dts/am43x-epos-evm.dts | 64
> arch/arm/boot/dts/am43xx-clocks.dtsi |2 +
> 4 files changed, 162 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index ea55a4e..b72a7df 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -684,6 +684,34 @@
> num-cs = <4>;
> status = "disabled";
> };
> +
> + dss: dss@4832A000 {
> + compatible = "ti,omap3-dss", "simple-bus";
> + reg = <0x4832A000 0x200>;
> + ti,hwmods = "dss_core";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + dispc@4832A400 {
> + compatible = "ti,omap3-dispc";
> + reg = <0x4832A400 0x400>;
> + interrupts = ;
> + ti,hwmods = "dss_dispc";
> + };
> +
> + dpi: encoder@0 {
> + compatible = "ti,omap3-dpi";
> + };
> +
> + rfbi: rfbi@4832A800 {
> + compatible = "ti,omap3-rfbi";
> + reg = <0x4832A800 0x100>;
> + ti,hwmods = "dss_rfbi";
> + };
> +
> + };
> +
> };
>
> clocks {
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
> b/arch/arm/boot/dts/am437x-gp-evm.dts
> index 2e79bda..e58652c6 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
> @@ -24,6 +24,31 @@
> brightness-levels = <0 51 53 56 62 75 101 152 255>;
> default-brightness-level = <8>;
> };
> +
> + aliases {
> + display0 = &lcd0;
> + };
> +
> + lcd0: display@0 {
> + compatible = "osddisplays,osd057T0559-34ts", "panel-dpi";
> + video-source = <&dpi>;
> + data-lines = <24>;
> + panel-timing {
> + clock-frequency = <3300>;
> + hactive = <800>;
> + vactive = <480>;
> + hfront-porch = <210>;
> + hback-porch = <16>;
> + hsync-len = <30>;
> + vback-porch = <10>;
> + vfront-porch = <22>;
> + vsync-len = <13>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + de-active = <1>;
> + pixelclk-active = <1>;
> + };
> + };
> };
>
> &am43xx_pinmux {
> @@ -46,6 +71,40 @@
> 0x164 MUX_MODE0 /*
> eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
> >;
> };
> +
> + dss_pinctrl: dss_pinctrl {
> + pinctrl-single,pins = <
> + 0x020 (PIN_OUTPUT_PULLUP | MUX_MODE1) /*gpmc ad 8 ->
> DSS DATA 23 */
> + 0x024 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> + 0x028 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> + 0x02C (PIN_OUTPUT_PULLUP | MUX_MODE1)
> + 0x030 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> + 0x034 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> + 0x038 (PIN_OUTPUT_PULLUP | MUX_MODE1)
> + 0x03C (PIN_OUTPUT_PULLUP | MUX_MODE1) /*gpmc ad 15 ->
> DSS DATA 16 */
> + 0x0A0 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS DATA 0 */
> + 0x0A4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> + 0x0A8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> + 0x0AC (PIN_OUTPUT_PULLUP | MUX_MODE0)
> + 0x0B0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> + 0x0B4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> + 0x0B8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> + 0x0BC (PIN_OUTPUT_PULLUP | MUX_MODE0)
> + 0x0C0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> + 0x0C4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
> + 0x0C8 (PIN_OUTPUT_PULLUP | MUX_MODE0
[PATCH 1/2] leds: add DT support for LEDs wired to supply and default brightness
Some PWM outputs are wired such that the LED they're controlling is
connected to supply rather than ground. Therefore, the duty cycle
needs to be inverted to make the LED behave as it should do.
We also provide a way to specify the default brightness when a
trigger is not specified.
Signed-off-by: Russell King
---
Documentation/devicetree/bindings/leds/leds-pwm.txt | 3 +++
drivers/leds/leds-pwm.c | 15 +++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.txt
b/Documentation/devicetree/bindings/leds/leds-pwm.txt
index 7297107cf832..ffcb74ab61fd 100644
--- a/Documentation/devicetree/bindings/leds/leds-pwm.txt
+++ b/Documentation/devicetree/bindings/leds/leds-pwm.txt
@@ -13,6 +13,9 @@ node's name represents the name of the corresponding LED.
For the pwms and pwm-names property please refer to:
Documentation/devicetree/bindings/pwm/pwm.txt
- max-brightness : Maximum brightness possible for the LED
+- default-brightness : (optional) Default brightness for the LED
+- active-low : (optional) For PWMs where the LED is wired to supply
+ rather than ground.
- label : (optional)
see Documentation/devicetree/bindings/leds/common.txt
- linux,default-trigger : (optional)
diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 605047428b5a..fe2cd849b593 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -70,6 +70,10 @@ static void led_pwm_set(struct led_classdev *led_cdev,
duty *= brightness;
do_div(duty, max);
+
+ if (led_dat->active_low)
+ duty = led_dat->period - duty;
+
led_dat->duty = duty;
if (led_dat->can_sleep)
@@ -93,6 +97,10 @@ static int led_pwm_create_of(struct platform_device *pdev,
for_each_child_of_node(pdev->dev.of_node, child) {
struct led_pwm_data *led_dat = &priv->leds[priv->num_leds];
+ led_dat->cdev.brightness_set = led_pwm_set;
+ led_dat->cdev.brightness = LED_OFF;
+ led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
+
led_dat->cdev.name = of_get_property(child, "label",
NULL) ? : child->name;
@@ -110,10 +118,9 @@ static int led_pwm_create_of(struct platform_device *pdev,
"linux,default-trigger", NULL);
of_property_read_u32(child, "max-brightness",
&led_dat->cdev.max_brightness);
-
- led_dat->cdev.brightness_set = led_pwm_set;
- led_dat->cdev.brightness = LED_OFF;
- led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
+ of_property_read_u32(child, "default-brightness",
+&led_dat->cdev.brightness);
+ led_dat->active_low = of_property_read_bool(child,
"active-low");
led_dat->can_sleep = pwm_can_sleep(led_dat->pwm);
if (led_dat->can_sleep)
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: add support for Cubox-i PWM-driven front panel LED
The front panel LED on the Cubox-i is driven by one of the iMX6 PWM
channels, and is wired between the PWM output and supply. This means
that outputting a low level results in the LED being turned on, so we
need the duty cycle inverted.
There's a question about whether the output inversion should be at the
pwm or pwm-leds level - setting the output inversion bit in the iMX6
results in a PWM duty cycle of zero outputting logic zero, meaning that
the LED is fully on. This is undesirable, as it becomes impossible to
turn the LED fully off.
Signed-off-by: Russell King
---
arch/arm/boot/dts/imx6qdl-cubox-i.dtsi | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
index c2a24888a276..7971387c2e13 100644
--- a/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-cubox-i.dtsi
@@ -12,6 +12,20 @@
pinctrl-0 = <&pinctrl_cubox_i_ir>;
};
+ pwmleds {
+ compatible = "pwm-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_cubox_i_pwm1>;
+
+ front {
+ active-low;
+ default-brightness = <128>;
+ label = "imx6:red:front";
+ max-brightness = <248>;
+ pwms = <&pwm1 0 5>;
+ };
+ };
+
regulators {
compatible = "simple-bus";
@@ -82,6 +96,10 @@
>;
};
+ pinctrl_cubox_i_pwm1: cubox-i-pwm1-front-led {
+ fsl,pins = ;
+ };
+
pinctrl_cubox_i_spdif: cubox-i-spdif {
fsl,pins = ;
};
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] phy-rcar-gen2-usb: add device tree support
Hello.
On 02/27/2014 06:56 PM, Mark Rutland wrote:
Add support of the device tree probing for the Renesas R-Car generation 2 SoCs
documenting the device tree binding as necessary.
Signed-off-by: Sergei Shtylyov
---
This patch is against the 'next' branch of Felipe Balbi's 'usb.git' repo.
Documentation/devicetree/bindings/usb/rcar-gen2-phy.txt | 29 +++
drivers/usb/phy/phy-rcar-gen2-usb.c | 64
++--
2 files changed, 85 insertions(+), 8 deletions(-)
Index: usb/Documentation/devicetree/bindings/usb/rcar-gen2-phy.txt
===
--- /dev/null
+++ usb/Documentation/devicetree/bindings/usb/rcar-gen2-phy.txt
@@ -0,0 +1,29 @@
+* Renesas R-Car generation 2 USB PHY
+
+This file provides information on what the device node for the R-Car generation
+2 USB PHY contains.
+
+Required properties:
+- compatible: "renesas,usb-phy-r8a7790" if the device is a part of R8A7790 SoC.
+ "renesas,usb-phy-r8a7791" if the device is a part of R8A7791 SoC.
Is the r8a7791's USB PHY known to be different to that of the r8a7790?
Not at all, according to the preliminary manuals. The problem is the
SH-Mobile maintainers don't trust the manuals (translated from Japanese, they
are sometimes indeed of a questionable quality).
If this is just to possibly handle the two differently in future, why
not have "renesas,usb-phy-r8a7790" as a fallback in the compatible list?
That was you only need it in the driver for now.
The SH-Mobile maintainers are against that approach.
+- reg: offset and length of the register block.
+- clocks: clock phandle and specifier pair.
+- clock-names: string, clock input name, must be "usbhs".
+
+Optional properties:
+- renesas,channel0-pci: boolean, specify when USB channel 0 should be connected
+ to PCI EHCI/OHCI; otherwise, it will be connected to the
+ USBHS controller.
+- renesas,channel2-pci: boolean, specify when USB channel 2 should be connected
+ to PCI EHCI/OHCI; otherwise, it will be connected to the
+ USBSS controller (xHCI).
When would you want this to connect to PCI, and when would you not? Why
is this not a run-time decision?
I think it's mostly connector type thing: A (host) vs B (device), USB 2.0
vs 3.0. With B connector you certainly want USBHS controller which is includes
the function controller (testing has shown that it also has the host
controller but the manuals don't quite say that). With A connector, user would
probably prefer PCI EHCI/OHCI, unless you have a USB 3.0 port in which case
the preference would probably be xHCI. So it appears to be the board specific
thing. Some runtime switching (e.g. downgrading from xHCI to PCI EHCI/OHCI)
might be considered too but I don't quite have a picture how that would work yet.
+
+Example (Lager board):
+
+ usb-phy@e6590100 {
+ compatible = "renesas,usb-phy-r8a7790";
+ reg = <0 0xe6590100 0 0x100>;
+ clocks = <&mstp7_clks R8A7790_CLK_HSUSB>;
+ clock-names = "usbhs";
+ renesas,channel2-pci;
+ };
We're not using the generic phy bindings?
It's not a driver/phy/ but driver/usb/phy/ code, so I guess we're not.
How is the linkage to the host controller expressed?
Looking at Documentation/devicetree/bindings/usb/, it's via "usb-phy"
property in the host device nodes.
[...]
- clk = devm_clk_get(dev, "usbhs");
+ if (np)
+ clk = of_clk_get_by_name(np, "usbhs");
+ else
+ clk = clk_get(dev, "usbhs");
Doesn't clk_get (and hence devm_clk_get) call of_clk_get_by_name?
Indeed, stupid me. I just didn't expect it, so didn't even look there.
Cheers,
Mark.
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 5/7] [media] of: move common endpoint parsing to drivers/of
On 02/27/2014 06:35 PM, Philipp Zabel wrote:
This patch adds a new struct of_endpoint which is then embedded in struct
v4l2_of_endpoint and contains the endpoint properties that are not V4L2
(or even media) specific: the port number, endpoint id, local device tree
node and remote endpoint phandle. of_graph_parse_endpoint parses those
properties and is used by v4l2_of_parse_endpoint, which just adds the
V4L2 MBUS information to the containing v4l2_of_endpoint structure.
Signed-off-by: Philipp Zabel
---
Changes since v4:
- Fixed users of struct v4l2_of_endpoint
- Removed left-over #include from v4l2-of.h
---
drivers/media/platform/exynos4-is/media-dev.c | 10 -
drivers/media/platform/exynos4-is/mipi-csis.c | 2 +-
drivers/media/v4l2-core/v4l2-of.c | 16 +++---
drivers/of/base.c | 31 +++
include/linux/of_graph.h | 20 +
include/media/v4l2-of.h | 8 ++-
6 files changed, 62 insertions(+), 25 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index d0f82da..04d6ecd 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -469,10 +469,10 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
return 0;
v4l2_of_parse_endpoint(ep,&endpoint);
- if (WARN_ON(endpoint.port == 0) || index>= FIMC_MAX_SENSORS)
+ if (WARN_ON(endpoint.base.port == 0) || index>= FIMC_MAX_SENSORS)
return -EINVAL;
- pd->mux_id = (endpoint.port - 1)& 0x1;
+ pd->mux_id = (endpoint.base.port - 1)& 0x1;
rem = of_graph_get_remote_port_parent(ep);
of_node_put(ep);
@@ -494,13 +494,13 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
return -EINVAL;
}
- if (fimc_input_is_parallel(endpoint.port)) {
+ if (fimc_input_is_parallel(endpoint.base.port)) {
if (endpoint.bus_type == V4L2_MBUS_PARALLEL)
pd->sensor_bus_type = FIMC_BUS_TYPE_ITU_601;
else
pd->sensor_bus_type = FIMC_BUS_TYPE_ITU_656;
pd->flags = endpoint.bus.parallel.flags;
- } else if (fimc_input_is_mipi_csi(endpoint.port)) {
+ } else if (fimc_input_is_mipi_csi(endpoint.base.port)) {
/*
* MIPI CSI-2: only input mux selection and
* the sensor's clock frequency is needed.
@@ -508,7 +508,7 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
pd->sensor_bus_type = FIMC_BUS_TYPE_MIPI_CSI2;
} else {
v4l2_err(&fmd->v4l2_dev, "Wrong port id (%u) at node %s\n",
-endpoint.port, rem->full_name);
+endpoint.base.port, rem->full_name);
}
/*
* For FIMC-IS handled sensors, that are placed under i2c-isp device
diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c
b/drivers/media/platform/exynos4-is/mipi-csis.c
index fd1ae65..3678ba5 100644
--- a/drivers/media/platform/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/exynos4-is/mipi-csis.c
@@ -772,7 +772,7 @@ static int s5pcsis_parse_dt(struct platform_device *pdev,
/* Get port node and validate MIPI-CSI channel id. */
v4l2_of_parse_endpoint(node,&endpoint);
- state->index = endpoint.port - FIMC_INPUT_MIPI_CSI2_0;
+ state->index = endpoint.base.port - FIMC_INPUT_MIPI_CSI2_0;
if (state->index< 0 || state->index>= CSIS_MAX_ENTITIES)
return -ENXIO;
diff --git a/drivers/media/v4l2-core/v4l2-of.c
b/drivers/media/v4l2-core/v4l2-of.c
index f919db3..b4ed9a9 100644
--- a/drivers/media/v4l2-core/v4l2-of.c
+++ b/drivers/media/v4l2-core/v4l2-of.c
@@ -127,17 +127,9 @@ static void v4l2_of_parse_parallel_bus(const struct
device_node *node,
int v4l2_of_parse_endpoint(const struct device_node *node,
struct v4l2_of_endpoint *endpoint)
{
- struct device_node *port_node = of_get_parent(node);
-
- memset(endpoint, 0, offsetof(struct v4l2_of_endpoint, head));
-
- endpoint->local_node = node;
- /*
-* It doesn't matter whether the two calls below succeed.
-* If they don't then the default value 0 is used.
-*/
- of_property_read_u32(port_node, "reg",&endpoint->port);
- of_property_read_u32(node, "reg",&endpoint->id);
+ of_graph_parse_endpoint(node,&endpoint->base);
+ endpoint->bus_type = 0;
+ memset(&endpoint->bus, 0, sizeof(endpoint->bus));
v4l2_of_parse_csi_bus(node, endpoint);
/*
@@ -147,8 +139,6 @@ int v4l2_of_parse_endpoint(const struct device_node *node,
if (endpoint->bus.mipi_csi2.flags == 0)
v4l2_of_parse_parallel_bus(node, endpoint);
- of_node_put(port_node);
-
return
Re: [PATCH v5 2/7] Documentation: of: Document graph bindings
Hi Philipp,
Just couple minor comments...
On 02/27/2014 06:35 PM, Philipp Zabel wrote:
The device tree graph bindings as used by V4L2 and documented in
Documentation/device-tree/bindings/media/video-interfaces.txt contain
generic parts that are not media specific but could be useful for any
subsystem with data flow between multiple devices. This document
describe the generic bindings.
s/describe/describes/
Signed-off-by: Philipp Zabel
---
Changes since v4:
- Differentiate from graphs made by simple phandle links
- Do not mention data flow except in video-interfaces example
-
---
Documentation/devicetree/bindings/graph.txt | 129
1 file changed, 129 insertions(+)
create mode 100644 Documentation/devicetree/bindings/graph.txt
diff --git a/Documentation/devicetree/bindings/graph.txt
b/Documentation/devicetree/bindings/graph.txt
new file mode 100644
index 000..554865b
--- /dev/null
+++ b/Documentation/devicetree/bindings/graph.txt
@@ -0,0 +1,129 @@
+Common bindings for device graphs
+
+General concept
+---
+
+The hierarchical organisation of the device tree is well suited to describe
+control flow to devices, but there can be more complex connections between
+devices that work together to form a logical compound device, following an
+arbitrarily complex graph.
+There already is a simple directed graph between devices tree nodes using
+phandle properties pointing to other nodes to describe connections that
+can not be inferred from device tree parent-child relationships. The device
+tree graph bindings described herein abstract more complex devices that can
+have multiple specifiable ports, each of which can be linked to one or more
+ports of other devices.
+
+These common bindings do not contain any information about the direction of
s/of/or/ ?
+type of the connections, they just map their existence. Specific properties
+may be described by specialized bindings depending on the type of connection.
+
+To see how this binding applies to video pipelines, for example, see
+Documentation/device-tree/bindings/media/video-interfaces.txt.
+Here the ports describe data interfaces, and the links between them are
+the connecting data buses. A single port with multiple connections can
+correspond to multiple devices being connected to the same physical bus.
+
+Organisation of ports and endpoints
+---
+
+Ports are described by child 'port' nodes contained in the device node.
+Each port node contains an 'endpoint' subnode for each remote device port
+connected to this port. If a single port is connected to more than one
+remote device, an 'endpoint' child node must be provided for each link.
+If more than one port is present in a device node or there is more than one
+endpoint at a port, or a port node needs to be associated with a selected
+hardware interface, a common scheme using '#address-cells', '#size-cells'
+and 'reg' properties is used number the nodes.
+
+device {
+...
+#address-cells =<1>;
+#size-cells =<0>;
+
+port@0 {
+ #address-cells =<1>;
+ #size-cells =<0>;
+ reg =<0>;
+
+endpoint@0 {
+ reg =<0>;
+ ...
+ };
+endpoint@1 {
+ reg =<1>;
+ ...
+ };
+};
+
+port@1 {
+ reg =<1>;
+
+ endpoint { ... };
+ };
+};
+
+All 'port' nodes can be grouped under an optional 'ports' node, which
+allows to specify #address-cells, #size-cells properties for the 'port'
+nodes independently from any other child device nodes a device might
+have.
+
+device {
+...
+ports {
+#address-cells =<1>;
+#size-cells =<0>;
+
+port@0 {
+...
+endpoint@0 { ... };
+endpoint@1 { ... };
+};
+
+port@1 { ... };
+};
+};
+
+Links between endpoints
+---
+
+Each endpoint should contain a 'remote-endpoint' phandle property that points
+to the corresponding endpoint in the port of the remote device. In turn, the
+remote endpoint should contain a 'remote-endpoint' property. If it has one,
+it must not point to another than the local endpoint. Two endpoints with their
+'remote-endpoint' phandles pointing at each other form a link between the
+containing ports.
+
+device_1 {
+port {
+device_1_output: endpoint {
+remote-endpoint =<&device_2_input>;
+};
+};
+};
+
+device_1 {
s/device_1/device_2/
But it might be better to use dashes instead of underscores
for the node names.
+port {
+device_2_input: endpoint {
+remote-endpoint =<&device_1_output>;
+};
+};
+};
+
Re: [PATCH v5 3/7] of: Warn if of_graph_get_next_endpoint is called with the root node
On 02/27/2014 06:35 PM, Philipp Zabel wrote:
If of_graph_get_next_endpoint is given a parentless node instead of an
endpoint node, it is clearly a bug.
Signed-off-by: Philipp Zabel
---
drivers/of/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index b2f223f..6e650cf 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2028,8 +2028,8 @@ struct device_node *of_graph_get_next_endpoint(const
struct device_node *parent,
of_node_put(node);
} else {
port = of_get_parent(prev);
- if (!port)
- /* Hm, has someone given us the root node ?... */
+ if (WARN_ONCE(!port, "%s(): endpoint has no parent node\n",
+ __func__))
Perhaps we can add more information to this error log, e.g.
if (WARN_ONCE(!port, "%s(): endpoint %s has no parent node\n",
__func__, prev->full_name))
?
return NULL;
/* Avoid dropping prev node refcount to 0. */
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 08/15] ahci-imx: Port to library-ised ahci_platform
On Sat, Feb 22, 2014 at 04:53:37PM +0100, Hans de Goede wrote: > + /* > + * set PHY Paremeters, two steps to configure the GPR13, > + * one write for rest of parameters, mask of first write > + * is 0x07ff, and the other one write for setting > + * the mpll_clk_en. > + */ > + regmap_update_bits(imxpriv->gpr, IOMUXC_GPR13, > +IMX6Q_GPR13_SATA_RX_EQ_VAL_MASK | > +IMX6Q_GPR13_SATA_RX_LOS_LVL_MASK | > +IMX6Q_GPR13_SATA_RX_DPLL_MODE_MASK | > +IMX6Q_GPR13_SATA_SPD_MODE_MASK | > +IMX6Q_GPR13_SATA_MPLL_SS_EN | > +IMX6Q_GPR13_SATA_TX_ATTEN_MASK | > +IMX6Q_GPR13_SATA_TX_BOOST_MASK | > +IMX6Q_GPR13_SATA_TX_LVL_MASK | > +IMX6Q_GPR13_SATA_MPLL_CLK_EN | > +IMX6Q_GPR13_SATA_TX_EDGE_RATE, > +IMX6Q_GPR13_SATA_RX_EQ_VAL_3_0_DB | > +IMX6Q_GPR13_SATA_RX_LOS_LVL_SATA2M | > +IMX6Q_GPR13_SATA_RX_DPLL_MODE_2P_4F | > +IMX6Q_GPR13_SATA_SPD_MODE_3P0G | > +IMX6Q_GPR13_SATA_MPLL_SS_EN | > +IMX6Q_GPR13_SATA_TX_ATTEN_9_16 | > +IMX6Q_GPR13_SATA_TX_BOOST_3_33_DB | > +IMX6Q_GPR13_SATA_TX_LVL_1_025_V); While I see this, I'll stick an oar in. It is totally wrong for this to be hard-coded into the driver - many of these should be specified via DT, since they're board specific. These are already different from the reset default in this register. The side effect of this hard coding is that eSATA just doesn't work at all on some boards - the board I have requires TX_LVL_1_104V and TX_BOOST_0_00_DB. Hence, I'd ask that while you move stuff like this around, you bear in mind that we do need to add additional properties. I'm in two minds about this - whether to make the existing binding with its compatible string always use these settings, and invent a new compatible string for one which is fully configurable (as it _should_ have been from the very start) or whether to make this the default if the various properties aren't specified. Either way, this driver is electrically unusable as it stands here. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] checkpatch: fix spurious vendor compatible warnings
Hi.
A couple of suggestions and a couple of questions.
I made the patch below against your patches to.
o Look for ".compatible = "foo" strings in .c and .h files too
o Improve the vendor name match in vendor-prefix.txt by only
matching the exact vendor name at the beginning of lines.
I then produced a file of all the compatible uses in dts
and used checkpatch on it. It's a long list and a longer
checkpatch warning list.
$ git ls-files | grep -E "\.dtsi?$" | \
xargs grep -hE "^\s*compatible\s*="| \
sed -r -e 's/^\s*//' -e 's/\s*=\s*/ = /'| sort | uniq > tmp.dts
$ .scripts/checkpatch.pl -f tmp.dts
A couple of questions:
How does the $compat2 variable actually work?
What is it supposed to do?
my $compat2 = $compat;
$compat2 =~ s/\,[a-z]*\-/\,<\.\*>\-/;
For instance:
WARNING: DT compatible string "marvell,tauros2-cache" appears un-documented --
check ./Documentation/devicetree/bindings/
The prefix "tauros2-" doesn't match '=~ s/[a-z]*-/
Should it? Should the '[a-z]*' be '[a-zA-Z0-9-]+'
like the other test?
Also the grep used when $compat2 is different than $compat
has <.*>
There aren't any descriptions I see in binding/ that have
any like uses with the angle brackets.
Are the angle brackets "<" and ">" necessary?
I think the code block should look more like:
my $compat2 = $compat;
$compat2 =~ s/\,[a-zA-Z0-9]*\-/\,\.\*\-/g;
my $grepfor = "\Q$compat\E";
$grepfor .= "|\Q$compat2\E" if ($compat2 ne
$compat);
`grep -Erq "$grepfor" $dt_path`;
so that there's only 1 grep pattern when
$compat2 is the same as $compat and the
strings are escape quoted.
There are a _lot_ of missing entries:
o 164 vendor names
o 2408 device names (maybe due to bad compat2 greps?)
What, if anything, should be done about them?
---
scripts/checkpatch.pl | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4b5e7b3..7a9eed9 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2051,29 +2051,29 @@ sub process {
}
# check for DT compatible documentation
- if (defined $root && $realfile =~ /\.dts/ &&
- $rawline =~ /^\+\s*compatible\s*=/) {
+ if (defined $root &&
+ (($realfile =~ /\.dtsi?$/ && $line =~
/^\+\s*compatible\s*=\s*\"/) ||
+($realfile =~ /\.[ch]$/ && $line =~
/^\+.*\.compatible\s*=\s*\"/))) {
+
my @compats = $rawline =~
/\"([a-zA-Z0-9\-\,\.\+_]+)\"/g;
+ my $dt_path = $root .
"/Documentation/devicetree/bindings/";
+ my $vp_file = $root .
"/Documentation/devicetree/bindings/vendor-prefixes.txt";
+
foreach my $compat (@compats) {
my $compat2 = $compat;
- my $dt_path = $root .
"/Documentation/devicetree/bindings/";
$compat2 =~ s/\,[a-z]*\-/\,<\.\*>\-/;
`grep -Erq "$compat|$compat2" $dt_path`;
if ( $? >> 8 ) {
WARN("UNDOCUMENTED_DT_STRING",
"DT compatible string \"$compat\"
appears un-documented -- check $dt_path\n" . $herecurr);
}
-
- my $vendor = $compat;
- my $vendor_path = $dt_path .
"vendor-prefixes.txt";
- next if (! -f $vendor_path);
- next if not $vendor =~ /^[a-zA-Z0-9\-]+\,.*/;
- $vendor =~ s/^([a-zA-Z0-9\-]+)\,.*/$1/;
- `grep -Eq "$vendor" $vendor_path`;
+ next if $compat !~ /^([a-zA-Z0-9\-]+)\,/;
+ my $vendor = $1;
+ `grep -Eq "^$vendor\\b" $vp_file`;
if ( $? >> 8 ) {
WARN("UNDOCUMENTED_DT_STRING",
-"DT compatible string vendor
\"$vendor\" appears un-documented -- check $vendor_path\n" . $herecurr);
+"DT compatible string vendor
\"$vendor\" appears un-documented -- check $vp_file\n" . $herecurr);
}
}
}
---
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv1 1/2] rx51_battery: convert to iio consumer
On Fri, Feb 28, 2014 at 9:32 PM, Belisko Marek wrote: > Hi Sebastian, > > On Fri, Feb 28, 2014 at 3:05 AM, Sebastian Reichel wrote: >> On Thu, Feb 27, 2014 at 10:34:35PM +0100, Belisko Marek wrote: >>> Well I've tried and it's worse :). I got during booting: >>> [2.218383] ERROR: could not get IIO channel /battery:temp(0) >>> [2.224639] platform battery.4: Driver twl4030_madc_battery >>> requests probe deferral >>> Not sure if it's just error or warning but temp is always reported as >>> 0 (and also other values in sysfs). >> >> This is an error, which basically means, that twl4030-madc has not >> yet been loaded. Do you get proper values when you use the old madc >> API with the patchset applied? > It works without converting to iio consumer (at least I get some > reasonable values). > With conversion it fails with above error. I recheck (add printk to > iio twl4030-madc) that > madc driver is loaded. Could this be that twl4030_madc_battery is > loaded earlier then > twl4030_madc and than it fails to get iio channels? Hmm I wasn't far away from truth in previous email. I think that channel doesn't exists because twl4030_madc driver isn't loaded yet and that is the reason for deferral probe message in log. So it seems after some time it is loaded correctly but not working. No ideas. >> >> -- Sebastian > > BR, > > marek > > -- > as simple and primitive as possible > - > Marek Belisko - OPEN-NANDRA > Freelance Developer > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic > Tel: +421 915 052 184 > skype: marekwhite > twitter: #opennandra > web: http://open-nandra.com BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 3/3] mmc: sdhci-msm: Add platform_execute_tunning implementation
On Fri, Feb 28, 2014 at 01:24:35PM +0200, Georgi Djakov wrote:
> This patch adds implementation for platform specific tuning in order to
> support
> HS200 bus speed mode on Qualcomm SDHCI controller.
>
> Signed-off-by: Asutosh Das
> Signed-off-by: Venkat Gopalakrishnan
> Signed-off-by: Georgi Djakov
> ---
> drivers/mmc/host/sdhci-msm.c | 424
> +-
> 1 file changed, 418 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index b4490a2..69f6887 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
[..]
> +int sdhci_msm_execute_tuning(struct sdhci_host *host, u32 opcode)
> +{
> + int tuning_seq_cnt = 3;
> + u8 phase, *data_buf, tuned_phases[16], tuned_phase_cnt = 0;
> + const u32 *tuning_block_pattern = tuning_block_64;
> + int size = sizeof(tuning_block_64); /* Pattern size in bytes */
> + int rc;
> + struct mmc_host *mmc = host->mmc;
> + struct mmc_ios ios = host->mmc->ios;
> +
> + /*
> + * Tuning is required for SDR104, HS200 and HS400 cards and
> + * if clock frequency is greater than 100MHz in these modes.
> + */
> + if (host->clock <= 100 * 1000 * 1000 ||
> + !((ios.timing == MMC_TIMING_MMC_HS200) ||
> + (ios.timing == MMC_TIMING_UHS_SDR104)))
> + return 0;
> +
> + if ((opcode == MMC_SEND_TUNING_BLOCK_HS200) &&
> + (mmc->ios.bus_width == MMC_BUS_WIDTH_8)) {
> + tuning_block_pattern = tuning_block_128;
> + size = sizeof(tuning_block_128);
> + }
> +
> + data_buf = kmalloc(size, GFP_KERNEL);
> + if (!data_buf)
> + return -ENOMEM;
> +
> +retry:
> + /* First of all reset the tuning block */
> + rc = msm_init_cm_dll(host);
> + if (rc)
> + goto out;
> +
> + phase = 0;
> + do {
> + struct mmc_command cmd = { 0 };
> + struct mmc_data data = { 0 };
> + struct mmc_request mrq = {
> + .cmd = &cmd,
> + .data = &data
> + };
> + struct scatterlist sg;
> +
> + /* Set the phase in delay line hw block */
> + rc = msm_config_cm_dll_phase(host, phase);
> + if (rc)
> + goto out;
> +
> + cmd.opcode = opcode;
> + cmd.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
> +
> + data.blksz = size;
> + data.blocks = 1;
> + data.flags = MMC_DATA_READ;
> + data.timeout_ns = NSEC_PER_SEC; /* 1 second */
> +
> + data.sg = &sg;
> + data.sg_len = 1;
> + sg_init_one(&sg, data_buf, sizeof(data_buf));
> + memset(data_buf, 0, sizeof(data_buf));
> + mmc_wait_for_req(mmc, &mrq);
> +
> + if (!cmd.error && !data.error &&
> + !memcmp(data_buf, tuning_block_pattern, sizeof(data_buf))) {
This memcmp is broken, sizeof(data_buf) is likely not what you want,
maybe you want 'size'? Same thing for sg_init_one()/memset() above.
>From sparse:
drivers/mmc/host/sdhci-msm.c: In function âsdhci_msm_execute_tuningâ:
drivers/mmc/host/sdhci-msm.c:461:53: warning: argument to âsizeofâ in
âmemcmpâ call is the same expression as the first source; did you mean to
provide an explicit length? [-Wsizeof-pointer-memaccess]
!memcmp(data_buf, tuning_block_pattern, sizeof(data_buf))) {
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/4] ARM: dts: OMAP4: Add IOMMU nodes
From: Florian Vaussard
Add the IOMMU nodes for the DSP and IPU subsystems. The MMU
within the IPU sub-system also supports a bus error back
capability, not available on the DSP MMU.
Signed-off-by: Florian Vaussard
[s-a...@ti.com: IPU bus error back addition]
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/omap4.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..ab7be95 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -461,6 +461,21 @@
dma-names = "tx", "rx";
};
+ mmu_dsp: mmu@4a066000 {
+ compatible = "ti,omap4-iommu";
+ reg = <0x4a066000 0xff>;
+ interrupts = ;
+ ti,hwmods = "mmu_dsp";
+ };
+
+ mmu_ipu: mmu@55082000 {
+ compatible = "ti,omap4-iommu";
+ reg = <0x55082000 0xff>;
+ interrupts = ;
+ ti,hwmods = "mmu_ipu";
+ ti,iommu-bus-err-back;
+ };
+
wdt2: wdt@4a314000 {
compatible = "ti,omap4-wdt", "ti,omap3-wdt";
reg = <0x4a314000 0x80>;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 4/4] ARM: dts: OMAP5: Add IOMMU nodes
The IOMMU DT nodes have been added for the DSP and IPU
subsystems. The MMUs in OMAP5 are identical to those in
OMAP4, including the bus error back capability on IPU.
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/omap5.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..42b9a44 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -513,6 +513,21 @@
dma-names = "tx", "rx";
};
+ mmu_dsp: mmu@4a066000 {
+ compatible = "ti,omap4-iommu";
+ reg = <0x4a066000 0xff>;
+ interrupts = ;
+ ti,hwmods = "mmu_dsp";
+ };
+
+ mmu_ipu: mmu@55082000 {
+ compatible = "ti,omap4-iommu";
+ reg = <0x55082000 0xff>;
+ interrupts = ;
+ ti,hwmods = "mmu_ipu";
+ ti,iommu-bus-err-back;
+ };
+
keypad: keypad@4ae1c000 {
compatible = "ti,omap4-keypad";
reg = <0x4ae1c000 0x400>;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/4] OMAP IOMMU DTS nodes
Hi, This is an updated series of the OMAP IOMMU DTS nodes for OMAP3, OMAP4 and OMAP5. The main change is the removal of the dma-window property from all the IOMMU DT nodes, as per the discussion on the bindings posted previously [1]. This series goes along with the v3 version of the driver DT adaptation series [2]. The DTS patches are updated as per the new bindings document patch [3]. [1] http://marc.info/?l=linux-omap&m=139345649217892&w=2 [2] http://marc.info/?l=linux-omap&m=139362022805667&w=2 [3] http://marc.info/?l=linux-omap&m=139362026905683&w=2 v1: DTS patches as per v2 series of driver DT adaptation series. http://marc.info/?l=linux-omap&m=139231582217147&w=2 Florian Vaussard (3): ARM: dts: OMAP3: Update ISP IOMMU node ARM: dts: OMAP3: Add IVA IOMMU node ARM: dts: OMAP4: Add IOMMU nodes Suman Anna (1): ARM: dts: OMAP5: Add IOMMU nodes arch/arm/boot/dts/omap3.dtsi | 15 --- arch/arm/boot/dts/omap4.dtsi | 15 +++ arch/arm/boot/dts/omap5.dtsi | 15 +++ 3 files changed, 42 insertions(+), 3 deletions(-) -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/4] ARM: dts: OMAP3: Update ISP IOMMU node
From: Florian Vaussard
Update the IOMMU node for the camera subsystem as per the
OMAP IOMMU bindings.
Signed-off-by: Florian Vaussard
[s-a...@ti.com: corrected interrupt number]
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/omap3.dtsi | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index a5fc83b..f7a47e3 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -411,10 +411,11 @@
};
mmu_isp: mmu@480bd400 {
- compatible = "ti,omap3-mmu-isp";
- ti,hwmods = "mmu_isp";
+ compatible = "ti,omap2-iommu";
reg = <0x480bd400 0x80>;
- interrupts = <8>;
+ interrupts = <24>;
+ ti,hwmods = "mmu_isp";
+ ti,#tlb-entries = <8>;
};
wdt2: wdt@48314000 {
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/4] ARM: dts: OMAP3: Add IVA IOMMU node
From: Florian Vaussard
Add the DT node for the IOMMU within the DSP subsystem. The entry
is disabled to keep in line with the hwmod usage as intended by
the deprecated CONFIG_OMAP_IOMMU_IVA2 flag.
Signed-off-by: Florian Vaussard
[s-a...@ti.com: split the entry and disable the node]
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/omap3.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index f7a47e3..9574a9e 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -418,6 +418,14 @@
ti,#tlb-entries = <8>;
};
+ mmu_iva: mmu@5d00 {
+ compatible = "ti,omap2-iommu";
+ reg = <0x5d00 0x80>;
+ interrupts = <28>;
+ ti,hwmods = "mmu_iva";
+ status = "disabled";
+ };
+
wdt2: wdt@48314000 {
compatible = "ti,omap3-wdt";
reg = <0x48314000 0x80>;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v9 3/3] mmc: sdhci-msm: Add platform_execute_tunning implementation
Nit below. On Fri, Feb 28, 2014 at 01:24:35PM +0200, Georgi Djakov wrote: > This patch adds implementation for platform specific tuning in order to > support > HS200 bus speed mode on Qualcomm SDHCI controller. > > Signed-off-by: Asutosh Das > Signed-off-by: Venkat Gopalakrishnan > Signed-off-by: Georgi Djakov > --- > drivers/mmc/host/sdhci-msm.c | 424 > +- > 1 file changed, 418 insertions(+), 6 deletions(-) > > diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c > index b4490a2..69f6887 100644 > --- a/drivers/mmc/host/sdhci-msm.c > +++ b/drivers/mmc/host/sdhci-msm.c [..] > > +int sdhci_msm_execute_tuning(struct sdhci_host *host, u32 opcode) This wants to be static. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 11/13] ARM: OMAP2+: use pdata quirks for iommu reset lines
The OMAP iommu driver performs the reset management for the
iommu instances in processor sub-systems using the omap_device
API which are currently supplied as platform data ops. Use pdata
quirks to maintain the functionality as the OMAP iommu driver
gets converted to use DT nodes, until the reset portions are
decoupled from omap_hwmod/omap_device into a separate reset
driver.
This patch adds the pdata quirks for the reset management of
iommus within the DSP (OMAP3 & OMAP4) and IPU subsystems (OMAP4).
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/pdata-quirks.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 3d5b24d..74e094a 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -16,12 +16,14 @@
#include
#include
+#include
#include "am35xx.h"
#include "common.h"
#include "common-board-devices.h"
#include "dss-common.h"
#include "control.h"
+#include "omap_device.h"
struct pdata_init {
const char *compatible;
@@ -92,6 +94,12 @@ static void __init hsmmc2_internal_input_clk(void)
omap_ctrl_writel(reg, OMAP343X_CONTROL_DEVCONF1);
}
+static struct iommu_platform_data omap3_iommu_pdata = {
+ .reset_name = "mmu",
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
+
static int omap3_sbc_t3730_twl_callback(struct device *dev,
unsigned gpio,
unsigned ngpio)
@@ -185,6 +193,12 @@ static void __init omap4_panda_legacy_init(void)
legacy_init_ehci_clk("auxclk3_ck");
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
+
+static struct iommu_platform_data omap4_iommu_pdata = {
+ .reset_name = "mmu_cache",
+ .assert_reset = omap_device_assert_hardreset,
+ .deassert_reset = omap_device_deassert_hardreset,
+};
#endif
#ifdef CONFIG_SOC_OMAP5
@@ -240,6 +254,8 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_ARCH_OMAP3
OF_DEV_AUXDATA("ti,omap3-padconf", 0x48002030, "48002030.pinmux",
&pcs_pdata),
OF_DEV_AUXDATA("ti,omap3-padconf", 0x48002a00, "48002a00.pinmux",
&pcs_pdata),
+ OF_DEV_AUXDATA("ti,omap2-iommu", 0x5d00, "5d00.mmu",
+ &omap3_iommu_pdata),
/* Only on am3517 */
OF_DEV_AUXDATA("ti,davinci_mdio", 0x5c03, "davinci_mdio.0", NULL),
OF_DEV_AUXDATA("ti,am3517-emac", 0x5c00, "davinci_emac.0",
@@ -248,6 +264,10 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a100040, "4a100040.pinmux",
&pcs_pdata),
OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a31e040, "4a31e040.pinmux",
&pcs_pdata),
+ OF_DEV_AUXDATA("ti,omap4-iommu", 0x4a066000, "4a066000.mmu",
+ &omap4_iommu_pdata),
+ OF_DEV_AUXDATA("ti,omap4-iommu", 0x55082000, "55082000.mmu",
+ &omap4_iommu_pdata),
#endif
{ /* sentinel */ },
};
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 13/13] ARM: OMAP2+: extend iommu pdata-quirks to OMAP5
OMAP5 has the same iommus as OMAP4, so extend the OMAP4
iommu pdata quirks for OMAP5 as well.
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/pdata-quirks.c | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 74e094a..551877f 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -193,7 +193,9 @@ static void __init omap4_panda_legacy_init(void)
legacy_init_ehci_clk("auxclk3_ck");
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
+#endif
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
static struct iommu_platform_data omap4_iommu_pdata = {
.reset_name = "mmu_cache",
.assert_reset = omap_device_assert_hardreset,
@@ -264,6 +266,8 @@ struct of_dev_auxdata omap_auxdata_lookup[] __initdata = {
#ifdef CONFIG_ARCH_OMAP4
OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a100040, "4a100040.pinmux",
&pcs_pdata),
OF_DEV_AUXDATA("ti,omap4-padconf", 0x4a31e040, "4a31e040.pinmux",
&pcs_pdata),
+#endif
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
OF_DEV_AUXDATA("ti,omap4-iommu", 0x4a066000, "4a066000.mmu",
&omap4_iommu_pdata),
OF_DEV_AUXDATA("ti,omap4-iommu", 0x55082000, "55082000.mmu",
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 10/13] ARM: OMAP2+: change the ISP device archdata MMU name for DT
The IOMMU DT adaptation support uses the device name instead
of an iommu object name. Fixup the ISP device archdata MMU
name at runtime if using DT-boot. This allows the OMAP3 camera
to be functional in both legacy and DT boots. The iommu object
names should eventually vanish when all the IOMMU users have
been converted to DT nodes.
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/devices.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 0dd6398..e58609b 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -229,6 +229,9 @@ static struct omap_iommu_arch_data omap3_isp_iommu = {
int omap3_init_camera(struct isp_platform_data *pdata)
{
+ if (of_have_populated_dt())
+ omap3_isp_iommu.name = "480bd400.mmu";
+
omap3isp_device.dev.platform_data = pdata;
omap3isp_device.dev.archdata.iommu = &omap3_isp_iommu;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 09/13] ARM: OMAP3: fix iva mmu programming issues
The IVA MMU is not functional when used through the hwmod and
omap_device layers. Add fixes to clockdomain and hwmod data
to have it functional. The hwmod changes are needed to enable
the clock, and the SWSUP change is needed to wakeup the domain
because the power domain is programmed to be in RET, and there
is no automatic power domain switching to ON.
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/clockdomains3xxx_data.c | 2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 4
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c
b/arch/arm/mach-omap2/clockdomains3xxx_data.c
index e6b91e5..f03dc97 100644
--- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
@@ -247,7 +247,7 @@ static struct clockdomain neon_clkdm = {
static struct clockdomain iva2_clkdm = {
.name = "iva2_clkdm",
.pwrdm = { .name = "iva2_pwrdm" },
- .flags = CLKDM_CAN_HWSUP_SWSUP,
+ .flags = CLKDM_CAN_SWSUP,
.dep_bit= OMAP3430_PM_WKDEP_MPU_EN_IVA2_SHIFT,
.wkdep_srcs = iva2_wkdeps,
.clktrctrl_mask = OMAP3430_CLKTRCTRL_IVA2_MASK,
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 81dd071..9c7e23a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3068,12 +3068,16 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.name = "mmu_iva",
.class = &omap3xxx_mmu_hwmod_class,
.mpu_irqs = omap3xxx_mmu_iva_irqs,
+ .clkdm_name = "iva2_clkdm",
.rst_lines = omap3xxx_mmu_iva_resets,
.rst_lines_cnt = ARRAY_SIZE(omap3xxx_mmu_iva_resets),
.main_clk = "iva2_ck",
.prcm = {
.omap2 = {
.module_offs = OMAP3430_IVA2_MOD,
+ .module_bit = OMAP3430_CM_FCLKEN_IVA2_EN_IVA2_SHIFT,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit = OMAP3430_ST_IVA2_SHIFT,
},
},
.dev_attr = &mmu_iva_dev_attr,
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 07/13] iommu/omap: allocate archdata on the fly for DT-based devices
From: Laurent Pinchart
The OMAP IOMMU driver locates the IOMMU associated to a device using the
IOMMU name stored in the device archdata iommu field. That field is
expected to be populated by platform code and is left unset for DT-based
devices. This results in a crash when the IOMMU driver attaches a domain
to a device.
Fix this by allocating the archdata iommu structure when devices are
added and freeing when they are removed. Devices without an OF node, and
devices without an iommus property in their OF node are ignored. The
iommu name is initialized from the IOMMU device node name.
This should be simplified when removing non-DT support completely from
the IOMMU users as the IOMMU name won't be needed anymore, and the
IOMMU device pointer could then be stored in the archdata iommu field
directly.
Signed-off-by: Laurent Pinchart
[s-a...@ti.com: updated to use device name instead of OF name]
Signed-off-by: Suman Anna
---
drivers/iommu/omap-iommu.c | 45 +
1 file changed, 45 insertions(+)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 28bc631..8acea87 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1253,6 +1253,49 @@ static int omap_iommu_domain_has_cap(struct iommu_domain
*domain,
return 0;
}
+static int omap_iommu_add_device(struct device *dev)
+{
+ struct omap_iommu_arch_data *arch_data;
+ struct device_node *np;
+
+ /*
+* Allocate the archdata iommu structure for DT-based devices.
+*
+* TODO: Simplify this when removing non-DT support completely from the
+* IOMMU users.
+*/
+ if (!dev->of_node)
+ return 0;
+
+ np = of_parse_phandle(dev->of_node, "iommus", 0);
+ if (!np)
+ return 0;
+
+ arch_data = kzalloc(sizeof(*arch_data), GFP_KERNEL);
+ if (!arch_data) {
+ of_node_put(np);
+ return -ENOMEM;
+ }
+
+ arch_data->name = kstrdup(dev_name(dev), GFP_KERNEL);
+ dev->archdata.iommu = arch_data;
+
+ of_node_put(np);
+
+ return 0;
+}
+
+static void omap_iommu_remove_device(struct device *dev)
+{
+ struct omap_iommu_arch_data *arch_data = dev->archdata.iommu;
+
+ if (!dev->of_node || !arch_data)
+ return;
+
+ kfree(arch_data->name);
+ kfree(arch_data);
+}
+
static struct iommu_ops omap_iommu_ops = {
.domain_init= omap_iommu_domain_init,
.domain_destroy = omap_iommu_domain_destroy,
@@ -1262,6 +1305,8 @@ static struct iommu_ops omap_iommu_ops = {
.unmap = omap_iommu_unmap,
.iova_to_phys = omap_iommu_iova_to_phys,
.domain_has_cap = omap_iommu_domain_has_cap,
+ .add_device = omap_iommu_add_device,
+ .remove_device = omap_iommu_remove_device,
.pgsize_bitmap = OMAP_IOMMU_PGSIZES,
};
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 12/13] ARM: OMAP5: hwmod data: add mmu data for ipu & dsp
A new MMU hwmod class and data structures are created
to represent the MMUs within the IPU and DSP processor
subsystems in OMAP5. The MMUs in OMAP5 are identical to
those in OMAP4.
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 83 ++
1 file changed, 83 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index e297d62..8923172 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1122,6 +1122,71 @@ static struct omap_hwmod omap54xx_mmc5_hwmod = {
};
/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_mmu_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_mmu_hwmod_class = {
+ .name = "mmu",
+ .sysc = &omap54xx_mmu_sysc,
+};
+
+static struct omap_hwmod_rst_info omap54xx_mmu_dsp_resets[] = {
+ { .name = "mmu_cache", .rst_shift = 1 },
+};
+
+static struct omap_hwmod omap54xx_mmu_dsp_hwmod = {
+ .name = "mmu_dsp",
+ .class = &omap54xx_mmu_hwmod_class,
+ .clkdm_name = "dsp_clkdm",
+ .rst_lines = omap54xx_mmu_dsp_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap54xx_mmu_dsp_resets),
+ .main_clk = "dpll_iva_h11x2_ck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_DSP_DSP_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP54XX_RM_DSP_RSTCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_DSP_DSP_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/* mmu ipu */
+static struct omap_hwmod_rst_info omap54xx_mmu_ipu_resets[] = {
+ { .name = "mmu_cache", .rst_shift = 2 },
+};
+
+static struct omap_hwmod omap54xx_mmu_ipu_hwmod = {
+ .name = "mmu_ipu",
+ .class = &omap54xx_mmu_hwmod_class,
+ .clkdm_name = "ipu_clkdm",
+ .rst_lines = omap54xx_mmu_ipu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap54xx_mmu_ipu_resets),
+ .main_clk = "dpll_core_h22x2_ck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_IPU_IPU_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP54XX_RM_IPU_RSTCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_IPU_IPU_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
+/*
* 'mpu' class
* mpu sub-system
*/
@@ -1763,6 +1828,14 @@ static struct omap_hwmod_ocp_if
omap54xx_l4_cfg__l3_main_1 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg -> mmu_dsp */
+static struct omap_hwmod_ocp_if omap54xx_l4_cfg__mmu_dsp = {
+ .master = &omap54xx_l4_cfg_hwmod,
+ .slave = &omap54xx_mmu_dsp_hwmod,
+ .clk= "l4_root_clk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* mpu -> l3_main_1 */
static struct omap_hwmod_ocp_if omap54xx_mpu__l3_main_1 = {
.master = &omap54xx_mpu_hwmod,
@@ -1787,6 +1860,14 @@ static struct omap_hwmod_ocp_if
omap54xx_l4_cfg__l3_main_2 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l3_main_2 -> mmu_ipu */
+static struct omap_hwmod_ocp_if omap54xx_l3_main_2__mmu_ipu = {
+ .master = &omap54xx_l3_main_2_hwmod,
+ .slave = &omap54xx_mmu_ipu_hwmod,
+ .clk= "l3_iclk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_1 -> l3_main_3 */
static struct omap_hwmod_ocp_if omap54xx_l3_main_1__l3_main_3 = {
.master = &omap54xx_l3_main_1_hwmod,
@@ -2345,6 +2426,7 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[]
__initdata = {
&omap54xx_l4_wkup__counter_32k,
&omap54xx_l4_cfg__dma_system,
&omap54xx_l4_abe__dmic,
+ &omap54xx_l4_cfg__mmu_dsp,
&omap54xx_mpu__emif1,
&omap54xx_mpu__emif2,
&omap54xx_l4_wkup__gpio1,
@@ -2360,6 +2442,7 @@ static struct omap_hwmod_ocp_if *omap54xx_hwmod_ocp_ifs[]
__initdata = {
&omap54xx_l4_per__i2c3,
&omap54xx_l4_per__i2c4,
&omap54xx_l4_per__i2c5,
+ &omap54xx_l3_main_2__mmu_ipu,
&omap54xx_l4_wkup__kbd,
&omap54xx_l4_cfg__mailbox,
&omap54xx_l4_abe__mcbsp1,
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe
[PATCHv3 06/13] iommu/omap: enable bus-error back on supported iommus
The remoteproc MMUs in OMAP4+ SoCs have some additional debug
registers that can give out the PC value in addition to the
MMU fault address. The PC value can be extracted properly only
on the DSP cores, and is not available on the ARM processors
within the IPU sub-systems. Instead, the MMUs have been enhanced
to throw a bus-error response back to the IPU processors.
This functionality is programmable through the MMU_GP_REG register.
The cores are simply stalled if the MMU_GP_REG.BUS_ERR_BACK_EN bit
is not set. When set, a bus-error exception is raised allowing the
processor to handle it as a bus fault and provide additional debug
information. This feature is turned on by default by the driver on
iommus supporting it.
Signed-off-by: Subramaniam Chanderashekarapuram
Signed-off-by: Suman Anna
---
drivers/iommu/omap-iommu.c | 2 ++
drivers/iommu/omap-iommu.h | 5 +
drivers/iommu/omap-iommu2.c | 3 +++
3 files changed, 10 insertions(+)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index eb73ef2..28bc631 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -961,6 +961,8 @@ static int omap_iommu_probe(struct platform_device *pdev)
*/
obj->da_start = 0;
obj->da_end = 0xf000;
+ if (of_find_property(of, "ti,iommu-bus-err-back", NULL))
+ obj->has_bus_err_back = MMU_GP_REG_BUS_ERR_BACK_EN;
} else {
obj->nr_tlb_entries = pdata->nr_tlb_entries;
obj->name = pdata->name;
diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h
index 1200842..ea920c3 100644
--- a/drivers/iommu/omap-iommu.h
+++ b/drivers/iommu/omap-iommu.h
@@ -52,6 +52,8 @@ struct omap_iommu {
void *ctx; /* iommu context: registres saved area */
u32 da_start;
u32 da_end;
+
+ int has_bus_err_back;
};
struct cr_regs {
@@ -130,6 +132,7 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
#define MMU_READ_CAM 0x68
#define MMU_READ_RAM 0x6c
#define MMU_EMU_FAULT_AD 0x70
+#define MMU_GP_REG 0x88
#define MMU_REG_SIZE 256
@@ -163,6 +166,8 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
#define MMU_RAM_MIXED_MASK (1 << MMU_RAM_MIXED_SHIFT)
#define MMU_RAM_MIXED MMU_RAM_MIXED_MASK
+#define MMU_GP_REG_BUS_ERR_BACK_EN 0x1
+
/*
* utilities for super page(16MB, 1MB, 64KB and 4KB)
*/
diff --git a/drivers/iommu/omap-iommu2.c b/drivers/iommu/omap-iommu2.c
index d745094..5e1ea3b 100644
--- a/drivers/iommu/omap-iommu2.c
+++ b/drivers/iommu/omap-iommu2.c
@@ -98,6 +98,9 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
iommu_write_reg(obj, pa, MMU_TTB);
+ if (obj->has_bus_err_back)
+ iommu_write_reg(obj, MMU_GP_REG_BUS_ERR_BACK_EN, MMU_GP_REG);
+
__iommu_set_twl(obj, true);
return 0;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 08/13] ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2
From: Florian Vaussard
CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting
usage by tidspbridge and other iommu users. The same can be achieved
by marking the DT node disabled, so remove this obsolete flag and
the corresponding hwmod data can be enabled.
Cc: Paul Walmsley
Signed-off-by: Florian Vaussard
[s-a...@ti.com: revise commit log]
Signed-off-by: Suman Anna
Acked-by: Laurent Pinchart
Acked-by: Tony Lindgren
Acked-by: Paul Walmsley
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8
arch/arm/plat-omap/Kconfig | 3 ---
2 files changed, 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 4c3b1e6..81dd071 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3029,8 +3029,6 @@ static struct omap_hwmod omap3xxx_mmu_isp_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
-#ifdef CONFIG_OMAP_IOMMU_IVA2
-
/* mmu iva */
static struct omap_mmu_dev_attr mmu_iva_dev_attr = {
@@ -3082,8 +3080,6 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
-#endif
-
/* l4_per -> gpio4 */
static struct omap_hwmod_addr_space omap3xxx_gpio4_addrs[] = {
{
@@ -3855,9 +3851,7 @@ static struct omap_hwmod_ocp_if *omap34xx_hwmod_ocp_ifs[]
__initdata = {
&omap3xxx_l4_core__hdq1w,
&omap3xxx_sad2d__l3,
&omap3xxx_l4_core__mmu_isp,
-#ifdef CONFIG_OMAP_IOMMU_IVA2
&omap3xxx_l3_main__mmu_iva,
-#endif
&omap34xx_l4_core__ssi,
NULL
};
@@ -3881,9 +3875,7 @@ static struct omap_hwmod_ocp_if *omap36xx_hwmod_ocp_ifs[]
__initdata = {
&omap3xxx_l4_core__hdq1w,
&omap3xxx_sad2d__l3,
&omap3xxx_l4_core__mmu_isp,
-#ifdef CONFIG_OMAP_IOMMU_IVA2
&omap3xxx_l3_main__mmu_iva,
-#endif
NULL
};
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 436ea97..02fc10d 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -86,9 +86,6 @@ config OMAP_MUX_WARNINGS
to change the pin multiplexing setup. When there are no warnings
printed, it's safe to deselect OMAP_MUX for your product.
-config OMAP_IOMMU_IVA2
- bool
-
config OMAP_MPU_TIMER
bool "Use mpu timer"
depends on ARCH_OMAP1
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 05/13] iommu/omap: add devicetree support
From: Florian Vaussard
As OMAP2+ is moving to a full DT boot for all SoC families, commit
7ce93f3 "ARM: OMAP2+: Fix more missing data for omap3.dtsi file"
adds basic DT bits for OMAP3. But the driver is not yet converted,
so this will not work and driver will not be probed. Convert it!
The legacy boot mode is still supported until OMAP3 is converted
to DT-boot only.
Signed-off-by: Florian Vaussard
[s-a...@ti.com: dev_name adaptation and improved error checking]
Signed-off-by: Suman Anna
[t...@atomide.com: Ack for arch/arm/*omap* parts]
Acked-by: Tony Lindgren
---
arch/arm/mach-omap2/omap-iommu.c | 5 +
drivers/iommu/omap-iommu.c | 42
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index f6daae8..f1fab56 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -10,6 +10,7 @@
* published by the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -58,6 +59,10 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
static int __init omap_iommu_init(void)
{
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
return omap_hwmod_for_each_by_class("mmu", omap_iommu_dev_init, NULL);
}
/* must be ready before omap3isp is probed */
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 217952b..eb73ef2 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -23,6 +23,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
@@ -936,17 +939,39 @@ static int omap_iommu_probe(struct platform_device *pdev)
struct omap_iommu *obj;
struct resource *res;
struct iommu_platform_data *pdata = pdev->dev.platform_data;
+ struct device_node *of = pdev->dev.of_node;
obj = devm_kzalloc(&pdev->dev, sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
if (!obj)
return -ENOMEM;
- obj->nr_tlb_entries = pdata->nr_tlb_entries;
- obj->name = pdata->name;
+ if (of) {
+ obj->name = dev_name(&pdev->dev);
+ obj->nr_tlb_entries = 32;
+ err = of_property_read_u32(of, "ti,#tlb-entries",
+ &obj->nr_tlb_entries);
+ if (err && err != -EINVAL)
+ return err;
+ if (obj->nr_tlb_entries != 32 && obj->nr_tlb_entries != 8)
+ return -EINVAL;
+ /*
+* da_start and da_end are needed for omap-iovmm, so hardcode
+* these values as used by OMAP3 ISP - the only user for
+* omap-iovmm
+*/
+ obj->da_start = 0;
+ obj->da_end = 0xf000;
+ } else {
+ obj->nr_tlb_entries = pdata->nr_tlb_entries;
+ obj->name = pdata->name;
+ obj->da_start = pdata->da_start;
+ obj->da_end = pdata->da_end;
+ }
+ if (obj->da_end <= obj->da_start)
+ return -EINVAL;
+
obj->dev = &pdev->dev;
obj->ctx = (void *)obj + sizeof(*obj);
- obj->da_start = pdata->da_start;
- obj->da_end = pdata->da_end;
spin_lock_init(&obj->iommu_lock);
mutex_init(&obj->mmap_lock);
@@ -987,11 +1012,20 @@ static int omap_iommu_remove(struct platform_device
*pdev)
return 0;
}
+static struct of_device_id omap_iommu_of_match[] = {
+ { .compatible = "ti,omap2-iommu" },
+ { .compatible = "ti,omap4-iommu" },
+ { .compatible = "ti,dra7-iommu" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_iommu_of_match);
+
static struct platform_driver omap_iommu_driver = {
.probe = omap_iommu_probe,
.remove = omap_iommu_remove,
.driver = {
.name = "omap-iommu",
+ .of_match_table = of_match_ptr(omap_iommu_of_match),
},
};
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 04/13] Documentation: dt: add OMAP iommu bindings
From: Florian Vaussard
This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from
the standard bindings used by OMAP peripherals, this patch uses a
'dma-window' (already used by Tegra SMMU) and adds two OMAP custom
bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'.
Signed-off-by: Florian Vaussard
[s-a...@ti.com: split bindings document, add dra7 and bus error back]
Signed-off-by: Suman Anna
---
.../devicetree/bindings/iommu/ti,omap-iommu.txt| 26 ++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
new file mode 100644
index 000..42531dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -0,0 +1,26 @@
+OMAP2+ IOMMU
+
+Required properties:
+- compatible : Should be one of,
+ "ti,omap2-iommu" for OMAP2/OMAP3 IOMMU instances
+ "ti,omap4-iommu" for OMAP4/OMAP5 IOMMU instances
+ "ti,dra7-iommu" for DRA7xx IOMMU instances
+- ti,hwmods : Name of the hwmod associated with the IOMMU instance
+- reg: Address space for the configuration registers
+- interrupts : Interrupt specifier for the IOMMU instance
+
+Optional properties:
+- ti,#tlb-entries : Number of entries in the translation look-aside buffer.
+Should be either 8 or 32 (default: 32)
+- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing
+ back a bus error response on MMU faults.
+
+Example:
+ /* OMAP3 ISP MMU */
+ mmu_isp: mmu@480bd400 {
+ compatible = "ti,omap2-iommu";
+ reg = <0x480bd400 0x80>;
+ interrupts = <24>;
+ ti,hwmods = "mmu_isp";
+ ti,#tlb-entries = <8>;
+ };
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 03/13] iommu/omap: allow enable/disable even without pdata
From: Florian Vaussard
When booting with a devicetree, no platform data is provided.
Do not prematurely exit iommu_enable() and iommu_disable() in
such a case.
Note: As OMAP do not yet has a proper reset controller driver,
IOMMUs requiring a reset signal should use pdata-quirks as a
transitional solution.
Signed-off-by: Florian Vaussard
Signed-off-by: Suman Anna
Acked-by: Laurent Pinchart
---
drivers/iommu/omap-iommu.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 647e4ba..217952b 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -146,13 +146,10 @@ static int iommu_enable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj->dev);
struct iommu_platform_data *pdata = pdev->dev.platform_data;
- if (!pdata)
- return -EINVAL;
-
if (!arch_iommu)
return -ENODEV;
- if (pdata->deassert_reset) {
+ if (pdata && pdata->deassert_reset) {
err = pdata->deassert_reset(pdev, pdata->reset_name);
if (err) {
dev_err(obj->dev, "deassert_reset failed: %d\n", err);
@@ -172,14 +169,11 @@ static void iommu_disable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj->dev);
struct iommu_platform_data *pdata = pdev->dev.platform_data;
- if (!pdata)
- return;
-
arch_iommu->disable(obj);
pm_runtime_put_sync(obj->dev);
- if (pdata->assert_reset)
+ if (pdata && pdata->assert_reset)
pdata->assert_reset(pdev, pdata->reset_name);
}
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 02/13] iommu/omap: fix error return paths in omap_iommu_attach()
There are couple of issues with the error return paths in
omap_iommu_attach():
1. omap_iommu_attach() returns NULL or ERR_PTR in case of error,
but omap_iommu_attach_dev() only checks for IS_ERR. Thus a NULL
return value (in case driver_find_device fails) will cause the
kernel to panic when omap_iommu_attach_dev() dereferences the
pointer.
2. A try_module_get() failure returns a valid success value as
returned from iommu_enable().
Both the above issues have been fixed up to return the proper
ERR_PTR.
Signed-off-by: Florian Vaussard
Signed-off-by: Suman Anna
---
drivers/iommu/omap-iommu.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index fff2ffd..647e4ba 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -863,7 +863,7 @@ static int device_match_by_alias(struct device *dev, void
*data)
**/
static struct omap_iommu *omap_iommu_attach(const char *name, u32 *iopgd)
{
- int err = -ENOMEM;
+ int err;
struct device *dev;
struct omap_iommu *obj;
@@ -871,7 +871,7 @@ static struct omap_iommu *omap_iommu_attach(const char
*name, u32 *iopgd)
(void *)name,
device_match_by_alias);
if (!dev)
- return NULL;
+ return ERR_PTR(-ENODEV);
obj = to_iommu(dev);
@@ -890,8 +890,10 @@ static struct omap_iommu *omap_iommu_attach(const char
*name, u32 *iopgd)
goto err_enable;
flush_iotlb_all(obj);
- if (!try_module_get(obj->owner))
+ if (!try_module_get(obj->owner)) {
+ err = -ENODEV;
goto err_module;
+ }
spin_unlock(&obj->iommu_lock);
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 00/13] OMAP IOMMU DT adaptation for 3.15
Hi Joerg, Tony, This is an updated series of the OMAP IOMMU DT adaptation intended for 3.15 merge window, addressing the comments from the v2 series. This series is rebased onto 3.14-rc4, and the only change to bindings is to drop the dma-window property. The first 7 patches in the series are in drivers/iommu, with the first 3 patches performing some cleanup. The DT bindings and adaptation are done in patches 4 and 5. Tony, Patches 8 through 13 are in arch/arm/mach-omap2 layer, so I am guessing these would have to go through your tree. Of these, patches 8 and 9 are cleanup fixes to get OMAP3 IVA MMU working, patches 10 & 11 are fixes required with DT-boot for OMAP3/4, patches 12 & 13 add the OMAP5 support. I have validated the functionality of all the different IOMMUs on OMAP3 (legacy and DT-boots), OMAP4 and OMAP5 (DT boot only). The full branch including the DTS patches used to test is here for reference, https://github.com/sumananna/omap-kernel/commits/iommu/3.14-rc4-dt-support-v3 Detailed changes in v3: - Updated patch for fixing return errors in omap_iommu_attach (Patch 2) - Updated bindings document and driver DT support patch to remove the dma-window property (Patches 4 and 5) - Updated the OMAP3 ISP archdata to support both legacy and DT boots (Patch 10). This patch is reworked completely w.r.t v2. - All the remaining patches are unchanged (Patches 1, 3, 6 through 9, 11 through 13), other than the addition of the Acked-by received on the respective patches. Patches 3 and 9 are reordered compared to previous version. - Dropped Patches 14 through 16 from previous series until OMAP3 is also converted to DT-only. These dealt with the cleanup of code used in legacy boot. v2: http://marc.info/?l=linux-omap&m=139231544416973&w=2 - Cleanup of driver probe/release to use devm_ interfaces (Patch 1) - The DT bindings are split into a separate patch, and updated based on discussion on v1 [1] (Patch 3) - Updated DT adaptation patch with improved error checking, and support for DRA7 compatible IOMMUs in the driver (Patch 4) - Added support for throwing a bus error response back to the processor cores on MMUs associated with IPUs (Patch 5) - Added preliminary support to DT-based IOMMU users (Patch 6) - Added preparatory patches to enable and use the hwmod for IVA MMU on OMAP3 (Patches 8 and 11) - Adapt the OMAP3 ISP archdata to support DT boot (Patch 9). Legacy mode will not work after this patch, and this will be cleaned up anyway once OMAP3ISP is converted to a DT node. - Reset functionality enablement with DT-boots using pdata quirks for OMAP3 IVA, OMAP4 and OMAP5 DSP & IPU MMUs (Patches 10, 13) - Added the basic hwmod data for OMAP5 iommus (Patch 12) - Clean up the iommu hwmod data and remove the legacy file for creating IOMMU devices (Patches 14, 15, 16). - Dropped the "iommu/omap: Do bus_set_iommu() only if probe() succeeds" patch from previous series. - Dropped the OMAP3 ISP MMU DTS patch (posting separately). v1: - Couple of cleanup and initial DT adaptation for OMAP3 ISP. http://marc.info/?l=linux-omap&m=138728485600624&w=2 Florian Vaussard (4): iommu/omap: allow enable/disable even without pdata Documentation: dt: add OMAP iommu bindings iommu/omap: add devicetree support ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2 Laurent Pinchart (1): iommu/omap: allocate archdata on the fly for DT-based devices Suman Anna (8): iommu/omap: convert to devm_* interfaces iommu/omap: fix error return paths in omap_iommu_attach() iommu/omap: enable bus-error back on supported iommus ARM: OMAP3: fix iva mmu programming issues ARM: OMAP2+: change the ISP device archdata MMU name for DT ARM: OMAP2+: use pdata quirks for iommu reset lines ARM: OMAP5: hwmod data: add mmu data for ipu & dsp ARM: OMAP2+: extend iommu pdata-quirks to OMAP5 .../devicetree/bindings/iommu/ti,omap-iommu.txt| 26 arch/arm/mach-omap2/clockdomains3xxx_data.c| 2 +- arch/arm/mach-omap2/devices.c | 3 + arch/arm/mach-omap2/omap-iommu.c | 5 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12 +- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 83 +++ arch/arm/mach-omap2/pdata-quirks.c | 24 arch/arm/plat-omap/Kconfig | 3 - drivers/iommu/omap-iommu.c | 159 + drivers/iommu/omap-iommu.h | 5 + drivers/iommu/omap-iommu2.c| 3 + 11 files changed, 256 insertions(+), 69 deletions(-) create mode 100644 Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 01/13] iommu/omap: convert to devm_* interfaces
Use the various devm_ interfaces to simplify the cleanup in
probe and remove functions.
Signed-off-by: Florian Vaussard
Signed-off-by: Suman Anna
Acked-by: Laurent Pinchart
---
drivers/iommu/omap-iommu.c | 52 +-
1 file changed, 10 insertions(+), 42 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index bcd78a7..fff2ffd 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -941,7 +941,7 @@ static int omap_iommu_probe(struct platform_device *pdev)
struct resource *res;
struct iommu_platform_data *pdata = pdev->dev.platform_data;
- obj = kzalloc(sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
+ obj = devm_kzalloc(&pdev->dev, sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
if (!obj)
return -ENOMEM;
@@ -958,33 +958,18 @@ static int omap_iommu_probe(struct platform_device *pdev)
INIT_LIST_HEAD(&obj->mmap);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- err = -ENODEV;
- goto err_mem;
- }
-
- res = request_mem_region(res->start, resource_size(res),
-dev_name(&pdev->dev));
- if (!res) {
- err = -EIO;
- goto err_mem;
- }
-
- obj->regbase = ioremap(res->start, resource_size(res));
- if (!obj->regbase) {
- err = -ENOMEM;
- goto err_ioremap;
- }
+ obj->regbase = devm_ioremap_resource(obj->dev, res);
+ if (IS_ERR(obj->regbase))
+ return PTR_ERR(obj->regbase);
irq = platform_get_irq(pdev, 0);
- if (irq < 0) {
- err = -ENODEV;
- goto err_irq;
- }
- err = request_irq(irq, iommu_fault_handler, IRQF_SHARED,
- dev_name(&pdev->dev), obj);
+ if (irq < 0)
+ return -ENODEV;
+
+ err = devm_request_irq(obj->dev, irq, iommu_fault_handler, IRQF_SHARED,
+ dev_name(obj->dev), obj);
if (err < 0)
- goto err_irq;
+ return err;
platform_set_drvdata(pdev, obj);
pm_runtime_irq_safe(obj->dev);
@@ -992,34 +977,17 @@ static int omap_iommu_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "%s registered\n", obj->name);
return 0;
-
-err_irq:
- iounmap(obj->regbase);
-err_ioremap:
- release_mem_region(res->start, resource_size(res));
-err_mem:
- kfree(obj);
- return err;
}
static int omap_iommu_remove(struct platform_device *pdev)
{
- int irq;
- struct resource *res;
struct omap_iommu *obj = platform_get_drvdata(pdev);
iopgtable_clear_entry_all(obj);
- irq = platform_get_irq(pdev, 0);
- free_irq(irq, obj);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(res->start, resource_size(res));
- iounmap(obj->regbase);
-
pm_runtime_disable(obj->dev);
dev_info(&pdev->dev, "%s removed\n", obj->name);
- kfree(obj);
return 0;
}
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 08/16] ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2
Paul, On 02/28/2014 01:58 PM, Paul Walmsley wrote: On Thu, 13 Feb 2014, Suman Anna wrote: From: Florian Vaussard CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting usage by tidspbridge and other iommu users. The same can be achieved by marking the DT node disabled, so remove this obsolete flag and the corresponding hwmod data can be enabled. Cc: Paul Walmsley Signed-off-by: Florian Vaussard [s-a...@ti.com: revise commit log] Signed-off-by: Suman Anna Acked-by: Paul Walmsley Am assuming that someone else will be merging this as part of the entire series. Thanks, I am expecting Tony to pick up all the arch/arm/mach-omap2/ patches. I am just about to send the v3 including all the acks received so far. regards Suman -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv1 1/2] rx51_battery: convert to iio consumer
Hi Sebastian, On Fri, Feb 28, 2014 at 3:05 AM, Sebastian Reichel wrote: > On Thu, Feb 27, 2014 at 10:34:35PM +0100, Belisko Marek wrote: >> Well I've tried and it's worse :). I got during booting: >> [2.218383] ERROR: could not get IIO channel /battery:temp(0) >> [2.224639] platform battery.4: Driver twl4030_madc_battery >> requests probe deferral >> Not sure if it's just error or warning but temp is always reported as >> 0 (and also other values in sysfs). > > This is an error, which basically means, that twl4030-madc has not > yet been loaded. Do you get proper values when you use the old madc > API with the patchset applied? It works without converting to iio consumer (at least I get some reasonable values). With conversion it fails with above error. I recheck (add printk to iio twl4030-madc) that madc driver is loaded. Could this be that twl4030_madc_battery is loaded earlier then twl4030_madc and than it fails to get iio channels? > > -- Sebastian BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] ARM: dts: tegra: add PCIe interrupt mapping properties
On 02/28/2014 10:28 AM, Lucas Stach wrote: > Those are defined by the common PCI binding. I have no reason to object to the two Tegra patches, but I'll wait for Thierry to take a closer look. I expect once he does, I would apply patch 1/7 through the Tegra tree, and Bjorn would take patch 2/7 through the PCI tree. Does that make sense? -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] PCI: designware: split samsung and fsl bindings
On Fri, Feb 28, 2014 at 9:28 AM, Lucas Stach wrote:
> The glue around the core designware IP is
> significantly different between the Exynos and
> i.MX, which is reflected in the DT bindings.
>
> Note that this patch doesn't change any bindings,
> but just alters the documentation to match reality
> of deployed DTs and kernels.
>
> Signed-off-by: Lucas Stach
> ---
> .../devicetree/bindings/pci/designware-pcie.txt| 69 +
> .../devicetree/bindings/pci/fsl,imx6q-pcie.txt | 48 +++
> .../bindings/pci/samsung,exynos5440-pcie.txt | 70
> ++
> 3 files changed, 119 insertions(+), 68 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> create mode 100644
> Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> index d6fae13ff062..8274c80fe874 100644
> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> @@ -1,15 +1,7 @@
> * Synopsys Designware PCIe interface
>
> Required properties:
> -- compatible: should contain "snps,dw-pcie" to identify the
> - core, plus an identifier for the specific instance, such
> - as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie".
> -- reg: base addresses and lengths of the pcie controller,
> - the phy controller, additional register for the phy controller.
> -- interrupts: interrupt values for level interrupt,
> - pulse interrupt, special interrupt.
> -- clocks: from common clock binding: handle to pci clock.
> -- clock-names: from common clock binding: should be "pcie" and "pcie_bus".
> +- compatible: should contain "snps,dw-pcie" to identify the core.
> - #address-cells: set to <3>
> - #size-cells: set to <2>
> - device_type: set to "pci"
> @@ -22,62 +14,3 @@ Required properties:
>
> Optional properties:
> - reset-gpio: gpio pin number of power good signal
> -
> -Optional properties for fsl,imx6q-pcie
> -- power-on-gpio: gpio pin number of power-enable signal
> -- wake-up-gpio: gpio pin number of incoming wakeup signal
> -- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal
> -
> -Example:
> -
> -SoC specific DT Entry:
> -
> - pcie@29 {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x29 0x1000
> - 0x27 0x1000
> - 0x271000 0x40>;
> - interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
> - clocks = <&clock 28>, <&clock 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x4000 0x4000 0 0x1000
> /* configuration space */
> - 0x8100 0 0 0x40001000 0 0x0001
> /* downstream I/O */
> - 0x8200 0 0x40011000 0x40011000 0 0x1ffef000>;
> /* non-prefetchable memory */
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0x0 0 &gic 53>;
> - num-lanes = <4>;
> - };
> -
> - pcie@2a {
> - compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
> - reg = <0x2a 0x1000
> - 0x272000 0x1000
> - 0x271040 0x40>;
> - interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
> - clocks = <&clock 29>, <&clock 27>;
> - clock-names = "pcie", "pcie_bus";
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges = <0x0800 0 0x6000 0x6000 0 0x1000
> /* configuration space */
> - 0x8100 0 0 0x60001000 0 0x0001
> /* downstream I/O */
> - 0x8200 0 0x60011000 0x60011000 0 0x1ffef000>;
> /* non-prefetchable memory */
> - #interrupt-cells = <1>;
> - interrupt-map-mask = <0 0 0 0>;
> - interrupt-map = <0x0 0 &gic 56>;
> - num-lanes = <4>;
> - };
> -
> -Board specific DT Entry:
> -
> - pcie@29 {
> - reset-gpio = <&pin_ctrl 5 0>;
> - };
> -
> - pcie@2a {
> - reset-gpio = <&pin_ctrl 22 0>;
> - };
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> new file mode 100644
> index ..93fbfd62f13c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
> @@ -0,0 +1,48 @@
> +* Freescale i.MX6 PCIe interface
> +
> +This PCIe host controller is based on the S
Re: [PATCH 0/7] PCI irq mapping fixes and cleanups
On Friday 28 February 2014, Lucas Stach wrote: > This series cleans up the PCI irq mapping for all > the ARM PCI host drivers, so they handle it in the > way defined in the common PCI bindings. > > Testing appreciated. > > Lucas Stach (7): > ARM: dts: tegra: add PCIe interrupt mapping properties > PCI: tegra: use new OF interrupt mapping when possible > PCI: rcar: use new OF interrupt mapping when possible > ARM: dts: exynos5440: fix PCIe interrupt mapping > ARM: dts: imx6: add PCIe interrupt mapping properties > PCI: designware: use new OF interrupt mapping when possible > PCI: designware: split samsung and fsl bindings Patches 1-6 Acked-by: Arnd Bergmann For the last patch, the clock information looks like it needs to be fixed. I realize that you are just documenting what the driver is using at the moment, but that is not a proper way of establishing a binding. Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] PCI: designware: split samsung and fsl bindings
On Friday 28 February 2014, Lucas Stach wrote: > +Required properties: > +- compatible: "fsl,imx6q-pcie" > +- reg: base addresse and length of the pcie controller > +- interrupts: First entry must contain interrupt handle for controller > + INTA output. I think this should be documented as "optional" and only for backwards compatibility with old kernels. > +- clocks: Must contain an entry for each entry in clock-names. > + See ../clocks/clock-bindings.txt for details. > +- clock-names: Must include the following entries: > + - "pcie_ref_125m" > + - "sata_ref_100m" > + - "lvds_gate" > + - "pcie_axi" I don't understand why you have completely different clocks here from the exynos documentation. The clock names should really be the same. Also, why do you have a "sata_ref_100m" clock? Is this just driving a device that happens to be on-board for a specific machine? Same for the "lvds_gate". Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 08/16] ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2
On Thu, 13 Feb 2014, Suman Anna wrote: > From: Florian Vaussard > > CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting > usage by tidspbridge and other iommu users. The same can be achieved > by marking the DT node disabled, so remove this obsolete flag and > the corresponding hwmod data can be enabled. > > Cc: Paul Walmsley > Signed-off-by: Florian Vaussard > [s-a...@ti.com: revise commit log] > Signed-off-by: Suman Anna Acked-by: Paul Walmsley Am assuming that someone else will be merging this as part of the entire series. - Paul -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/12] ARM: OMAP2: PRM: add support for OMAP2 specific clock providers
On 02/28/2014 03:23 AM, Tero Kristo wrote:
> This patch adds support for initializing also omap2-prcm and omap2-scrm
> through DT.
>
> Signed-off-by: Tero Kristo
> ---
> arch/arm/mach-omap2/prm_common.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/prm_common.c
> b/arch/arm/mach-omap2/prm_common.c
> index b4c4ab9..878ae9f 100644
> --- a/arch/arm/mach-omap2/prm_common.c
> +++ b/arch/arm/mach-omap2/prm_common.c
> @@ -475,6 +475,8 @@ static struct of_device_id omap_prcm_dt_match_table[] = {
> { .compatible = "ti,am3-scrm" },
> { .compatible = "ti,am4-prcm" },
> { .compatible = "ti,am4-scrm" },
> + { .compatible = "ti,omap2-prcm" },
> + { .compatible = "ti,omap2-scrm" },
> { .compatible = "ti,omap3-prm" },
> { .compatible = "ti,omap3-cm" },
> { .compatible = "ti,omap3-scrm" },
>
probably needs Bindings documentation as well.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/12] CLK: TI: APLL: add support for omap2 aplls
On 02/28/2014 03:22 AM, Tero Kristo wrote:
[...]
> +static void __init of_omap2_apll_setup(struct device_node *node)
> +{
> + struct dpll_data *ad = NULL;
> + struct clk_hw_omap *clk_hw = NULL;
> + struct clk_init_data *init = NULL;
> + struct clk *clk;
> + const char *parent_name;
> + u32 val;
> +
> + ad = kzalloc(sizeof(*clk_hw), GFP_KERNEL);
> + clk_hw = kzalloc(sizeof(*clk_hw), GFP_KERNEL);
> + init = kzalloc(sizeof(*init), GFP_KERNEL);
> +
> + if (!ad || !clk_hw || !init)
> + goto cleanup;
> +
> + clk_hw->dpll_data = ad;
> + clk_hw->hw.init = init;
> + init->ops = &omap2_apll_ops;
> + init->name = node->name;
> + clk_hw->ops = &omap2_apll_hwops;
> +
> + init->num_parents = of_clk_get_parent_count(node);
> + if (init->num_parents != 1) {
> + pr_err("%s must have one parent\n", node->name);
> + goto cleanup;
> + }
> +
> + parent_name = of_clk_get_parent_name(node, 0);
> + init->parent_names = &parent_name;
> +
> + if (of_property_read_u32(node, "ti,clock-frequency", &val)) {
> + pr_err("%s missing clock-frequency\n", node->name);
> + goto cleanup;
> + }
> + clk_hw->fixed_rate = val;
> +
> + if (of_property_read_u32(node, "ti,bit-shift", &val)) {
> + pr_err("%s missing bit-shift\n", node->name);
> + goto cleanup;
> + }
> +
> + clk_hw->enable_bit = val;
> + ad->enable_mask = 0x3 << val;
> + ad->autoidle_mask = 0x3 << val;
> +
> + if (of_property_read_u32(node, "ti,idlest-shift", &val)) {
> + pr_err("%s missing idlest-shift\n", node->name);
> + goto cleanup;
> + }
> +
> + ad->idlest_mask = 1 << val;
> +
> + ad->control_reg = ti_clk_get_reg_addr(node, 0);
> + ad->autoidle_reg = ti_clk_get_reg_addr(node, 1);
> + ad->idlest_reg = ti_clk_get_reg_addr(node, 2);
> +
> + if (!ad->control_reg || !ad->autoidle_reg || !ad->idlest_reg)
> + goto cleanup;
> +
> + clk = clk_register(NULL, &clk_hw->hw);
> + if (!IS_ERR(clk)) {
> + of_clk_add_provider(node, of_clk_src_simple_get, clk);
> + kfree(init);
> + return;
> + }
> +cleanup:
> + kfree(clk_hw);
> + kfree(init);
kfree(ad)?
smatch reported (as part of the kernel_patch_verify_report:
+drivers/clk/ti/apll.c:400 of_omap2_apll_setup() warn: possible memory
leak of 'ad'
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 7/9] devicetree: bindings: Document PM8921/8058 keypads
On Fri, Feb 28, 2014 at 10:37:08AM -0800, Stephen Boyd wrote:
> On 02/28, Josh Cartwright wrote:
> > On Thu, Feb 27, 2014 at 05:55:18PM -0800, Stephen Boyd wrote:
> > > +
> > > +EXAMPLE
> > > +
> > > + keypad {
> > > + compatible = "qcom,pm8921-keypad";
> > > + interrupt-parent = <&pmicintc>;
> > > + interrupts = <74 1>, <75 1>;
> > > + linux,keymap = <
> > > + MATRIX_KEY(0, 0, KEY_VOLUMEUP)
> > > + MATRIX_KEY(0, 1, KEY_VOLUMEDOWN)
> > > + MATRIX_KEY(0, 2, KEY_CAMERA_FOCUS)
> > > + MATRIX_KEY(0, 3, KEY_CAMERA)
> > > + >;
> > > + keypad,num-rows = <1>;
> > > + keypad,num-columns = <5>;
> > > + debounce = <15>;
> > > + scan-delay = <32>;
> > > + row-hold = <91500>;
> > > + };
> >
> > It odd to me that these newly created bindings don't have 'reg'
> > properties, even though the device clearly has a register region.
> >
> > I suppose it makes sense from a "port over from platform data to DT"
> > perspective, as these drivers have just assumed the location of their
> > registers to be fixed; however I suspect things will need to be changed
> > if/when we hope to share these drivers with pm8841/pm8941 and beyond...
> >
>
> Agreed. I would love it if the platform OF code would create
> IORESOURCE_REG resources for any reg properties that aren't
> translatable to CPU addresses. That way we don't have to pick out the
> reg property from DT with special OF code (like you've done in
> rtc-pm8xxx).
Yes, I agree this would be nice. The rtc-pm8xxx register parsing magic
is misplaced/ugly. I'll see about taking a crack at this and seeing
what it looks like.
> I'll throw the reg property into the binding so that in
> the future we can support the register moving around (although at the
> moment the driver will ignore it).
Great, I think this sounds good.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 7/9] devicetree: bindings: Document PM8921/8058 keypads
On 02/28, Josh Cartwright wrote:
> On Thu, Feb 27, 2014 at 05:55:18PM -0800, Stephen Boyd wrote:
>
> - linux,wakeup?
> - linux,no-auto-repeat?
Added.
>
> > +
> > +EXAMPLE
> > +
> > + keypad {
> > + compatible = "qcom,pm8921-keypad";
> > + interrupt-parent = <&pmicintc>;
> > + interrupts = <74 1>, <75 1>;
> > + linux,keymap = <
> > + MATRIX_KEY(0, 0, KEY_VOLUMEUP)
> > + MATRIX_KEY(0, 1, KEY_VOLUMEDOWN)
> > + MATRIX_KEY(0, 2, KEY_CAMERA_FOCUS)
> > + MATRIX_KEY(0, 3, KEY_CAMERA)
> > + >;
> > + keypad,num-rows = <1>;
> > + keypad,num-columns = <5>;
> > + debounce = <15>;
> > + scan-delay = <32>;
> > + row-hold = <91500>;
> > + };
>
> It odd to me that these newly created bindings don't have 'reg'
> properties, even though the device clearly has a register region.
>
> I suppose it makes sense from a "port over from platform data to DT"
> perspective, as these drivers have just assumed the location of their
> registers to be fixed; however I suspect things will need to be changed
> if/when we hope to share these drivers with pm8841/pm8941 and beyond...
>
Agreed. I would love it if the platform OF code would create
IORESOURCE_REG resources for any reg properties that aren't
translatable to CPU addresses. That way we don't have to pick out
the reg property from DT with special OF code (like you've done
in rtc-pm8xxx). I'll throw the reg property into the binding so
that in the future we can support the register moving around
(although at the moment the driver will ignore it).
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] ARM: OMAP2 DT clock conversion
* Tero Kristo [140228 10:21]: > > Hmm, some clock node is broken, might be missing a name or parent > name for some reason. Can you try to boot with DEBUG enabled so you > get pr_debug:s out and see which clock is being initialized during > the crash? ... [0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: core_d18_ck [0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: vlynq_mux_fck [0.00] ti_dt_clk_init_provider: ti_dt_clk_init_provider: initializing: vlynq_fck [0.00] Unable to handle kernel NULL pointer dereference at virtual address ... We really should be registering the clocks lazily as needed BTW. That leaves out the dependency to DEBUG_LL for seeing any kind of decent error messages during the booting. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] ARM: OMAP2 DT clock conversion
On 02/28/2014 08:01 PM, Tony Lindgren wrote: * Nishanth Menon [140228 08:02]: On 02/28/2014 03:22 AM, Tero Kristo wrote: Hi, This set concludes the omap2+ clock DT conversion work by creating the DT clock data for omap2 SoC also. I am also currently doing related work to cleanup CM/PRM codebase in preparation to move it into drivers/, this set is basically going to be a pre-requisite for that. I'll hopefully post something related to that early next week. This set has been boot tested on OMAP2430 only (thanks Nishanth, I don't have access to OMAP2 hardware myself), so any testing feedback on 2420 board(s) would be appreciated. Working tree: Tree: https://github.com/t-kristo/linux-pm.git Branch: 3.14-rc4-omap2-dt-clks I do see checkpatch warnings in the series: http://slexy.org/view/s20mzhlJ93 Series boot tested with: 3.14-rc4-omap2-dt-clks fc73a96 ARM: OMAP2: clock: use DT clock boot if available from the tree mentioned above. Things look good other than the checkpatch violation noticed in report, so other than that, I noticed the checkpatch warnings also, most of them are impossible to fix, and/or are false warnings (see the fixed-factor / fixed-clock complaints for example.) Tested-by: Nishanth Menon omap2plus_defconfig 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2jdV3XMCC 2: am335x-sk: Boot PASS: http://slexy.org/raw/s210nZI8Hx 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21MG8kg6u 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20coVhzLt 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21XKjjwyk 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s27PCmlDq7 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2HX1Q3iPb 8: crane: No Image built - Missing platform support?: 9: dra7: Boot PASS: http://slexy.org/raw/s21ofDfpD2 10:ldp: Boot FAIL: http://slexy.org/raw/s2SbrpyX2p ^^ legacy behavior 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s21n4iMUKd 12:sdp2430: Boot PASS: http://slexy.org/raw/s2CJ5hYl72 13:sdp3430: Boot PASS: http://slexy.org/raw/s20axZ1nyb 14:sdp4430: Boot PASS: http://slexy.org/raw/s21wt3C5F3 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s208PhmCpm TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2 I'm getting this with omap2 only build: drivers/clk/ti/dpll.c:235: undefined reference to `clkhwops_omap3_dpll' drivers/built-in.o:(.rodata+0x1dd50): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0x1dd54): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0x1dd60): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0x1dd74): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0x1ddb8): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0x1ddfc): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0x1de10): undefined reference to `omap3_noncore_dpll_set_rate' And this if 2430 is not selected: drivers/clk/ti/interface.c:129: undefined reference to `clkhwops_omap2430_i2chs_wait' Hmm okay, these should be easy to fix... I'll need to see if I have introduced some other build breakages also... Then I get this early on when trying to boot on n800: [0.00] Unable to handle kernel NULL pointer dereference at virtual address [0.00] pgd = c0004000 [0.00] [] *pgd= [0.00] Internal error: Oops: 5 [#1] ARM [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 3.14.0-rc1-00012-ga93a376 #225 [0.00] task: c073ee80 ti: c0734000 task.ti: c0734000 [0.00] PC is at strcmp+0xc/0x34 [0.00] LR is at __clk_init+0x244/0x4d0 [0.00] pc : []lr : []psr: 21d3 [0.00] sp : c0735e68 ip : c781cf80 fp : c05440b8 [0.00] r10: r9 : c781ba80 r8 : c781ba80 [0.00] r7 : 000b r6 : c781ba80 r5 : 000b r4 : c0cf27f4 [0.00] r3 : c781cfc0 r2 : r1 : r0 : 0076 [0.00] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 00c5387d Table: 80004000 DAC: 0017 [0.00] Process swapper (pid: 0, stack limit = 0xc0734240) [0.00] Stack: (0xc0735e68 to 0xc0736000) [0.00] 5e60: c7df5868 c781ba00 000b c781cfc0 c781ba80 c781ba00 [0.00] 5e80: c781ce80 c0544074 c0401bcc c781ba80 c781ba00 c7df5a68 [0.00] 5ea0: c781cec0 c0401d08 c05442b8 c781ba00 000b c0403070 c0686038 [0.00] 5ec0: c0686038 c7df5a68 c781ba08 c781cec0 c0735f0b 0020 c0d09ce8 [0.00] 5ee0: c781cf40 c781cf40 c781cf4c 4107b362 c7df59a8 c0719f30 [0.00] 5f00: c781ce80 c05442b8 c0544074 c781cc80 c05440b8 c781cf44 [0.00] 5f20: 4107b362 c7df59a8 c781cf40 0002 0002 c781cf48 c0735
[PATCH 1/5] Power: reset: keystone-reset: introduce keystone reset driver
The keystone SoC can be rebooted in several ways. By external reset
pin, by soft and by watchdogs. To allow keystone SoC reset if
watchdog is triggered we have to enable it in reset mux configuration
register regarding of watchdog configuration. Also we need to set
soft/hard reset we are going to use.
So add keystone reset driver to handle all this stuff.
Signed-off-by: Ivan Khoronzhuk
---
CC: Dmitry Eremin-Solenikov
CC: David Woodhouse
CC: Grant Likely
CC: Rob Herring
drivers/power/reset/Kconfig | 7 ++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/keystone-reset.c | 171 +++
3 files changed, 179 insertions(+)
create mode 100644 drivers/power/reset/keystone-reset.c
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 6d452a7..9082a72 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -57,3 +57,10 @@ config POWER_RESET_XGENE
depends on POWER_RESET
help
Reboot support for the APM SoC X-Gene Eval boards.
+
+config POWER_RESET_KEYSTONE
+ bool "Keystone reset driver"
+ depends on ARCH_KEYSTONE
+ help
+ Reboot support for the KEYSTONE SoCs.
+
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index a5b4a77..802a420 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
+obj-$(CONFIG_POWER_RESET_KEYSTONE) += keystone-reset.o
diff --git a/drivers/power/reset/keystone-reset.c
b/drivers/power/reset/keystone-reset.c
new file mode 100644
index 000..73f6e7a
--- /dev/null
+++ b/drivers/power/reset/keystone-reset.c
@@ -0,0 +1,171 @@
+/*
+ * TI keystone reboot driver
+ *
+ * Copyright (C) 2014 Texas Instruments Incorporated. http://www.ti.com/
+ *
+ * Author: Ivan Khoronzhuk
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+
+#define RSCTRL_KEY_MASK0x
+#define RSCTRL_KEY 0x5a69
+#define RSCTRL_RESET BIT(16)
+
+#define RSCFG_RSTYPE_SOFT 0x300f
+#define RSCFG_RSTYPE_HARD 0x0
+
+#define RSTYPE_RG 0x0
+#define RSCTRL_RG 0x4
+#define RSCFG_RG 0x8
+#define RSISO_RG 0xc
+
+#define RSMUX_OMODE_MASK 0xe
+#define RSMUX_OMODE_RESET_SOC 0xa
+#define RSMUX_OMODE_RESET_OFF 0x0
+#define RSMUX_LOCK_MASK0x1
+#define RSMUX_LOCK_SET 0x1
+
+#define WDT_MUX_NUMBER 0x4
+
+static void __iomem *rspll_base;
+
+/**
+ * rsctrl_enable_rspll_write - enable access to RSCTRL, RSCFG
+ * To be able to access to RSCTRL, RSCFG registers
+ * we has to write a key before
+ */
+static void rsctrl_enable_rspll_write(void)
+{
+ void __iomem *rstctrl_rg;
+ u32 val;
+
+ rstctrl_rg = rspll_base + RSCTRL_RG;
+ val = readl(rstctrl_rg);
+ val &= RSCTRL_KEY_MASK;
+ val |= RSCTRL_KEY;
+ writel(val, rstctrl_rg);
+}
+
+static void rsctrl_restart(enum reboot_mode mode, const char *cmd)
+{
+ u32 val;
+ void __iomem *rstctrl;
+
+ /* enable write access to RSTCTRL */
+ rsctrl_enable_rspll_write();
+
+ /* reset the SOC */
+ rstctrl = rspll_base + RSCTRL_RG;
+ val = readl(rstctrl);
+ val &= ~RSCTRL_RESET;
+ writel(val, rstctrl);
+}
+
+static struct of_device_id rsctrl_of_match[] = {
+ {.compatible = "ti,keystone-reset", },
+ {},
+};
+
+static int rsctrl_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ void __iomem *rsmux_base;
+ void __iomem *rg;
+ struct resource *res;
+ u32 val;
+ int ret;
+ int i;
+
+ if (!np)
+ return -ENODEV;
+
+ i = of_property_match_string(np, "reg-names", "pllregs");
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ rspll_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(rspll_base))
+ return PTR_ERR(rspll_base);
+
+ i = of_property_match_string(np, "reg-names", "muxregs");
+ res = platform_get_resource(pdev, IORESOURCE_MEM, i);
+ rsmux_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(rsmux_base))
+ return PTR_ERR(rsmux_base);
+
+ /* set soft/hard reset */
+ val = of_property_read_bool(np, "ti,soft-reset");
+ val = val ? RSCFG_RSTYPE_SOFT : RSCFG_RSTYPE_HARD;
+
+ rsctr
[PATCH 2/5] Power: reset: add bindings for keystone reset driver
This node is intended to allow SoC reset in case of software reset
or appropriate watchdogs.
The Keystone SoCs can contain up to 4 watchdog timers to reset
SoC. Each watchdog timer event input is connected to the Reset Mux
block. The Reset Mux block can be configured to cause reset or not.
Additionally soft or hard reset can be configured.
Signed-off-by: Ivan Khoronzhuk
---
CC: Rob Herring
CC: Pawel Moll
CC: Mark Rutland
CC: Ian Campbell
CC: Kumar Gala
CC: Rob Landley
.../bindings/power/reset/keystone-reset.txt| 59 ++
1 file changed, 59 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power/reset/keystone-reset.txt
diff --git a/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
new file mode 100644
index 000..5ad5883
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
@@ -0,0 +1,59 @@
+* Device tree bindings for Texas Instruments keystone reset
+
+This node is intended to allow SoC reset in case of software reset
+of selected watchdogs.
+
+The Keystone SoCs can contain up to 4 watchdog timers to reset
+SoC. Each watchdog timer event input is connected to the Reset Mux
+block. The Reset Mux block can be configured to cause reset or not.
+
+Additionally soft or hard reset can be configured.
+
+Required properties:
+
+- compatible: ti,keystone-reset
+
+- reg: Contains offset/length value for mux registers.
+
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
+
+-reg-names:Contains two ranges "pllregs" and "muxregs".
+ "pllregs" - PLL reset control regs: RSTYPE, RSCTRL,
+ RSCFG, RSISO.
+ "muxregs" - mux block registers for all watchdogs.
+
+Optional properties:
+
+- ti,soft-reset: Boolean option indicating soft reset.
+ By default hard reset is used.
+
+- ti,wdt_list: WDT list that can cause SoC reset.
+ The list in format: <0>, <2>;
+ Begins from 0 to 3, as keystone can contain up
+ to 4 SoC reset watchdogs.
+
+Example 1:
+Setup keystone reset so that in case software reset or
+WDT1 is triggered it issues hard reset for SoC.
+
+rstctrl: reset-controller {
+ compatible = "ti,keystone-reset";
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
+ reg-names = "pllregs", "muxregs";
+ ti,wdt_list = <0>;
+};
+
+Example 2:
+Setup keystone reset so that in case of software reset or
+WDT1 or WDT3 is triggered it issues soft reset for SoC.
+
+rstctrl: reset-controller {
+ compatible = "ti,keystone-reset";
+ reg = <0x23100e4 0x10>,
+ <0x2620328 0x10>;
+ reg-names = "pllregs", "muxregs";
+ ti,wdt_list = <0>, <2>;
+ ti,soft-reset;
+};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] ARM: dts: keystone: update reset node to work with reset driver
The reset controller registers are part of the PLL Controller MMRs.
According to TRM there are the following registers:
RSTYPE, RSCTRL, RSCFG and RSISO. Currently declared only one of them,
but that is not enough to correctly setup reset properties, so add
whole range of pll registers - pllregs.
Also add range for reset multiplex registers for SoC on the device.
These registers are located in Bootcfg memory space and needed
to setup behaviour after appropriate watchdog is triggered.
Add "ti,wdt_list" option to declare what watchdog are used to reboot
the SoC.
Signed-off-by: Ivan Khoronzhuk
---
CC: Rob Herring
CC: Pawel Moll
CC: Mark Rutland
CC: Ian Campbell
CC: Kumar Gala
CC: Russell King
arch/arm/boot/dts/keystone.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 3a83ffe..7092208 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -99,7 +99,9 @@
rstctrl: reset-controller {
compatible = "ti,keystone-reset";
- reg = <0x023100e8 4>; /* pll reset control reg */
+ reg = <0x23100e4 0x10>, <0x2620328 0x10>;
+ reg-names = "pllregs", "muxregs";
+ ti,wdt_list = <0>;
};
/include/ "keystone-clocks.dtsi"
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Introduce keystone reset driver
These patches introduce keystone reset driver. The keystone SoC can be rebooted in several ways. By external reset pin, by soft and by watchdogs. This driver allows software reset or reset by one of the watchdogs. Also added opportunity to set soft/hard reset type. Based on v3.14-rc4 CC: Dmitry Eremin-Solenikov CC: David Woodhouse CC: Grant Likely CC: Rob Herring CC: Pawel Moll CC: Mark Rutland CC: Ian Campbell CC: Kumar Gala CC: Rob Landley CC: Santosh Shilimkar CC: Russell King Ivan Khoronzhuk (5): Power: reset: keystone-reset: introduce keystone reset driver Power: reset: add bindings for keystone reset driver ARM: keystone: remove redundant reset stuff ARM: dts: keystone: update reset node to work with reset driver ARM: keystone: enable reset driver support .../bindings/power/reset/keystone-reset.txt| 59 +++ arch/arm/boot/dts/keystone.dtsi| 4 +- arch/arm/configs/keystone_defconfig| 3 + arch/arm/mach-keystone/keystone.c | 35 - drivers/power/reset/Kconfig| 7 + drivers/power/reset/Makefile | 1 + drivers/power/reset/keystone-reset.c | 171 + 7 files changed, 244 insertions(+), 36 deletions(-) create mode 100644 Documentation/devicetree/bindings/power/reset/keystone-reset.txt create mode 100644 drivers/power/reset/keystone-reset.c -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] ARM: keystone: enable reset driver support
Enable reset driver support in order to have opportunity to reboot SoC by watchdog and by software. Signed-off-by: Ivan Khoronzhuk --- CC: Russell King CC: Santosh Shilimkar arch/arm/configs/keystone_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig index 4582e16..3f9c688 100644 --- a/arch/arm/configs/keystone_defconfig +++ b/arch/arm/configs/keystone_defconfig @@ -130,6 +130,9 @@ CONFIG_SPI=y CONFIG_SPI_DAVINCI=y CONFIG_SPI_SPIDEV=y # CONFIG_HWMON is not set +CONFIG_POWER_SUPPLY=y +CONFIG_POWER_RESET=y +CONFIG_POWER_RESET_KEYSTONE=y CONFIG_WATCHDOG=y CONFIG_USB=y CONFIG_USB_DEBUG=y -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] ARM: keystone: remove redundant reset stuff
Remove reset stuff in flavour of using keystone reset driver:
driver/power/reset/keystone-reset.c
Signed-off-by: Ivan Khoronzhuk
---
CC: Santosh Shilimkar
CC: Russell King
arch/arm/mach-keystone/keystone.c | 35 ---
1 file changed, 35 deletions(-)
diff --git a/arch/arm/mach-keystone/keystone.c
b/arch/arm/mach-keystone/keystone.c
index 6e6bb7d..4d46e30 100644
--- a/arch/arm/mach-keystone/keystone.c
+++ b/arch/arm/mach-keystone/keystone.c
@@ -23,24 +23,8 @@
#include "keystone.h"
-#define PLL_RESET_WRITE_KEY_MASK 0x
-#define PLL_RESET_WRITE_KEY0x5a69
-#define PLL_RESET BIT(16)
-
-static void __iomem *keystone_rstctrl;
-
static void __init keystone_init(void)
{
- struct device_node *node;
-
- node = of_find_compatible_node(NULL, NULL, "ti,keystone-reset");
- if (WARN_ON(!node))
- pr_warn("ti,keystone-reset node undefined\n");
-
- keystone_rstctrl = of_iomap(node, 0);
- if (WARN_ON(!keystone_rstctrl))
- pr_warn("ti,keystone-reset iomap error\n");
-
keystone_pm_runtime_init();
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
@@ -50,24 +34,6 @@ static const char *keystone_match[] __initconst = {
NULL,
};
-void keystone_restart(enum reboot_mode mode, const char *cmd)
-{
- u32 val;
-
- BUG_ON(!keystone_rstctrl);
-
- /* Enable write access to RSTCTRL */
- val = readl(keystone_rstctrl);
- val &= PLL_RESET_WRITE_KEY_MASK;
- val |= PLL_RESET_WRITE_KEY;
- writel(val, keystone_rstctrl);
-
- /* Reset the SOC */
- val = readl(keystone_rstctrl);
- val &= ~PLL_RESET;
- writel(val, keystone_rstctrl);
-}
-
DT_MACHINE_START(KEYSTONE, "Keystone")
#if defined(CONFIG_ZONE_DMA) && defined(CONFIG_ARM_LPAE)
.dma_zone_size = SZ_2G,
@@ -75,5 +41,4 @@ DT_MACHINE_START(KEYSTONE, "Keystone")
.smp= smp_ops(keystone_smp_ops),
.init_machine = keystone_init,
.dt_compat = keystone_match,
- .restart= keystone_restart,
MACHINE_END
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/12] ARM: OMAP2 DT clock conversion
* Nishanth Menon [140228 08:02]: > On 02/28/2014 03:22 AM, Tero Kristo wrote: > > Hi, > > > > This set concludes the omap2+ clock DT conversion work by creating the > > DT clock data for omap2 SoC also. > > > > I am also currently doing related work to cleanup CM/PRM codebase in > > preparation to move it into drivers/, this set is basically going to > > be a pre-requisite for that. I'll hopefully post something related > > to that early next week. > > > > This set has been boot tested on OMAP2430 only (thanks Nishanth, I don't > > have access to OMAP2 hardware myself), so any testing feedback on > > 2420 board(s) would be appreciated. > > > > Working tree: > > > > Tree: https://github.com/t-kristo/linux-pm.git > > Branch: 3.14-rc4-omap2-dt-clks > > I do see checkpatch warnings in the series: > http://slexy.org/view/s20mzhlJ93 > > Series boot tested with: > 3.14-rc4-omap2-dt-clks fc73a96 ARM: OMAP2: clock: use DT clock boot > if available > from the tree mentioned above. > > Things look good other than the checkpatch violation noticed in > report, so other than that, > > Tested-by: Nishanth Menon > > omap2plus_defconfig > 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2jdV3XMCC > 2: am335x-sk: Boot PASS: http://slexy.org/raw/s210nZI8Hx > 3: am3517-evm: Boot PASS: http://slexy.org/raw/s21MG8kg6u > 4: am37x-evm: Boot PASS: http://slexy.org/raw/s20coVhzLt > 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21XKjjwyk > 6: BeagleBoard-XM: Boot PASS: http://slexy.org/raw/s27PCmlDq7 > 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2HX1Q3iPb > 8: crane: No Image built - Missing platform support?: > 9: dra7: Boot PASS: http://slexy.org/raw/s21ofDfpD2 > 10:ldp: Boot FAIL: http://slexy.org/raw/s2SbrpyX2p > ^^ legacy behavior > 11: PandaBoard-ES: Boot PASS: http://slexy.org/raw/s21n4iMUKd > 12:sdp2430: Boot PASS: http://slexy.org/raw/s2CJ5hYl72 > 13:sdp3430: Boot PASS: http://slexy.org/raw/s20axZ1nyb > 14:sdp4430: Boot PASS: http://slexy.org/raw/s21wt3C5F3 > 15: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s208PhmCpm > TOTAL = 15 boards, Booted Boards = 13, No Boot boards = 2 I'm getting this with omap2 only build: drivers/clk/ti/dpll.c:235: undefined reference to `clkhwops_omap3_dpll' drivers/built-in.o:(.rodata+0x1dd50): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0x1dd54): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0x1dd60): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0x1dd74): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0x1ddb8): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0x1ddfc): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0x1de10): undefined reference to `omap3_noncore_dpll_set_rate' And this if 2430 is not selected: drivers/clk/ti/interface.c:129: undefined reference to `clkhwops_omap2430_i2chs_wait' Then I get this early on when trying to boot on n800: [0.00] Unable to handle kernel NULL pointer dereference at virtual address [0.00] pgd = c0004000 [0.00] [] *pgd= [0.00] Internal error: Oops: 5 [#1] ARM [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 3.14.0-rc1-00012-ga93a376 #225 [0.00] task: c073ee80 ti: c0734000 task.ti: c0734000 [0.00] PC is at strcmp+0xc/0x34 [0.00] LR is at __clk_init+0x244/0x4d0 [0.00] pc : []lr : []psr: 21d3 [0.00] sp : c0735e68 ip : c781cf80 fp : c05440b8 [0.00] r10: r9 : c781ba80 r8 : c781ba80 [0.00] r7 : 000b r6 : c781ba80 r5 : 000b r4 : c0cf27f4 [0.00] r3 : c781cfc0 r2 : r1 : r0 : 0076 [0.00] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [0.00] Control: 00c5387d Table: 80004000 DAC: 0017 [0.00] Process swapper (pid: 0, stack limit = 0xc0734240) [0.00] Stack: (0xc0735e68 to 0xc0736000) [0.00] 5e60: c7df5868 c781ba00 000b c781cfc0 c781ba80 c781ba00 [0.00] 5e80: c781ce80 c0544074 c0401bcc c781ba80 c781ba00 c7df5a68 [0.00] 5ea0: c781cec0 c0401d08 c05442b8 c781ba00 000b c0403070 c0686038 [0.00] 5ec0: c0686038 c7df5a68 c781ba08 c781cec0 c0735f0b 0020 c0d09ce8 [0.00] 5ee0: c781cf40 c781cf40 c781cf4c 4107b362 c7df59a8 c0719f30 [0.00] 5f00: c781ce80 c05442b8 c0544074 c781cc80 c05440b8 c781cf44 [0.00] 5f20: 4107b362 c7df59a8 c781cf40 0002 0002 c781cf48 c0735f48 c071a040 [0.00] 5f40: c0735f48 c007533c c7df5874 a1d3 a1d3 c0797b6c 80004008 [0.00] 5f60: c0797b6c c04e07c4 a1d3 c07320d0 c7df59a8 c7df59a8 c7de8d10 c07a7454 [0.
Re: [PATCH v2 4/5] DMA: sun6i: Add driver for the Allwinner A31 DMA controller
On Fri, 2014-02-28 at 17:37 +0100, Maxime Ripard wrote:
> The Allwinner A31 has a 16 channels DMA controller that it shares with the
> newer A23. Although sharing some similarities with the DMA controller of the
> older Allwinner SoCs, it's significantly different, I don't expect it to be
> possible to share the driver for these two.
>
> The A31 Controller is able to memory-to-memory or memory-to-device transfers
> on
> the 16 channels in parallel.
Thanks for update.
Few more small comments.
>
> Signed-off-by: Maxime Ripard
> ---
> .../devicetree/bindings/dma/sun6i-dma.txt | 45 +
> drivers/dma/Kconfig| 8 +
> drivers/dma/Makefile | 1 +
> drivers/dma/sun6i-dma.c| 959
> +
> 4 files changed, 1013 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/sun6i-dma.txt
> create mode 100644 drivers/dma/sun6i-dma.c
>
> diff --git a/Documentation/devicetree/bindings/dma/sun6i-dma.txt
> b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
> new file mode 100644
> index 000..5d7c86d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
> @@ -0,0 +1,45 @@
> +Allwinner A31 DMA Controller
> +
> +This driver follows the generic DMA bindings defined in dma.txt.
> +
> +Required properties:
> +
> +- compatible:Must be "allwinner,sun6i-a31-dma"
> +- reg: Should contain the registers base address and length
> +- interrupts:Should contain a reference to the interrupt used by
> this device
> +- clocks:Should contain a reference to the parent AHB clock
> +- resets:Should contain a reference to the reset controller asserting
> + this device in reset
> +- #dma-cells : Should be 1, a single cell holding a line request number
> +
> +Example:
> + dma: dma-controller@01c02000 {
> + compatible = "allwinner,sun6i-a31-dma";
> + reg = <0x01c02000 0x1000>;
> + interrupts = <0 50 4>;
> + clocks = <&ahb1_gates 6>;
> + resets = <&ahb1_rst 6>;
> + #dma-cells = <1>;
> + };
> +
> +Clients:
> +
> +DMA clients connected to the A31 DMA controller must use the format
> +described in the dma.txt file, using a two-cell specifier for each
> +channel: a phandle plus one integer cells.
> +The two cells in order are:
> +
> +1. A phandle pointing to the DMA controller.
> +2. The port ID as specified in the datasheet
> +
> +Example:
> +spi2: spi@01c6a000 {
> + compatible = "allwinner,sun6i-a31-spi";
> + reg = <0x01c6a000 0x1000>;
> + interrupts = <0 67 4>;
> + clocks = <&ahb1_gates 22>, <&spi2_clk>;
> + clock-names = "ahb", "mod";
> + dmas = <&dma 25>, <&dma 25>;
> + dma-names = "rx", "tx";
> + resets = <&ahb1_rst 22>;
> +};
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 605b016..7923697 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -351,6 +351,14 @@ config MOXART_DMA
> help
> Enable support for the MOXA ART SoC DMA controller.
>
> +config DMA_SUN6I
> + tristate "Allwinner A31 SoCs DMA support"
> + depends on ARCH_SUNXI
> + select DMA_ENGINE
> + select DMA_VIRTUAL_CHANNELS
> + help
> + Support for the DMA engine for Allwinner A31 SoCs.
> +
> config DMA_ENGINE
> bool
>
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index a029d0f4..18cdbad 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -44,3 +44,4 @@ obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
> obj-$(CONFIG_TI_CPPI41) += cppi41.o
> obj-$(CONFIG_K3_DMA) += k3dma.o
> obj-$(CONFIG_MOXART_DMA) += moxart-dma.o
> +obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> new file mode 100644
> index 000..ba852f0
> --- /dev/null
> +++ b/drivers/dma/sun6i-dma.c
> @@ -0,0 +1,959 @@
> +/*
> + * Copyright (C) 2013-2014 Allwinner Tech Co., Ltd
> + * Author: Sugar
> + *
> + * Copyright (C) 2014 Maxime Ripard
> + * Maxime Ripard
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "virt-dma.h"
> +
> +/*
> + * There's 16 physical channels that can work in parallel.
> + *
> + * However we have 30 different endpoints for our requests.
> + *
> + * Since the channels are able to handle only an unidirectional
> + * transfer, we need to allocate more virtual channels so that
> + * everyone can grab one channel.
> + *
> + * Some devices can't work in both direction (mostly because it
> + * wouldn't make sense), so we have a bit
[PATCH 5/7] ARM: dts: imx6: add PCIe interrupt mapping properties
As defined by the common PCI bindings.
Signed-off-by: Lucas Stach
---
arch/arm/boot/dts/imx6qdl.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index fb28b2ecb1db..db3339e7d3a2 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -10,6 +10,8 @@
* http://www.gnu.org/copyleft/gpl.html
*/
+#include
+
#include "skeleton.dtsi"
/ {
@@ -126,7 +128,16 @@
0x8100 0 0 0x01f8 0
0x0001 /* downstream I/O */
0x8200 0 0x0100 0x0100 0
0x00f0>; /* non-prefetchable memory */
num-lanes = <1>;
+
interrupts = <0 123 0x04>;
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc GIC_SPI 123
IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc GIC_SPI 122
IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc GIC_SPI 121
IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc GIC_SPI 120
IRQ_TYPE_LEVEL_HIGH>;
+
clocks = <&clks 189>, <&clks 187>, <&clks 206>, <&clks
144>;
clock-names = "pcie_ref_125m", "sata_ref_100m",
"lvds_gate", "pcie_axi";
status = "disabled";
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] ARM: dts: exynos5440: fix PCIe interrupt mapping
So it actually works. Signed-off-by: Lucas Stach --- arch/arm/boot/dts/exynos5440.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi index 02a0a1226cef..65d425d9ec27 100644 --- a/arch/arm/boot/dts/exynos5440.dtsi +++ b/arch/arm/boot/dts/exynos5440.dtsi @@ -274,7 +274,7 @@ 0x8200 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */ #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0x0 0 &gic 53>; + interrupt-map = <0 0 0 0 &gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>; num-lanes = <4>; status = "disabled"; }; @@ -295,7 +295,7 @@ 0x8200 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */ #interrupt-cells = <1>; interrupt-map-mask = <0 0 0 0>; - interrupt-map = <0x0 0 &gic 56>; + interrupt-map = <0 0 0 0 &gic GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>; num-lanes = <4>; status = "disabled"; }; -- 1.8.5.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] ARM: dts: tegra: add PCIe interrupt mapping properties
Those are defined by the common PCI binding. Signed-off-by: Lucas Stach --- Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt | 8 arch/arm/boot/dts/tegra20.dtsi| 4 arch/arm/boot/dts/tegra30.dtsi| 4 3 files changed, 16 insertions(+) diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt index 24cee06915c9..c300391e8d3e 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt @@ -42,6 +42,10 @@ Required properties: - 0xc200: prefetchable memory region Please refer to the standard PCI bus binding document for a more detailed explanation. +- #interrupt-cells: Size representation for interrupts (must be 1) +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties + Please refer to the standard PCI bus binding document for a more detailed + explanation. - clocks: Must contain an entry for each entry in clock-names. See ../clocks/clock-bindings.txt for details. - clock-names: Must include the following entries: @@ -86,6 +90,10 @@ SoC DTSI: 0 99 0x04>; /* MSI interrupt */ interrupt-names = "intr", "msi"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &intc GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; + bus-range = <0x00 0xff>; #address-cells = <3>; #size-cells = <2>; diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi index 480ecda3416b..52ef2cf0b142 100644 --- a/arch/arm/boot/dts/tegra20.dtsi +++ b/arch/arm/boot/dts/tegra20.dtsi @@ -552,6 +552,10 @@ GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */ interrupt-names = "intr", "msi"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &intc GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; + bus-range = <0x00 0xff>; #address-cells = <3>; #size-cells = <2>; diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi index ed8e7700b46d..e5ab7adbc28a 100644 --- a/arch/arm/boot/dts/tegra30.dtsi +++ b/arch/arm/boot/dts/tegra30.dtsi @@ -28,6 +28,10 @@ GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>; /* MSI interrupt */ interrupt-names = "intr", "msi"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &intc GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; + bus-range = <0x00 0xff>; #address-cells = <3>; #size-cells = <2>; -- 1.8.5.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] PCI: designware: use new OF interrupt mapping when possible
This is the recommended method of doing the IRQ
mapping. For old devicetrees we fall back to the
previous practice.
Signed-off-by: Lucas Stach
---
drivers/pci/host/pcie-designware.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 17ce88f79d2b..3e0c2af11528 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -738,8 +739,13 @@ static struct pci_bus *dw_pcie_scan_bus(int nr, struct
pci_sys_data *sys)
static int dw_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
{
struct pcie_port *pp = sys_to_pcie(dev->bus->sysdata);
+ int irq;
- return pp->irq;
+ irq = of_irq_parse_and_map_pci(dev, slot, pin);
+ if (!irq)
+ irq = pp->irq;
+
+ return irq;
}
static void dw_pcie_add_bus(struct pci_bus *bus)
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] PCI irq mapping fixes and cleanups
This series cleans up the PCI irq mapping for all the ARM PCI host drivers, so they handle it in the way defined in the common PCI bindings. Testing appreciated. Lucas Stach (7): ARM: dts: tegra: add PCIe interrupt mapping properties PCI: tegra: use new OF interrupt mapping when possible PCI: rcar: use new OF interrupt mapping when possible ARM: dts: exynos5440: fix PCIe interrupt mapping ARM: dts: imx6: add PCIe interrupt mapping properties PCI: designware: use new OF interrupt mapping when possible PCI: designware: split samsung and fsl bindings .../devicetree/bindings/pci/designware-pcie.txt| 69 + .../devicetree/bindings/pci/fsl,imx6q-pcie.txt | 48 +++ .../bindings/pci/nvidia,tegra20-pcie.txt | 8 +++ .../bindings/pci/samsung,exynos5440-pcie.txt | 70 ++ arch/arm/boot/dts/exynos5440.dtsi | 4 +- arch/arm/boot/dts/imx6qdl.dtsi | 11 arch/arm/boot/dts/tegra20.dtsi | 4 ++ arch/arm/boot/dts/tegra30.dtsi | 4 ++ drivers/pci/host/pci-rcar-gen2.c | 8 ++- drivers/pci/host/pci-tegra.c | 7 ++- drivers/pci/host/pcie-designware.c | 8 ++- 11 files changed, 168 insertions(+), 73 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt create mode 100644 Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt -- 1.8.5.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] PCI: rcar: use new OF interrupt mapping when possible
This is the recommended method of doing the IRQ
mapping. Still fall back to the old method in order
to not break the just submitted board files.
Signed-off-by: Lucas Stach
---
drivers/pci/host/pci-rcar-gen2.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-rcar-gen2.c b/drivers/pci/host/pci-rcar-gen2.c
index ceec147baec3..3aa0c6311a42 100644
--- a/drivers/pci/host/pci-rcar-gen2.c
+++ b/drivers/pci/host/pci-rcar-gen2.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -160,8 +161,13 @@ static int __init rcar_pci_map_irq(const struct pci_dev
*dev, u8 slot, u8 pin)
{
struct pci_sys_data *sys = dev->bus->sysdata;
struct rcar_pci_priv *priv = sys->private_data;
+ int irq;
+
+ irq = of_irq_parse_and_map_pci(dev, slot, pin);
+ if (!irq)
+ irq = priv->irq;
- return priv->irq;
+ return irq;
}
/* PCI host controller setup */
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] PCI: tegra: use new OF interrupt mapping when possible
This is the recommended method of doing the IRQ
mapping. For old devicetrees we fall back to the
previous practice.
Signed-off-by: Lucas Stach
---
drivers/pci/host/pci-tegra.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index 330f7e3a32dd..083cf37ca047 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -639,10 +639,15 @@ static int tegra_pcie_setup(int nr, struct pci_sys_data
*sys)
static int tegra_pcie_map_irq(const struct pci_dev *pdev, u8 slot, u8 pin)
{
struct tegra_pcie *pcie = sys_to_pcie(pdev->bus->sysdata);
+ int irq;
tegra_cpuidle_pcie_irqs_in_use();
- return pcie->irq;
+ irq = of_irq_parse_and_map_pci(pdev, slot, pin);
+ if (!irq)
+ irq = pcie->irq;
+
+ return irq;
}
static void tegra_pcie_add_bus(struct pci_bus *bus)
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] PCI: designware: split samsung and fsl bindings
The glue around the core designware IP is
significantly different between the Exynos and
i.MX, which is reflected in the DT bindings.
Note that this patch doesn't change any bindings,
but just alters the documentation to match reality
of deployed DTs and kernels.
Signed-off-by: Lucas Stach
---
.../devicetree/bindings/pci/designware-pcie.txt| 69 +
.../devicetree/bindings/pci/fsl,imx6q-pcie.txt | 48 +++
.../bindings/pci/samsung,exynos5440-pcie.txt | 70 ++
3 files changed, 119 insertions(+), 68 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
create mode 100644
Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index d6fae13ff062..8274c80fe874 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -1,15 +1,7 @@
* Synopsys Designware PCIe interface
Required properties:
-- compatible: should contain "snps,dw-pcie" to identify the
- core, plus an identifier for the specific instance, such
- as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie".
-- reg: base addresses and lengths of the pcie controller,
- the phy controller, additional register for the phy controller.
-- interrupts: interrupt values for level interrupt,
- pulse interrupt, special interrupt.
-- clocks: from common clock binding: handle to pci clock.
-- clock-names: from common clock binding: should be "pcie" and "pcie_bus".
+- compatible: should contain "snps,dw-pcie" to identify the core.
- #address-cells: set to <3>
- #size-cells: set to <2>
- device_type: set to "pci"
@@ -22,62 +14,3 @@ Required properties:
Optional properties:
- reset-gpio: gpio pin number of power good signal
-
-Optional properties for fsl,imx6q-pcie
-- power-on-gpio: gpio pin number of power-enable signal
-- wake-up-gpio: gpio pin number of incoming wakeup signal
-- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal
-
-Example:
-
-SoC specific DT Entry:
-
- pcie@29 {
- compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
- reg = <0x29 0x1000
- 0x27 0x1000
- 0x271000 0x40>;
- interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
- clocks = <&clock 28>, <&clock 27>;
- clock-names = "pcie", "pcie_bus";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- ranges = <0x0800 0 0x4000 0x4000 0 0x1000 /*
configuration space */
- 0x8100 0 0 0x40001000 0 0x0001 /*
downstream I/O */
- 0x8200 0 0x40011000 0x40011000 0 0x1ffef000>; /*
non-prefetchable memory */
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0x0 0 &gic 53>;
- num-lanes = <4>;
- };
-
- pcie@2a {
- compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
- reg = <0x2a 0x1000
- 0x272000 0x1000
- 0x271040 0x40>;
- interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
- clocks = <&clock 29>, <&clock 27>;
- clock-names = "pcie", "pcie_bus";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- ranges = <0x0800 0 0x6000 0x6000 0 0x1000 /*
configuration space */
- 0x8100 0 0 0x60001000 0 0x0001 /*
downstream I/O */
- 0x8200 0 0x60011000 0x60011000 0 0x1ffef000>; /*
non-prefetchable memory */
- #interrupt-cells = <1>;
- interrupt-map-mask = <0 0 0 0>;
- interrupt-map = <0x0 0 &gic 56>;
- num-lanes = <4>;
- };
-
-Board specific DT Entry:
-
- pcie@29 {
- reset-gpio = <&pin_ctrl 5 0>;
- };
-
- pcie@2a {
- reset-gpio = <&pin_ctrl 22 0>;
- };
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
new file mode 100644
index ..93fbfd62f13c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
@@ -0,0 +1,48 @@
+* Freescale i.MX6 PCIe interface
+
+This PCIe host controller is based on the Synopsis Designware PCIe IP
+and thus inherits all the common properties defined in designware-pcie.txt.
+
+Required properties:
+- compatible: "fsl,imx6q-pcie"
+- reg: base addresse and length of the pcie controller
+- interrupts: First entry must contain interrupt handle for controller
