Re: OMAP baseline test results for v3.8-rc6
Hi, On Wed, Feb 06, 2013 at 11:34:32PM +, Paul Walmsley wrote: Boot tests: * am335xbone: hangs after Starting kernel - Cause unknown - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg82297.html - http://marc.info/?l=linux-omapm=135903184512238w=2 - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg83942.html After testing quite a lot and having help from other folks, the problem (for me at least) was missing fdt_high in u-boot environment. setenv fdt_high 0x fixed everything. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/2] ARM: dts: Add DT bindings for OMAP SDMA
On Wed, Feb 06, 2013 at 03:03:14PM -0600, Jon Hunter wrote: Adds device-tree bindings from SDMA on OMAP2+ devices. DMA client bindings are also added for devices that have SPI and MMC bindings populated. Client binding data is based upon existing HWMOD data for OMAP and has been checked against OMAP documentation. Testing includes ... 1. Boot tested on OMAP3430 Beagle board, OMAP4430 Panda board and OMAP4460 Panda board with and without device-tree present. 2. Testing of MMC1 with SD card on OMAP3430 Beagle board, OMAP4430 Panda board and OMAP4460 Panda board with and without device-tree present. looks alright to me: Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
RE: [PATCH v3 00/10] video: da8xx-fb: runtime timing configuration
Hi Tomi, Florian,
On Tue, Jan 15, 2013 at 19:00:50, Mohammed, Afzal wrote:
This series makes da8xx-fb driver (device found on DaVinci and AM335x)
capable of handling runtime timing configuration by adding fb_set_par.
The last change adds actual fb_set_par support. Other preceeding
changes makes the way clear for it as well as does certain cleanup's
on the way.
This has been tested on da850 evm as is. This was also tested on
am335x-evm am335x-evmsk with a series that adds DT support.
This is based on v3.8-rc3, this is the only change in this revision.
The new version of this series is being posted so that this series can
be applied easily (as __dev* are removed, there would be merge
conflicts with v2, which was based on -rc2).
series
Can you please consider this series for inclusion. There are no
pending comments or dependency for this series. If you need a
pull request, let me know, I will sent it.
Regards
Afzal
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
Re: [PATCH v3 00/10] video: da8xx-fb: runtime timing configuration
Hi, On 2013-02-07 11:05, Mohammed, Afzal wrote: Hi Tomi, Florian, On Tue, Jan 15, 2013 at 19:00:50, Mohammed, Afzal wrote: This series makes da8xx-fb driver (device found on DaVinci and AM335x) capable of handling runtime timing configuration by adding fb_set_par. The last change adds actual fb_set_par support. Other preceeding changes makes the way clear for it as well as does certain cleanup's on the way. This has been tested on da850 evm as is. This was also tested on am335x-evm am335x-evmsk with a series that adds DT support. This is based on v3.8-rc3, this is the only change in this revision. The new version of this series is being posted so that this series can be applied easily (as __dev* are removed, there would be merge conflicts with v2, which was based on -rc2). series Can you please consider this series for inclusion. There are no pending comments or dependency for this series. If you need a pull request, let me know, I will sent it. I handled only the pull request for 3.8 merge window to help Florian with it. I didn't mean to become a co-maintainer or such =). Tomi signature.asc Description: OpenPGP digital signature
Re: MUSB regression in linux next at least for pandboard
On 02/06/2013 05:43 PM, Alan Stern wrote:
On Wed, 6 Feb 2013, Felipe Balbi wrote:
I can't reproduce the problem on Panda, but I can on Beagle with a slightly
different behaviour.
1) connecting/disconnecting device directly to the beagleboard's USB port
works fine.
2) If I connect a USB Hub to the port and connect a device to it after the
hub has
autosuspended, the device is never detected.
doing lsusb after that triggers the detection and produces a lot of
transaction errors.
Beagle log is below, before and after 'lsusb'
I suppose this doesn't affect Panda because it has a hub connected
immediately below the
root hub that never suspends (as ethernet is hardwired to it).
Roger, try changing hub's autosuspend delay to something greater than
30ms and see if it helps. There was a discussion lately about that.
There also were some patches to address this problem recently merged by
Greg KH (they are in Linus's current git, added after 3.8-rc6 was
released):
da0aa7169b97d90f4af39a9dc84d58bbe19d7e78 USB: add
usb_hcd_{start,end}_port_resume
f292e7f9fb0e4bec68bbd83443407d6bb7922d36 USB: EHCI: notify usbcore about port
resumes
ee74290b7853db9d5fd64db70e5c175241c59fba USB: EHCI: fix timer bug affecting
port resume
Alan, thanks for the hints.
It seems the beagleboard problem is related to OMAP silicon errata [1].
Apparently, remote wakeup as well as host issued wakeup break omap-ehci and have
nothing to do with the hub or it's driver.
I'll work on this issue after I'm done with device tree migration.
cheers,
-roger
[1] - Advisory 3.1.1.157 EHCI Controller- Issue in Suspend Resume Protocol
http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=sprz278ffileType=pdf
--
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
Re: [PATCH 1/3] mtd nand : onfi need to be probed in 8 bits mode
Hi Paul, Paul Walmsley a écrit : Hi Matthieu, On Tue, 22 Jan 2013, Paul Walmsley wrote: Any progress on updating and resending your omap3 nand : use NAND_BUSWIDTH_AUTO patch? We're in danger of missing the 3.9 merge window if it takes too much longer. Could you let us know if you're planning to update and repost this one? Sorry for the delay I attached an updated version of the patch. I was not able to test it : with mtd tree and my configuration I have to apply https://patchwork.kernel.org/patch/1810441/ https://patchwork.kernel.org/patch/1884341/ http://comments.gmane.org/gmane.linux.ports.arm.omap/91096 in order the kernel build. And after that the kernel doesn't seem to boot on my beagle board. Could you test the patch ? I have also a problem : how should I change nand bus size. It is done by gpmc_cs_configure(info-gpmc_cs, GPMC_CONFIG_DEV_SIZE, ...);, but now gpmc.h header is not public anymore. I have to do a '#include ../gpmc.h'. Matthieu 0001-omap3-nand-use-NAND_BUSWIDTH_AUTO.patch Description: application/mbox
Re: DT GPMC SRAM and NOR flash support ?
Okay ... I have made some progress, but it's not ideal.
Currently I've hacked the GPMC DT driver (gpmc_probe_dt(), etc) so it now
handles setting up the
chip selects and timings for NOR devices, e.g.
gpmc: gpmc@5000 {
status = okay;
ranges = 0 0 0x0800 0x0800; /* CS0: NOR 16M
*/
nor@0,0 {
compatible = spansion,s29gl064n90t,
cfi-flash;
reg = 0 0 0;
bank-width = 2;
gpmc,sync-clk = 0;
gpmc,cs-on = 10;
gpmc,cs-rd-off = 150;
gpmc,cs-wr-off = 150;
gpmc,adv-on = 10;
gpmc,adv-rd-off = 10;
gpmc,adv-wr-off = 10;
gpmc,oe-on = 30;
gpmc,oe-off = 150;
gpmc,we-on = 30;
gpmc,we-off = 150;
gpmc,rd-cycle = 150;
gpmc,wr-cycle = 150;
gpmc,access = 130;
gpmc,page-burst-access = 10;
gpmc,cycle2cycle-diff = 1;
gpmc,cycle2cycle-same = 1;
gpmc,cycle2cycle-delay = 10;
gpmc,wr-data-mux-bus = 60;
};
};
But the physmap driver (of_flash_probe()) is unable to use this information.
It seems that although
I can call of_flash_probe() from my NOR setup code, the platform_device being
reference is wrong.
The platform_device passed to my gpmc_probe_nor_child() routine from
gpmc_probe_dt() points to my
gpmc entry (above), but the physmap probe requires its own DT entry (rather
than a node child such
as my NOR entry with the GPMC device entry).
So I need to have any extra entry in the DT file as follows:-
nor-flash@0800 {
compatible = spansion,s29gl064n90t, cfi-flash;
reg = 0x0800 0x0080;
bank-width = 2;
};
So the GPMC entry handles all the chip select and timing setup, but the 2nd
entry is the only one
the physmap driver can see.
Would it be acceptable to re-code of_flash_probe() to allow either a child
device_node to be passed
or a platform_device ?
Cheers
Mark J.
--
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
Re: DT GPMC SRAM and NOR flash support ?
On 07/02/13 09:51, Mark Jackson wrote:
Okay ... I have made some progress, but it's not ideal.
snip
But the physmap driver (of_flash_probe()) is unable to use this information.
It seems that although
I can call of_flash_probe() from my NOR setup code, the platform_device being
reference is wrong.
The platform_device passed to my gpmc_probe_nor_child() routine from
gpmc_probe_dt() points to my
gpmc entry (above), but the physmap probe requires its own DT entry (rather
than a node child such
as my NOR entry with the GPMC device entry).
So I need to have any extra entry in the DT file as follows:-
nor-flash@0800 {
compatible = spansion,s29gl064n90t, cfi-flash;
reg = 0x0800 0x0080;
bank-width = 2;
};
So the GPMC entry handles all the chip select and timing setup, but the 2nd
entry is the only one
the physmap driver can see.
Would it be acceptable to re-code of_flash_probe() to allow either a child
device_node to be passed
or a platform_device ?
Or is it acceptable to simply state the gpmc portion is for setting up the chip
access, and you *do*
need a separate physmap section ?
That's certainly easier, and it works without any changes to the physmap driver.
Regards
Mark J.
--
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
[PATCH v2 0/4] suspend/resume support for OMAP nand driver
This patch series adds low power transition support for OMAP NAND driver. With recent driver conversion of GPMC to platform_driver, pm_runtime calls can be used to handle module enable disable of GPMC. This is taken care patch #1. patch #2 is for GPMC suspend/resume support. This includes low power transition support of - GPMC module - ELM module - OMAP2 NAND driver User initiated suspend/resume sequence tested on am335x-evm with NAND flash support. Also tested in omap3-evm for user initiated suspend/resume sequence with NAND flash. This patch series based on [1] and is present in [2]. 1. ARM: OMAP2+: AM33XX: Add suspend-resume support http://comments.gmane.org/gmane.linux.ports.arm.omap/91405 2. https://github.com/avinashphilip/am335x_linux/commits/NAND_supend_resume_support Philip Avinash (4): arm: gpmc: Converts GPMC driver to pm_runtime capable arm: gpmc: Low power transition support mtd: devices: elm: Low power transition support mtd: nand: omap2: Low power transition support arch/arm/mach-omap2/gpmc.c | 30 +++--- drivers/mtd/devices/elm.c | 40 drivers/mtd/nand/omap2.c | 19 +++ 3 files changed, 86 insertions(+), 3 deletions(-) -- 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
[PATCH v2 1/4] arm: gpmc: Converts GPMC driver to pm_runtime capable
Support for pm_runtime add to GPMC driver.
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 2c57f81..b1cd6c1 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -29,6 +29,7 @@
#include linux/of_mtd.h
#include linux/of_device.h
#include linux/mtd/nand.h
+#include linux/pm_runtime.h
#include linux/platform_data/mtd-nand-omap2.h
@@ -1317,7 +1318,8 @@ static int gpmc_probe(struct platform_device *pdev)
return PTR_ERR(gpmc_l3_clk);
}
- clk_prepare_enable(gpmc_l3_clk);
+ pm_runtime_enable(pdev-dev);
+ pm_runtime_get_sync(pdev-dev);
gpmc_dev = pdev-dev;
@@ -1329,7 +1331,7 @@ static int gpmc_probe(struct platform_device *pdev)
rc = gpmc_mem_init();
if (IS_ERR_VALUE(rc)) {
- clk_disable_unprepare(gpmc_l3_clk);
+ pm_runtime_put_sync(pdev-dev);
clk_put(gpmc_l3_clk);
dev_err(gpmc_dev, failed to reserve memory\n);
return rc;
@@ -1340,7 +1342,7 @@ static int gpmc_probe(struct platform_device *pdev)
rc = gpmc_probe_dt(pdev);
if (rc 0) {
- clk_disable_unprepare(gpmc_l3_clk);
+ pm_runtime_put_sync(pdev-dev);
clk_put(gpmc_l3_clk);
dev_err(gpmc_dev, failed to probe DT parameters\n);
return rc;
@@ -1353,6 +1355,8 @@ static __devexit int gpmc_remove(struct platform_device
*pdev)
{
gpmc_free_irq();
gpmc_mem_exit();
+ pm_runtime_put_sync(pdev-dev);
+ pm_runtime_disable(pdev-dev);
gpmc_dev = NULL;
return 0;
}
--
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
[PATCH v2 2/4] arm: gpmc: Low power transition support
With GPMC converted to platform driver recently, adds low power
transition support in driver itself.
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
Changes since v1:
Module disable enable added using pm_runtime support.
arch/arm/mach-omap2/gpmc.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index b1cd6c1..cc57988 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -1361,9 +1361,29 @@ static __devexit int gpmc_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int gpmc_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ omap3_gpmc_save_context();
+ pm_runtime_put_sync(pdev-dev);
+ return 0;
+}
+
+static int gpmc_resume(struct platform_device *pdev)
+{
+ pm_runtime_get_sync(pdev-dev);
+ omap3_gpmc_restore_context();
+ return 0;
+}
+#endif
+
static struct platform_driver gpmc_driver = {
.probe = gpmc_probe,
.remove = __devexit_p(gpmc_remove),
+#ifdef CONFIG_PM
+ .suspend= gpmc_suspend,
+ .resume = gpmc_resume,
+#endif
.driver = {
.name = DEVICE_NAME,
.owner = THIS_MODULE,
--
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
[PATCH v2 3/4] mtd: devices: elm: Low power transition support
In low power modes of AM335X platforms, peripherals power is cut off.
This patch supports low power sleep transition support for ELM driver.
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
drivers/mtd/devices/elm.c | 40
1 file changed, 40 insertions(+)
diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
index f034239..a9ac8f2 100644
--- a/drivers/mtd/devices/elm.c
+++ b/drivers/mtd/devices/elm.c
@@ -20,6 +20,7 @@
#include linux/interrupt.h
#include linux/io.h
#include linux/of.h
+#include linux/sched.h
#include linux/pm_runtime.h
#include linux/platform_data/elm.h
@@ -62,6 +63,7 @@ struct elm_info {
struct completion elm_completion;
struct list_head list;
enum bch_ecc bch_type;
+ bool idle;
};
static LIST_HEAD(elm_devices);
@@ -86,9 +88,11 @@ void elm_config(struct device *dev, enum bch_ecc bch_type)
u32 reg_val;
struct elm_info *info = dev_get_drvdata(dev);
+ info-idle = true;
reg_val = (bch_type ECC_BCH_LEVEL_MASK) | (ELM_ECC_SIZE 16);
elm_write_reg(info, ELM_LOCATION_CONFIG, reg_val);
info-bch_type = bch_type;
+ info-idle = false;
}
EXPORT_SYMBOL(elm_config);
@@ -280,6 +284,7 @@ void elm_decode_bch_error_page(struct device *dev, u8
*ecc_calc,
struct elm_info *info = dev_get_drvdata(dev);
u32 reg_val;
+ info-idle = true;
/* Enable page mode interrupt */
reg_val = elm_read_reg(info, ELM_IRQSTATUS);
elm_write_reg(info, ELM_IRQSTATUS, reg_val INTR_STATUS_PAGE_VALID);
@@ -298,6 +303,7 @@ void elm_decode_bch_error_page(struct device *dev, u8
*ecc_calc,
reg_val = elm_read_reg(info, ELM_IRQENABLE);
elm_write_reg(info, ELM_IRQENABLE, reg_val ~INTR_EN_PAGE_MASK);
elm_error_correction(info, err_vec);
+ info-idle = false;
}
EXPORT_SYMBOL(elm_decode_bch_error_page);
@@ -368,6 +374,7 @@ static int elm_probe(struct platform_device *pdev)
INIT_LIST_HEAD(info-list);
list_add(info-list, elm_devices);
platform_set_drvdata(pdev, info);
+ info-idle = false;
return ret;
}
@@ -379,6 +386,38 @@ static int elm_remove(struct platform_device *pdev)
return 0;
}
+static int elm_suspend(struct device *dev)
+{
+ struct elm_info *info = dev_get_drvdata(dev);
+ wait_queue_head_t wq;
+ DECLARE_WAITQUEUE(wait, current);
+
+ init_waitqueue_head(wq);
+ while (1) {
+ /* Make sure that ELM not running */
+ if (info-idle) {
+ add_wait_queue(wq, wait);
+ schedule();
+ remove_wait_queue(wq, wait);
+ } else {
+ break;
+ }
+ }
+ pm_runtime_put_sync(dev);
+ return 0;
+}
+
+static int elm_resume(struct device *dev)
+{
+ struct elm_info *info = dev_get_drvdata(dev);
+
+ pm_runtime_get_sync(dev);
+ elm_config(dev, info-bch_type);
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(elm_pm_ops, elm_suspend, elm_resume);
+
#ifdef CONFIG_OF
static const struct of_device_id elm_of_match[] = {
{ .compatible = ti,am3352-elm },
@@ -392,6 +431,7 @@ static struct platform_driver elm_driver = {
.name = elm,
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(elm_of_match),
+ .pm = elm_pm_ops,
},
.probe = elm_probe,
.remove = elm_remove,
--
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
[PATCH v2 4/4] mtd: nand: omap2: Low power transition support
Add support for Low power transition support in nand driver. Also
ensures the current transaction finishes before going to low power mode
with _suspend support in mtd layer.
Signed-off-by: Philip Avinash avinashphi...@ti.com
---
drivers/mtd/nand/omap2.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 8e820dd..790215b 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -2103,9 +2103,28 @@ static int omap_nand_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int omap_nand_suspend(struct platform_device *pdev, pm_message_t state)
+{
+ struct mtd_info *mtd = platform_get_drvdata(pdev);
+
+ mtd-_suspend(mtd);
+ return 0;
+}
+
+static int omap_nand_resume(struct platform_device *pdev)
+{
+ return 0;
+}
+#endif
+
static struct platform_driver omap_nand_driver = {
.probe = omap_nand_probe,
.remove = omap_nand_remove,
+#ifdef CONFIG_PM
+ .suspend= omap_nand_suspend,
+ .resume = omap_nand_resume,
+#endif
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
--
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
Re: [PATCH 0/2] ARM: dts: Add DT bindings for OMAP SDMA
Hi Jon, On 02/06/2013 10:03 PM, Jon Hunter wrote: Adds device-tree bindings from SDMA on OMAP2+ devices. DMA client bindings are also added for devices that have SPI and MMC bindings populated. Client binding data is based upon existing HWMOD data for OMAP and has been checked against OMAP documentation. Testing includes ... 1. Boot tested on OMAP3430 Beagle board, OMAP4430 Panda board and OMAP4460 Panda board with and without device-tree present. 2. Testing of MMC1 with SD card on OMAP3430 Beagle board, OMAP4430 Panda board and OMAP4460 Panda board with and without device-tree present. I looked briefly around in the mentioned code and I wonder how this is going to work with audio (ASoC). When we boot with DT it looks like we are _not_ creating the DMA resources for the device as it is done for the IRQ and IO/MEM. So this means that we can not use get_resource*() for DMA anymore when we move to DT. This might be OK for (OMAP)mmc, (OMAP)spi, etc. But in audio we have a common library used by all platforms to deal with the dmaengine. I don't think we can switch to use dma_request_slave_channel_compat() in soc-dmaengine-pcm.c. We need to pass the dma channel number to the lib from the ASoC platform drivers. Or we need to synchronize the order of the dmas and the dma-names around all SOCs in existence? Has anyone thought about this? CC-ing Mark Brown and Lars-Peter Clausen they might already know the answer to this. Testing branch available here [1]. Series is based upon v3.8-rc6 on top of the following ... - Vinod's topic/dmaengine_dt branch [2] - Matt Porter's series DMA Engine support for AM33XX [3] - Matt Porter's series omap_hsmmc DT DMA Client support [4] - Sourav Poddar's series add omap mcspi device tree data [5] [1] https://github.com/jonhunter/linux/commits/dev-dt-dma [2] http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dmaengine_dt [3] http://permalink.gmane.org/gmane.linux.kernel.spi.devel/12508 [4] http://permalink.gmane.org/gmane.linux.ports.arm.omap/93165 [5] http://permalink.gmane.org/gmane.linux.kernel/1435002 Jon Hunter (2): ARM: dts: OMAP2+: Add SDMA controller bindings and nodes dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver .../devicetree/bindings/dma/omap-sdma.txt | 44 arch/arm/boot/dts/omap2.dtsi | 12 ++ arch/arm/boot/dts/omap3.dtsi | 40 ++ arch/arm/boot/dts/omap4.dtsi | 41 ++ arch/arm/boot/dts/omap5.dtsi | 41 ++ drivers/dma/omap-dma.c | 31 +- 6 files changed, 208 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt -- Péter -- 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
Re: [PATCH 0/2] ARM: dts: Add DT bindings for OMAP SDMA
On Thursday 07 February 2013 14:18:05 Peter Ujfalusi wrote: I looked briefly around in the mentioned code and I wonder how this is going to work with audio (ASoC). When we boot with DT it looks like we are _not_ creating the DMA resources for the device as it is done for the IRQ and IO/MEM. So this means that we can not use get_resource*() for DMA anymore when we move to DT. Yes, this is very much intentional. The use of DMA resources is not really possible across platforms, and I would like to kill it off entirely, as it is not clearly defined what they actually mean. In many cases, a single number cannot express the configuration for a DMA channel, e.g. when you have multiple DMA engines in the system, or you have one that can drive multiple masters for instance. While we could in theory extend the infrastructure around DMA resources to behave like IRQ resources, which can deal with all of that, this would require a lot of code, and go against the trend: in case of GPIO numbers and IRQ numbers, people are generally trying to find ways to get rid of a flat number space and use a more structured interface. This might be OK for (OMAP)mmc, (OMAP)spi, etc. But in audio we have a common library used by all platforms to deal with the dmaengine. I don't think we can switch to use dma_request_slave_channel_compat() in soc-dmaengine-pcm.c. We need to pass the dma channel number to the lib from the ASoC platform drivers. Or we need to synchronize the order of the dmas and the dma-names around all SOCs in existence? Has anyone thought about this? It's the first time I look at the sounds specific portion of this, but it seems straightforward: snd_dmaengine_pcm_open is a wrapper around dma_request_channel and requires a filter function plus data as arguments. We don't want to use filter functions here any more because they don't do what we need, so the logical conclusion is to add a similar wrapper around dma_request_slave_channel, and port drivers to use that instead. I see no connection in ASoC between the use of IORESOURCE_DMA and snd_dmaengine_pcm_open. About half of the drivers calling that function get the argument from a dma resource, while the other ones don't. Similarly, not all ASoC drivers using DMA resources pass the contents of that into snd_dmaengine_pcm_open. Arnd -- 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
Re: MUSB regression in linux next at least for pandboard
On Thu, Feb 7, 2013 at 11:16 AM, Roger Quadros rog...@ti.com wrote: snip It seems the beagleboard problem is related to OMAP silicon errata [1]. Apparently, remote wakeup as well as host issued wakeup break omap-ehci and have nothing to do with the hub or it's driver. I'll work on this issue after I'm done with device tree migration. Looking forward to this, mainline has been suffering from this since almost forever.. -- Gražvydas -- 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
[PATCH] ARM: dts: add minimal DT support for DevKit8000
DevKit8000 is a beagle board clone from Timll, sold by
armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D,
S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and
JTAG interface.
This patch adds the basic DT support for devkit8000. At this time, Information
of twl4030, MMC1, I2C1, leds and there pim mux information are added.
Signed-off-by: Anil Kumar anilk...@gmail.com
Tested-by: Thomas Weber tho...@tomweber.eu
---
-This patch is based on top of kernel 3.8-rc5.
-Tested on Devkit8000.
:100644 100644 5ebb44f... 22ebc76... M arch/arm/boot/dts/Makefile
:00 100644 000... 9864fd7... A arch/arm/boot/dts/omap3-devkit8000.dts
:100644 100644 53cb380b.. 6e2cef6... M arch/arm/mach-omap2/board-generic.c
arch/arm/boot/dts/Makefile |1 +
arch/arm/boot/dts/omap3-devkit8000.dts | 125
arch/arm/mach-omap2/board-generic.c|1 +
3 files changed, 127 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 5ebb44f..22ebc76 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -102,6 +102,7 @@ dtb-$(CONFIG_ARCH_MXS) += imx23-evk.dtb \
imx28-tx28.dtb
dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-beagle.dtb \
+ omap3-devkit8000.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
b/arch/arm/boot/dts/omap3-devkit8000.dts
new file mode 100644
index 000..9864fd7
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -0,0 +1,125 @@
+/*
+ * Anil Kumar anilk...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+/ {
+ model = TI OMAP3 Devkit8000;
+ compatible = ti,omap3-devkit8000, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ leds {
+ compatible = gpio-leds;
+ pinctrl-names = default;
+ pinctrl-0 = leds_pins;
+
+ heartbeat {
+ label = devkit8000::led1;
+ gpios = gpio6 26 0; /* 186 - LED1 */
+ default-state = on;
+ linux,default-trigger = heartbeat;
+ };
+
+ mmc {
+ label = devkit8000::led2;
+ gpios = gpio6 3 0; /* 163 - LED2 */
+ default-state = on;
+ linux,default-trigger = none;
+ };
+
+ usr {
+ label = devkit8000::led3;
+ gpios = gpio6 4 0; /* 164 - LED3 */
+ default-state = on;
+ linux,default-trigger = usr;
+};
+
+ };
+};
+
+omap3_pmx_core {
+ leds_pins: pinmux_led_pins {
+ pinctrl-single,pins =
+ 0x168 0x4 /* GPIO_163 */
+ 0x16c 0x4 /* GPIO_164 */
+ 0x1b0 0x4 /* GPIO_186 */
+
+ ;
+ };
+
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins =
+ 0x188 0x118 /* I2C1_SCL */
+ 0x18c 0x118 /* I2C1_SDA */
+;
+ };
+};
+
+i2c1 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_pins;
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
+
+i2c2 {
+ status = disabled;
+};
+
+i2c3 {
+ status = disabled;
+};
+
+/include/ twl4030.dtsi
+
+mmc1 {
+ vmmc-supply = vmmc1;
+ vmmc_aux-supply = vsim;
+ bus-width = 8;
+};
+
+mmc2 {
+ status = disabled;
+};
+
+mmc3 {
+ status = disabled;
+};
+
+wdt2 {
+ status = disabled;
+};
+
+mcbsp1 {
+ status = disabled;
+};
+
+mcbsp2 {
+ status = disabled;
+};
+
+mcbsp3 {
+ status = disabled;
+};
+
+mcbsp4 {
+ status = disabled;
+};
+
+mcbsp5 {
+ status = disabled;
+};
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 53cb380..6e2cef6 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -110,6 +110,7 @@ MACHINE_END
static const char *omap3_gp_boards_compat[] __initdata = {
ti,omap3-beagle,
+ ti,omap3-devkit8000,
NULL,
};
--
1.7.0.4
--
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
Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
On Wednesday 06 February 2013, Jon Hunter wrote:
+static struct of_dma_filter_info info;
Both members of this structure are constant, so you can just initialize it here,
and it would be nice to give it a more descriptive name, such as
omap_dmadev_info.
static struct platform_driver omap_dma_driver = {
.probe = omap_dma_probe,
.remove = omap_dma_remove,
.driver = {
.name = omap-dma-engine,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(omap_dma_match)
},
};
please end the new line with a comma.
@@ -673,7 +702,7 @@ static int omap_dma_init(void)
{
int rc = platform_driver_register(omap_dma_driver);
- if (rc == 0) {
+ if ((rc == 0) (!of_have_populated_dt())) {
pdev = platform_device_register_full(omap_dma_dev_info);
if (IS_ERR(pdev)) {
platform_driver_unregister(omap_dma_driver);
There is already a patch in linux-next that makes this obsolete.
The device is now registered in arch/arm/mach-omap2/dma.c, so
I guess you have to change that location now.
Arnd
--
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
Re: [PATCH 1/2] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
On Wednesday 06 February 2013, Jon Hunter wrote: Add SDMA controller binding for OMAP2+ devices and populate DMA client information for SPI and MMC periperhal on OMAP3+ devices. Please note that OMAP24xx devices do not have SPI and MMC bindings available yet and so DMA client information is not populated. Signed-off-by: Jon Hunter jon-hun...@ti.com Acked-by: Arnd Bergmann a...@arndb.de -- 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
[PATCH 0/1] OMAP4: DSS: Add panel for Blaze Tablet boards
Hi, This patch adds support for TC358765 DSI-to-LVDS transmitter from Toshiba, that is used in OMAP4 Blaze Tablet development platform. It was originally developed a long time ago and was used internally survived few kernel migrations. Different people worked in this driver during last two years changing its sources to what each new version of kernel expects. Current version is ported from internal kernel v3.4 to 3.8.0-rc6 Tested basic functioning under busybox. - Ruslan Tomi Valkeinen (1): OMAP4: DSS: Add panel for Blaze Tablet boards drivers/video/omap2/displays/Kconfig | 15 + drivers/video/omap2/displays/Makefile |1 + drivers/video/omap2/displays/panel-tc358765.c | 1001 + drivers/video/omap2/displays/panel-tc358765.h | 170 + include/video/omap-panel-tc358765.h | 53 ++ 5 files changed, 1240 insertions(+) create mode 100644 drivers/video/omap2/displays/panel-tc358765.c create mode 100644 drivers/video/omap2/displays/panel-tc358765.h create mode 100644 include/video/omap-panel-tc358765.h -- 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
[PATCH 1/1] OMAP4: DSS: Add panel for Blaze Tablet boards
From: Tomi Valkeinen tomi.valkei...@ti.com
TC358765 is DSI-to-LVDS transmitter from Toshiba, used in
OMAP44XX Blaze Tablet and Blaze Tablet2 boards.
Signed-off-by: Dan Murphy dmur...@ti.com
Signed-off-by: Sergiy Kibrik sergiy.kib...@globallogic.com
Signed-off-by: Volodymyr Riazantsev v.riazant...@ti.com
Signed-off-by: Ruslan Bilovol ruslan.bilo...@ti.com
---
drivers/video/omap2/displays/Kconfig | 15 +
drivers/video/omap2/displays/Makefile |1 +
drivers/video/omap2/displays/panel-tc358765.c | 1001 +
drivers/video/omap2/displays/panel-tc358765.h | 170 +
include/video/omap-panel-tc358765.h | 53 ++
5 files changed, 1240 insertions(+)
create mode 100644 drivers/video/omap2/displays/panel-tc358765.c
create mode 100644 drivers/video/omap2/displays/panel-tc358765.h
create mode 100644 include/video/omap-panel-tc358765.h
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index c3853c9..c6ab261 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -72,4 +72,19 @@ config PANEL_N8X0
depends on BACKLIGHT_CLASS_DEVICE
help
This is the LCD panel used on Nokia N8x0
+
+config PANEL_TC358765
+ tristate Toshiba TC358765 DSI-2-LVDS bridge
+ depends on OMAP2_DSS_DSI I2C
+ select BACKLIGHT_CLASS_DEVICE
+ help
+ Toshiba TC358765 DSI-2-LVDS chip with 1024x768 panel,
+ which can be found in OMAP4-based Blaze Tablet boards
+ and some other boards.
+
+config TC358765_DEBUG
+ bool Toshiba TC358765 DSI-2-LVDS chip debug
+ depends on PANEL_TC358765 DEBUG_FS
+ help
+ Support of TC358765 DSI-2-LVDS chip register access via debugfs
endmenu
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index 58a5176..b9f2ab6 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_PANEL_PICODLP) += panel-picodlp.o
obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_PANEL_ACX565AKM) += panel-acx565akm.o
obj-$(CONFIG_PANEL_N8X0) += panel-n8x0.o
+obj-$(CONFIG_PANEL_TC358765) += panel-tc358765.o
diff --git a/drivers/video/omap2/displays/panel-tc358765.c
b/drivers/video/omap2/displays/panel-tc358765.c
new file mode 100644
index 000..e9d7e96
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-tc358765.c
@@ -0,0 +1,1001 @@
+/*
+ * Toshiba TC358765 DSI-to-LVDS chip driver
+ *
+ * Copyright (C) Texas Instruments
+ * Author: Tomi Valkeinen tomi.valkei...@ti.com (3.0)
+ * Author: Sergii Kibrik sergiikib...@ti.com (3.4)
+ * Author: Ruslan Bilovol ruslan.bilo...@ti.com (3.8+)
+ *
+ * Based on original version from Jerry Alexander x0135...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/mm.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/mutex.h
+#include linux/i2c.h
+#include linux/pm_runtime.h
+#include linux/debugfs.h
+#include linux/seq_file.h
+#include linux/uaccess.h
+
+#include video/omapdss.h
+#include video/omap-panel-tc358765.h
+
+#include panel-tc358765.h
+
+#define A_RO 0x1
+#define A_WO 0x2
+#define A_RW (A_RO|A_WO)
+
+#define FLD_MASK(start, end) (((1 ((start) - (end) + 1)) - 1) (end))
+#define FLD_VAL(val, start, end) (((val) (end)) FLD_MASK(start, end))
+#define FLD_GET(val, start, end) (((val) FLD_MASK(start, end)) (end))
+#define FLD_MOD(orig, val, start, end) \
+ (((orig) ~FLD_MASK(start, end)) | FLD_VAL(val, start, end))
+
+static struct omap_video_timings tc358765_timings;
+static struct tc358765_board_data *get_board_data(struct omap_dss_device
+ *dssdev) __attribute__ ((unused));
+
+/* device private data structure */
+struct tc358765_data {
+ struct mutex lock;
+
+ struct omap_dss_device *dssdev;
+
+ int channel0;
+ int channel1;
+
+ struct omap_dsi_pin_config pin_config;
+};
+
+static struct {
+ struct i2c_client *client;
+ struct mutex xfer_lock;
+} *tc358765_i2c;
+
+
+#ifdef CONFIG_TC358765_DEBUG
+
+struct {
+ struct device *dev;
+ struct dentry *dir;
+} tc358765_debug;
+
+struct tc358765_reg {
+
RE: OMAP baseline test results for v3.8-rc4
On Thu, Feb 07, 2013 at 03:30:56, Paul Walmsley wrote: Hi Vaibhav, On Thu, 24 Jan 2013, Bedia, Vaibhav wrote: I could not track down U-Boot that you were using It's posted now at: http://www.pwsan.com/omap/bootloaders/beaglebone/u-boot/2011.09-9-gcf6e04d__20120803171543/ Care to try it? Thanks. Unfortunately, I'll be able to do this early next week only. However, using your build configs for v3.7 and v3.8-rcX I got the same observations i.e. v3.7 boots but others don't. One difference that I found was that post v3.7 the configs that you are using have CONFIG_EARLY_PRINTK set. Once I disabled that I was able to bootup v3.8-rc1/4 (didn't try rc2/3 but I suspect early_printk was the culprit there too). I checked with Santosh on this and he mentioned that for DT-only boot, which AM335x is, that's expected behavior. Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK Setting CONFIG_EARLY_PRINTK=n doesn't fix the problem I'm seeing. I also tried building a v3.8-rc6 kernel with the old v3.7-rc config that was used before; no luck. Ah, I was really hoping you wouldn't say that ;) or just skip earlyprintk option in the bootargs for now? Haven't tried this one yet. If you still have issues booting can you update your U-Boot to v2013.01 since things seem to be working fine at this point. Let's try to identify and get rid of bootloader dependencies in the kernel. They indicate that the kernel isn't initializing something appropriately, which could cause strange problems later. Agreed. It could also be that the boot-loader is doing something crazy but we do need to know what's the dependency. Regards, Vaibhav -- 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
Re: MUSB regression in linux next at least for pandboard
On Wed, 6 Feb 2013, Alan Stern wrote: Is this issue fixed ? Actually we too are getting very similar issue with samsung exynos5250 hardware. With latest 'usb-next' kernel and supporting arch patches, when i use following test scenerio: Connect a USB 2.0 external hub to USB 2.0 port, and connect mice or keyboard enumeration and functionality is fine but once disconnecting the HID we get to see the error log: hid-generic 0003:04B3:3025.0002: can't reset device, s5p-ehci-1.3/input0, status -71 When i tried to enable CONFIG_USB_DEBUG, get the following log: looks like it's not OMAP-specific. Alan any tips ? It could be a problem with the hub the keyboard is plugged into. Or something going on with the hub driver. I'll try doing the same thing on my system. I tried it. This is on an Intel system, not OMAP or anything like that. The result was as expected; there were a few can't reset device error messages but they stopped after a few hundred ms. If they persist for several minutes then something else is wrong. On the other hand, we could change the priority of those log messages. They don't have to be errors or warnings. Alan Stern -- 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
Re: [PATCH 1/1] OMAP4: DSS: Add panel for Blaze Tablet boards
Hi,
TC358765 is DSI-to-LVDS transmitter from Toshiba, used in
OMAP44XX Blaze Tablet and Blaze Tablet2 boards.
I had a really fast look and I have few comments
+static int tc358765_read_register(struct omap_dss_device *dssdev,
+ u16 reg, u32 *val)
+{
+ int ret = 0;
+ pm_runtime_get_sync(dssdev-dev);
+ /* I2C is preferred way of reading, but fall back to DSI
+ * if I2C didn't got initialized
+ */
+ if (tc358765_i2c)
+ ret = tc358765_i2c_read(reg, val);
+ else
+ ret = tc358765_dsi_read(dssdev, reg, val);
+ pm_runtime_put_sync(dssdev-dev);
+
+ return ret;
+}
+
+static int tc358765_write_register(struct omap_dss_device *dssdev, u16 reg,
+ u32 value)
+{
+ struct tc358765_data *d2d = dev_get_drvdata(dssdev-dev);
+ u8 buf[6];
+ int r;
+
+ buf[0] = (reg 0) 0xff;
+ buf[1] = (reg 8) 0xff;
+ buf[2] = (value 0) 0xff;
+ buf[3] = (value 8) 0xff;
+ buf[4] = (value 16) 0xff;
+ buf[5] = (value 24) 0xff;
+
+ r = dsi_vc_generic_write_nosync(dssdev, d2d-channel1, buf, 6);
+ if (r)
+ dev_err(dssdev-dev, reg write reg(%x) val(%x) failed: %d\n,
+reg, value, r);
+ return r;
+}
+
+/
+* DEBUG *
+/
+#ifdef CONFIG_TC358765_DEBUG
+static int tc358765_write_register_i2c(u16 reg, u32 val)
+{
+ int ret = -ENODEV;
+ unsigned char buf[6];
+ struct i2c_msg msg;
+
+ if (!tc358765_i2c) {
+ dev_err(tc358765_debug.dev, %s: I2C not initilized\n,
+ __func__);
+ return ret;
+ }
+
+ buf[0] = (reg 8) 0xff;
+ buf[1] = (reg 0) 0xff;
+ buf[2] = (val 0) 0xff;
+ buf[3] = (val 8) 0xff;
+ buf[4] = (val 16) 0xff;
+ buf[5] = (val 24) 0xff;
+ msg.addr = tc358765_i2c-client-addr;
+ msg.len = sizeof(buf);
+ msg.flags = 0;
+ msg.buf = buf;
+
+ mutex_lock(tc358765_i2c-xfer_lock);
+ ret = i2c_transfer(tc358765_i2c-client-adapter, msg, 1);
+ mutex_unlock(tc358765_i2c-xfer_lock);
+
+ if (ret != 1)
+ return ret;
+ return 0;
+}
What about using smbus?
+
+ if (copy_from_user(buf, ubuf, size))
+ return -EFAULT;
+
+ buf[size-1] = '\0';
+ if (sscanf(buf, %s %x, name, value) != 2) {
+ dev_err(dev, %s: unable to parse input\n, __func__);
+ return -1;
+ }
+
+ if (!tc358765_i2c) {
+ dev_warn(dev,
+ failed to write register: I2C not initialized\n);
+ return -ENODEV;
+ }
+
+ reg_count = sizeof(tc358765_regs) / sizeof(tc358765_regs[0]);
+ for (i = 0; i reg_count; i++) {
+ if (!strcmp(name, tc358765_regs[i].name)) {
+ if (!(tc358765_regs[i].perm A_WO)) {
+ dev_err(dev, %s is write-protected\n, name);
+ return -EACCES;
+ }
+
+ error = tc358765_write_register_i2c(
+ tc358765_regs[i].reg, value);
+ if (error) {
+ dev_err(dev, %s: failed to write %s\n,
+ __func__, name);
+ return -1;
Could avoid returning -1 instead of returning a correct errno?
+ gpio_set_value(dssdev-reset_gpio, 1);
+ udelay(200);
+ /* reset the panel */
+ gpio_set_value(dssdev-reset_gpio, 0);
+ /* assert reset */
+ udelay(200);
+ gpio_set_value(dssdev-reset_gpio, 1);
+ /* wait after releasing reset */
+ msleep(200);
I invite you to have a look at
Documentation/timers/timers-howto.txt
+ /* reset LVDS-PHY */
+ tc358765_write_register(dssdev, LVPHY0, (1 22));
+ mdelay(2);
You should give me a really good reason for using mdelay.
+ if (r) {
+ dev_err(dssdev-dev, failed to configure DSI pins\n);
+ goto err_disp_enable;
+ };
^^^
???
+static int tc358765_i2c_probe(struct i2c_client *client,
+const struct i2c_device_id *id)
+{
+ tc358765_i2c = kzalloc(sizeof(*tc358765_i2c), GFP_KERNEL);
what about devm_kzalloc?
--
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
Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
On 02/07/2013 08:39 AM, Arnd Bergmann wrote:
On Wednesday 06 February 2013, Jon Hunter wrote:
+static struct of_dma_filter_info info;
Both members of this structure are constant, so you can just initialize it
here,
and it would be nice to give it a more descriptive name, such as
omap_dmadev_info.
static struct platform_driver omap_dma_driver = {
.probe = omap_dma_probe,
.remove = omap_dma_remove,
.driver = {
.name = omap-dma-engine,
.owner = THIS_MODULE,
+.of_match_table = of_match_ptr(omap_dma_match)
},
};
please end the new line with a comma.
Ok.
@@ -673,7 +702,7 @@ static int omap_dma_init(void)
{
int rc = platform_driver_register(omap_dma_driver);
-if (rc == 0) {
+if ((rc == 0) (!of_have_populated_dt())) {
pdev = platform_device_register_full(omap_dma_dev_info);
if (IS_ERR(pdev)) {
platform_driver_unregister(omap_dma_driver);
There is already a patch in linux-next that makes this obsolete.
The device is now registered in arch/arm/mach-omap2/dma.c, so
I guess you have to change that location now.
Thanks. Will rebase on top of linux-next.
Cheers
Jon
--
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
[PATCH v2 03/14] mfd: omap-usb-tll: move configuration code to omap_tll_init()
This is because we want to get rid of platform_data usage from probe().
The only information we need is PORT_MODE, and this can be supplied
to us by the user (i.e. omap-usb-host.c).
We also move channel clock management from runtime PM handlers into
omap_tll_enable/disable().
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c |7 +-
drivers/mfd/omap-usb-tll.c | 204 +--
drivers/mfd/omap-usb.h |5 +-
3 files changed, 107 insertions(+), 109 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 502a779..f8ed08e 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -278,7 +278,7 @@ static int usbhs_runtime_resume(struct device *dev)
dev_dbg(dev, usbhs_runtime_resume\n);
- omap_tll_enable();
+ omap_tll_enable(pdata);
if (!IS_ERR(omap-ehci_logic_fck))
clk_enable(omap-ehci_logic_fck);
@@ -353,7 +353,7 @@ static int usbhs_runtime_suspend(struct device *dev)
if (!IS_ERR(omap-ehci_logic_fck))
clk_disable(omap-ehci_logic_fck);
- omap_tll_disable();
+ omap_tll_disable(pdata);
return 0;
}
@@ -499,6 +499,9 @@ static int usbhs_omap_probe(struct platform_device *pdev)
omap-pdata = pdata;
+ /* Initialize the TLL subsystem */
+ omap_tll_init(pdata);
+
pm_runtime_enable(dev);
platform_set_drvdata(pdev, omap);
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index 0aef1a7..f7d2568 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -1,8 +1,9 @@
/**
* omap-usb-tll.c - The USB TLL driver for OMAP EHCI OHCI
*
- * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2012-2013 Texas Instruments Incorporated - http://www.ti.com
* Author: Keshava Munegowda keshava_mgo...@ti.com
+ * Author: Roger Quadros rog...@ti.com
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 of
@@ -105,8 +106,8 @@
struct usbtll_omap {
int nch;/* num. of channels */
- struct usbhs_omap_platform_data *pdata;
struct clk **ch_clk;
+ void __iomem*base;
};
/*-*/
@@ -210,14 +211,10 @@ static unsigned ohci_omap3_fslsmode(enum
usbhs_omap_port_mode mode)
static int usbtll_omap_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
- struct usbhs_omap_platform_data *pdata = dev-platform_data;
- void __iomem*base;
struct resource *res;
struct usbtll_omap *tll;
- unsignedreg;
int ret = 0;
int i, ver;
- bool needs_tll;
dev_dbg(dev, starting TI HSUSB TLL Controller\n);
@@ -227,16 +224,9 @@ static int usbtll_omap_probe(struct platform_device *pdev)
return -ENOMEM;
}
- if (!pdata) {
- dev_err(dev, Platform data missing\n);
- return -ENODEV;
- }
-
- tll-pdata = pdata;
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- base = devm_request_and_ioremap(dev, res);
- if (!base) {
+ tll-base = devm_request_and_ioremap(dev, res);
+ if (!tll-base) {
ret = -EADDRNOTAVAIL;
dev_err(dev, Resource request/ioremap failed:%d\n, ret);
return ret;
@@ -246,7 +236,7 @@ static int usbtll_omap_probe(struct platform_device *pdev)
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
- ver = usbtll_read(base, OMAP_USBTLL_REVISION);
+ ver = usbtll_read(tll-base, OMAP_USBTLL_REVISION);
switch (ver) {
case OMAP_USBTLL_REV1:
case OMAP_USBTLL_REV4:
@@ -283,11 +273,77 @@ static int usbtll_omap_probe(struct platform_device *pdev)
dev_dbg(dev, can't get clock : %s\n, clkname);
}
+ pm_runtime_put_sync(dev);
+ /* only after this can omap_tll_enable/disable work */
+ spin_lock(tll_lock);
+ tll_dev = dev;
+ spin_unlock(tll_lock);
+
+ return 0;
+
+err_clk_alloc:
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
+
+ return ret;
+}
+
+/**
+ * usbtll_omap_remove - shutdown processing for UHH TLL HCDs
+ * @pdev: USB Host Controller being removed
+ *
+ * Reverses the effect of usbtll_omap_probe().
+ */
+static int usbtll_omap_remove(struct platform_device *pdev)
+{
+ struct usbtll_omap *tll =
[PATCH v2 09/14] mfd: omap-usb-host: Add device tree support and binding information
Allows the OMAP HS USB host controller to be specified
via device tree.
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/mfd/omap-usb-host.txt | 80 ++
drivers/mfd/omap-usb-host.c| 160 +++-
2 files changed, 234 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
new file mode 100644
index 000..b381fa6
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -0,0 +1,80 @@
+OMAP HS USB Host
+
+Required properties:
+
+- compatible: should be ti,usbhs-host
+- reg: should contain one register range i.e. start and length
+- ti,hwmods: must contain usb_host_hs
+
+Optional properties:
+
+- num-ports: number of USB ports. Usually this is automatically detected
+ from the IP's revision register but can be overridden by specifying
+ this property. A maximum of 3 ports are supported at the moment.
+
+- portN-mode: String specifying the port mode for port N, where N can be
+ from 1 to 3. If the port mode is not specified, that port is treated
+ as unused. When specified, it must be one of the following.
+ ehci-phy,
+ehci-tll,
+ehci-hsic,
+ohci-phy-6pin-datse0,
+ohci-phy-6pin-dpdm,
+ohci-phy-3pin-datse0,
+ohci-phy-4pin-dpdm,
+ohci-tll-6pin-datse0,
+ohci-tll-6pin-dpdm,
+ohci-tll-3pin-datse0,
+ohci-tll-4pin-dpdm,
+ohci-tll-2pin-datse0,
+ohci-tll-2pin-dpdm,
+
+- single-ulpi-bypass: Must be present if the controller contains a single
+ ULPI bypass control bit. e.g. OMAP3 silicon = ES2.1
+
+Required properties if child node exists:
+
+- #address-cells: Must be 1
+- #size-cells: Must be 1
+- ranges: must be present
+
+Properties for children:
+
+The OMAP HS USB Host subsystem contains EHCI and OHCI controllers.
+See Documentation/devicetree/bindings/usb/omap-ehci.txt and
+omap3-ohci.txt
+
+Example for OMAP4:
+
+usbhshost: usbhshost@4a064000 {
+ compatible = ti,usbhs-host;
+ reg = 0x4a064000 0x800;
+ ti,hwmods = usb_host_hs;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbhsohci: ohci@4a064800 {
+ compatible = ti,ohci-omap3, usb-ohci;
+ reg = 0x4a064800 0x400;
+ interrupt-parent = gic;
+ interrupts = 0 76 0x4;
+ };
+
+ usbhsehci: ehci@4a064c00 {
+ compatible = ti,ehci-omap, usb-ehci;
+ reg = 0x4a064c00 0x400;
+ interrupt-parent = gic;
+ interrupts = 0 77 0x4;
+ };
+};
+
+usbhshost {
+ port1-mode = ehci-phy;
+ port2-mode = ehci-tll;
+ port3-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = hsusb1_phy 0 hsusb3_phy;
+};
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index f8ed08e..ffc373bc 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -1,8 +1,9 @@
/**
* omap-usb-host.c - The USBHS core driver for OMAP EHCI OHCI
*
- * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2011-2013 Texas Instruments Incorporated - http://www.ti.com
* Author: Keshava Munegowda keshava_mgo...@ti.com
+ * Author: Roger Quadros rog...@ti.com
*
* This program is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 of
@@ -27,6 +28,8 @@
#include linux/platform_device.h
#include linux/platform_data/usb-omap.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_platform.h
#include omap-usb.h
@@ -137,6 +140,49 @@ static inline u8 usbhs_readb(void __iomem *base, u8 reg)
/*-*/
+/**
+ * Map 'enum usbhs_omap_port_mode' found in linux/platform_data/usb-omap.h
+ * to the device tree binding portN-mode found in
+ * 'Documentation/devicetree/bindings/mfd/omap-usb-host.txt'
+ */
+static const char *port_modes[] = {
+ [OMAP_USBHS_PORT_MODE_UNUSED] = ,
+ [OMAP_EHCI_PORT_MODE_PHY] = ehci-phy,
+ [OMAP_EHCI_PORT_MODE_TLL] = ehci-tll,
+ [OMAP_EHCI_PORT_MODE_HSIC] = ehci-hsic,
+ [OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0] = ohci-phy-6pin-datse0,
+ [OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM] = ohci-phy-6pin-dpdm,
+ [OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0] = ohci-phy-3pin-datse0,
+ [OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM] = ohci-phy-4pin-dpdm,
+ [OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0] = ohci-tll-6pin-datse0,
+ [OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM] = ohci-tll-6pin-dpdm,
+ [OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0] = ohci-tll-3pin-datse0,
+ [OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM] = ohci-tll-4pin-dpdm,
+
[PATCH v2 13/14] ARM: dts: omap3-beagle: Add USB Host support
Provide RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 71
1 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..02d23f1 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -38,6 +38,57 @@
};
};
+ /* HS USB Port 2 RESET */
+ hsusb2_reset: hsusb2_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio5 19 0; /* gpio_147 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Port 2 Power */
+ hsusb2_power: hsusb2_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb2_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = twl_gpio 18 0;/* GPIO LEDA */
+ startup-delay-us = 7;
+ };
+
+ /* HS USB Host PHY on PORT 2 */
+ hsusb2_phy: hsusb2_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb2_reset;
+ vcc-supply = hsusb2_power;
+ };
+};
+
+omap3_pmx_core {
+ pinctrl-names = default;
+ pinctrl-0 =
+ hsusbb2_pins
+ ;
+
+ hsusbb2_pins: pinmux_hsusbb2_pins {
+ pinctrl-single,pins =
+ 0x5c0 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk OUTPUT */
+ 0x5c2 0x3 /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+ 0x5c4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+ 0x5c6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+ 0x5c8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+ 0x5cA 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+ 0x1a4 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+ 0x1a6 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+ 0x1a8 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+ 0x1aa 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+ 0x1ac 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+ 0x1ae 0x10b /*
USBB2_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+ ;
+ };
};
i2c1 {
@@ -65,3 +116,23 @@
mmc3 {
status = disabled;
};
+
+usbhshost {
+ port2-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = 0 hsusb2_phy;
+};
+
+twl_gpio {
+ ti,use-leds;
+ /* pullups: BIT(1) */
+ ti,pullups = 0x02;
+ /*
+* pulldowns:
+* BIT(2), BIT(6), BIT(7), BIT(8), BIT(13)
+* BIT(15), BIT(16), BIT(17)
+*/
+ ti,pulldowns = 0x03a1c4;
+};
--
1.7.4.1
--
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
[PATCH v2 14/14] USB: ehci-omap: Fix autoloading of module
The module alias should be ehci-omap and not omap-ehci to match the platform device name. The omap-ehci module should now autoload correctly. Signed-off-by: Roger Quadros rog...@ti.com --- drivers/usb/host/ehci-omap.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index a8ce10d..a2d16c0 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -340,9 +340,10 @@ static void __exit ehci_omap_cleanup(void) } module_exit(ehci_omap_cleanup); -MODULE_ALIAS(platform:omap-ehci); +MODULE_ALIAS(platform:ehci-omap); MODULE_AUTHOR(Texas Instruments, Inc.); MODULE_AUTHOR(Felipe Balbi felipe.ba...@nokia.com); +MODULE_AUTHOR(Roger Quadros rog...@ti.com); MODULE_DESCRIPTION(DRIVER_DESC); MODULE_LICENSE(GPL); -- 1.7.4.1 -- 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
[PATCH v2 11/14] ARM: dts: omap4-panda: Add USB Host support
Provide the RESET and Power regulators for the USB PHY,
the USB Host port mode and the PHY device.
Also provide pin multiplexer information for the USB host
pins.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 55 +
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..d6e59c7 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -57,6 +57,35 @@
AFML, Line In,
AFMR, Line In;
};
+
+ /* HS USB Port 1 RESET */
+ hsusb1_reset: hsusb1_reset_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_reset;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio2 30 0; /* gpio_62 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Port 1 Power */
+ hsusb1_power: hsusb1_power_reg {
+ compatible = regulator-fixed;
+ regulator-name = hsusb1_vbus;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ gpio = gpio1 1 0;/* gpio_1 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
+
+ /* HS USB Host PHY on PORT 1 */
+ hsusb1_phy: hsusb1_phy {
+ compatible = usb-nop-xceiv;
+ reset-supply = hsusb1_reset;
+ vcc-supply = hsusb1_power;
+ };
};
omap4_pmx_core {
@@ -67,6 +96,7 @@
mcbsp1_pins
dss_hdmi_pins
tpd12s015_pins
+ hsusbb1_pins
;
twl6040_pins: pinmux_twl6040_pins {
@@ -110,6 +140,23 @@
0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
;
};
+
+ hsusbb1_pins: pinmux_hsusbb1_pins {
+ pinctrl-single,pins =
+ 0x82 0x10C /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_clk INPUT | PULLDOWN */
+ 0x84 0x4/*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_stp OUTPUT */
+ 0x86 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dir INPUT | PULLDOWN */
+ 0x88 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_nxt INPUT | PULLDOWN */
+ 0x8a 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat0 INPUT | PULLDOWN */
+ 0x8c 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat1 INPUT | PULLDOWN */
+ 0x8e 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat2 INPUT | PULLDOWN */
+ 0x90 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat3 INPUT | PULLDOWN */
+ 0x92 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat4 INPUT | PULLDOWN */
+ 0x94 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat5 INPUT | PULLDOWN */
+ 0x96 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat6 INPUT | PULLDOWN */
+ 0x98 0x104 /*
USBB1_ULPITLL_CLK_MUXMODE.usbb1_ulpiphy_dat7 INPUT | PULLDOWN */
+ ;
+ };
};
i2c1 {
@@ -206,3 +253,11 @@
twl_usb_comparator {
usb-supply = vusb;
};
+
+usbhshost {
+ port1-mode = ehci-phy;
+};
+
+usbhsehci {
+ phys = hsusb1_phy;
+};
--
1.7.4.1
--
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
[PATCH v2 07/14] USB: ohci-omap3: Add device tree support and binding information
Allows the OHCI controller found in OMAP3 and later chips to
be specified via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
.../devicetree/bindings/usb/omap3-ohci.txt | 17 +
drivers/usb/host/ohci-omap3.c | 19 +++
2 files changed, 36 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/omap3-ohci.txt
diff --git a/Documentation/devicetree/bindings/usb/omap3-ohci.txt
b/Documentation/devicetree/bindings/usb/omap3-ohci.txt
new file mode 100644
index 000..ad2ace0
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap3-ohci.txt
@@ -0,0 +1,17 @@
+OMAP HS USB OHCI controller (OMAP3 and later)
+
+Required properties:
+
+- compatible: should be ti,ohci-omap3
+- reg: should contain one register range i.e. start and length
+- interrupt-parent: phandle to the interrupt controller
+- interrupts: description of the interrupt line
+
+Example for OMAP4:
+
+usbhsohci: ohci@4a064800 {
+ compatible = ti,ohci-omap3, usb-ohci;
+ reg = 0x4a064800 0x400;
+ interrupt-parent = gic;
+ interrupts = 0 76 0x4;
+};
diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
index 5ed28c5..ddfc314 100644
--- a/drivers/usb/host/ohci-omap3.c
+++ b/drivers/usb/host/ohci-omap3.c
@@ -31,6 +31,8 @@
#include linux/platform_device.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/dma-mapping.h
/*-*/
@@ -112,6 +114,8 @@ static const struct hc_driver ohci_omap3_hc_driver = {
/*-*/
+static u64 omap_ohci_dma_mask = DMA_BIT_MASK(32);
+
/*
* configure so an HC device and id are always provided
* always called with process context; sleeping is OK
@@ -159,6 +163,13 @@ static int ohci_hcd_omap3_probe(struct platform_device
*pdev)
return -ENOMEM;
}
+ /*
+* Right now device-tree probed devices don't get dma_mask set.
+* Since shared usb code relies on it, set it here for now.
+* Once we have dma capability bindings this can go away.
+*/
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = omap_ohci_dma_mask;
hcd = usb_create_hcd(ohci_omap3_hc_driver, dev,
dev_name(dev));
@@ -228,12 +239,20 @@ static void ohci_hcd_omap3_shutdown(struct
platform_device *pdev)
hcd-driver-shutdown(hcd);
}
+static const struct of_device_id omap_ohci_dt_ids[] = {
+ { .compatible = ti,ohci-omap3 },
+ { }
+};
+
+MODULE_DEVICE_TABLE(of, omap_ohci_dt_ids);
+
static struct platform_driver ohci_hcd_omap3_driver = {
.probe = ohci_hcd_omap3_probe,
.remove = ohci_hcd_omap3_remove,
.shutdown = ohci_hcd_omap3_shutdown,
.driver = {
.name = ohci-omap3,
+ .of_match_table = of_match_ptr(omap_ohci_dt_ids),
},
};
--
1.7.4.1
--
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
[PATCH v2 08/14] USB: ehci-omap: Add device tree support and binding information
Allows the OMAP EHCI controller to be specified via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
.../devicetree/bindings/usb/omap-ehci.txt | 34 ++
drivers/usb/host/ehci-omap.c | 36 +++-
2 files changed, 69 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/omap-ehci.txt
diff --git a/Documentation/devicetree/bindings/usb/omap-ehci.txt
b/Documentation/devicetree/bindings/usb/omap-ehci.txt
new file mode 100644
index 000..b00a654
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-ehci.txt
@@ -0,0 +1,34 @@
+OMAP HS USB EHCI controller
+
+This device is usually the child of the omap-usb-host
+Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+
+Required properties:
+
+- compatible: should be ti,ehci-omap
+- reg: should contain one register range i.e. start and length
+- interrupt-parent: phandle to the interrupt controller
+- interrupts: description of the interrupt line
+
+Optional properties:
+
+- phys: list of phandles to PHY nodes.
+ This property is required if at least one of the ports are in
+ PHY mode i.e. OMAP_EHCI_PORT_MODE_PHY
+
+To specify the port mode, see
+Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+
+Example for OMAP4:
+
+usbhsehci: ehci@4a064c00 {
+ compatible = ti,ehci-omap, usb-ehci;
+ reg = 0x4a064c00 0x400;
+ interrupt-parent = gic;
+ interrupts = 0 77 0x4;
+};
+
+usbhsehci {
+ phys = hsusb1_phy 0 hsusb3_phy;
+};
+
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 02a7893..a8ce10d 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -48,6 +48,8 @@
#include linux/clk.h
#include linux/usb.h
#include linux/usb/hcd.h
+#include linux/of.h
+#include linux/dma-mapping.h
#include ehci.h
@@ -121,6 +123,8 @@ static const struct ehci_driver_overrides
ehci_omap_overrides __initdata = {
.extra_priv_size = sizeof(struct omap_hcd),
};
+static u64 omap_ehci_dma_mask = DMA_BIT_MASK(32);
+
/**
* ehci_hcd_omap_probe - initialize TI-based HCDs
*
@@ -148,6 +152,17 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
return -ENODEV;
}
+ /* For DT boot, get platform data from parent. i.e. usbhshost */
+ if (dev-of_node) {
+ pdata = dev-parent-platform_data;
+ dev-platform_data = pdata;
+ }
+
+ if (!pdata) {
+ dev_err(dev, Missing platform data\n);
+ return -ENODEV;
+ }
+
irq = platform_get_irq(pdev, 0);
if (irq 0) {
dev_err(dev, EHCI irq failed\n);
@@ -161,6 +176,14 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
return -EADDRNOTAVAIL;
}
+ /*
+* Right now device-tree probed devices don't get dma_mask set.
+* Since shared usb code relies on it, set it here for now.
+* Once we have dma capability bindings this can go away.
+*/
+ if (!pdev-dev.dma_mask)
+ pdev-dev.dma_mask = omap_ehci_dma_mask;
+
hcd = usb_create_hcd(ehci_omap_hc_driver, dev,
dev_name(dev));
if (!hcd) {
@@ -185,7 +208,10 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
continue;
/* get the PHY device */
- phy = devm_usb_get_phy_dev(dev, i);
+ if (dev-of_node)
+ phy = devm_usb_get_phy_by_phandle(dev, phys, i);
+ else
+ phy = devm_usb_get_phy_dev(dev, i);
if (IS_ERR(phy) || !phy) {
ret = IS_ERR(phy) ? PTR_ERR(phy) : -ENODEV;
dev_err(dev, Can't get PHY device for port %d: %d\n,
@@ -275,6 +301,13 @@ static void ehci_hcd_omap_shutdown(struct platform_device
*pdev)
hcd-driver-shutdown(hcd);
}
+static const struct of_device_id omap_ehci_dt_ids[] = {
+ { .compatible = ti,ehci-omap },
+ { }
+};
+
+MODULE_DEVICE_TABLE(of, omap_ehci_dt_ids);
+
static struct platform_driver ehci_hcd_omap_driver = {
.probe = ehci_hcd_omap_probe,
.remove = ehci_hcd_omap_remove,
@@ -283,6 +316,7 @@ static struct platform_driver ehci_hcd_omap_driver = {
/*.resume = ehci_hcd_omap_resume, */
.driver = {
.name = hcd_name,
+ .of_match_table = of_match_ptr(omap_ehci_dt_ids),
}
};
--
1.7.4.1
--
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
[PATCH v2 12/14] ARM: dts: OMAP3: Add HS USB Host IP nodes
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..a14f74b 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -397,5 +397,36 @@
ti,timer-alwon;
ti,timer-secure;
};
+
+ usbhstll: usbhstll@48062000 {
+ compatible = ti,usbhs-tll;
+ reg = 0x48062000 0x1000;
+ interrupts = 78;
+ ti,hwmods = usb_tll_hs;
+ };
+
+ usbhshost: usbhshost@48064000 {
+ compatible = ti,usbhs-host;
+ reg = 0x48064000 0x400;
+ ti,hwmods = usb_host_hs;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbhsohci: ohci@48064400 {
+ compatible = ti,ohci-omap3, usb-ohci;
+ reg = 0x48064400 0x400;
+ interrupt-parent = intc;
+ interrupts = 76;
+ };
+
+ usbhsehci: ehci@48064800 {
+ compatible = ti,ehci-omap, usb-ehci;
+ reg = 0x48064800 0x400;
+ interrupt-parent = intc;
+ interrupts = 77;
+ };
+ };
+
};
};
--
1.7.4.1
--
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
[PATCH v2 10/14] ARM: dts: OMAP4: Add HS USB Host IP nodes
Adds device nodes for HS USB Host module, TLL module,
OHCI and EHCI controllers.
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 30 ++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..b7db1a2 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -529,5 +529,35 @@
ti,hwmods = timer11;
ti,timer-pwm;
};
+
+ usbhstll: usbhstll@4a062000 {
+ compatible = ti,usbhs-tll;
+ reg = 0x4a062000 0x1000;
+ interrupts = 0 78 0x4;
+ ti,hwmods = usb_tll_hs;
+ };
+
+ usbhshost: usbhshost@4a064000 {
+ compatible = ti,usbhs-host;
+ reg = 0x4a064000 0x800;
+ ti,hwmods = usb_host_hs;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ usbhsohci: ohci@4a064800 {
+ compatible = ti,ohci-omap3, usb-ohci;
+ reg = 0x4a064800 0x400;
+ interrupt-parent = gic;
+ interrupts = 0 76 0x4;
+ };
+
+ usbhsehci: ehci@4a064c00 {
+ compatible = ti,ehci-omap, usb-ehci;
+ reg = 0x4a064c00 0x400;
+ interrupt-parent = gic;
+ interrupts = 0 77 0x4;
+ };
+ };
};
};
--
1.7.4.1
--
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
[PATCH v2 06/14] USB: ohci-omap3: Get platform resources by index rather than by name
Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ohci-omap3.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ohci-omap3.c b/drivers/usb/host/ohci-omap3.c
index eb35d96..5ed28c5 100644
--- a/drivers/usb/host/ohci-omap3.c
+++ b/drivers/usb/host/ohci-omap3.c
@@ -141,14 +141,13 @@ static int ohci_hcd_omap3_probe(struct platform_device
*pdev)
return -ENODEV;
}
- irq = platform_get_irq_byname(pdev, ohci-irq);
+ irq = platform_get_irq(pdev, 0);
if (irq 0) {
dev_err(dev, OHCI irq failed\n);
return -ENODEV;
}
- res = platform_get_resource_byname(pdev,
- IORESOURCE_MEM, ohci);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, UHH OHCI get resource failed\n);
return -ENOMEM;
--
1.7.4.1
--
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
[PATCH v2 00/14] Device tree support for OMAP HS USB Host
Hi, This patchset adds device tree support for OMAP's High Speed USB Host subsystem. Board adaptation for Panda and Beagleboard is also provided. Tested on Beagleboard. Will not yet work on Pandaboard as PHY clock is not provided in device tree. We will need to address the PHY clock as per the discussion. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg84525.html v2: - Addressed review comments, hopefully device tree parsing is more compliant and robust now. - Added one new patch to fix omap-ehci module auto loading The following changes since commit 286752ff5401f4b1675c4c33d13252a96e66bcb3: USB: ehci-omap: Select NOP USB transceiver driver (2013-02-07 17:00:54 +0200) are available in the git repository at: g...@github.com:rogerq/linux.git usb-next-usbhost16-dt Roger Quadros (14): usb: phy: nop: Add device tree support and binding information USB: phy: nop: Defer probe if device needs VCC/RESET mfd: omap-usb-tll: move configuration code to omap_tll_init() mfd: omap-usb-tll: Add device tree support USB: ehci-omap: Get platform resources by index rather than by name USB: ohci-omap3: Get platform resources by index rather than by name USB: ohci-omap3: Add device tree support and binding information USB: ehci-omap: Add device tree support and binding information mfd: omap-usb-host: Add device tree support and binding information ARM: dts: OMAP4: Add HS USB Host IP nodes ARM: dts: omap4-panda: Add USB Host support ARM: dts: OMAP3: Add HS USB Host IP nodes ARM: dts: omap3-beagle: Add USB Host support USB: ehci-omap: Fix autoloading of module .../devicetree/bindings/mfd/omap-usb-host.txt | 80 .../devicetree/bindings/mfd/omap-usb-tll.txt | 17 ++ .../devicetree/bindings/usb/omap-ehci.txt | 34 +++ .../devicetree/bindings/usb/omap3-ohci.txt | 17 ++ .../devicetree/bindings/usb/usb-nop-xceiv.txt | 34 +++ arch/arm/boot/dts/omap3-beagle.dts | 71 +++ arch/arm/boot/dts/omap3.dtsi | 31 +++ arch/arm/boot/dts/omap4-panda.dts | 55 + arch/arm/boot/dts/omap4.dtsi | 30 +++ drivers/mfd/omap-usb-host.c| 167 +++- drivers/mfd/omap-usb-tll.c | 213 ++-- drivers/mfd/omap-usb.h |5 +- drivers/usb/host/ehci-omap.c | 46 - drivers/usb/host/ohci-omap3.c | 24 ++- drivers/usb/otg/nop-usb-xceiv.c| 47 - include/linux/usb/nop-usb-xceiv.h |4 + 16 files changed, 743 insertions(+), 132 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-host.txt create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-tll.txt create mode 100644 Documentation/devicetree/bindings/usb/omap-ehci.txt create mode 100644 Documentation/devicetree/bindings/usb/omap3-ohci.txt create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt -- 1.7.4.1 -- 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
[PATCH v2 01/14] usb: phy: nop: Add device tree support and binding information
The PHY clock, clock rate, VCC regulator and RESET regulator
can now be provided via device tree.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
.../devicetree/bindings/usb/usb-nop-xceiv.txt | 34 ++
drivers/usb/otg/nop-usb-xceiv.c| 36 +++
2 files changed, 62 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
new file mode 100644
index 000..d7e2726
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -0,0 +1,34 @@
+USB NOP PHY
+
+Required properties:
+- compatible: should be usb-nop-xceiv
+
+Optional properties:
+- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
+ /bindings/clock/clock-bindings.txt
+ This property is required if clock-frequency is specified.
+
+- clock-names: Should be main_clk
+
+- clock-frequency: the clock frequency (in Hz) that the PHY clock must
+ be configured to.
+
+- vcc-supply: phandle to the regulator that provides RESET to the PHY.
+
+- reset-supply: phandle to the regulator that provides power to the PHY.
+
+Example:
+
+ hsusb1_phy {
+ compatible = usb-nop-xceiv;
+ clock-frequency = 1920;
+ clocks = osc 0;
+ clock-names = main_clk;
+ vcc-supply = hsusb1_vcc_regulator;
+ reset-supply = hsusb1_reset_regulator;
+ };
+
+hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
+and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
+hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
+controls RESET.
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index ac027a1..6b7a9a0 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -34,13 +34,15 @@
#include linux/slab.h
#include linux/clk.h
#include linux/regulator/consumer.h
+#include linux/of.h
struct nop_usb_xceiv {
- struct usb_phy phy;
- struct device *dev;
- struct clk *clk;
- struct regulator*vcc;
- struct regulator*reset;
+ struct usb_phy phy;
+ struct device *dev;
+ struct clk *clk;
+ struct regulator *vcc;
+ struct regulator *reset;
+ u32 clk_rate;
};
static struct platform_device *pd;
@@ -140,6 +142,7 @@ static int nop_set_host(struct usb_otg *otg, struct usb_bus
*host)
static int nop_usb_xceiv_probe(struct platform_device *pdev)
{
+ struct device *dev = pdev-dev;
struct nop_usb_xceiv_platform_data *pdata = pdev-dev.platform_data;
struct nop_usb_xceiv*nop;
enum usb_phy_type type = USB_PHY_TYPE_USB2;
@@ -153,8 +156,17 @@ static int nop_usb_xceiv_probe(struct platform_device
*pdev)
if (!nop-phy.otg)
return -ENOMEM;
- if (pdata)
+ if (dev-of_node) {
+ struct device_node *node = dev-of_node;
+ u32 clk_rate;
+
+ if (!of_property_read_u32(node, clock-frequency, clk_rate))
+ nop-clk_rate = clk_rate;
+
+ } else if (pdata) {
type = pdata-type;
+ nop-clk_rate = pdata-clk_rate;
+ }
nop-clk = devm_clk_get(pdev-dev, main_clk);
if (IS_ERR(nop-clk)) {
@@ -162,8 +174,8 @@ static int nop_usb_xceiv_probe(struct platform_device *pdev)
PTR_ERR(nop-clk));
}
- if (!IS_ERR(nop-clk) pdata pdata-clk_rate) {
- err = clk_set_rate(nop-clk, pdata-clk_rate);
+ if (!IS_ERR(nop-clk) nop-clk_rate) {
+ err = clk_set_rate(nop-clk, nop-clk_rate);
if (err) {
dev_err(pdev-dev, Error setting clock rate\n);
return err;
@@ -236,12 +248,20 @@ static int nop_usb_xceiv_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id nop_xceiv_dt_ids[] = {
+ { .compatible = usb-nop-xceiv },
+ { }
+};
+
+MODULE_DEVICE_TABLE(of, nop_xceiv_dt_ids);
+
static struct platform_driver nop_usb_xceiv_driver = {
.probe = nop_usb_xceiv_probe,
.remove = nop_usb_xceiv_remove,
.driver = {
.name = nop_usb_xceiv,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(nop_xceiv_dt_ids),
},
};
--
1.7.4.1
--
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
[PATCH v2 02/14] USB: phy: nop: Defer probe if device needs VCC/RESET
Add 2 flags, needs_vcc and needs_reset to platform data.
If the flag is set and the regulator couldn't be found
then we bail out with -EPROBE_DEFER.
For device tree boot we depend on presensce of vcc-supply/
reset-supply properties to decide if we should bail out
with -EPROBE_DEFER or just continue in case the regulator
can't be found.
This is required for proper functionality in cases where the
regulator is needed but is probed later than the PHY device.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
---
drivers/usb/otg/nop-usb-xceiv.c | 11 +++
include/linux/usb/nop-usb-xceiv.h |4
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/otg/nop-usb-xceiv.c b/drivers/usb/otg/nop-usb-xceiv.c
index 6b7a9a0..7b0e8a8 100644
--- a/drivers/usb/otg/nop-usb-xceiv.c
+++ b/drivers/usb/otg/nop-usb-xceiv.c
@@ -43,6 +43,8 @@ struct nop_usb_xceiv {
struct regulator *vcc;
struct regulator *reset;
u32 clk_rate;
+ unsigned int needs_vcc:1;
+ unsigned int needs_reset:1;
};
static struct platform_device *pd;
@@ -163,9 +165,14 @@ static int nop_usb_xceiv_probe(struct platform_device
*pdev)
if (!of_property_read_u32(node, clock-frequency, clk_rate))
nop-clk_rate = clk_rate;
+ nop-needs_vcc = of_property_read_bool(node, vcc-supply);
+ nop-needs_reset = of_property_read_bool(node, reset-supply);
+
} else if (pdata) {
type = pdata-type;
nop-clk_rate = pdata-clk_rate;
+ nop-needs_vcc = pdata-needs_vcc;
+ nop-needs_reset = pdata-needs_reset;
}
nop-clk = devm_clk_get(pdev-dev, main_clk);
@@ -194,12 +201,16 @@ static int nop_usb_xceiv_probe(struct platform_device
*pdev)
if (IS_ERR(nop-vcc)) {
dev_dbg(pdev-dev, Error getting vcc regulator: %ld\n,
PTR_ERR(nop-vcc));
+ if (nop-needs_vcc)
+ return -EPROBE_DEFER;
}
nop-reset = devm_regulator_get(pdev-dev, reset);
if (IS_ERR(nop-reset)) {
dev_dbg(pdev-dev, Error getting reset regulator: %ld\n,
PTR_ERR(nop-reset));
+ if (nop-needs_reset)
+ return -EPROBE_DEFER;
}
nop-dev= pdev-dev;
diff --git a/include/linux/usb/nop-usb-xceiv.h
b/include/linux/usb/nop-usb-xceiv.h
index 3265b61..148d351 100644
--- a/include/linux/usb/nop-usb-xceiv.h
+++ b/include/linux/usb/nop-usb-xceiv.h
@@ -6,6 +6,10 @@
struct nop_usb_xceiv_platform_data {
enum usb_phy_type type;
unsigned long clk_rate;
+
+ /* if set fails with -EPROBE_DEFER if can't get regulator */
+ unsigned int needs_vcc:1;
+ unsigned int needs_reset:1;
};
#if defined(CONFIG_NOP_USB_XCEIV) || (defined(CONFIG_NOP_USB_XCEIV_MODULE)
defined(MODULE))
--
1.7.4.1
--
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
[PATCH v2 04/14] mfd: omap-usb-tll: Add device tree support
Enable this driver to probe in device tree boot.
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/mfd/omap-usb-tll.txt | 17 +
drivers/mfd/omap-usb-tll.c |9 +
2 files changed, 26 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
new file mode 100644
index 000..62fe697
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
@@ -0,0 +1,17 @@
+OMAP HS USB Host TLL (Transceiver-Less Interface)
+
+Required properties:
+
+- compatible : should be ti,usbhs-tll
+- reg : should contain one register range i.e. start and length
+- interrupts : should contain the TLL module's interrupt
+- ti,hwmod : must contain usb_tll_hs
+
+Example:
+
+ usbhstll: usbhstll@4a062000 {
+ compatible = ti,usbhs-tll;
+ reg = 0x4a062000 0x1000;
+ interrupts = 78;
+ ti,hwmods = usb_tll_hs;
+ };
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index f7d2568..f7afb22 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -28,6 +28,7 @@
#include linux/err.h
#include linux/pm_runtime.h
#include linux/platform_data/usb-omap.h
+#include linux/of.h
#define USBTLL_DRIVER_NAME usbhs_tll
@@ -311,10 +312,18 @@ static int usbtll_omap_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id usbtll_omap_dt_ids[] = {
+ { .compatible = ti,usbhs-tll },
+ { }
+};
+
+MODULE_DEVICE_TABLE(of, usbtll_omap_dt_ids);
+
static struct platform_driver usbtll_omap_driver = {
.driver = {
.name = (char *)usbtll_driver_name,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(usbtll_omap_dt_ids),
},
.probe = usbtll_omap_probe,
.remove = usbtll_omap_remove,
--
1.7.4.1
--
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
[PATCH v2 05/14] USB: ehci-omap: Get platform resources by index rather than by name
Since there is only one resource per type we don't really need
to use resource name to obtain it. This also also makes it easier
for device tree adaptation.
Signed-off-by: Roger Quadros rog...@ti.com
Acked-by: Alan Stern st...@rowland.harvard.edu
---
drivers/usb/host/ehci-omap.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 0aa12f6..02a7893 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -148,16 +148,15 @@ static int ehci_hcd_omap_probe(struct platform_device
*pdev)
return -ENODEV;
}
- irq = platform_get_irq_byname(pdev, ehci-irq);
+ irq = platform_get_irq(pdev, 0);
if (irq 0) {
dev_err(dev, EHCI irq failed\n);
return -ENODEV;
}
- res = platform_get_resource_byname(pdev,
- IORESOURCE_MEM, ehci);
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
regs = devm_request_and_ioremap(dev, res);
- if (!regs) {
+ if (IS_ERR(regs)) {
dev_err(dev, Resource request/ioremap failed\n);
return -EADDRNOTAVAIL;
}
--
1.7.4.1
--
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
Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
On Thursday 07 February 2013 09:51:11 Jon Hunter wrote:
@@ -673,7 +702,7 @@ static int omap_dma_init(void)
{
int rc = platform_driver_register(omap_dma_driver);
-if (rc == 0) {
+if ((rc == 0) (!of_have_populated_dt())) {
pdev = platform_device_register_full(omap_dma_dev_info);
if (IS_ERR(pdev)) {
platform_driver_unregister(omap_dma_driver);
There is already a patch in linux-next that makes this obsolete.
The device is now registered in arch/arm/mach-omap2/dma.c, so
I guess you have to change that location now.
Thanks. Will rebase on top of linux-next.
Actually, there is another problem with that, because then
you may get into the situation where nobody can apply your
patch.
You should never build work on top of linux-next, because
then your base gets rebuilt every day. Instead, you should
/test/ your branch merged with linux-next to ensure it works
with all the other things in place, and when you see conflicts
like this, you have to find out what they are and then decide
whether you need to rebase it, and to what.
Example:
$ git log --oneline next/master drivers/dma/omap-dma.c | head
be1f948 ARM: OMAP: Fix dmaengine init for multiplatform
45c3eb7 ARM: OMAP: Move plat-omap/dma-omap.h to include/linux/omap-dma.h
8280960 ARM: OMAP: Remove cpu_is_omap usage from plat-omap/dma.c
94c6578 Merge branch 'omap-for-v3.8/cleanup-headers-dma' into
omap-for-v3.8/cleanup-headers
27615a9 ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
2b6c4e7 ARM: OMAP: DMA: Move plat/dma.h to plat-omap/dma-omap.h
f5a246e Merge tag 'sound-3.7' of
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
2dde5b9 dmaengine: omap-dma: Add support to suppress interrupts in cyclic mode
ec8b5e4 dmaengine: Pass flags via device_prep_dma_cyclic() callback
2dcdf57 dmaengine: omap: Add support for pause/resume in cyclic dma mode
The topmost patch in linux-next is what has the conflict, so let's
see how that got there:
$ git log --oneline --ancestry-path --merges be1f948..next/master | tail
669166d Merge branch 'next/cleanup' into for-next
82fe557 Merge branch 'next/cleanup' into for-next
2f9adc9 Merge branch 'next/soc' into for-next
91ae65c Merge branch 'next/multiplatform' into for-next
2fd73eb Merge tag 'vt8500-multiplatform-3.9' of
git://server.prisktech.co.nz/git/linuxwmt into next/multiplatform
33740d2 Merge branch 'fixes' into for-next
b75baf8 Merge branch 'next/multiplatform' into for-next
6130133 Merge tag 'omap-for-v3.9/multiplatform-enable-signed-v2' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
next/multiplatform
3613f45 Merge branch 'next/multiplatform' into for-next
45f6a1d Merge tag 'omap-for-v3.9/multiplatform-enable-signed-v2' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into
next/multiplatform
At the bottom, you can see where it got merged. The commit was
in Tony's omap-for-v3.9/multiplatform-enable-signed-v2, which
subsequently got merged into arm-soc/next/multiplatform,
arm-soc/for-next and next/master.
The logical step is to base your patch on top of
omap-for-v3.9/multiplatform-enable-signed-v2, and work with
Tony and/or Olof and me to get that upstream.
Arnd
--
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
Re: [PATCH v2 14/14] USB: ehci-omap: Fix autoloading of module
On Thu, 7 Feb 2013, Roger Quadros wrote: The module alias should be ehci-omap and not omap-ehci to match the platform device name. The omap-ehci module should now autoload correctly. Signed-off-by: Roger Quadros rog...@ti.com Acked-by: Alan Stern st...@rowland.harvard.edu --- drivers/usb/host/ehci-omap.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c index a8ce10d..a2d16c0 100644 --- a/drivers/usb/host/ehci-omap.c +++ b/drivers/usb/host/ehci-omap.c @@ -340,9 +340,10 @@ static void __exit ehci_omap_cleanup(void) } module_exit(ehci_omap_cleanup); -MODULE_ALIAS(platform:omap-ehci); +MODULE_ALIAS(platform:ehci-omap); MODULE_AUTHOR(Texas Instruments, Inc.); MODULE_AUTHOR(Felipe Balbi felipe.ba...@nokia.com); +MODULE_AUTHOR(Roger Quadros rog...@ti.com); MODULE_DESCRIPTION(DRIVER_DESC); MODULE_LICENSE(GPL); -- 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
Re: On MIPI-CSI2 YUV420 formats and V4L2 Media Bus formats
Hi Antonio, On Wednesday 06 February 2013 23:33:47 Antonio Ospite wrote: On Wed, 30 Jan 2013 01:23:48 +0100 Laurent Pinchart wrote: On Monday 28 January 2013 13:22:10 Antonio Ospite wrote: Hi, looking at the MIPI Alliance Specification for Camera Serial Interface 2 (I'll call it MIPI-CSI2 from now on, the document I am referring to is mentioned at [1] and available at [2]), I see there is an YUV420 8 bit format (MIPI Data Type 0x18) specified with interleaved components in the form of: ... (odd lines) UYVYUYVY... (even lines) With even lines twice the size of odd lines. Such format is also supported by some sensors, for instance ov5640, and by MIPI-CSI2 receivers like OMAP4 ISS. The doubt I have is: how should I represent those formats as media bus formats? We likely need new media bus formats to describe those. OK, I'll think to some names if I am going to actually use them. I've seen that some drivers (sensors and SoC, for instance[3]) tend to identify the MIPI-CSI2 format above (0x18) with media bus formats like V4L2_MBUS_FMT_UYVY8_1_5X8 (actually the code above uses V4L2_MBUS_FMT_YUYV8_1_5X8 is this OK?), but from the v4l2 documentation [4] I understand that this format is supposed to have data in this configuration: ... ... ... ... ... ... Not exactly, the UYVY8_1_5X8 is transmits Y, U and V samples as UYYVYY... Wait, am I misunderstanding the documentation at http://kernel.org/doc/htmldocs/media/subdev.html#v4l2-mbus-pixelcode-yuv8 ? From the tables there it looks like that in UYVY8_1_5X8 the components are not interleaved on the same line, only the lines are. Yes there's a misunderstanding. The table shows how bits are layed in in samples transmitted on the bus. The first sample transmits a U byte (8 bits, u7 to u0), the next two samples two Y bytes, the next sample a V byte, ... Every line does contain Y, U and V data. And that's why I was believing the code in [3] which maps YUYV8_1_5X8 (line interleaved, according to my interpretation of the v4l doc) to the MIPI-CSI2 0x18 format (components interleaved), was inaccurate (in the sense that I would have expected another [new] media bus format). That is with interleaved lines, but NOT interleaved components. Should new media bus formats be added for .../UYVYUYVY...? Yes, I think so. Another doubt I have is: how is the .../UYVYUYVY... data supposed to be processed in userspace? Is the MIPI Receiver (i.e, the SoC) expected to be able to convert it to a more usable format like YUV420P or NV12/NV21? Or are there applications capable of handling this data directly, or efficiently convert them to planar or semi-planar YUV420 formats? The bridge (receiver and DMA engine) driver will expose V4L2 pixel formats corresponding to the bridge capabilities. If the bridge can store the above stream in memory in NV12 it will expose that to applications. If the bridge stores data in memory as described above, it will just expose that format (it seems to correspond to the V4L2 M420 pixel format), and applications will need to handle that explicitly. I see, so what I can get in userspace obviously depends on the hardware _and_ the driver (i.e. how complete it is in exposing the hardware capabilities), but that means that if a bridge can transparently pass the data it gets from the sensor (in a given mediabus format) we could have as many pixelformats as we have media bus formats, I know these latter won't be added in practice, but is my reasoning right in principle? Each mediabus format is a possible candidate for a new pixelformat. Maybe I am asking the obvious but I am trying to complete my understanding about the relationship between media bus formats and pixelformats. That's nearly correct. Let's say that you have two sensors that generate YUYV 4:2:2 packed data. The first one has an 8-bit parallel bus and transmits samples as Y0 U0 Y1 V0 Y2 U2 Y3 V2... The second one has a 16-bit parallel bus and transmits samples as Y0U0 Y1V0 Y2U2 Y3V2... Both would result in the same pixel format in memory, even though they are different media bus pixel codes. Other than that, yes, your understanding is correct. BTW that M420 format you mention is a bit different, from what I can see[6] it is something like a line interleaved NV12: ... ... UVUV... ... ... UVUV... [6] http://www.linuxtv.org/downloads/v4l-dvb-apis/V4L2-PIX-FMT-M420.html So still another variation on the theme :) Or am I still reading the documentation the wrong way? You're right, my bad. In particular I am curios if the OMAP4 ISS can do the conversion to NV12, I understand that the formats with interleaved _lines_ can be produced by the resizer and handled by the OMAP ISP DMA-Engine by setting
Re: [PATCH] ARM: dts: add minimal DT support for DevKit8000
Hello,
I have a couple of minor comments.
On Thu, Feb 07, 2013 at 02:11:37PM +, Anil Kumar wrote:
DevKit8000 is a beagle board clone from Timll, sold by
armkits.com. The DevKit8000 has RS232 serial port, LCD, DVI-D,
S-Video, Ethernet, SD/MMC, keyboard, camera, SPI, I2C, USB and
JTAG interface.
This patch adds the basic DT support for devkit8000. At this time, Information
of twl4030, MMC1, I2C1, leds and there pim mux information are added.
Signed-off-by: Anil Kumar anilk...@gmail.com
Tested-by: Thomas Weber tho...@tomweber.eu
---
-This patch is based on top of kernel 3.8-rc5.
-Tested on Devkit8000.
[...]
diff --git a/arch/arm/boot/dts/omap3-devkit8000.dts
b/arch/arm/boot/dts/omap3-devkit8000.dts
new file mode 100644
index 000..9864fd7
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-devkit8000.dts
@@ -0,0 +1,125 @@
+/*
+ * Anil Kumar anilk...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ omap3.dtsi
+/ {
+ model = TI OMAP3 Devkit8000;
Should this not be TimLL Devkit8000 ?
+ compatible = ti,omap3-devkit8000, ti,omap3;
timll,devkit8000 ?
[...]
Thanks,
Mark.
--
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
[PATCH] ARM: smp_twd: convert to use CLKSRC_OF init
From: Rob Herring rob.herr...@calxeda.com
Now that we have OF based init with CLKSRC_OF, convert smp_twd init
function to use it and covert all callers of
twd_local_timer_of_register.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
Cc: Shawn Guo shawn@linaro.org
Cc: Sascha Hauer ker...@pengutronix.de
Cc: Russell King li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Cc: Viresh Kumar viresh.li...@gmail.com
Cc: Shiraz Hashim shiraz.has...@st.com
Cc: Srinidhi Kasagar srinidhi.kasa...@stericsson.com
Cc: Linus Walleij linus.wall...@linaro.org
Cc: John Stultz johns...@us.ibm.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: linux-omap@vger.kernel.org
Cc: spear-de...@list.st.com
---
This is dependent on my previous series:
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-February/148313.html
arch/arm/Kconfig|1 +
arch/arm/include/asm/smp_twd.h |8
arch/arm/kernel/smp_twd.c | 17 -
arch/arm/mach-highbank/highbank.c |5 ++---
arch/arm/mach-imx/mach-imx6q.c |3 +--
arch/arm/mach-omap2/timer.c |2 +-
arch/arm/mach-spear13xx/spear13xx.c |3 +--
arch/arm/mach-ux500/timer.c |2 +-
arch/arm/mach-vexpress/v2m.c|4 ++--
drivers/clocksource/tegra20_timer.c |3 ---
10 files changed, 13 insertions(+), 35 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index bd30fe6..d530b60 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1570,6 +1570,7 @@ config ARM_ARCH_TIMER
config HAVE_ARM_TWD
bool
depends on SMP
+ select CLKSRC_OF if OF
help
This options enables support for the ARM timer and watchdog unit
diff --git a/arch/arm/include/asm/smp_twd.h b/arch/arm/include/asm/smp_twd.h
index 0f01f46..7b2899c 100644
--- a/arch/arm/include/asm/smp_twd.h
+++ b/arch/arm/include/asm/smp_twd.h
@@ -34,12 +34,4 @@ struct twd_local_timer name __initdata = { \
int twd_local_timer_register(struct twd_local_timer *);
-#ifdef CONFIG_HAVE_ARM_TWD
-void twd_local_timer_of_register(void);
-#else
-static inline void twd_local_timer_of_register(void)
-{
-}
-#endif
-
#endif
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index dc9bb01..963852e 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -376,22 +376,10 @@ int __init twd_local_timer_register(struct
twd_local_timer *tlt)
}
#ifdef CONFIG_OF
-const static struct of_device_id twd_of_match[] __initconst = {
- { .compatible = arm,cortex-a9-twd-timer, },
- { .compatible = arm,cortex-a5-twd-timer, },
- { .compatible = arm,arm11mp-twd-timer,},
- { },
-};
-
-void __init twd_local_timer_of_register(void)
+static void __init twd_local_timer_of_register(struct device_node *np)
{
- struct device_node *np;
int err;
- np = of_find_matching_node(NULL, twd_of_match);
- if (!np)
- return;
-
twd_ppi = irq_of_parse_and_map(np, 0);
if (!twd_ppi) {
err = -EINVAL;
@@ -409,4 +397,7 @@ void __init twd_local_timer_of_register(void)
out:
WARN(err, twd_local_timer_of_register failed (%d)\n, err);
}
+CLOCKSOURCE_OF_DECLARE(arm_twd_a9, arm,cortex-a9-twd-timer,
twd_local_timer_of_register);
+CLOCKSOURCE_OF_DECLARE(arm_twd_a5, arm,cortex-a5-twd-timer,
twd_local_timer_of_register);
+CLOCKSOURCE_OF_DECLARE(arm_twd_11mp, arm,arm11mp-twd-timer,
twd_local_timer_of_register);
#endif
diff --git a/arch/arm/mach-highbank/highbank.c
b/arch/arm/mach-highbank/highbank.c
index 70abc27..6abf987 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -31,7 +31,6 @@
#include asm/cacheflush.h
#include asm/cputype.h
#include asm/smp_plat.h
-#include asm/smp_twd.h
#include asm/hardware/arm_timer.h
#include asm/hardware/timer-sp.h
#include asm/hardware/cache-l2x0.h
@@ -118,10 +117,10 @@ static void __init highbank_timer_init(void)
sp804_clocksource_and_sched_clock_init(timer_base + 0x20, timer1);
sp804_clockevents_init(timer_base, irq, timer0);
- twd_local_timer_of_register();
-
arch_timer_of_register();
arch_timer_sched_clock_init();
+
+ clocksource_of_init();
}
static void highbank_power_off(void)
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 1786b2d..089cb10 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -26,7 +26,6 @@
#include linux/regmap.h
#include linux/micrel_phy.h
#include linux/mfd/syscon.h
-#include asm/smp_twd.h
#include asm/hardware/cache-l2x0.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -227,7 +226,7 @@ static void __init imx6q_init_irq(void)
static void __init imx6q_timer_init(void)
{
mx6q_clocks_init();
- twd_local_timer_of_register();
+ clocksource_of_init();
imx_print_silicon_rev(i.MX6Q, imx6q_revision());
}
diff --git
Re: [PATCH] ARM: smp_twd: convert to use CLKSRC_OF init
On 02/07/2013 01:53 PM, Rob Herring wrote: From: Rob Herring rob.herr...@calxeda.com Now that we have OF based init with CLKSRC_OF, convert smp_twd init function to use it and covert all callers of twd_local_timer_of_register. Reviewed-by: Stephen Warren swar...@nvidia.com Thanks for cleaning these up. I really should have gone through all the timer objects and converted them when I implemented the CLKSRC_OF feature in the first place. -- 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
Re: [PATCH v5] watchdog: introduce retu_wdt driver
Hi Aaro, Introduce Retu watchdog driver. Cc: linux-watch...@vger.kernel.org Acked-by: Felipe Balbi ba...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: Wim Van Sebroeck w...@iguana.be Added tolinux-watchdog-next. Kind regards, Wim. -- 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
Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
On 02/07/2013 10:07 AM, Arnd Bergmann wrote:
On Thursday 07 February 2013 09:51:11 Jon Hunter wrote:
@@ -673,7 +702,7 @@ static int omap_dma_init(void)
{
int rc = platform_driver_register(omap_dma_driver);
-if (rc == 0) {
+if ((rc == 0) (!of_have_populated_dt())) {
pdev = platform_device_register_full(omap_dma_dev_info);
if (IS_ERR(pdev)) {
platform_driver_unregister(omap_dma_driver);
There is already a patch in linux-next that makes this obsolete.
The device is now registered in arch/arm/mach-omap2/dma.c, so
I guess you have to change that location now.
Thanks. Will rebase on top of linux-next.
Actually, there is another problem with that, because then
you may get into the situation where nobody can apply your
patch.
Yes Tony mentioned always using a proper branch for pulls. I will base
upon his omap-for-v3.9/multiplatform-v2 (per your inputs, thanks!).
You should never build work on top of linux-next, because
then your base gets rebuilt every day. Instead, you should
/test/ your branch merged with linux-next to ensure it works
with all the other things in place, and when you see conflicts
like this, you have to find out what they are and then decide
whether you need to rebase it, and to what.
Ugh, looks like linux-next is broken for omap2+ boards at the moment
and is panic'ing in the twl i2c code ... some else to look into ...
Peter have you seen this on linux-next? I am seeing this on omap2-4 boards.
[2.286132] Unable to handle kernel NULL pointer dereference at virtual
address
[2.294738] pgd = c0004000
[2.297576] [] *pgd=
[2.301361] Internal error: Oops: 5 [#1] SMP ARM
[2.306243] Modules linked in:
[2.309448] CPU: 0Not tainted (3.8.0-rc6-next-20130207-00016-g735c237
#35)
[2.317169] PC is at twl_i2c_read+0x3c/0xec
[2.321563] LR is at twl_i2c_read+0x1c/0xec
[2.325988] pc : [c0333950]lr : [c0333930]psr: 8153
[2.325988] sp : c702fed0 ip : fp :
[2.338043] r10: c702e000 r9 : c06e84e8 r8 : c06e51c8
[2.343536] r7 : 0001 r6 : 0006 r5 : c702fef6 r4 : 0004
[2.350402] r3 : c129508c r2 : 0006 r1 : c702fef6 r0 : 000e
[2.357269] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment
kernel
[2.365051] Control: 10c5387d Table: 80004019 DAC: 0017
[2.371093] Process swapper/0 (pid: 1, stack limit = 0xc702e240)
[2.377410] Stack: (0xc702fed0 to 0xc703)
[2.382019] fec0: c0d42180 c0d429d0
c70a7640 c07354c4
[2.390624] fee0: 0001 c0719798 c0d42180 c06f2cc0 c04e76cc c06ee1ac
c07354c4
[2.399230] ff00: 0007 c06f2d64 0017 c06fb308 c06f07a4
c0cb8580 c06edee0
[2.407836] ff20: c06eded4 c06e8504 c0d42180 c0008768 009e c00611b4
0001
[2.416442] ff40: c061994c c06b7548 0007 0007 c07354c4
0007 c0719798
[2.425048] ff60: c0d42180 c06e51c8 c07197a0 009e c06e590c
0007 0007
[2.433654] ff80: c06e51c8 c04d26ec
[2.442260] ffa0: c04d26f4 c00137b0
[2.450866] ffc0:
[2.459472] ffe0: 0013
80fb6c10 71bbcd20
[2.468078] [c0333950] (twl_i2c_read+0x3c/0xec) from [c06f2cc0]
(omap3_twl_set_sr_bit+0x3c/0xb4)
[2.477722] [c06f2cc0] (omap3_twl_set_sr_bit+0x3c/0xb4) from [c06f2d64]
(omap3_twl_init+0x2c/0x70)
[2.487518] [c06f2d64] (omap3_twl_init+0x2c/0x70) from [c06fb308]
(omap_pmic_late_init+0x18/0x24)
[2.497222] [c06fb308] (omap_pmic_late_init+0x18/0x24) from [c06f07a4]
(omap2_common_pm_late_init+0x18/0xd0)
[2.507934] [c06f07a4] (omap2_common_pm_late_init+0x18/0xd0) from
[c06edee0] (omap3_init_late+0xc/0x18)
[2.518188] [c06edee0] (omap3_init_late+0xc/0x18) from [c06e8504]
(init_machine_late+0x1c/0x28)
[2.527740] [c06e8504] (init_machine_late+0x1c/0x28) from [c0008768]
(do_one_initcall+0x100/0x16c)
[2.537536] [c0008768] (do_one_initcall+0x100/0x16c) from [c06e590c]
(kernel_init_freeable+0xfc/0x1c8)
[2.547698] [c06e590c] (kernel_init_freeable+0xfc/0x1c8) from [c04d26f4]
(kernel_init+0x8/0xe4)
[2.557250] [c04d26f4] (kernel_init+0x8/0xe4) from [c00137b0]
(ret_from_fork+0x14/0x24)
Cheers
Jon
--
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
[PATCH V2 1/2] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
Add SDMA controller binding for OMAP2+ devices and populate DMA client
information for SPI and MMC periperhal on OMAP3+ devices. Please note
that OMAP24xx devices do not have SPI and MMC bindings available yet and
so DMA client information is not populated.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
.../devicetree/bindings/dma/omap-sdma.txt | 51
arch/arm/boot/dts/omap2.dtsi | 12 +
arch/arm/boot/dts/omap3.dtsi | 40 +++
arch/arm/boot/dts/omap4.dtsi | 41
arch/arm/boot/dts/omap5.dtsi | 41
5 files changed, 185 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt
diff --git a/Documentation/devicetree/bindings/dma/omap-sdma.txt
b/Documentation/devicetree/bindings/dma/omap-sdma.txt
new file mode 100644
index 000..22aab28
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/omap-sdma.txt
@@ -0,0 +1,51 @@
+* TI OMAP SDMA controller
+
+Required properties:
+- compatible: Should be set to one of the following:
+
+ ti,omap2420-sdma (omap2420)
+ ti,omap2430-sdma (omap2430)
+ ti,omap3430-sdma (omap3430)
+ ti,omap3630-sdma (omap3630)
+ ti,omap4430-sdma (omap4430 omap4460 omap543x)
+
+- reg: Contains DMA registers location and length.
+- interrupts: Contains DMA interrupt information.
+- #dma-cells: Must be 1.
+- #dma-channels: Contains total number of programmable DMA channels.
+- #dma-requests: Contains total number of DMA requests.
+
+Example:
+
+ sdma: dma-controller@4A056000 {
+ compatible = ti,omap-sdma;
+ reg = 0x4A056000 0x1000;
+ interrupts = 0 12 0x4,
+0 13 0x4,
+0 14 0x4,
+0 15 0x4;
+ #dma-cells = 1;
+ #dma-channels = 32;
+ #dma-requests = 127;
+ };
+
+
+* TI OMAP SDMA clients
+
+Required properties:
+- dmas:List of one or more DMA specifiers, each
consisting of
+ - A phandle pointing to DMA controller node
+ - The DMA request number associated with client device
+- dma-names: Contains one identifier string for each dma specifier in
+ the dmas property. The specific strings that can be used
+ are defined in the binding of the DMA client device.
+
+Example:
+
+ mmc1: mmc@4809c000 {
+ ...
+ dmas = sdma 61, /* TX channel */
+ sdma 62; /* RX channel */
+ dma-names = tx, rx;
+ ...
+ };
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 761c4b6..22dffa0 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -49,6 +49,18 @@
reg = 0x480FE000 0x1000;
};
+ sdma: dma-controller@48056000 {
+ compatible = ti,omap2430-sdma, ti,omap2420-sdma;
+ reg = 0x48056000 0x1000;
+ interrupts = 12,
+13,
+14,
+15;
+ #dma-cells = 1;
+ #dma-channels = 32;
+ #dma-requests = 64;
+ };
+
uart1: serial@4806a000 {
compatible = ti,omap2-uart;
ti,hwmods = uart1;
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..4e7acb6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -75,6 +75,18 @@
reg = 0x4820 0x1000;
};
+ sdma: dma-controller@48056000 {
+ compatible = ti,omap3630-sdma, ti,omap3430-sdma;
+ reg = 0x48056000 0x1000;
+ interrupts = 12,
+13,
+14,
+15;
+ #dma-cells = 1;
+ #dma-channels = 32;
+ #dma-requests = 96;
+ };
+
omap3_pmx_core: pinmux@48002030 {
compatible = ti,omap3-padconf, pinctrl-single;
reg = 0x48002030 0x05cc;
@@ -192,6 +204,16 @@
#size-cells = 0;
ti,hwmods = mcspi1;
ti,spi-num-cs = 4;
+ dmas = sdma 35,
+ sdma 36,
+ sdma 37,
+
[PATCH V2 0/2] ARM: dts: Add DT bindings for OMAP SDMA
Adds device-tree bindings from SDMA on OMAP2+ devices. DMA client bindings are also added for devices that have SPI and MMC bindings populated. Client binding data is based upon existing HWMOD data for OMAP and has been checked against OMAP documentation. Please note that the underlying (legacy) OMAP SDMA driver has not been ported over to DT and this still needs to be done. However, this allows DMA clients to look-up the DMA resource information via device-tree. Testing includes ... 1. Boot tested on OMAP3430 Beagle board, OMAP4430 Panda board and OMAP4460 Panda board with and without device-tree present. 2. Testing of MMC1 with SD card on OMAP3430 Beagle board, OMAP4430 Panda board and OMAP4460 Panda board with and without device-tree present. Testing branch available here [1]. Series is based upon Tony Lindgren's omap-for-v3.9/multiplatform-v2 branch [2] on top of the following ... - Vinod's topic/dmaengine_dt branch [3] - Matt Porter's series DMA Engine support for AM33XX [4] - Matt Porter's series omap_hsmmc DT DMA Client support [5] - Sourav Poddar's series add omap mcspi device tree data [6] V2 changes: - Updated to Tony's omap-for-v3.9/multiplatform-v2 branch to pull in DMA changes for v3.9 - Added comma to omap_dma_driver structure as pointed out by Arnd. - Updated OMAP SDMA DT binding compatible strings to indicate which devices are bit compatible with each other with respect to the SDMA controller. Grant had mentioned in the past that he wants the compatible string to be based upon a particular device and not something generic like ti,omap-sdma. [1] https://github.com/jonhunter/linux/commits/dev-dt-dma [2] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git omap-for-v3.9/multiplatform-v2 [3] http://git.infradead.org/users/vkoul/slave-dma.git/shortlog/refs/heads/topic/dmaengine_dt [4] http://permalink.gmane.org/gmane.linux.kernel.spi.devel/12508 [5] http://permalink.gmane.org/gmane.linux.ports.arm.omap/93165 [6] http://permalink.gmane.org/gmane.linux.kernel/1435002 Jon Hunter (2): ARM: dts: OMAP2+: Add SDMA controller bindings and nodes dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver .../devicetree/bindings/dma/omap-sdma.txt | 51 arch/arm/boot/dts/omap2.dtsi | 12 + arch/arm/boot/dts/omap3.dtsi | 40 +++ arch/arm/boot/dts/omap4.dtsi | 41 arch/arm/boot/dts/omap5.dtsi | 41 arch/arm/mach-omap2/dma.c |4 ++ drivers/dma/omap-dma.c | 37 +- 7 files changed, 224 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/omap-sdma.txt -- 1.7.10.4 -- 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
[PATCH V2 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
If the device-tree blob is present during boot, then register the SDMA
controller with the device-tree DMA driver so that we can use device-tree
to look-up DMA client information.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/mach-omap2/dma.c |4
drivers/dma/omap-dma.c| 37 +++--
2 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index 5cd8d76..71dadff 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -28,6 +28,7 @@
#include linux/init.h
#include linux/device.h
#include linux/dma-mapping.h
+#include linux/of.h
#include linux/omap-dma.h
#include soc.h
@@ -304,6 +305,9 @@ static int __init omap2_system_dma_init(void)
if (res)
return res;
+ if (of_have_populated_dt())
+ return res;
+
pdev = platform_device_register_full(omap_dma_dev_info);
if (IS_ERR(pdev))
return PTR_ERR(pdev);
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index c4b4fd2..0067bd0 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -16,6 +16,8 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/spinlock.h
+#include linux/of_dma.h
+#include linux/of_device.h
#include virt-dma.h
@@ -67,6 +69,8 @@ static const unsigned es_bytes[] = {
[OMAP_DMA_DATA_TYPE_S32] = 4,
};
+static struct of_dma_filter_info info;
+
static inline struct omap_dmadev *to_omap_dma_dev(struct dma_device *d)
{
return container_of(d, struct omap_dmadev, ddev);
@@ -621,8 +625,23 @@ static int omap_dma_probe(struct platform_device *pdev)
pr_warn(OMAP-DMA: failed to register slave DMA engine device:
%d\n,
rc);
omap_dma_free(od);
- } else {
- platform_set_drvdata(pdev, od);
+ return rc;
+ }
+
+ platform_set_drvdata(pdev, od);
+
+ if (pdev-dev.of_node) {
+ info.dma_cap = od-ddev.cap_mask;
+ info.filter_fn = omap_dma_filter_fn;
+
+ /* Device-tree DMA controller registration */
+ rc = of_dma_controller_register(pdev-dev.of_node,
+ of_dma_simple_xlate, info);
+ if (rc) {
+ pr_warn(OMAP-DMA: failed to register DMA
controller\n);
+ dma_async_device_unregister(od-ddev);
+ omap_dma_free(od);
+ }
}
dev_info(pdev-dev, OMAP DMA engine driver\n);
@@ -634,18 +653,32 @@ static int omap_dma_remove(struct platform_device *pdev)
{
struct omap_dmadev *od = platform_get_drvdata(pdev);
+ if (pdev-dev.of_node)
+ of_dma_controller_free(pdev-dev.of_node);
+
dma_async_device_unregister(od-ddev);
omap_dma_free(od);
return 0;
}
+static const struct of_device_id omap_dma_match[] = {
+ { .compatible = ti,omap2420-sdma, },
+ { .compatible = ti,omap2430-sdma, },
+ { .compatible = ti,omap3430-sdma, },
+ { .compatible = ti,omap3630-sdma, },
+ { .compatible = ti,omap4430-sdma, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_dma_match);
+
static struct platform_driver omap_dma_driver = {
.probe = omap_dma_probe,
.remove = omap_dma_remove,
.driver = {
.name = omap-dma-engine,
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(omap_dma_match),
},
};
--
1.7.10.4
--
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
Re: [PATCH] ARM: OMAP4: PM: Warn users about usage of older bootloaders
Paul Walmsley p...@pwsan.com writes:
On Mon, 4 Feb 2013, Rajendra Nayak wrote:
OMAP4 CHIP level PM works only with newer bootloaders. The
dependency on the bootloader comes from the fact that the
kernel is missing reset and initialization code for some
devices.
While the right thing to do is to add reset and init code in
the kernel, for some co-processor IP blocks like DSP and IVA
it means downloading firmware into each one of them to execute
idle instructions.
While a feasible solution is worked upon on how such IP blocks
can be better handled in the kernel, in the interim, to avoid
any further frustration to users testing PM on OMAP4 and finding
it broken, warn them about the bootloader being a possible
cause.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: R Sricharan r.sricha...@ti.com
Thanks Rajendra, I appreciate the patch. I've tweaked it slightly and the
following is what's queued here; hopefully it can go in for v3.9.
- Paul
From: Rajendra Nayak rna...@ti.com
Date: Mon, 4 Feb 2013 17:54:43 +0530
Subject: [PATCH] ARM: OMAP4: PM: Warn users about usage of older bootloaders
OMAP4 CHIP level PM works only with newer bootloaders. The
dependency on the bootloader comes from the fact that the
kernel is missing reset and initialization code for some
devices.
While the right thing to do is to add reset and init code in
the kernel, for some co-processor IP blocks like DSP and IVA
it means downloading firmware into each one of them to execute
idle instructions.
While a feasible solution is worked upon on how such IP blocks
can be better handled in the kernel, in the interim, to avoid
any further frustration to users testing PM on OMAP4 and finding
it broken, warn them about the bootloader being a possible
cause.
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: R Sricharan r.sricha...@ti.com
[p...@pwsan.com: tweaked warning messages and comments slightly]
Signed-off-by: Paul Walmsley p...@pwsan.com
FWIW
Acked-by: Kevin Hilman khil...@linaro.org
---
arch/arm/mach-omap2/pm44xx.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index aa6fd98..502ed9b 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -77,8 +77,18 @@ static int omap4_pm_suspend(void)
omap_set_pwrdm_state(pwrst-pwrdm, pwrst-saved_state);
pwrdm_set_logic_retst(pwrst-pwrdm, pwrst-saved_logic_state);
}
- if (ret)
+ if (ret) {
pr_crit(Could not enter target state in pm_suspend\n);
+ /*
+ * OMAP4 chip PM currently works only with certain (newer)
+ * versions of bootloaders. This is due to missing code in the
+ * kernel to properly reset and initialize some devices.
+ * Warn the user about the bootloader version being one of the
+ * possible causes.
+ * http://www.spinics.net/lists/arm-kernel/msg218641.html
+ */
+ pr_warn(A possible cause could be an old bootloader - try
u-boot = v2012.07\n);
+ }
else
pr_info(Successfully put all powerdomains to target state\n);
@@ -146,6 +156,13 @@ int __init omap4_pm_init(void)
}
pr_err(Power Management for TI OMAP4.\n);
+ /*
+ * OMAP4 chip PM currently works only with certain (newer)
+ * versions of bootloaders. This is due to missing code in the
+ * kernel to properly reset and initialize some devices.
+ * http://www.spinics.net/lists/arm-kernel/msg218641.html
+ */
+ pr_warn(u-boot = v2012.07 is required for full PM support\n);
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
--
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
Re: [PATCH 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
* Jon Hunter jon-hun...@ti.com [130207 16:55]: Ugh, looks like linux-next is broken for omap2+ boards at the moment and is panic'ing in the twl i2c code ... some else to look into ... Peter have you seen this on linux-next? I am seeing this on omap2-4 boards. Does not happen with arm-soc/for-next, probably related to the drivers/mfd/*twl* changes? Tony [2.286132] Unable to handle kernel NULL pointer dereference at virtual address [2.294738] pgd = c0004000 [2.297576] [] *pgd= [2.301361] Internal error: Oops: 5 [#1] SMP ARM [2.306243] Modules linked in: [2.309448] CPU: 0Not tainted (3.8.0-rc6-next-20130207-00016-g735c237 #35) [2.317169] PC is at twl_i2c_read+0x3c/0xec [2.321563] LR is at twl_i2c_read+0x1c/0xec [2.325988] pc : [c0333950]lr : [c0333930]psr: 8153 [2.325988] sp : c702fed0 ip : fp : [2.338043] r10: c702e000 r9 : c06e84e8 r8 : c06e51c8 [2.343536] r7 : 0001 r6 : 0006 r5 : c702fef6 r4 : 0004 [2.350402] r3 : c129508c r2 : 0006 r1 : c702fef6 r0 : 000e [2.357269] Flags: Nzcv IRQs on FIQs off Mode SVC_32 ISA ARM Segment kernel [2.365051] Control: 10c5387d Table: 80004019 DAC: 0017 [2.371093] Process swapper/0 (pid: 1, stack limit = 0xc702e240) [2.377410] Stack: (0xc702fed0 to 0xc703) [2.382019] fec0: c0d42180 c0d429d0 c70a7640 c07354c4 [2.390624] fee0: 0001 c0719798 c0d42180 c06f2cc0 c04e76cc c06ee1ac c07354c4 [2.399230] ff00: 0007 c06f2d64 0017 c06fb308 c06f07a4 c0cb8580 c06edee0 [2.407836] ff20: c06eded4 c06e8504 c0d42180 c0008768 009e c00611b4 0001 [2.416442] ff40: c061994c c06b7548 0007 0007 c07354c4 0007 c0719798 [2.425048] ff60: c0d42180 c06e51c8 c07197a0 009e c06e590c 0007 0007 [2.433654] ff80: c06e51c8 c04d26ec [2.442260] ffa0: c04d26f4 c00137b0 [2.450866] ffc0: [2.459472] ffe0: 0013 80fb6c10 71bbcd20 [2.468078] [c0333950] (twl_i2c_read+0x3c/0xec) from [c06f2cc0] (omap3_twl_set_sr_bit+0x3c/0xb4) [2.477722] [c06f2cc0] (omap3_twl_set_sr_bit+0x3c/0xb4) from [c06f2d64] (omap3_twl_init+0x2c/0x70) [2.487518] [c06f2d64] (omap3_twl_init+0x2c/0x70) from [c06fb308] (omap_pmic_late_init+0x18/0x24) [2.497222] [c06fb308] (omap_pmic_late_init+0x18/0x24) from [c06f07a4] (omap2_common_pm_late_init+0x18/0xd0) [2.507934] [c06f07a4] (omap2_common_pm_late_init+0x18/0xd0) from [c06edee0] (omap3_init_late+0xc/0x18) [2.518188] [c06edee0] (omap3_init_late+0xc/0x18) from [c06e8504] (init_machine_late+0x1c/0x28) [2.527740] [c06e8504] (init_machine_late+0x1c/0x28) from [c0008768] (do_one_initcall+0x100/0x16c) [2.537536] [c0008768] (do_one_initcall+0x100/0x16c) from [c06e590c] (kernel_init_freeable+0xfc/0x1c8) [2.547698] [c06e590c] (kernel_init_freeable+0xfc/0x1c8) from [c04d26f4] (kernel_init+0x8/0xe4) [2.557250] [c04d26f4] (kernel_init+0x8/0xe4) from [c00137b0] (ret_from_fork+0x14/0x24) Cheers Jon -- 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
Re: [PATCH V2 1/2] ARM: dts: OMAP2+: Add SDMA controller bindings and nodes
On Thu, Feb 07, 2013 at 07:05:05PM -0600, Jon Hunter wrote: Add SDMA controller binding for OMAP2+ devices and populate DMA client information for SPI and MMC periperhal on OMAP3+ devices. Please note that OMAP24xx devices do not have SPI and MMC bindings available yet and so DMA client information is not populated. Signed-off-by: Jon Hunter jon-hun...@ti.com already given before, but here you go: Reviewed-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCH V2 2/2] dmaengine: OMAP: Register SDMA controller with Device Tree DMA driver
Hi,
On Thu, Feb 07, 2013 at 07:05:06PM -0600, Jon Hunter wrote:
If the device-tree blob is present during boot, then register the SDMA
controller with the device-tree DMA driver so that we can use device-tree
to look-up DMA client information.
Signed-off-by: Jon Hunter jon-hun...@ti.com
single comment below, other than that:
Reviewed-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/dma.c |4
drivers/dma/omap-dma.c| 37 +++--
2 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/dma.c b/arch/arm/mach-omap2/dma.c
index 5cd8d76..71dadff 100644
--- a/arch/arm/mach-omap2/dma.c
+++ b/arch/arm/mach-omap2/dma.c
@@ -28,6 +28,7 @@
#include linux/init.h
#include linux/device.h
#include linux/dma-mapping.h
+#include linux/of.h
#include linux/omap-dma.h
#include soc.h
@@ -304,6 +305,9 @@ static int __init omap2_system_dma_init(void)
if (res)
return res;
+ if (of_have_populated_dt())
+ return res;
+
pdev = platform_device_register_full(omap_dma_dev_info);
if (IS_ERR(pdev))
return PTR_ERR(pdev);
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index c4b4fd2..0067bd0 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -16,6 +16,8 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/spinlock.h
+#include linux/of_dma.h
+#include linux/of_device.h
#include virt-dma.h
@@ -67,6 +69,8 @@ static const unsigned es_bytes[] = {
[OMAP_DMA_DATA_TYPE_S32] = 4,
};
+static struct of_dma_filter_info info;
Arnd also mentioned that since all fields belonging to this are
constant, you could statically initialize them here. He also mentioned
you should call this by a more descriptive name:
--
balbi
signature.asc
Description: Digital signature
