[PATCH v4 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board
- AM1808 based board
- 64 MiB DDR ram
- 2 MiB Nor flash
- 128 MiB NAND flash
- use internal RTC
- I2C support
- hwmon lm75 support
- UBI/UBIFS support
- MMC support
- USB OTG support
Signed-off-by: Heiko Schocher
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: linux-...@lists.infradead.org
Cc: linux-i2c@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: David Woodhouse
Cc: Ben Dooks
Cc: Wolfram Sang
Cc: Sekhar Nori
Cc: Kevin Hilman
Cc: Wolfgang Denk
Cc: Scott Wood
Cc: Sylwester Nawrocki
---
- post this board support with USB support, even though
USB is only working with the 10 ms "workaround", posted here:
http://comments.gmane.org/gmane.linux.usb.general/54505
I see this issue also on the AM1808 TMDXEXP1808L evalboard.
- MMC and USB are not using OF support yet, ideas how to port
this are welcome. I need for USB and MMC boards board
specific callbacks, how to solve this with OF support?
- changes for v2:
- changes in the nand node due to comments from Scott Wood:
- add "ti,davinci-" prefix
- Dashes are preferred to underscores
- rename "nandflash" to "nand"
- introduce new "ti,davinci" specific properties for setting
up ecc_mode, ecc_bits, options and bbt options, instead
using linux defines
- changes for i2c due to comments from Sylwester Nawrocki:
- use "cell-index" instead "id"
- OF_DEV_AUXDATA in the machine code, instead pre-define
platform device name
- add comment from Grant Likely for i2c:
- removed "id" resp. "cell-index" completely
- fixed documentation
- use of_match_ptr()
- use devm_kzalloc() for allocating plattform data mem
- fixed a whitespace issue
- add net comments from Grant Likely:
- add prefix "ti,davinci-" to davinci specific property names
- remove version property
- use compatible name "ti,davinci-dm6460-emac"
- add comment from Grant Likely:
- rename compatible node
- do not use cell-index
- CONFIG_OF required for this board
TODO:
- create a generic board support file, as I got no
answer to my ping to grant, maybe this could be done
in a second step?
- changes for v3:
- add comments from Sergei Shtylyov:
- rename compatible" prop to "ti,cp_intc"
- cp_intc_init now used for Interrupt controller init
- changes for v4:
add comment from Nori Sekhar:
- rename davinci emac compatible property to "ti,davinci-dm6467-emac"
- remove "pinmux-handle" property as discussed here:
http://www.spinics.net/lists/arm-kernel/msg175701.html
with Nori Sekhar
---
arch/arm/boot/dts/enbw_cmc.dts | 172 +++
arch/arm/configs/enbw_cmc_defconfig | 123
arch/arm/mach-davinci/Kconfig |9 +
arch/arm/mach-davinci/Makefile |1 +
arch/arm/mach-davinci/board-enbw-cmc.c | 374 +++
arch/arm/mach-davinci/include/mach/uncompress.h |1 +
6 files changed, 680 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/enbw_cmc.dts
create mode 100644 arch/arm/configs/enbw_cmc_defconfig
create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c
diff --git a/arch/arm/boot/dts/enbw_cmc.dts b/arch/arm/boot/dts/enbw_cmc.dts
new file mode 100644
index 000..2d5dea9
--- /dev/null
+++ b/arch/arm/boot/dts/enbw_cmc.dts
@@ -0,0 +1,172 @@
+/*
+ * Device Tree for the EnBW CMC plattform
+ *
+ * Copyright 2011 DENX Software Engineering GmbH
+ * Heiko Schocher
+ *
+ * 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.
+ */
+/dts-v1/;
+/include/ "skeleton.dtsi"
+
+/ {
+ model = "EnBW CMC";
+ compatible = "enbw,cmc";
+
+ aliases {
+ ethernet0 = ð0;
+ };
+
+ arm {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0xfffee000 0x0002>;
+ intc: interrupt-controller@1 {
+ compatible = "ti,cp_intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ ti,intc-size = <101>;
+ reg = <0x0 0x2000>;
+ };
+ };
+ soc@1c0 {
+ compatible = "ti,da850";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x01c0 0x40>;
+
+ serial0: serial@1c42000 {
+ compatible = "ti,da850", "ns16550a";
+ reg = <0x42000 0x100>;
+ clock-frequency = <15000>;
+ reg-shift = <2>;
+ interrupts = <25>;
+ interrupt-parent = <&intc>;
+
[PATCH v4 0/7] ARM: davinci: add support for the am1808 based enbw_cmc board
this patchserie add support for the davinci am1808 based enbw_cmc board. changes for v2: Post this patchserie now as v2, as reworked in the comments I got for the RFC serie. changes for v3: - Interrupt Controller: - comment from Sergei Shtylyov: - rename compatible" prop to "ti,cp_intc" - cp_intc_init() is now also for the of case the name of the init function (it calls the "new" __cp_intc_init() function, which was the "old" cp_intc_init()). Through this rework the changes for OF is better visible. As the OF case uses the irq_domain rework from Grant Likely, maybe the none OF case can use this also, but this should be tested on a hw ... changes for v4: - Interrupt Controller: - split in two patches as Nori Sekhar suggested one for the irq_domain change one for DT support - add comment from Grant Likely for the DT part: remove if/else clause, not needed. Make use of DT runtime configurable The non OF case is not tested! Got no comments to the following points, I noted in the RFC series, so posting this patchseries with them: - ARM: davinci: configure davinci aemif chipselects through OF not moved to mfd, as mentioned in this discussion: http://davinci-linux-open-source.1494791.n2.nabble.com/PATCH-arm-davinci-configure-davinci-aemif-chipselects-through-OF-td7059739.html instead use a phandle in the DTS, so drivers which uses the davinci aemif, can call davinci_aemif_setup_timing_of() This is just thought as an RFC ... The enbw_cmc board support not really need to setup this bus timings, as they are setup in U-Boot ... but I want to post this, as I think, it is a nice to have, and I am not really sure, if this has to be a MFD device (If so, all bus interfaces for other SoCs should be converted also to MFD devices) ... as an example how this can be used I add this to the davinci nand controller OF support patch, in this patchserie. - ARM: davinci: mux: add OF support I want to get rid of the pin setup code in board code ... This patch introduces a davinci_cfg_reg_of() function, which davinci drivers can call, if they found a "pinmux-handle", so used in the following drivers in this patchserie: drivers/net/ethernet/ti/davinci_emac drivers/i2c/busses/i2c-davinci.c drivers/mtd/nand/davinci_nand.c This is removed for v4 serie, as Nori Sekhar suggested. - post this board support with USB support, even though USB is only working with the 10 ms "workaround", posted here: http://comments.gmane.org/gmane.linux.usb.general/54505 I see this issue also on the AM1808 TMDXEXP1808L evalboard. change for v4: The 10 ms delay is no longer needed, see discussion here: http://www.spinics.net/lists/linux-usb/msg64232.html shows the way to go ... - MMC and USB are not using OF support yet, ideas how to port this are welcome. I need for USB and MMC board specific callbacks, how to solve this with OF support? Signed-off-by: Heiko Schocher Cc: linux-arm-ker...@lists.infradead.org Cc: devicetree-disc...@lists.ozlabs.org Cc: davinci-linux-open-sou...@linux.davincidsp.com Cc: linux-...@lists.infradead.org Cc: linux-i2c@vger.kernel.org Cc: net...@vger.kernel.org Cc: David Woodhouse Cc: Ben Dooks Cc: Wolfram Sang Cc: Sekhar Nori Cc: Kevin Hilman Cc: Wolfgang Denk Cc: Sergei Shtylyov Cc: Grant Likely Heiko Schocher (7): ARM: davinci, intc: Add irq domain support ARM: davinci, intc: Add OF support for TI interrupt controller ARM: davinci: configure davinci aemif chipselects through OF ARM: davinci: net: davinci_emac: add OF support ARM: davinci: i2c: add OF support ARM: mtd: nand: davinci: add OF support for davinci nand controller ARM: davinci: add support for the am1808 based enbw_cmc board .../devicetree/bindings/arm/davinci/aemif.txt | 119 +++ .../devicetree/bindings/arm/davinci/i2c.txt| 31 ++ .../devicetree/bindings/arm/davinci/intc.txt | 27 ++ .../devicetree/bindings/arm/davinci/nand.txt | 72 .../devicetree/bindings/net/davinci_emac.txt | 41 +++ arch/arm/boot/dts/enbw_cmc.dts | 172 + arch/arm/configs/enbw_cmc_defconfig| 123 +++ arch/arm/mach-davinci/Kconfig |9 + arch/arm/mach-davinci/Makefile |1 + arch/arm/mach-davinci/aemif.c | 86 +- arch/arm/mach-davinci/board-enbw-cmc.c | 374 arch/arm/mach-davinci/cp_intc.c| 74 - arch/arm/mach-davinci/include/mach/aemif.h |1 + arch/arm/mach-davinci/include/mach/uncompress.h|1 + drivers/i2c/busses/i2c-davinci.c | 32 ++ drivers/mtd/nand/davinci_nand.c| 80 - drivers/net/ethernet/ti/davinci_emac.c | 87 +- 17 files changed, 1317 insertions(+), 13 deletions(-) create mode 100644 Documentation
[PATCH v4 5/7] ARM: davinci: i2c: add OF support
add of support for the davinci i2c driver.
Signed-off-by: Heiko Schocher
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-i2c@vger.kernel.org
Cc: Ben Dooks
Cc: Wolfram Sang
Cc: Grant Likely
Cc: Sekhar Nori
Cc: Wolfgang Denk
Cc: Sylwester Nawrocki
---
- changes for v2:
- add comments from Sylwester Nawrocki :
- use "cell-index" instead "id"
- OF_DEV_AUXDATA in the machine code, instead pre-define platform
device name
- add comment from Grant Likely:
- removed "id" resp. "cell-index" completely
- fixed documentation
- use of_match_ptr()
- use devm_kzalloc() for allocating plattform data mem
- fixed a whitespace issue
- no changes for v3
- changes for v4
remove "pinmux-handle" property as discussed here:
http://www.spinics.net/lists/arm-kernel/msg175701.html
with Nori Sekhar
---
.../devicetree/bindings/arm/davinci/i2c.txt| 31 +++
drivers/i2c/busses/i2c-davinci.c | 32
2 files changed, 63 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt
b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
new file mode 100644
index 000..e98a025
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
@@ -0,0 +1,31 @@
+* Texas Instruments Davinci I2C
+
+This file provides information, what the device node for the
+davinci i2c interface contain.
+
+Required properties:
+- compatible: "ti,davinci-i2c";
+- reg : Offset and length of the register set for the device
+
+Recommended properties :
+- interrupts : standard interrupt property.
+- clock-frequency : desired I2C bus clock frequency in Hz.
+
+Optional properties:
+- bus-delay: bus delay in usec
+
+Example (enbw_cmc board):
+ i2c@1c22000 {
+ compatible = "ti,davinci-i2c";
+ reg = <0x22000 0x1000>;
+ clock-frequency = <10>;
+ interrupts = <15>;
+ interrupt-parent = <&intc>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dtt@48 {
+ compatible = "national,lm75";
+ reg = <0x48>;
+ };
+ };
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index a76d85f..c1783bb 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -38,9 +38,12 @@
#include
#include
#include
+#include
+#include
#include
#include
+#include
/* - global defines --- */
@@ -635,6 +638,12 @@ static struct i2c_algorithm i2c_davinci_algo = {
.functionality = i2c_davinci_func,
};
+static const struct of_device_id davinci_i2c_of_match[] = {
+ {.compatible = "ti,davinci-i2c", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, davinci_i2c_of_match);
+
static int davinci_i2c_probe(struct platform_device *pdev)
{
struct davinci_i2c_dev *dev;
@@ -676,6 +685,26 @@ static int davinci_i2c_probe(struct platform_device *pdev)
dev->irq = irq->start;
platform_set_drvdata(pdev, dev);
+ if ((dev->dev->platform_data == NULL) &&
+ (pdev->dev.of_node)) {
+ struct davinci_i2c_platform_data *pdata;
+ u32 prop;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ r = -ENOMEM;
+ goto err_free_mem;
+ }
+ memcpy(pdata, &davinci_i2c_platform_data_default,
+ sizeof(*pdata));
+ dev->dev->platform_data = pdata;
+ if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
+ &prop))
+ pdata->bus_freq = prop / 1000;
+ if (!of_property_read_u32(pdev->dev.of_node, "bus-delay",
+ &prop))
+ pdata->bus_delay = prop;
+ }
dev->clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(dev->clk)) {
r = -ENODEV;
@@ -711,6 +740,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
adap->algo = &i2c_davinci_algo;
adap->dev.parent = &pdev->dev;
adap->timeout = DAVINCI_I2C_TIMEOUT;
+ adap->dev.of_node = pdev->dev.of_node;
adap->nr = pdev->id;
r = i2c_add_numbered_adapter(adap);
@@ -718,6 +748,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "failure adding adapter\n");
goto err_free_irq;
}
+ of_i2c_register_devices(adap);
return 0;
@@ -809,6 +840,7 @@ static struct platform_driver davinci_i2c_driver = {
.name = "i2c_davinci",
Re: [PATCH V2 00/11] enable imx6q_sabrelite sgtl5000 audio support
On Tue, May 22, 2012 at 09:39:21AM +0800, Richard Zhao wrote: > On Mon, May 21, 2012 at 03:45:44PM +0100, Mark Brown wrote: > > For the first patch it wasn't clear if the > > changes in pinctrl were the actual dependencies or if there were more > > things needed from the ARM tree, > I remembered someone already explained the dependencies. It depends > on imx pinctrl work and dummy pinctrl enabled in ARM platform code. It > is why Shawn suggest it goes to ARM SoC. There was mention of some changes but only a vauge description of them, I've no idea where they are or anything, initially people had mentioned an already cross-merged point in Linus' tree but apparently that wasn't sufficient due to these arch specific bits and I don't know where those are. We should really have got this resolved in -next... > > Guys, you really need to think about how you're organising what you're > > doing more. You need to split your work out into focused lines of > > development rather than just having a single branch. > Except the clean up patch, others are all related to enable audio. Do > you mean I supposed to split them in advance? Well, a lot of the time there's no actual dependency (eg, you add a driver and add registration of that device so there's no need for them to go in together since both are perfectly fine without the other) then it is best to merge things separately. If there are dependencies then that needs to be handled differently but it needs communication and ideally the dependencies would be on focused things that can just be pulled in. In the case of things like the devm_clk_get() cleanup if there's any complexity at all then it's usually best just to punt for a release. signature.asc Description: Digital signature
Re: [RFC v2 5/5] drm: Add NVIDIA Tegra support
On Wed, Apr 25, 2012 at 2:45 AM, Thierry Reding wrote: > This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It > currently has rudimentary GEM support and can run a console on the > framebuffer as well as X using the xf86-video-modesetting driver. Only > the RGB output is supported. > > HDMI support was taken from NVIDIA's Linux kernel tree but it doesn't > quite work. EDID data can be retrieved but the output doesn't properly > activate the connected TV. > > The DSI and TVO outputs and the HOST1X driver are just stubs that setup > the corresponding resources but don't do anything useful yet. > Nice work Thierry, I'm happy with the display programming bits. I think the pll_p enable/disable problem with RGB is better fixed when we have some fancier clock infrastructure. I have some ideas how it could be fixed now, but given that I want to see pll_p or pll_d / pll_d2 selected automatically based on final clock, I'd rather hold off on fixing things that are not really broken that going to be replaced anyways. You can save a little power by leaving D pll's off, and the logic to do it isn't hard and fairly safe to hard code into the driver instead of trying to represent it in DT. (FYI - pll_d2 is a Tegra3 feature, this way you can do things like run DSI and HDMI with low jitter, instead of trying to take over pll_c for HDMI, which deprives other modules of the clock freedom) I have more DSI devices on Tegra3 than on Tegra2, so I'm putting Tegra3 support near the top of my TODO list, because in my mind getting forward progress on DSI support depends on it. HDMI programming is not too tough, it's mostly loading calibrated magic values into some SOR registers. The values are different for T20 and T30 series (same fields, just needed different calibration). -- "If you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime." — David Leinweber -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
