Re: OMAP baseline test results for v3.7-rc3
Hi,
On Tue, Nov 06, 2012 at 07:17:19AM +0100, Hiremath, Vaibhav wrote:
On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
Hi,
On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt, which
he has
already submitted to the list recently. So MMC support will come
along with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see
how it goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
It should just print a warning instead and continue.
1869 host-rx_chan = dma_request_channel(mask,
omap_dma_filter_fn, rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain RX
DMA engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask,
omap_dma_filter_fn, tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain TX
DMA engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
It should, CONFIG_DMADEVICES is optional. If it does not compile,
then there's a bug somewhere.
you're right, there's a static inline nop for when we don't have omap
dma engine driver compiled.
nevermind.
Did anybody tried polling mode MMC support on OMAP devices in the
past?
why are you trying out polling when we have a working interrupt mode ?
--
balbi
signature.asc
Description: Digital signature
RE: OMAP baseline test results for v3.7-rc3
On Tue, Nov 06, 2012 at 13:28:00, Balbi, Felipe wrote:
Hi,
On Tue, Nov 06, 2012 at 07:17:19AM +0100, Hiremath, Vaibhav wrote:
On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
Hi,
On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt,
which he has
already submitted to the list recently. So MMC support will
come along with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see
how it goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
It should just print a warning instead and continue.
1869 host-rx_chan = dma_request_channel(mask,
omap_dma_filter_fn, rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain RX
DMA engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask,
omap_dma_filter_fn, tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain TX
DMA engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
It should, CONFIG_DMADEVICES is optional. If it does not compile,
then there's a bug somewhere.
you're right, there's a static inline nop for when we don't have omap
dma engine driver compiled.
nevermind.
Did anybody tried polling mode MMC support on OMAP devices in the
past?
why are you trying out polling when we have a working interrupt mode ?
The thread started with need of MMC support without EDMA.
So when I say polling, I would like to try MMC without DMA support, not to
put dependency on EDMA-DMA engine migration patches.
Thanks,
Vaibhav
--
balbi
--
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: OMAP baseline test results for v3.7-rc3
Hi,
On Tue, Nov 06, 2012 at 09:07:47AM +0100, Hiremath, Vaibhav wrote:
On Tue, Nov 06, 2012 at 13:28:00, Balbi, Felipe wrote:
Hi,
On Tue, Nov 06, 2012 at 07:17:19AM +0100, Hiremath, Vaibhav wrote:
On Wed, Oct 31, 2012 at 00:21:02, Balbi, Felipe wrote:
Hi,
On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt,
which he has
already submitted to the list recently. So MMC support will
come along with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets
see how it goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
It should just print a warning instead and continue.
1869 host-rx_chan = dma_request_channel(mask,
omap_dma_filter_fn, rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain
RX DMA engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask,
omap_dma_filter_fn, tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain
TX DMA engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
It should, CONFIG_DMADEVICES is optional. If it does not compile,
then there's a bug somewhere.
you're right, there's a static inline nop for when we don't have omap
dma engine driver compiled.
nevermind.
Did anybody tried polling mode MMC support on OMAP devices in the
past?
why are you trying out polling when we have a working interrupt mode ?
The thread started with need of MMC support without EDMA. So when I
say polling, I would like to try MMC without DMA support, not to put
dependency on EDMA-DMA engine migration patches.
I see, so you meant interrupt/PIO mode. That's supposed to be working
and I'm sure Venkat and Balaji test that every now and then.
--
balbi
signature.asc
Description: Digital signature
[PATCH 2/7] net: cpsw: Add parent-child relation support between cpsw and mdio
From: Vaibhav Hiremath hvaib...@ti.com
CPGMAC SubSystem consist of various sub-modules, like, mdio, cpdma,
cpsw, etc... These sub-modules are also used in some of Davinci family
of devices. Now based on requirement, use-case and available technology
nodes the integration of these sub-modules varies across devices.
So coming back to Linux net driver, currently separate and independent
platform devices drivers for CPSW and MDIO is implemented. In case of
Davinci they both has separate control, from resources perspective,
like clock.
In case of AM33XX, the resources are shared and only one register
bit-field is provided to control module/clock enable/disable, makes it
difficult to handle common resource.
So the solution here implemented in this patch is,
Create parent-child relationship between both the drivers, making
CPSW as a parent and MDIO as its child and enumerate all the child nodes
under CPSW module.
Both the drivers will function exactly the way it was operating before,
including runtime-pm functionality. No change is required in MDIO driver
(for that matter to any child driver).
As this is only supported during DT boot, the parent-child relationship
is created and populated in DT execution flow. The only required change
is inside DTS file, making MDIO as a child to CPSW node.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Mugunthan V N mugunthan...@ti.com
Cc: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/ti/cpsw.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 7654a62..7007aba 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -1144,7 +1144,7 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
}
data-mac_control = prop;
- for_each_child_of_node(node, slave_node) {
+ for_each_node_by_name(slave_node, slave) {
struct cpsw_slave_data *slave_data = data-slave_data + i;
const char *phy_id = NULL;
const void *mac_addr = NULL;
@@ -1179,6 +1179,14 @@ static int cpsw_probe_dt(struct cpsw_platform_data *data,
i++;
}
+ /*
+* Populate all the child nodes here...
+*/
+ ret = of_platform_populate(node, NULL, NULL, pdev-dev);
+ /* We do not want to force this, as in some cases may not have child */
+ if (ret)
+ pr_warn(Doesn't have any child node\n);
+
return 0;
error_ret:
@@ -1212,6 +1220,11 @@ static int __devinit cpsw_probe(struct platform_device
*pdev)
priv-msg_enable = netif_msg_init(debug_level, CPSW_DEBUG);
priv-rx_packet_max = max(rx_packet_max, 128);
+ /*
+* This may be required here for child devices.
+*/
+ pm_runtime_enable(pdev-dev);
+
if (cpsw_probe_dt(priv-data, pdev)) {
pr_err(cpsw: platform data missing\n);
ret = -ENODEV;
@@ -1238,7 +1251,6 @@ static int __devinit cpsw_probe(struct platform_device
*pdev)
for (i = 0; i data-slaves; i++)
priv-slaves[i].slave_num = i;
- pm_runtime_enable(pdev-dev);
priv-clk = clk_get(pdev-dev, fck);
if (IS_ERR(priv-clk)) {
dev_err(pdev-dev, fck is not found\n);
--
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
[PATCH 5/7] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
Add CPSW and MDIO related device tree data for AM33XX.
Also enable them into board/evm dts files by providing
respective phy-id.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Richard Cochran richardcoch...@gmail.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |8 +++
arch/arm/boot/dts/am335x-evm.dts |8 +++
arch/arm/boot/dts/am33xx.dtsi | 42 +
3 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..e233cfa 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -78,3 +78,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = 4a101000.mdio:00;
+};
+
+cpsw_emac1 {
+ phy_id = 4a101000.mdio:01;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 185d632..415c3b3 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -118,3 +118,11 @@
};
};
};
+
+cpsw_emac0 {
+ phy_id = 4a101000.mdio:00;
+};
+
+cpsw_emac1 {
+ phy_id = 4a101000.mdio:01;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..2a0c8fe 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -210,5 +210,47 @@
interrupt-parent = intc;
interrupts = 91;
};
+
+ mac: ethernet@4A10 {
+ compatible = ti,cpsw;
+ ti,hwmods = cpgmac0;
+ cpdma_channels = 8;
+ ale_entries = 1024;
+ bd_ram_size = 0x2000;
+ no_bd_ram = 0;
+ rx_descs = 64;
+ mac_control = 0x20;
+ slaves = 2;
+ cpts_active_slave = 0;
+ cpts_clock_mult = 0x8000;
+ cpts_clock_shift = 29;
+ reg = 0x4a10 0x800
+ 0x4a101200 0x100
+ 0x4a101000 0x100;
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = intc;
+ /* c0_rx_thresh_pend c0_rx_pend c0_tx_pend
c0_misc_pend*/
+ interrupts = 40 41 42 43;
+ ranges;
+ cpsw_emac0: slave@0 {
+ phy_id = davinci_mdio.16:00;
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+ cpsw_emac1: slave@1 {
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
+
+ davinci_mdio: mdio@4a101000 {
+ compatible = ti,davinci_mdio;
+ #address-cells = 1;
+ #size-cells = 0;
+ ti,hwmods = davinci_mdio;
+ bus_freq = 100;
+ reg = 0x4a101000 0x100;
+ };
+ };
};
};
--
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
[PATCH 3/7] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
This patch adds hwmod entry for davinci MDIO module,
creating parent-child relationship between CPSW and MDIO module.
This Parent-child relation is required in order to use common resources
like, clock, but still maintaining the logical separation between them.
CPGMAC SubSystem consist of various sub-modules, like, mdio, cpdma,
cpsw, etc... These sub-modules are also used in some of Davinci
family of devices, so separate and independent platform devices
drivers for CPSW and MDIO is implemented.
In case of AM33XX, the resources are shared and common register
bit-field is provided to control module/clock enable/disable,
makes it difficult to handle common resources from both drivers.
So the solution is, create parent-child relationship between
CPGMAC MDIO modules.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Richard Cochran richardcoch...@gmail.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 59d5c1c..b3f9ce4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -674,6 +674,7 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
.name = cpgmac0,
.class = am33xx_cpgmac0_hwmod_class,
.clkdm_name = cpsw_125mhz_clkdm,
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
.mpu_irqs = am33xx_cpgmac0_irqs,
.main_clk = cpsw_125mhz_gclk,
.prcm = {
@@ -685,6 +686,20 @@ static struct omap_hwmod am33xx_cpgmac0_hwmod = {
};
/*
+ * mdio class
+ */
+static struct omap_hwmod_class am33xx_mdio_hwmod_class = {
+ .name = davinci_mdio,
+};
+
+static struct omap_hwmod am33xx_mdio_hwmod = {
+ .name = davinci_mdio,
+ .class = am33xx_mdio_hwmod_class,
+ .clkdm_name = cpsw_125mhz_clkdm,
+ .main_clk = cpsw_125mhz_gclk,
+};
+
+/*
* dcan class
*/
static struct omap_hwmod_class am33xx_dcan_hwmod_class = {
@@ -2501,6 +2516,22 @@ static struct omap_hwmod_ocp_if am33xx_l4_hs__cpgmac0 = {
.user = OCP_USER_MPU,
};
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x4A101000,
+ .pa_end = 0x4A101000 + SZ_256 - 1,
+ .flags = ADDR_MAP_ON_INIT,
+ },
+ { }
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+ .master = am33xx_cpgmac0_hwmod,
+ .slave = am33xx_mdio_hwmod,
+ .addr = am33xx_mdio_addr_space,
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
{
.pa_start = 0x4808,
@@ -3371,6 +3402,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[]
__initdata = {
am33xx_l3_main__tptc2,
am33xx_l3_s__usbss,
am33xx_l4_hs__cpgmac0,
+ am33xx_cpgmac0__mdio,
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
[PATCH 4/7] cpsw: simplify the setup of the register pointers
From: Richard Cochran richardcoch...@gmail.com
Instead of having a host of different register offsets in the device tree,
this patch simplifies the CPSW code by letting the driver set the proper
register offsets automatically, based on the CPSW version.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
Documentation/devicetree/bindings/net/cpsw.txt | 34
drivers/net/ethernet/ti/cpsw.c | 209 +--
include/linux/platform_data/cpsw.h | 19 --
3 files changed, 82 insertions(+), 180 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt
b/Documentation/devicetree/bindings/net/cpsw.txt
index 2214607..6cf5d92 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -9,15 +9,7 @@ Required properties:
number
- interrupt-parent : The parent interrupt controller
- cpdma_channels : Specifies number of channels in CPDMA
-- host_port_no : Specifies host port shift
-- cpdma_reg_ofs: Specifies CPDMA submodule register offset
-- cpdma_sram_ofs : Specifies CPDMA SRAM offset
-- ale_reg_ofs : Specifies ALE submodule register offset
- ale_entries : Specifies No of entries ALE can hold
-- host_port_reg_ofs: Specifies host port register offset
-- hw_stats_reg_ofs : Specifies hardware statistics register offset
-- cpts_reg_ofs : Specifies the offset of the CPTS registers
-- bd_ram_ofs : Specifies internal desciptor RAM offset
- bd_ram_size : Specifies internal descriptor RAM size
- rx_descs : Specifies number of Rx descriptors
- mac_control : Specifies Default MAC control register content
@@ -26,8 +18,6 @@ Required properties:
- cpts_active_slave: Specifies the slave to use for time stamping
- cpts_clock_mult : Numerator to convert input clock ticks into
nanoseconds
- cpts_clock_shift : Denominator to convert input clock ticks into
nanoseconds
-- slave_reg_ofs: Specifies slave register offset
-- sliver_reg_ofs : Specifies slave sliver register offset
- phy_id : Specifies slave phy id
- mac-address : Specifies slave MAC address
@@ -49,15 +39,7 @@ Examples:
interrupts = 55 0x4;
interrupt-parent = intc;
cpdma_channels = 8;
- host_port_no = 0;
- cpdma_reg_ofs = 0x800;
- cpdma_sram_ofs = 0xa00;
- ale_reg_ofs = 0xd00;
ale_entries = 1024;
- host_port_reg_ofs = 0x108;
- hw_stats_reg_ofs = 0x900;
- cpts_reg_ofs = 0xc00;
- bd_ram_ofs = 0x2000;
bd_ram_size = 0x2000;
no_bd_ram = 0;
rx_descs = 64;
@@ -67,15 +49,11 @@ Examples:
cpts_clock_mult = 0x8000;
cpts_clock_shift = 29;
cpsw_emac0: slave@0 {
- slave_reg_ofs = 0x200;
- sliver_reg_ofs = 0xd80;
phy_id = davinci_mdio.16:00;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
- slave_reg_ofs = 0x300;
- sliver_reg_ofs = 0xdc0;
phy_id = davinci_mdio.16:01;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
@@ -87,15 +65,7 @@ Examples:
compatible = ti,cpsw;
ti,hwmods = cpgmac0;
cpdma_channels = 8;
- host_port_no = 0;
- cpdma_reg_ofs = 0x800;
- cpdma_sram_ofs = 0xa00;
- ale_reg_ofs = 0xd00;
ale_entries = 1024;
- host_port_reg_ofs = 0x108;
- hw_stats_reg_ofs = 0x900;
- cpts_reg_ofs = 0xc00;
- bd_ram_ofs = 0x2000;
bd_ram_size = 0x2000;
no_bd_ram = 0;
rx_descs = 64;
@@ -105,15 +75,11 @@ Examples:
cpts_clock_mult = 0x8000;
cpts_clock_shift = 29;
cpsw_emac0: slave@0 {
- slave_reg_ofs = 0x200;
- sliver_reg_ofs = 0xd80;
phy_id = davinci_mdio.16:00;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
cpsw_emac1: slave@1 {
- slave_reg_ofs = 0x300;
- sliver_reg_ofs = 0xdc0;
phy_id = davinci_mdio.16:01;
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
diff --git
[PATCH 6/7] ARM: OMAP2+: omap2plus_defconfig: Enable CPSW support
Enable CPSW support in defconfig which is present in AM33xx SoC Signed-off-by: Mugunthan V N mugunthan...@ti.com --- arch/arm/configs/omap2plus_defconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index a4b330e..41b595e 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -242,3 +242,6 @@ CONFIG_CRC_ITU_T=y CONFIG_CRC7=y CONFIG_LIBCRC32C=y CONFIG_SOC_OMAP5=y +CONFIG_TI_DAVINCI_MDIO=y +CONFIG_TI_DAVINCI_CPDMA=y +CONFIG_TI_CPSW=y -- 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
[PATCH 7/7] net: cpsw: halt network stack before halting the device during suspend
Move network stack halt APIs before halting the hardware to ensure no packets are queued to hardware during closing the device during suspend sequence. Signed-off-by: Mugunthan V N mugunthan...@ti.com --- drivers/net/ethernet/ti/cpsw.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c index f94aa8f..b46dbb4 100644 --- a/drivers/net/ethernet/ti/cpsw.c +++ b/drivers/net/ethernet/ti/cpsw.c @@ -698,12 +698,12 @@ static int cpsw_ndo_stop(struct net_device *ndev) struct cpsw_priv *priv = netdev_priv(ndev); cpsw_info(priv, ifdown, shutting down cpsw device\n); - cpsw_intr_disable(priv); - cpdma_ctlr_int_ctrl(priv-dma, false); - cpdma_ctlr_stop(priv-dma); netif_stop_queue(priv-ndev); napi_disable(priv-napi); netif_carrier_off(priv-ndev); + cpsw_intr_disable(priv); + cpdma_ctlr_int_ctrl(priv-dma, false); + cpdma_ctlr_stop(priv-dma); cpsw_ale_stop(priv-ale); for_each_slave(priv, cpsw_slave_stop, priv); pm_runtime_put_sync(priv-pdev-dev); -- 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
[PATCH 1/7] net: davinci_mdio: Fix typo mistake in calling runtime-pm api
From: Vaibhav Hiremath hvaib...@ti.com By mistake (most likely a copy-paste), instead of pm_runtime_get_sync() api, driver is calling pm_runtime_put_sync() api in resume callback function. The bug was introduced by commit id (ae2c07aaf74: davinci_mdio: runtime PM support). Now, the reason why it didn't impact functionality is, the patch has been tested on AM335x-EVM and BeagleBone platform while submitting; and in case of AM335x the MDIO driver doesn't control the module enable/disable part, which is handled by CPSW driver. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Mugunthan V N mugunthan...@ti.com Cc: Richard Cochran richardcoch...@gmail.com --- drivers/net/ethernet/ti/davinci_mdio.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c index 51a96db..ae74280 100644 --- a/drivers/net/ethernet/ti/davinci_mdio.c +++ b/drivers/net/ethernet/ti/davinci_mdio.c @@ -465,7 +465,7 @@ static int davinci_mdio_resume(struct device *dev) u32 ctrl; spin_lock(data-lock); - pm_runtime_put_sync(data-dev); + pm_runtime_get_sync(data-dev); /* restart the scan state machine */ ctrl = __raw_readl(data-regs-control); -- 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
[PATCH 0/7] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver
This patch-series adds support for, [1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's [2/7]: Adds parent-child relation between CPSW MDIO module inside cpsw driver, as in case of AM33XX, the resources are shared and common register bit-field is provided to control module/clock enable/disable, makes it difficult to handle common resource. So the solution here is, to create parent-child relation between them. [3/7]: Add hwmod entry for MDIO module, required for MDIO driver. [4/7]: cpsw: simplify the setup of the register pointers [5/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi, am335x-evm.dts and am335x-bone.dts file [6/7]: Enable CPSW support to omap2plus_defconfig [7/7]: cpsw: Kernel warn fix during suspend This patch series has been created on top of net-next/master and tested on BeagleBone platform for NFS boot and basic ping test cases. Mugunthan V N (4): ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX ARM: OMAP2+: omap2plus_defconfig: Enable CPSW support net: cpsw: halt network stack before halting the device during suspend Richard Cochran (1): cpsw: simplify the setup of the register pointers Vaibhav Hiremath (2): net: davinci_mdio: Fix typo mistake in calling runtime-pm api net: cpsw: Add parent-child relation support between cpsw and mdio Documentation/devicetree/bindings/net/cpsw.txt | 34 arch/arm/boot/dts/am335x-bone.dts |8 + arch/arm/boot/dts/am335x-evm.dts |8 + arch/arm/boot/dts/am33xx.dtsi | 42 + arch/arm/configs/omap2plus_defconfig |3 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 32 drivers/net/ethernet/ti/cpsw.c | 231 ++-- drivers/net/ethernet/ti/davinci_mdio.c |2 +- include/linux/platform_data/cpsw.h | 19 -- 9 files changed, 193 insertions(+), 186 deletions(-) -- 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/3] capebus moving omap_devices to mach-omap2
Hi Joel, On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote: Hi Grant, On Mon, Nov 5, 2012 at 5:58 PM, Grant Likely grant.lik...@secretlab.ca wrote: Joel A Fernandes agnel.j...@gmail.com wrote: Hi Grant, On Mon, Nov 5, 2012 at 2:14 PM, Grant Likely grant.lik...@secretlab.ca wrote: I'm open to suggestions if anyone has any. I have not objections to a fixup approach, but I'm not comfortable with anything that is fragile to modifications to the fragment. I am fairly new to the DT world so please bear with me, but how about a method that resolves symbols the same way that the linux dynamic linker does when shared libraries are loaded? A separate table (similar to .PLT/GOT sections in the ELF object format) could be created when the fragment is loaded, and the phandle references could be fixed to point to the table offsets during compile time. This table would be a second level indirection and the kernel would populate this table with the in-kernel values of the phandles that the dt fragment refers to. That's an interesting idea that is worth exploring. That would make it possible to avoid a fixup stage, but it also means that any parsing code must know how to handle the got-like table. It won't be backwards compatible with existing tools. It also wouldn't easily support the case of firmware applying the overlay and passing the resulting tree to the kernel. Hmmm Not being backwards compatible at the data level is a big problem. I really want a method that can resolve back to the current data format or is a compatible extension of it. Is it meaningful or feasible to make the table a part of the tree structure itself? the table would initially be empty. If I'm right, this is how the GOT tables in ELF objects that refer to unresolved symbols in shared libraries are implemented as well, they are a part of the object and are loaded into memory and fixed up. If the table is a part of the DT data, the tools would then be able to parse such a tree. We could enforce that the got-like tree would strictly follow a predefined format. Something along these lines would also avoid the need for a tree fix up. Do you think this reduces the difficulty of backward compatibility with the parsing tools and firmware loading? To be honest here, we are discussing a new object format. There are a few twists IMO. a) We definitely, absolutely, don't want to introduce anything that will risk compatibility with devices already out there. The binary format for device trees that don't need the dynamic resolution features we're talking about here, should be be usable for those older devices. b) Device tree is flexible enough to store the additional data in it's own node format. So we shouldn't have any kind of binary data tacked on; this ties with a) - make sure that the binary format doesn't change. c) There is no need (at least AFAIKT) of having any other resolution type than a phandle of a node. d) Finally, for some use-cases the problem is simplified by not having all the features of a true dynamic linker. For example for the capebus case the 'base' DTS won't have any references to any fragments. It is only the fragments that have unresolved references and only to the 'base' DTS. This might involve changes to the DT core, but as such, this method wouldn't suffer from the fragility problem of either base or fragment DT trees being modified. The table itself could be added to the tree by the compiler, and the phandles could point to it (fixed). such phandles could be marked for special handling to facilitate the 1-level indirection. That's part of the problem. Property values are essentially anaonymous data. There is no mechanism currently for marking data such as indicate which data values are phandles. If there were then it would be a simple matter to find all the phandles and fix them up. We could possibly add data type suppplementary properties to the tree to solve that problem. They would have to be optional for the base tree to retain backwards compatibility, but could be required on overlays. Sure, so if we add data type supplementary properties to the tree to indicate the data type as indirect phandle, then kernel could refer to the index in the got-like table to fetch the actual phandle address (1-level of indirection), instead of directly using the address in the data field. I'm fine with this. Thanks and Regards, Joel Regards -- Pantelis -- 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] mailbox: OMAP: introduce mailbox framework
On Tue, Nov 6, 2012 at 4:40 AM, Stephen Warren swar...@wwwdotorg.org wrote: Is this a public interface to the driver? If so, shouldn't the header be in include/linux somewhere? I think the split out of the public header is done in patch 2/2. Yours, Linus Walleij -- 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] mailbox: OMAP: introduce mailbox framework
On Tue, Nov 06, 2012 at 09:55:52AM +0100, Linus Walleij wrote: On Tue, Nov 6, 2012 at 4:40 AM, Stephen Warren swar...@wwwdotorg.org wrote: Is this a public interface to the driver? If so, shouldn't the header be in include/linux somewhere? I think the split out of the public header is done in patch 2/2. Yes, but the names are still omap_*, which doesn't make much sense here. greg k-h -- 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] spi: omap2-mcspi: Reorder the wait_for_completion for tx
The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function]
changed the wait_for_completion order. Move the wait so that the
rx doesnot wait for the tx to complete.
Reported-and-tested-by: Sørensen, Stefan soren...@polycom.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 39 +++
1 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index bcfd062..251f6d0 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -323,18 +323,13 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi,
struct omap2_mcspi *mcspi;
struct omap2_mcspi_dma *mcspi_dma;
unsigned intcount;
- u8 * rx;
const u8* tx;
- void __iomem*chstat_reg;
- struct omap2_mcspi_cs *cs = spi-controller_state;
mcspi = spi_master_get_devdata(spi-master);
mcspi_dma = mcspi-dma_channels[spi-chip_select];
count = xfer-len;
- rx = xfer-rx_buf;
tx = xfer-tx_buf;
- chstat_reg = cs-base + OMAP2_MCSPI_CHSTAT0;
if (mcspi_dma-dma_tx) {
struct dma_async_tx_descriptor *tx;
@@ -359,19 +354,6 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi,
dma_async_issue_pending(mcspi_dma-dma_tx);
omap2_mcspi_set_dma_req(spi, 0, 1);
- wait_for_completion(mcspi_dma-dma_tx_completion);
- dma_unmap_single(mcspi-dev, xfer-tx_dma, count,
-DMA_TO_DEVICE);
-
- /* for TX_ONLY mode, be sure all words have shifted out */
- if (rx == NULL) {
- if (mcspi_wait_for_reg_bit(chstat_reg,
- OMAP2_MCSPI_CHSTAT_TXS) 0)
- dev_err(spi-dev, TXS timed out\n);
- else if (mcspi_wait_for_reg_bit(chstat_reg,
- OMAP2_MCSPI_CHSTAT_EOT) 0)
- dev_err(spi-dev, EOT timed out\n);
- }
}
static unsigned
@@ -492,6 +474,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
struct dma_slave_config cfg;
enum dma_slave_buswidth width;
unsigned es;
+ void __iomem*chstat_reg;
mcspi = spi_master_get_devdata(spi-master);
mcspi_dma = mcspi-dma_channels[spi-chip_select];
@@ -526,8 +509,24 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
omap2_mcspi_tx_dma(spi, xfer, cfg);
if (rx != NULL)
- return omap2_mcspi_rx_dma(spi, xfer, cfg, es);
-
+ count = omap2_mcspi_rx_dma(spi, xfer, cfg, es);
+
+ if (tx != NULL) {
+ chstat_reg = cs-base + OMAP2_MCSPI_CHSTAT0;
+ wait_for_completion(mcspi_dma-dma_tx_completion);
+ dma_unmap_single(mcspi-dev, xfer-tx_dma, xfer-len,
+DMA_TO_DEVICE);
+
+ /* for TX_ONLY mode, be sure all words have shifted out */
+ if (rx == NULL) {
+ if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_TXS) 0)
+ dev_err(spi-dev, TXS timed out\n);
+ else if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_EOT) 0)
+ dev_err(spi-dev, EOT timed out\n);
+ }
+ }
return count;
}
--
1.7.5.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] spi: omap2-mcspi: Reorder the wait_for_completion for tx
On Tue, Nov 06, 2012 at 02:30:19PM +0530, Shubhrajyoti D wrote: The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function] changed the wait_for_completion order. Move the wait so that the rx doesnot wait for the tx to complete. Applied, thanks. signature.asc Description: Digital signature
Re: hdmi on 4430 (kernel 3.4)
Hi Jon, Il giorno 06/nov/2012, alle ore 00:21, Jon Hunter jon-hun...@ti.com ha scritto: I wanted to check the HDMI registers, but I didn't find the hdmi registers table on the TRM. Does someone have some hint, comment or previous experience on that? Where can I find the hdmi registers list on the manual or other documentation? Note that as far as i know, the 2.6.35 kernel was working correctly (I can't check right now, unfortunately). Thank you. I would recommend posting this query on the TI E2E forum for Linux [1]. You may get better help there seeing that this is with regard to a specific TI development kernel branch. Thank you very much for the suggestion! I'll post there. Can you confirm that the kernel version I am using works without problem with HDMI-1080p? Thanks Cheers Federico -- 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: [PATCHv9 6/8] ARM: OMAP4: retrigger localtimers after re-enabling gic
On Mon, 2012-11-05 at 14:25 -0800, Kevin Hilman wrote: Tero Kristo t-kri...@ti.com writes: From: Colin Cross ccr...@android.com 'Workaround for ROM bug because of CA9 r2pX gic control' register change disables the gic distributor while the secondary Just to clarify: this is referring to PATCH 3/8 of this series, correct? Yes. -Tero -- 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] spi: omap2-mcspi: Reorder the wait_for_completion for tx
The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function]
changed the wait_for_completion order. Move the wait so that the
rx doesnot wait for the tx to complete.
Reported-and-tested-by: Sørensen, Stefan soren...@polycom.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 39 +++
1 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index bcfd062..251f6d0 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -323,18 +323,13 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi,
struct omap2_mcspi *mcspi;
struct omap2_mcspi_dma *mcspi_dma;
unsigned intcount;
- u8 * rx;
const u8* tx;
- void __iomem*chstat_reg;
- struct omap2_mcspi_cs *cs = spi-controller_state;
mcspi = spi_master_get_devdata(spi-master);
mcspi_dma = mcspi-dma_channels[spi-chip_select];
count = xfer-len;
- rx = xfer-rx_buf;
tx = xfer-tx_buf;
- chstat_reg = cs-base + OMAP2_MCSPI_CHSTAT0;
if (mcspi_dma-dma_tx) {
struct dma_async_tx_descriptor *tx;
@@ -359,19 +354,6 @@ static void omap2_mcspi_tx_dma(struct spi_device *spi,
dma_async_issue_pending(mcspi_dma-dma_tx);
omap2_mcspi_set_dma_req(spi, 0, 1);
- wait_for_completion(mcspi_dma-dma_tx_completion);
- dma_unmap_single(mcspi-dev, xfer-tx_dma, count,
-DMA_TO_DEVICE);
-
- /* for TX_ONLY mode, be sure all words have shifted out */
- if (rx == NULL) {
- if (mcspi_wait_for_reg_bit(chstat_reg,
- OMAP2_MCSPI_CHSTAT_TXS) 0)
- dev_err(spi-dev, TXS timed out\n);
- else if (mcspi_wait_for_reg_bit(chstat_reg,
- OMAP2_MCSPI_CHSTAT_EOT) 0)
- dev_err(spi-dev, EOT timed out\n);
- }
}
static unsigned
@@ -492,6 +474,7 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
struct dma_slave_config cfg;
enum dma_slave_buswidth width;
unsigned es;
+ void __iomem*chstat_reg;
mcspi = spi_master_get_devdata(spi-master);
mcspi_dma = mcspi-dma_channels[spi-chip_select];
@@ -526,8 +509,24 @@ omap2_mcspi_txrx_dma(struct spi_device *spi, struct
spi_transfer *xfer)
omap2_mcspi_tx_dma(spi, xfer, cfg);
if (rx != NULL)
- return omap2_mcspi_rx_dma(spi, xfer, cfg, es);
-
+ count = omap2_mcspi_rx_dma(spi, xfer, cfg, es);
+
+ if (tx != NULL) {
+ chstat_reg = cs-base + OMAP2_MCSPI_CHSTAT0;
+ wait_for_completion(mcspi_dma-dma_tx_completion);
+ dma_unmap_single(mcspi-dev, xfer-tx_dma, xfer-len,
+DMA_TO_DEVICE);
+
+ /* for TX_ONLY mode, be sure all words have shifted out */
+ if (rx == NULL) {
+ if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_TXS) 0)
+ dev_err(spi-dev, TXS timed out\n);
+ else if (mcspi_wait_for_reg_bit(chstat_reg,
+ OMAP2_MCSPI_CHSTAT_EOT) 0)
+ dev_err(spi-dev, EOT timed out\n);
+ }
+ }
return count;
}
--
1.7.5.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: [PATCHv9 0/8] ARM: OMAP4: core retention support
Hi Kevin,
On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
Hi Tero,
Tero Kristo t-kri...@ti.com writes:
Hi,
Changes compared to previous version:
- rebased on top of 3.7-rc1
- applies on top of latest func pwrst code (v6)
- added back patch #1 to this set (it wasn't queued yet after all)
- added patch #7 for fixing a bug in the functional pwrst code
- added patch #8 for fixing a regression with MUSB PHY power handling
(not quite sure if this is the correct way to fix this or not)
Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle +
suspend.
Branch also available here:
git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.7-rc1-omap4-ret-v9
I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing
several domains not hitting target power state in suspend[1].
Am I missing some other fixes? Using omap2plus_defconfig, I tried your
branch alone, and merged with v3.7-rc4, and I get the same errors.
Kevin
[1]
# echo enabled /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup
# echo mem /sys/power/state
[ 102.271087] PM: Syncing filesystems ... done.
[ 102.282196] Freezing user space processes ... (elapsed 0.02 seconds) done.
[ 102.312133] Freezing remaining freezable tasks ... (elapsed 0.02 seconds)
done.
[ 102.343353] Suspending console(s) (use no_console_suspend to debug)
�[ 102.363433] PM: suspend of devices complete after 10.650 msecs
[ 102.365631] PM: late suspend of devices complete after 2.166 msecs
[ 102.369201] PM: noirq suspend of devices complete after 3.509 msecs
[ 102.369232] Disabling non-boot CPUs ...
[ 102.373016] CPU1: shutdown
[ 104.357421] Powerdomain (core_pwrdm) didn't enter target state 1
[ 104.357452] Powerdomain (tesla_pwrdm) didn't enter target state 1
[ 104.357452] Powerdomain (ivahd_pwrdm) didn't enter target state 1
[ 104.357482] Powerdomain (l3init_pwrdm) didn't enter target state 1
[ 104.357482] Could not enter target state in pm_suspend
[ 104.357666] Enabling non-boot CPUs ...
[ 104.359863] CPU1: Booted secondary processor
[ 104.360626] cpu cpu0: opp_init_cpufreq_table: Device OPP not found (-19)
[ 104.360656] cpu cpu0: omap_cpu_init: cpu1: failed creating freq table[-19]
[ 104.360656] CPU1 is up
[ 104.362579] PM: noirq resume of devices complete after 1.892 msecs
[ 104.364807] PM: early resume of devices complete after 1.373 msecs
[ 104.710937] PM: resume of devices complete after 346.099 msecs
[ 104.817901] Restarting tasks ... done.
This looks like a combination of boot loader/kernel problems. My guess
is that l3init is probably held on by the USB, and both ivahd / tesla
are held on by some DSP/IVA modules which are not idling properly.
The last patch in this set should fix the USB problems at least
partially, but also the USB DPLL itself might be in wrong state,
attached patch might help for that one and get l3init to idle.
For DSP I don't have a patch right now, what is the boot loader you are
using? (Can you provide git / commit / config info?)
-Tero
From 2bde02977db605822ee83042ebc0077ba133277e Mon Sep 17 00:00:00 2001
From: Tero Kristo t-kri...@ti.com
Date: Thu, 21 Jun 2012 14:56:40 +0300
Subject: [PATCH 3/7] ARM: OMAP4: clock: setup USB DPLL during init
The reset setup for USB DPLL does not allow idle, thus the kernel must
program it during init. This puts the USB DPLL in locked mode, autoidle
for it is enabled automatically later during the boot sequence.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index e2b701e..e28950a 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3413,6 +3413,7 @@ int __init omap4xxx_clk_init(void)
{
struct omap_clk *c;
u32 cpu_clkflg;
+ struct clk *dpll_usb;
if (cpu_is_omap443x()) {
cpu_mask = RATE_IN_4430;
@@ -3456,5 +3457,12 @@ int __init omap4xxx_clk_init(void)
*/
clk_enable_init_clocks();
+ /*
+ * Setup USB DPLL
+ */
+ dpll_usb = clk_get(NULL, dpll_usb_ck);
+
+ clk_set_rate(dpll_usb, 96000);
+
return 0;
}
--
1.7.4.1
Re: [PATCH] spi: omap2-mcspi: Reorder the wait_for_completion for tx
On Tue, Nov 6, 2012 at 2:33 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 06, 2012 at 02:30:19PM +0530, Shubhrajyoti D wrote: The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function] changed the wait_for_completion order. Move the wait so that the rx doesnot wait for the tx to complete. Applied, thanks. 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
Re: [PATCH] spi: omap2-mcspi: Reorder the wait_for_completion for tx
On Tue, Nov 06, 2012 at 02:47:27PM +0530, Shubhrajyoti D wrote: The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function] changed the wait_for_completion order. Move the wait so that the rx doesnot wait for the tx to complete. Is this a resend of the patch I just applied, or is it something different? signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.7-rc1
Hi Kevin, Paul, On Tue, Nov 6, 2012 at 1:01 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Jean Pihet jean.pi...@newoldbits.com writes: [...] I ran some intensive stress tests on the I2C and ... unfortunately I could not trigger the problem. It looks like the issue is caused by some transient situation where the CORE and/or I2C is in a low power state. FYI... I just ran across what appears to be the same bug on 3430/n900 during suspend/resume testing. With CPUidle enabled, this happens every time. Reverting the I2C QoS patch makes it work again. That makes sense with CPU_IDLE enabled and suspend. The cause of the problem is that the cpuidle influences the MPU and CORE states, depending on the constraints set and the latency figures for the power domains (in arch/arm/mach-omap2/cpuidle34xx.c). Since the latency numbers have not been updated to measured (i.e. realistic) values in too-low power state is used, hence the timeout problem. Note: that does not explain why the I2C timeout issue is present without CPU_IDLE enabled, since in that case PM QoS should not have any effect on the power domains states. So yes the PM QoS I2C patch shall be reverted as long as the PM QoS support for OMAP is not merged in. For the records here are the patches that have been submitted to support the OMAP PM QoS: - func power states [1], - OMAP PM QoS support [2], which includes the latency figures update and which depends on [1], - the conversion of I2C to PM QoS [3], - the removal of the old no-op OMAP PM API [4], which depends on [3], The chicken-and-egg problem is clearly visible since [3] depends on [2]. What to do now with those patches? As said above [3] and [4] must be held until [1] and [2] are merged in. [1] http://marc.info/?l=linux-arm-kernelm=134744383120921w=2 [2] http://marc.info/?l=linux-omapm=134795835604288w=2 [3] http://marc.info/?l=linux-omapm=134815730108344w=2 [4] http://marc.info/?l=linux-omapm=134795836904299w=2 Kevin Thanks for testing and reporting the issue. Jean # rtcwake -m mem -s 1 Date:Fri Dec 31 17:00:34 MST 1999 hwclock: Sat Jan 1 00:00:34 2000 0.00 seconds [ 38.819732] omap_i2c omap_i2c.1: timeout waiting for bus ready wakeup from mem at Sat Jan 1 00:00:36 2000 [ 38.841949] PM: Syncing filesystems ... done. [ 38.859466] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 38.885284] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 38.916412] Suspending console(s) (use no_console_suspend to debug) [ 39.944274] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 39.944305] twl: i2c_read failed to transfer all messages [ 39.944305] twl_rtc: Could not read TWLregister D - error -110 [ 39.944335] twl_rtc twl_rtc: twl_rtc_read_time: reading CTRL_REG, error -110 [ 40.975524] omap_i2c omap_i2c.1: timeout waiting for bus ready [ 40.97] twl: i2c_read failed to transfer all messages [ 40.97] VMMC2_IO_18: failed to disable [ 40.978698] PM: suspend of devices complete after 2049.163 msecs [ 40.984222] PM: late suspend of devices complete after 5.493 msecs [ 40.992126] PM: noirq suspend of devices complete after 7.873 msecs [ 40.992187] Disabling non-boot CPUs ... [ 40.992675] Successfully put all powerdomains to target state [ 40.997009] PM: noirq resume of devices complete after 4.058 msecs [ 41.002014] PM: early resume of devices complete after 3.601 msecs [ 41.179016] PM: resume of devices complete after 176.818 msecs [ 41.277740] Restarting tasks ... done. real0m 3.50s user0m 0.00s sys 0m 0.10s Date:Fri Dec 31 17:00:40 MST 1999 hwclock: Sat Jan 1 00:00:40 2000 0.00 seconds -- 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 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
On 11/5/2012 2:40 PM, Bedia, Vaibhav wrote: On Sun, Nov 04, 2012 at 20:54:17, Bedia, Vaibhav wrote: On Sat, Nov 03, 2012 at 21:48:48, Shilimkar, Santosh wrote: On Friday 02 November 2012 06:02 PM, Vaibhav Bedia wrote: The first entry for CPGMAC0 should be ADDR_MAP_ON_INIT instead of ADDR_TYPE_RT to ensure the omap hwmod code maps the memory space at init and writes to the SYSCONFIG registers. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com --- Sorry again similar question. Why CPGMAC0 should be mapped and sysconfig updated early ? Hmm I need to revisit this one. CPGMAC0 was not going to standby without this. Maybe something else is wrong in the hwmod data and needs fixing. Ok I checked this one. The change I made was indirectly fixing another issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two entries and the SYSC register is part of the second entry. The function _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with the flag ADDR_TYPE_RT flag. The change I made indirectly made the second entry in am33xx_cpgmac0_addr_space[] become the first memory space with the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct SYSC address of CPGMAC0 and the IP went to standby during bootup. After changing the order of the entries in am33xx_cpgmac0_addr_space[] things work fine. Good catch. Just a side note on this, driver expects the addresses in this order only, first SS and then WR. Thanks, Vaibhav I'll make the changes in the next version. 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 -- 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 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
Hi Jon, On Tue, Nov 06, 2012 at 02:50:50, Hunter, Jon wrote: [...] Why is this? How is the dmtimer TIOCP_CFG register configured on AM33xx? Is it using smart-idle? Yes, it is set to smart-idle with wakeup capable mode. (this needs a fixup since this timer is not wakeup capable) but unfortunately this is not sufficient. On AM33xx there's no HW_AUTO mode magic so unless the IPs in PER domain are disabled by s/w, PER domain can't transition. The next one is that the clockevent doesn't generate any further interrupts once the system resumes. We need to restore the pre-suspend configuration. I haven't tried but I guess we could have used the save and restore of timer registers here. It would be interesting to try using an non-wakeup domain timer on OMAP3/4 for clock events and seeing if suspend/resume works. Do you know what the exact problem here is? I understand that the timer context could get lost, but exactly what is not getting restarted by the kernel? For example, the only place we set the interrupt enable is during the clock event init and so if the context is lost, then I could see no more interrupts occurring. So is it enough to just restore the interrupt enable register, do you really need to program the timer again? Just restoring the interrupt enable register works. But since there's no logic retention I think a context save-restore would be better. 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: OMAP baseline test results for v3.7-rc3
On 06/11/12 06:16, Hiremath, Vaibhav wrote: Where is your DTB? Is it appended to Kernel image? Can you try below sequence/commands from u-boot? mmc rescan 0 fatload mmc 0 8000 am335x-bone.dtb fatload mmc 0 8100 uImage setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/mmcblk0p2 rw noinitrd rootfstype=ext3 rootwait earlyprink=serial sendln 'bootm 8100 - 8000' To build DTB files, use make dtbs command on your kernel home directory. That works ... great !! But now I'm confused, since I thought the DTB was appended to the uImage file. I have the following in my .config:- ARM_ATAG_DTB_COMPAT=y ARM_APPENDED_DTB=y ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y And then I create my uImage file using:- $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- uImage $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- am335x-bone.dtb $ cat arch/arm/boot/uImage arch/arm/boot/am335x-bone.dtb arch/arm/boot/uImage-dtb.am335x-bone $ cp arch/arm/boot/uImage-dtb.am335x-bone /media/boot/uImage Do you now have to load the DTB as a separate file ? Or should the appended DTB still work ? 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
[PATCH] i2c: omap: Move the remove constraint
Currently we just queue the transfer and release the qos constraints, however we donot wait for the transfer to complete to release the constraint. Move the remove constraint after the bus busy as we are sure that the transfers are completed by then. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com --- drivers/i2c/busses/i2c-omap.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 94ff685..8b079d7 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -655,13 +655,13 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) break; } - if (dev-latency) - pm_qos_remove_request(dev-pm_qos_request); - if (r == 0) r = num; omap_i2c_wait_for_bb(dev); + + if (dev-latency) + pm_qos_remove_request(dev-pm_qos_request); out: pm_runtime_mark_last_busy(dev-dev); pm_runtime_put_autosuspend(dev-dev); -- 1.7.5.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: OMAP baseline test results for v3.7-rc1
On Tue, Nov 6, 2012 at 5:31 AM, Kevin Hilman khil...@deeprootsystems.com wrote: Jean Pihet jean.pi...@newoldbits.com writes: [...] I ran some intensive stress tests on the I2C and ... unfortunately I could not trigger the problem. It looks like the issue is caused by some transient situation where the CORE and/or I2C is in a low power state. FYI... I just ran across what appears to be the same bug on 3430/n900 during suspend/resume testing. With CPUidle enabled, this happens every time. Reverting the I2C QoS patch makes it work again. I think we should defer the release of the constraints Does this help http://www.mail-archive.com/linux-omap@vger.kernel.org/msg79841.html -- 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 3/7] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
On Tue, Nov 06, 2012 at 13:42:21, N, Mugunthan V wrote:
[...]
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x4A101000,
+ .pa_end = 0x4A101000 + SZ_256 - 1,
+ .flags = ADDR_MAP_ON_INIT,
Based on the recent discussions and looking the hwmod code,
I guess ADDR_MAP_ON_INIT does not make sense here. Since you
are just creating a parent-child relationship here, maybe no
flag is needed?
+ },
+ { }
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+ .master = am33xx_cpgmac0_hwmod,
+ .slave = am33xx_mdio_hwmod,
+ .addr = am33xx_mdio_addr_space,
+ .user = OCP_USER_MPU,
Is this flag necessary? Shouldn't you just skip the
user field since there's nothing for the hwmod code
to do here?
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: [PATCH 3/8] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
On Mon, Nov 05, 2012 at 14:42:24, Philip, Avinash wrote:
[...]
+
+static struct omap_hwmod_ocp_if am33xx_epwmss0__ecap0 = {
+ .master = am33xx_epwmss0_hwmod,
+ .slave = am33xx_ecap0_hwmod,
+ .clk= l4ls_gclk,
+ .addr = am33xx_ecap0_addr_space,
+ .user = OCP_USER_MPU,
+};
Noticed this in another patch which is quite similar so commenting here
again. Is the user field required if you are just creating a parent-child
relationship here?
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: [PATCH 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
On Tue, Nov 06, 2012 at 14:59:45, Hiremath, Vaibhav wrote: [...] Ok I checked this one. The change I made was indirectly fixing another issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two entries and the SYSC register is part of the second entry. The function _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with the flag ADDR_TYPE_RT flag. The change I made indirectly made the second entry in am33xx_cpgmac0_addr_space[] become the first memory space with the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct SYSC address of CPGMAC0 and the IP went to standby during bootup. After changing the order of the entries in am33xx_cpgmac0_addr_space[] things work fine. Good catch. Just a side note on this, driver expects the addresses in this order only, first SS and then WR. Sorry I didn't understand your comment. For HWMOD code to work as expected, we need to change the order. Are you saying that I should not be doing this because the driver will get affected? 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: [PATCH] spi: omap2-mcspi: Reorder the wait_for_completion for tx
On Tue, Nov 6, 2012 at 2:52 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Tue, Nov 06, 2012 at 02:47:27PM +0530, Shubhrajyoti D wrote: The commit d7b4394e[Cleanup the omap2_mcspi_txrx_dma function] changed the wait_for_completion order. Move the wait so that the rx doesnot wait for the tx to complete. Is this a resend of the patch I just applied, or is it something different? No please ignore this one. Something wrong at my end it got sent twice. Please ignore. -- 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: OMAP baseline test results for v3.7-rc3
On Tue, Nov 06, 2012 at 11:39:18, Hiremath, Vaibhav wrote: On Mon, Nov 05, 2012 at 08:11:24, Paul Walmsley wrote: Hi On Tue, 30 Oct 2012, Vaibhav Hiremath wrote: This is surprising, I have tested v3.7-rc3 branch on AM335xBone platform and its booting up for me without any issues. Jon had submitted another patch which fixes boot issue on Bone. https://patchwork.kernel.org/patch/1606471/ v3.7-rc4 failed for me with a detached .dtb in a quick test. Probably it is due to the original u-boot that was shipped with the MMC card: Pulling the tree, let me try now and update you shortly... Just tried -rc4, and it boots up fine for me. I tested it with Mainline u- boot and mainline Kernel, I have pasted log below for reference - U-Boot 2011.09-9-gcf6e04d (Mar 08 2012 - 17:15:43) arm-arago-linux-gnueabi-gcc (GCC) 4.5.3 20110311 (prerelease) I do not suspect anything here, but still think we should use mainline u-boot version. Can you share the images with me, so that I can try them? Log=== U-Boot SPL 2013.01-rc1-00071-g1cc619b (Nov 06 2012 - 15:33:43) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.01-rc1-00071-g1cc619b (Nov 06 2012 - 15:33:43) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: cpsw Hit any key to stop autoboot: 0 U-Boot# U-Boot# U-Boot# mmc rescan 0 U-Boot# fatload mmc 0 8000 am335x-bone.dtb reading am335x-bone.dtb 4391 bytes read U-Boot# fatload mmc 0 8100 uImage reading uImage 3842256 bytes read U-Boot# fatload mmc 0 8200 ramdisk-pm.gz reading ramdisk-pm.gz 2022580 bytes read U-Boot# setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial U-Boot# bootm 8100 - 8000 ## Booting kernel from Legacy Image at 8100 ... Image Name: Linux-3.7.0-rc4 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3842192 Bytes = 3.7 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 8000 Booting using the fdt blob at 0x8000 Loading Kernel Image ... OK OK Loading Device Tree to 8fe65000, end 8fe69126 ... OK Starting kernel ... [0.00] Booting Linux on physical CPU 0 [0.00] Linux version 3.7.0-rc4 (a0393758@psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Nov 6 15:28:21 IST 2012 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] AM335X ES1.0 (neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0f03000 s12928 r8192 d15744 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [0.00] Kernel command line: console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=65536 earlyprintk=serial [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes) [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [0.00] Memory: 255MB = 255MB total [0.00] Memory: 229112k/229112k available, 33032k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB) [0.00] lowmem : 0xc000 - 0xd000 ( 256 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc06c4b94 (6899 kB) [0.00] .init : 0xc06c5000 - 0xc0715280 ( 321 kB) [0.00] .data : 0xc0716000 - 0xc07a13a0 ( 557 kB) [0.00].bss : 0xc07a13c4 - 0xc0cfbd6c (5483 kB) [0.00] Hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 interrupts [0.00] Total of 128 interrupts on 1 active controller [0.00] OMAP clockevent source: GPTIMER1 at 2400 Hz [0.00] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms [0.00] OMAP clocksource: GPTIMER2 at 2400 Hz [0.00] Console: colour dummy device 80x30 [0.00] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.00] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.00] ... MAX_LOCK_DEPTH:
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Grant, On Nov 5, 2012, at 9:40 PM, Grant Likely wrote: Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Device Tree Overlay Feature Purpose === Sometimes it is not convenient to describe an entire system with a single FDT. For example, processor modules that are plugged into one or more modules (a la the BeagleBone), or systems with an FPGA peripheral that is programmed after the system is booted. For these cases it is proposed to implement an overlay feature for the so that the initial device tree data can be modified by userspace at runtime by loading additional overlay FDTs that amend the original data. User Stories Note - These are potential use cases, but just because it is listed here doesn't mean it is important. I just want to thoroughly think through the implications before making design decisions. Jane is building custom BeagleBone expansion boards called 'capes'. She can boot the system with a stock BeagleBoard device tree, but additional data is needed before a cape can be used. She could replace the FDT file used by U-Boot with one that contains the extra data, but she uses the same Linux system image regardless of the cape, and it is inconvenient to have to select a different device tree at boot time depending on the cape. Jane solves this problem by storing an FDT overlay for each cape in the root filesystem. When the kernel detects that a cape is installed it reads the cape's eeprom to identify it and uses request_firmware() to obtain the appropriate overlay. Userspace passes the overlay to the kernel in the normal way. If the cape doesn't have an eeprom, then the kernel will still use firmware_request(), but userspace needs to already know which cape is installed. Jane is a really productive hardware engineer - she manages to fix a number of problems with her cape design by spinning different revisions of the cape. Using the flexibility that the DT provides, documents and defines the hardware changes of the cape revisions in the FDT overlay. The loader matches the revision of the cape with the proper FDT overlay so that the drivers are relieved of having to do revision management. Nigel is building a real-time video processing system around a MIPS SoC and a Virtex FPGA. Video data is streamed through the FPGA for post processing operations like motion tracking or compression. The FPGA is configured via the SPI bus, and is also connected to GPIO lines and the memory mapped peripheral bus. Nigel has designed several FPGA configurations for different video processing tasks. The user will choose which configuration to load which can even be reprogrammed at runtime to switch tasks. Each FPGA has a different interface to the processor, so the kernel needs additional data before it can use each device. Nigel is passing that data to the kernel using an FDT overlay. When Linux loads a new FPGA configuration, it uses request_firmare() to obtain the overlay for that FPGA. When the FPGA gets reprogrammed, the kernel throws away the previous overlay data and uses request_firmware() to get the overlay for the new design. Mandy has a Raspberry Pi which she has wired by hand up to sensors and motor controllers in her prototype autonomous robot project. She is doing self-hosted driver development on the Raspberry Pi itself. However, she needs a method to tell the kernel about the attached devices. By installing dtc on the Pi, Mandy compiles the overlay for her prototype hardware. However, she doesn't have a copy of the Pi's original FDT source, so instead she uses the dtc 'fs' input format to compile the overlay file against the live DT data in /proc. Jane (the cape designer) can use this too. Developing the cape, she really appreciates that she doesn't have to reboot every time she makes a change in the cape hardware. By removing the FDT overlay, compiling with the dtc on the board, and re-inserting the overlay, she can be more productive by waiting less. Johnny, Jane's little son, doesn't know anything about device trees, linux kernel trees, or hard-core s/w engineering. He is a bright kid, and due to the board having a node.js based educational electronic design kit, he can use the web-based simplified development environment, that allows him graphically to connect the parts in his kit. He can save the design and the IDE creates on the fly the DT overlay for later use. Amit is writing kernel drivers for Jane's BeagleBone capes, but he finds loading new DT files into the root filesystem inconvenient. Instead, he includes the FDT overlay file in the initramfs that is built and linked in at kernel compile time so that the kernel can find and load overlays automatically. Joanne has purchased one of Jane's capes and packaged it into a rugged case for data
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
Hi Timur, On Nov 5, 2012, at 10:40 PM, Tabi Timur-B04825 wrote: On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely grant.lik...@secretlab.ca wrote: Jane is building custom BeagleBone expansion boards called 'capes'. She can boot the system with a stock BeagleBoard device tree, but additional data is needed before a cape can be used. She could replace the FDT file used by U-Boot with one that contains the extra data, but she uses the same Linux system image regardless of the cape, and it is inconvenient to have to select a different device tree at boot time depending on the cape. What's wrong with having the boot loader detect the presence of the Cape and update the device tree accordingly? We do this all the time in U-Boot. Doing stuff like reading EEPROMs and testing for the presence of hardware is easier in U-Boot than in Linux. For configurations that can be determined by the boot loader, I'm not sure overlays are practical. Each use case is different. For our use-cases boot loader DT modifications just won't work. What's nice about the stuff we're talking about is that if you don't use the new functionality, nothing changes for you. Go on and use DT the old way if you'd like. Nigel is building a real-time video processing system around a MIPS SoC and a Virtex FPGA. Video data is streamed through the FPGA for post processing operations like motion tracking or compression. The FPGA is configured via the SPI bus, and is also connected to GPIO lines and the memory mapped peripheral bus. Nigel has designed several FPGA configurations for different video processing tasks. The user will choose which configuration to load which can even be reprogrammed at runtime to switch tasks. Now this, on the other hand, makes more sense. If the hardware configuration is literally user-configurable, then okay. However, I'm not sure I see the need to update the device tree. The device tree is generally for hardware that cannot be discovered/probed by the device driver. If we're loading a configuration from user space, doesn't the driver already know what the hardware's capabilities are, since it's the one doing the uploading of a new FPGA code? Why not skip the device tree update and just tell the driver what the new capabilities are? -- Timur Tabi Linux kernel developer at Freescale Regards -- Pantelis -- 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 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
Hi Kevin,
On Mon, Nov 05, 2012 at 23:10:27, Kevin Hilman wrote:
[...]
First, some general comments. This is a big patch and probably should
be broken up a bit. I suspect it could be broken up a bit, maybe into
at least:
- EMIF interface
- SCM interface, new APIs
- assembly/OCM code
- pm33xx.[ch]
- lastly, the late_init stuff that actually initizlizes
Ok, I'll try splitting the patches in the next version.
I have a handful of comments below. I wrote this up on the plane over
the weekend, and I see that Santosh has already made some similar
comments, but I'll send mine anyways.
[...]
Doing this on every suspend looks a bit strange. Why not just have some
init function handle these devices once at boot. If this is really
needed on every suspend, it needs some more description, and probably
some basic stub drivers need to be created.
We do require it for every suspend (but more below). I'll add in more
description in the comment that's already there.
Also, if there are drivers for these devices, won't this interfere?
Hmm, I can think of the following scenarios
1. Runtime PM adapted drivers are compiled in - We'll have to ensure that
in their suspend callbacks they end up doing omap_hwmod_idle() via the
runtime PM APIs. In this case the omap_hwmod_enable() followed by
omap_hwmod_idle() is not necessary in the PM code.
2. The drivers are not compiled in - In this case, the hwmod code puts
the IPs in standby during bootup so the first suspend-resume iteration
will pass. During resuming, the SYSC configuration for forced standby will
be lost, so in the subsequent iterations these IPs won't go standby and the
hwmod code does not touch them since they never got enabled. In this case
we do need the sequence that is there currently.
3. For some reason the respective drivers don't idle the IPs during suspend -
(no_idle_on_suspend flag for the hwmod in DT?). In this scenario I think
we should abort the suspend process since we know that the suspend is not
going to work.
Is there some other scenario that needs to be covered?
How about adding some flag in hwmod code for handling this? Something
similar to what was done for MMC [1]. I think the problem that we have
is in some ways similar to the one addressed in [1].
+ /* Put the GFX clockdomains to sleep */
+ clkdm_sleep(gfx_l3_clkdm);
+ clkdm_sleep(gfx_l4ls_clkdm);
+
+ /* Try to put GFX to sleep */
+ pwrdm_set_next_pwrst(gfx_pwrdm, PWRDM_POWER_OFF);
ditto.
I'll check if this can be removed.
[...]
+static int am33xx_pm_begin(suspend_state_t state)
+{
+ int ret = 0;
+
+ disable_hlt();
+
+ /*
+* Physical resume address to be used by ROM code
+*/
+ wkup_m3-resume_addr = (AM33XX_OCMC_END - am33xx_do_wfi_sz +
+ am33xx_resume_offset + 0x4);
Why does this need to be calculated every suspend/resume?
Will move this to init phase.
+ wkup_m3-sleep_mode = IPC_CMD_DS0;
+ wkup_m3-ipc_data1 = DS_IPC_DEFAULT;
+ wkup_m3-ipc_data2 = DS_IPC_DEFAULT;
+
+ am33xx_ipc_cmd();
This IPC needs a cleaner interface/API. Also, since it involves
register writes to the SCM, it should be defined in control.c. (NOTE:
we're in the process of creating a real driver out of the SCM, so all
SCM register accesses need to be contained in control.c)
For example, you probably want an am33xx_m3_* API in control.c, with
some pre-baked commands for the M3.
Ok. I'll work on this for the next version.
+ wkup_m3-state = M3_STATE_MSG_FOR_LP;
+ omap_mbox_enable_irq(wkup_m3-mbox, IRQ_RX);
+
+ ret = omap_mbox_msg_send(wkup_m3-mbox, 0xABCDABCD);
+ if (ret) {
+ pr_err(A8-CM3 MSG for LP failed\n);
+ am33xx_m3_state_machine_reset();
+ ret = -1;
+ }
+
+ if (!wait_for_completion_timeout(wkup_m3_sync,
+ msecs_to_jiffies(500))) {
hmm, interesting. I know you're not implementing idle here, but I'm
rather curious how this sync w/M3 is going to work for idle.
Like you mentioned in another thread we could probably not have
a sync in the idle path. (More in the other thread).
+ pr_err(A8-CM3 sync failure\n);
+ am33xx_m3_state_machine_reset();
+ ret = -1;
+ } else {
+ pr_debug(Message sent for entering DeepSleep mode\n);
+ omap_mbox_disable_irq(wkup_m3-mbox, IRQ_RX);
+ }
+
+ return ret;
+}
+
[...]
+static void am33xx_m3_state_machine_reset(void)
+{
+ int ret = 0;
+
+ wkup_m3-resume_addr= 0x0;
+ wkup_m3-sleep_mode = IPC_CMD_RESET;
+ wkup_m3-ipc_data1 = DS_IPC_DEFAULT;
+ wkup_m3-ipc_data2 = DS_IPC_DEFAULT;
+
+ am33xx_ipc_cmd();
+
+ wkup_m3-state = M3_STATE_MSG_FOR_RESET;
+
+ ret = omap_mbox_msg_send(wkup_m3-mbox, 0xABCDABCD);
magic constant needs a #define
Ok.
+ if (!ret) {
+
Re: [PATCH 0/7] ARM: AM33XX: net: Add DT support to CPGMAC and MDIO driver
On Tue, Nov 06, 2012 at 01:42:18PM +0530, Mugunthan V N wrote: This patch-series adds support for, [1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's [2/7]: Adds parent-child relation between CPSW MDIO module inside cpsw driver, as in case of AM33XX, the resources are shared and common register bit-field is provided to control module/clock enable/disable, makes it difficult to handle common resource. So the solution here is, to create parent-child relation between them. [3/7]: Add hwmod entry for MDIO module, required for MDIO driver. [4/7]: cpsw: simplify the setup of the register pointers [5/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi, am335x-evm.dts and am335x-bone.dts file [6/7]: Enable CPSW support to omap2plus_defconfig [7/7]: cpsw: Kernel warn fix during suspend Acked-by: Richard Cochran richardcoch...@gmail.com -- 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/3] mtd nand : onfi need to be probed in 8 bits mode
- NAND_CMD_READID want an address that it is not scaled on x16 device (it is always 0x20) - NAND_CMD_PARAM want 8 bits data Signed-off-by: Matthieu CASTET matthieu.cas...@parrot.com --- drivers/mtd/nand/nand_base.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c index 5894c2c..abeb8e9 100644 --- a/drivers/mtd/nand/nand_base.c +++ b/drivers/mtd/nand/nand_base.c @@ -2851,6 +2851,8 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip, int i; int val; + /* ONFI need to be probed in 8 bits mode */ + WARN_ON(chip-options NAND_BUSWIDTH_16); /* Try ONFI for unknown chip or LP */ chip-cmdfunc(mtd, NAND_CMD_READID, 0x20, -1); if (chip-read_byte(mtd) != 'O' || chip-read_byte(mtd) != 'N' || -- 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 2/3] mtd nand : add NAND_BUSWIDTH_AUTO to autodetect bus width
The driver call nand_scan_ident in 8 bit mode, then
readid or onfi detection are done (and detect bus width).
The driver should update its bus width before calling nand_scan_tail.
This work because readid and onfi are read work 8 byte mode.
Note that nand_scan_ident send command (NAND_CMD_RESET, NAND_CMD_READID,
NAND_CMD_PARAM), address and read data
The ONFI specificication is not very clear for x16 device if high byte of
address should be driven to 0,
but according to [1] it should be ok to not drive it during autodetection.
[1]
3.3.2. Target Initialization
[...]
The Read ID and Read Parameter Page commands only use the lower 8-bits of the
data bus.
The host shall not issue commands that use a word data width on x16 devices
until the host
determines the device supports a 16-bit data bus width in the parameter page.
Signed-off-by: Matthieu CASTET matthieu.cas...@parrot.com
---
drivers/mtd/nand/nand_base.c | 14 +-
include/linux/mtd/nand.h |7 +++
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index abeb8e9..c90ef66 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3245,11 +3245,15 @@ ident_done:
break;
}
- /*
-* Check, if buswidth is correct. Hardware drivers should set
-* chip correct!
-*/
- if (busw != (chip-options NAND_BUSWIDTH_16)) {
+ if (chip-options NAND_BUSWIDTH_AUTO) {
+ WARN_ON(chip-options NAND_BUSWIDTH_16);
+ chip-options |= busw;
+ nand_set_defaults(chip, busw);
+ } else if (busw != (chip-options NAND_BUSWIDTH_16)) {
+ /*
+* Check, if buswidth is correct. Hardware drivers should set
+* chip correct!
+*/
pr_info(NAND device: Manufacturer ID:
0x%02x, Chip ID: 0x%02x (%s %s)\n, *maf_id,
*dev_id, nand_manuf_ids[maf_idx].name, mtd-name);
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 24e9159..c8518d4 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -219,6 +219,13 @@ typedef enum {
#define NAND_OWN_BUFFERS 0x0002
/* Chip may not exist, so silence any errors in scan */
#define NAND_SCAN_SILENT_NODEV 0x0004
+/*
+ * Autodetect nand buswidth with readid/onfi.
+ * This suppose the driver will configure the hardware in 8 bits mode
+ * when calling nand_scan_ident, and update its configuration
+ * before calling nand_scan_tail.
+ */
+#define NAND_BUSWIDTH_AUTO 0x0008
/* Options set by nand scan */
/* Nand scan has allocated controller struct */
--
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 3/3] omap3 nand : use NAND_BUSWIDTH_AUTO
This allow to clean the omap nand driver that were trying in x8 and x16 bits
mode.
This also make work onfi detection on beagleboard :
Before :
[1.954803] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND
256MiB 1,8V 16-bit), page size: 2048, OOB size: 64
After :
[1.914825] ONFI param page 0 valid
[1.919158] ONFI flash detected
[1.922515] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron
MT29F2G16ABD), page size: 2048, OOB size: 64
platform data devsize is renamed bussize. It now indicate the maximun size of
the nand bus.
Signed-off-by: Matthieu CASTET matthieu.cas...@parrot.com
---
arch/arm/mach-omap2/board-3630sdp.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-flash.c|8 ++---
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
arch/arm/mach-omap2/board-zoom.c |2 +-
arch/arm/mach-omap2/common-board-devices.c |2 +-
arch/arm/mach-omap2/gpmc-nand.c |5 ---
drivers/mtd/nand/omap2.c | 42 ++
include/linux/platform_data/mtd-nand-omap2.h |7 -
13 files changed, 42 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index fc224ad..d7b981b 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -198,7 +198,7 @@ static void __init omap_sdp_init(void)
h8mbx00u0mer0em_sdrc_params);
zoom_display_init();
board_smc91x_init();
- board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_BUSWIDTH_16);
+ board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_OMAP_BUS_16);
enable_board_wakeup_source();
usbhs_init(usbhs_bdata);
}
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 1fd161e..b3487e1 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -621,7 +621,7 @@ static void __init devkit8000_init(void)
usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
- omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
+ omap_nand_flash_init(NAND_OMAP_BUS_16, devkit8000_nand_partitions,
ARRAY_SIZE(devkit8000_nand_partitions));
omap_twl4030_audio_init(omap3beagle);
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 0cabe61..488a1fa 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -133,12 +133,12 @@ static struct omap_nand_platform_data board_nand_data = {
void
__init board_nand_init(struct mtd_partition *nand_parts,
- u8 nr_parts, u8 cs, int nand_type)
+ u8 nr_parts, u8 cs, int bus_type)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
- board_nand_data.devsize = nand_type;
+ board_nand_data.bussize = bus_type;
board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
gpmc_nand_init(board_nand_data);
@@ -185,7 +185,7 @@ unmap:
* @return - void.
*/
void __init board_flash_init(struct flash_partitions partition_info[],
- char chip_sel_board[][GPMC_CS_NUM], int nand_type)
+ char chip_sel_board[][GPMC_CS_NUM], int bus_type)
{
u8 cs = 0;
u8 norcs = GPMC_CS_NUM + 1;
@@ -238,5 +238,5 @@ void __init board_flash_init(struct flash_partitions
partition_info[],
pr_err(NAND: Unable to find configuration in GPMC\n);
else
board_nand_init(partition_info[2].parts,
- partition_info[2].nr_parts, nandcs, nand_type);
+ partition_info[2].nr_parts, nandcs, bus_type);
}
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 48d5e41..732f183 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -175,7 +175,7 @@ static void __init igep_flash_init(void)
pr_info(IGEP: initializing NAND memory device\n);
board_nand_init(igep_flash_partitions,
ARRAY_SIZE(igep_flash_partitions),
- 0, NAND_BUSWIDTH_16);
+ 0, NAND_OMAP_BUS_16);
} else if (mux == IGEP_SYSBOOT_ONENAND) {
pr_info(IGEP: initializing OneNAND memory device\n);
board_onenand_init(igep_flash_partitions,
diff --git
Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On Tue, Nov 6, 2012 at 10:30 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Grant, On Nov 5, 2012, at 9:40 PM, Grant Likely wrote: Hey folks, As promised, here is my early draft to try and capture what device tree overlays need to do and how to get there. Comments and suggestions greatly appreciated. Device Tree Overlay Feature Purpose === Sometimes it is not convenient to describe an entire system with a single FDT. For example, processor modules that are plugged into one or more modules (a la the BeagleBone), or systems with an FPGA peripheral that is programmed after the system is booted. For these cases it is proposed to implement an overlay feature for the so that the initial device tree data can be modified by userspace at runtime by loading additional overlay FDTs that amend the original data. User Stories Note - These are potential use cases, but just because it is listed here doesn't mean it is important. I just want to thoroughly think through the implications before making design decisions. Jane is building custom BeagleBone expansion boards called 'capes'. She can boot the system with a stock BeagleBoard device tree, but additional data is needed before a cape can be used. She could replace the FDT file used by U-Boot with one that contains the extra data, but she uses the same Linux system image regardless of the cape, and it is inconvenient to have to select a different device tree at boot time depending on the cape. Jane solves this problem by storing an FDT overlay for each cape in the root filesystem. When the kernel detects that a cape is installed it reads the cape's eeprom to identify it and uses request_firmware() to obtain the appropriate overlay. Userspace passes the overlay to the kernel in the normal way. If the cape doesn't have an eeprom, then the kernel will still use firmware_request(), but userspace needs to already know which cape is installed. Jane is a really productive hardware engineer - she manages to fix a number of problems with her cape design by spinning different revisions of the cape. Using the flexibility that the DT provides, documents and defines the hardware changes of the cape revisions in the FDT overlay. The loader matches the revision of the cape with the proper FDT overlay so that the drivers are relieved of having to do revision management. Okay By installing dtc on the Pi, Mandy compiles the overlay for her prototype hardware. However, she doesn't have a copy of the Pi's original FDT source, so instead she uses the dtc 'fs' input format to compile the overlay file against the live DT data in /proc. Jane (the cape designer) can use this too. Developing the cape, she really appreciates that she doesn't have to reboot every time she makes a change in the cape hardware. By removing the FDT overlay, compiling with the dtc on the board, and re-inserting the overlay, she can be more productive by waiting less. Yes, but I'll leave this paragraph out of the spec. It isn't significantly different from what is already there. Johnny, Jane's little son, doesn't know anything about device trees, linux kernel trees, or hard-core s/w engineering. He is a bright kid, and due to the board having a node.js based educational electronic design kit, he can use the web-based simplified development environment, that allows him graphically to connect the parts in his kit. He can save the design and the IDE creates on the fly the DT overlay for later use. Yes. Joanne has purchased one of Jane's capes and packaged it into a rugged case for data logging. As far as Joanne is concerned, the BeagleBone and cape together are a single unit and she'd prefer a single monolithic FDT instead of using an FDT overlay. Option A: Using dtc, she uses the BeagleBone and cape .dts source files to generate a single .dtb for the entire system which is loaded by U-Boot. -or- Unlikely. Option B: Joanne uses a tool to merge the BeagleBone and cape .dtb files (instead of .dts files), -or- Possible but low probability. Option C: U-Boot loads both the base and overlay FDT files, merges them, and passes the resolved tree to the kernel. Could be made to work. Only really required if Joanne wants the cape interface to work for u-boot too. For example if the cape has some kind of network interface that u-boot will use to boot from. Unlikely for your focus perhaps, but I'm trying to capture all the relevant permutations, and I can guarantee that some people really will want this. If not on the bone, then on some other platform. Summary points: - Create an FDT overlay data format and usage model - SHALL reliable resolve or validate of phandles between base and overlay trees - SHOULD reliably handle changes between different underlying overlays (ie. what happens to existing .dtb overly files if the structure of the dtb it is layered
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On Tue, Nov 6, 2012 at 8:14 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote: Sure, so if we add data type supplementary properties to the tree to indicate the data type as indirect phandle, then kernel could refer to the index in the got-like table to fetch the actual phandle address (1-level of indirection), instead of directly using the address in the data field. I'm fine with this. But if the data about phandles is already in the tree, then the need for a GOT simply goes away. The phandles can be fixed up directly and it is so much better because it works with existing parsing code after the merge is applied. g. -- 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 3/7] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
On 11/6/2012 3:39 PM, Bedia, Vaibhav wrote:
On Tue, Nov 06, 2012 at 13:42:21, N, Mugunthan V wrote:
[...]
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x4A101000,
+ .pa_end = 0x4A101000 + SZ_256 - 1,
+ .flags = ADDR_MAP_ON_INIT,
Based on the recent discussions and looking the hwmod code,
I guess ADDR_MAP_ON_INIT does not make sense here. Since you
are just creating a parent-child relationship here, maybe no
flag is needed?
+ },
+ { }
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+ .master = am33xx_cpgmac0_hwmod,
+ .slave = am33xx_mdio_hwmod,
+ .addr = am33xx_mdio_addr_space,
+ .user = OCP_USER_MPU,
Is this flag necessary? Shouldn't you just skip the
user field since there's nothing for the hwmod code
to do here?
Will remove the unnecessary flags and submit the patch.
Regards
Mugunthan V N
--
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 v3 0/7] Create platform device for audio support
On 2012-11-06 08:19, Ricardo Neri wrote: Hi Tomi, l-o list, The main purpose of this patch set is to create a platform device for audio support from the OMAPDSS HDMI driver. This tries to follow an approach similar to MFD drivers in which a core driver creates domain-specific devices. Under this approach, the OMAPDSS HDMI drivers acts as the core driver, retrieves its resources (from DT or hwmod) and passes the relevant audio resources for other drivers to use. This is also beneficial for future DT boot support, as the OMAP HDMI IP will be represented by a single node in the tree. Before creating the platform device for audio, I also did minor cleanup to the OMAPDSS HDMI driver probe function. Changes from v2: *Check the validity of the audio platform device by checking a non-NULL condition rather than an error pointer condition. *Pass the ID of the HDMI platform device to handle more than one instance of HDMI audio platform devices. This is for future implementations that support more than one HDMI output. Changes from v1: *Simplify ioremap further by using devm_request_and_ioremap. *Pass to the audio driver only the DMA port and not the whole register space. *Use a local array for the audio resources and init them with DEFINE_RES_MEM. *Obtain the DMA port address offset and size from the HDMI IP-specific library. v2 is accessible here: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg79529.html v1 is accessible here: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg77861.html Looks good to me, I'll apply to omapdss tree. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCHv2 1/6] arch: Change defconfigs to point to g_mass_storage.
Hi, On Fri, Nov 02, 2012 at 02:31:50PM +0100, Michal Nazarewicz wrote: From: Michal Nazarewicz min...@mina86.com The File-backed Storage Gadget (g_file_storage) is being removed, since it has been replaced by Mass Storage Gadget (g_mass_storage). This commit changes defconfigs point to the new gadget. Signed-off-by: Michal Nazarewicz min...@mina86.com I need more Acks here. Only got one from Nicolas. Anyone else ? --- arch/arm/configs/afeb9260_defconfig|2 +- arch/arm/configs/at91sam9260_defconfig |2 +- arch/arm/configs/at91sam9261_defconfig |2 +- arch/arm/configs/at91sam9263_defconfig |2 +- arch/arm/configs/at91sam9g20_defconfig |2 +- arch/arm/configs/corgi_defconfig |2 +- arch/arm/configs/davinci_all_defconfig |2 +- arch/arm/configs/h7202_defconfig |3 +-- arch/arm/configs/magician_defconfig|2 +- arch/arm/configs/mini2440_defconfig|2 +- arch/arm/configs/omap1_defconfig |3 +-- arch/arm/configs/prima2_defconfig |1 - arch/arm/configs/spitz_defconfig |2 +- arch/arm/configs/stamp9g20_defconfig |2 +- arch/arm/configs/viper_defconfig |2 +- arch/arm/configs/zeus_defconfig|2 +- arch/avr32/configs/atngw100_defconfig |2 +- arch/avr32/configs/atngw100_evklcd100_defconfig|2 +- arch/avr32/configs/atngw100_evklcd101_defconfig|2 +- arch/avr32/configs/atngw100_mrmt_defconfig |2 +- arch/avr32/configs/atngw100mkii_defconfig |2 +- .../avr32/configs/atngw100mkii_evklcd100_defconfig |2 +- .../avr32/configs/atngw100mkii_evklcd101_defconfig |2 +- arch/avr32/configs/atstk1002_defconfig |2 +- arch/avr32/configs/atstk1003_defconfig |2 +- arch/avr32/configs/atstk1004_defconfig |2 +- arch/avr32/configs/atstk1006_defconfig |2 +- arch/avr32/configs/favr-32_defconfig |2 +- arch/avr32/configs/hammerhead_defconfig|2 +- arch/blackfin/configs/CM-BF527_defconfig |2 +- arch/blackfin/configs/CM-BF548_defconfig |2 +- arch/blackfin/configs/CM-BF561_defconfig |2 +- arch/mips/configs/bcm47xx_defconfig|2 +- arch/mips/configs/mtx1_defconfig |2 +- arch/sh/configs/ecovec24_defconfig |2 +- arch/sh/configs/se7724_defconfig |2 +- 37 files changed, 35 insertions(+), 39 deletions(-) diff --git a/arch/arm/configs/afeb9260_defconfig b/arch/arm/configs/afeb9260_defconfig index c285a9d..a8dbc1e 100644 --- a/arch/arm/configs/afeb9260_defconfig +++ b/arch/arm/configs/afeb9260_defconfig @@ -79,7 +79,7 @@ CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_USB_ZERO=m CONFIG_USB_GADGETFS=m -CONFIG_USB_FILE_STORAGE=m +CONFIG_USB_MASS_STORAGE=m CONFIG_USB_G_SERIAL=m CONFIG_RTC_CLASS=y CONFIG_RTC_DEBUG=y diff --git a/arch/arm/configs/at91sam9260_defconfig b/arch/arm/configs/at91sam9260_defconfig index 505b376..0ea5d2c 100644 --- a/arch/arm/configs/at91sam9260_defconfig +++ b/arch/arm/configs/at91sam9260_defconfig @@ -75,7 +75,7 @@ CONFIG_USB_STORAGE_DEBUG=y CONFIG_USB_GADGET=y CONFIG_USB_ZERO=m CONFIG_USB_GADGETFS=m -CONFIG_USB_FILE_STORAGE=m +CONFIG_USB_MASS_STORAGE=m CONFIG_USB_G_SERIAL=m CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_AT91SAM9=y diff --git a/arch/arm/configs/at91sam9261_defconfig b/arch/arm/configs/at91sam9261_defconfig index 1e8712e..c87beb9 100644 --- a/arch/arm/configs/at91sam9261_defconfig +++ b/arch/arm/configs/at91sam9261_defconfig @@ -125,7 +125,7 @@ CONFIG_USB_GADGET=y CONFIG_USB_ZERO=m CONFIG_USB_ETH=m CONFIG_USB_GADGETFS=m -CONFIG_USB_FILE_STORAGE=m +CONFIG_USB_MASS_STORAGE=m CONFIG_USB_G_SERIAL=m CONFIG_MMC=y CONFIG_MMC_ATMELMCI=m diff --git a/arch/arm/configs/at91sam9263_defconfig b/arch/arm/configs/at91sam9263_defconfig index d2050ca..c5212f4 100644 --- a/arch/arm/configs/at91sam9263_defconfig +++ b/arch/arm/configs/at91sam9263_defconfig @@ -133,7 +133,7 @@ CONFIG_USB_GADGET=y CONFIG_USB_ZERO=m CONFIG_USB_ETH=m CONFIG_USB_GADGETFS=m -CONFIG_USB_FILE_STORAGE=m +CONFIG_USB_MASS_STORAGE=m CONFIG_USB_G_SERIAL=m CONFIG_MMC=y CONFIG_SDIO_UART=m diff --git a/arch/arm/configs/at91sam9g20_defconfig b/arch/arm/configs/at91sam9g20_defconfig index e1b0e80..3b18810 100644 --- a/arch/arm/configs/at91sam9g20_defconfig +++ b/arch/arm/configs/at91sam9g20_defconfig @@ -96,7 +96,7 @@ CONFIG_USB_STORAGE=y CONFIG_USB_GADGET=y CONFIG_USB_ZERO=m CONFIG_USB_GADGETFS=m -CONFIG_USB_FILE_STORAGE=m +CONFIG_USB_MASS_STORAGE=m CONFIG_USB_G_SERIAL=m CONFIG_MMC=y CONFIG_MMC_ATMELMCI=m diff --git
Re: [PATCH v4 6/7] usb: dwc3-omap: Minor fixes to get dt working
Hi, On Thu, Oct 25, 2012 at 08:24:09PM +0530, kishon wrote: Hi Benoit, On Thursday 25 October 2012 07:11 PM, Benoit Cousson wrote: Hi Kishon, On 10/15/2012 03:27 PM, Kishon Vijay Abraham I wrote: Includes few minor fixes in dwc3-omap like populating the compatible string in a correct way, extracting the utmi-mode property properly and changing the index of get_irq since irq of core is removed from hwmod entry. Also updated the documentation with dwc3-omap device tree binding information. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- drivers/usb/dwc3/dwc3-omap.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c index b84ddf3..10aad46 100644 --- a/drivers/usb/dwc3/dwc3-omap.c +++ b/drivers/usb/dwc3/dwc3-omap.c @@ -318,11 +318,10 @@ static int __devinit dwc3_omap_probe(struct platform_device *pdev) struct resource *res; struct device *dev = pdev-dev; - int size; int ret = -ENOMEM; int irq; - const u32 *utmi_mode; + u32 utmi_mode; u32 reg; void __iomem*base; @@ -336,13 +335,13 @@ static int __devinit dwc3_omap_probe(struct platform_device *pdev) platform_set_drvdata(pdev, omap); - irq = platform_get_irq(pdev, 1); + irq = platform_get_irq(pdev, 0); Cannot you use the name of the resource to avoid that kind of trick? *name* is mostly used when we have multiple resource of the same type for a single device. Previously we were clubbing wrapper resources and core resources in a single hwmod device, so we had to use different indexing. But with dt we have separated those under two different devices and hence we can always use index as '0'. But if you think we should have *name*, let me know, I can resend this patch :-) since there were no more replies here, i'm assuming Benoit's happy with Kishon's explanation. Will apply this series as is. -- balbi signature.asc Description: Digital signature
Re: [PATCH v4 0/7] usb: dwc3-omap: add dt support
On Mon, Oct 15, 2012 at 06:57:53PM +0530, Kishon Vijay Abraham I wrote:
This patch series adds dt support to dwc3 core and fixes few minor
stuff in dwc3-omap glue to get dwc3 working.
While at that it also uses *of_platform* to create the child device
(dwc3-core) and fixes to use runtime API's to enable clock and write
to SYSCONFIG register.
Changes from v3:
* rebased to latest commit in balbi's tree
* Fixed few typos in the commit log
* Added *extern* keyword for dwc3_omap_mailbox function declaration
Changes from v2:
* Fixed Sergei comment to use of_property_read_u32 insted of of_get_property
Changes from v1:
* made device_for_each_child() as a seperate patch
* made all other minor fixes wrt typos and function renames
This patch series is developed on:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git dwc3
please rebase on my dwc3 branch. Because of commit belo, patches 1 and 2
won't apply:
commit 124dafde8f8174caf5cef1c3eaba001657d66f4f
Author: Sebastian Andrzej Siewior bige...@linutronix.de
Date: Mon Oct 29 18:09:53 2012 +0100
usb: dwc3: remove custom unique id handling
The lockless implementation of the unique id is quite impressive (:P)
but dirver's core can handle it, we can remove it and make our code a
little smaller.
Cc: Anton Tikhomirov av.tikhomi...@samsung.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b923183..d8d327a 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -66,45 +66,6 @@ MODULE_PARM_DESC(maximum_speed, Maximum supported speed.);
/* --
*/
-#define DWC3_DEVS_POSSIBLE 32
-
-static DECLARE_BITMAP(dwc3_devs, DWC3_DEVS_POSSIBLE);
-
-int dwc3_get_device_id(void)
-{
- int id;
-
-again:
- id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
- if (id DWC3_DEVS_POSSIBLE) {
- int old;
-
- old = test_and_set_bit(id, dwc3_devs);
- if (old)
- goto again;
- } else {
- pr_err(dwc3: no space for new device\n);
- id = -ENOMEM;
- }
-
- return id;
-}
-EXPORT_SYMBOL_GPL(dwc3_get_device_id);
-
-void dwc3_put_device_id(int id)
-{
- int ret;
-
- if (id 0)
- return;
-
- ret = test_bit(id, dwc3_devs);
- WARN(!ret, dwc3: ID %d not in use\n, id);
- smp_mb__before_clear_bit();
- clear_bit(id, dwc3_devs);
-}
-EXPORT_SYMBOL_GPL(dwc3_put_device_id);
-
void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
{
u32 reg;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 243affc..4999563 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -868,7 +868,4 @@ void dwc3_host_exit(struct dwc3 *dwc);
int dwc3_gadget_init(struct dwc3 *dwc);
void dwc3_gadget_exit(struct dwc3 *dwc);
-extern int dwc3_get_device_id(void);
-extern void dwc3_put_device_id(int id);
-
#endif /* __DRIVERS_USB_DWC3_CORE_H */
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index ca65978..586f105 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -94,7 +94,6 @@ static int __devinit dwc3_exynos_probe(struct platform_device
*pdev)
struct dwc3_exynos *exynos;
struct clk *clk;
- int devid;
int ret = -ENOMEM;
exynos = kzalloc(sizeof(*exynos), GFP_KERNEL);
@@ -105,20 +104,16 @@ static int __devinit dwc3_exynos_probe(struct
platform_device *pdev)
platform_set_drvdata(pdev, exynos);
- devid = dwc3_get_device_id();
- if (devid 0)
- goto err1;
-
ret = dwc3_exynos_register_phys(exynos);
if (ret) {
dev_err(pdev-dev, couldn't register PHYs\n);
goto err1;
}
- dwc3 = platform_device_alloc(dwc3, devid);
+ dwc3 = platform_device_alloc(dwc3, PLATFORM_DEVID_AUTO);
if (!dwc3) {
dev_err(pdev-dev, couldn't allocate dwc3 device\n);
- goto err2;
+ goto err1;
}
clk = clk_get(pdev-dev, usbdrd30);
@@ -170,8 +165,6 @@ err4:
clk_put(clk);
err3:
platform_device_put(dwc3);
-err2:
- dwc3_put_device_id(devid);
err1:
kfree(exynos);
err0:
@@ -187,8 +180,6 @@ static int __devexit dwc3_exynos_remove(struct
platform_device *pdev)
platform_device_unregister(exynos-usb2_phy);
platform_device_unregister(exynos-usb3_phy);
- dwc3_put_device_id(exynos-dwc3-id);
-
if (pdata pdata-phy_exit)
pdata-phy_exit(pdev, pdata-phy_type);
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index
RE: [PATCH 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
Hi Santosh, Kevin On Tue, Nov 06, 2012 at 03:22:16, Shilimkar, Santosh wrote: [...] + +/* + * This a subset of registers defined in drivers/memory/emif.h + * Move that to include/linux/? + */ I'd probably suggest just moving the register definitions you need into plat/emif_plat.h so they can be shared with the driver. Also, the EMIF stuff would benefit greatly from using symbolic defines for the values being written. Probably having those in plat/emif_plat.h would also help out here. Or, maybe the EMIF driver can provide some self-contained stubs that can be copied to OCP RAM for the functionality needed here? Santosh, what do you think of that? Thats what I mentioned in my comment. I also don't know why such a bad hardware choice was made when we have perfectly working EMIF IP across low power states. Even the self refresh control is managed inside hardware upon idle. My guess is DDR self-refresh might be the reason to use OCMC RAM. In either case, Keeping EMIF changes separate as part of EMIF driver/platform code is right way to go about it. May be the disable_selfrefresh() might need to kept in assembly files since it needs to be running from SRAM but rest need not be part of PM code. In the suspend path we do lot of I/O manipulations to lower final power number which must be done after the external memory has gone into self-refresh. So, these steps will have to be done from code in OCMC RAM. Other than saving the EMIF configuration the other thing that we do during suspend from assembly is to put the PLLs in bypass. We could possibly move the DISP PLL bypass to C code. MPU PLL is another candidate but this might add in more delays in the suspend and abort sequence (I don't have any delay numbers to justify this right now) The resume path undoes the I/O manipulations and then restores the EMIF configuration all of which I think is necessary before we can jump back to external memory. So, I think we'll have just the EMIF context save and possibly the PLL bypass for DISP PLL during suspend that we can move out of assembly. Coming to point of sharing the EMIF register definitions, with the recent changes to move around the header files out of plat-omap, is it ok to add in the required offsets and related bit-field definitions from the EMIF driver to plat-omap? 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: [PATCH 3/3] omap3 nand : use NAND_BUSWIDTH_AUTO
Cc: Tony Lindgren, Afzal Mohammed,
On 11/06/12 12:51, Matthieu CASTET wrote:
This allow to clean the omap nand driver that were trying in x8 and x16 bits
mode.
This also make work onfi detection on beagleboard :
Before :
[1.954803] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND
256MiB 1,8V 16-bit), page size: 2048, OOB size: 64
After :
[1.914825] ONFI param page 0 valid
[1.919158] ONFI flash detected
[1.922515] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron
MT29F2G16ABD), page size: 2048, OOB size: 64
platform data devsize is renamed bussize. It now indicate the maximun size of
the nand bus.
Signed-off-by: Matthieu CASTET matthieu.cas...@parrot.com
I think, you should base on one of Tony's branches with that kind of patches.
Because, for example the omap_nand_flash_init() function does not exist anymore
in Tony's master and may be several more things will need to have adjustments.
Also, the GPMC related stuff inside the NAND driver
should probably be coordinated with Afzal, as he is reworking the whole
GPMC related code.
---
arch/arm/mach-omap2/board-3630sdp.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-flash.c|8 ++---
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
arch/arm/mach-omap2/board-zoom.c |2 +-
arch/arm/mach-omap2/common-board-devices.c |2 +-
arch/arm/mach-omap2/gpmc-nand.c |5 ---
drivers/mtd/nand/omap2.c | 42
++
include/linux/platform_data/mtd-nand-omap2.h |7 -
13 files changed, 42 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3630sdp.c
b/arch/arm/mach-omap2/board-3630sdp.c
index fc224ad..d7b981b 100644
--- a/arch/arm/mach-omap2/board-3630sdp.c
+++ b/arch/arm/mach-omap2/board-3630sdp.c
@@ -198,7 +198,7 @@ static void __init omap_sdp_init(void)
h8mbx00u0mer0em_sdrc_params);
zoom_display_init();
board_smc91x_init();
- board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_BUSWIDTH_16);
+ board_flash_init(sdp_flash_partitions, chip_sel_sdp, NAND_OMAP_BUS_16);
enable_board_wakeup_source();
usbhs_init(usbhs_bdata);
}
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 1fd161e..b3487e1 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -621,7 +621,7 @@ static void __init devkit8000_init(void)
usb_musb_init(NULL);
usbhs_init(usbhs_bdata);
- omap_nand_flash_init(NAND_BUSWIDTH_16, devkit8000_nand_partitions,
+ omap_nand_flash_init(NAND_OMAP_BUS_16, devkit8000_nand_partitions,
ARRAY_SIZE(devkit8000_nand_partitions));
omap_twl4030_audio_init(omap3beagle);
diff --git a/arch/arm/mach-omap2/board-flash.c
b/arch/arm/mach-omap2/board-flash.c
index 0cabe61..488a1fa 100644
--- a/arch/arm/mach-omap2/board-flash.c
+++ b/arch/arm/mach-omap2/board-flash.c
@@ -133,12 +133,12 @@ static struct omap_nand_platform_data board_nand_data =
{
void
__init board_nand_init(struct mtd_partition *nand_parts,
- u8 nr_parts, u8 cs, int nand_type)
+ u8 nr_parts, u8 cs, int bus_type)
{
board_nand_data.cs = cs;
board_nand_data.parts = nand_parts;
board_nand_data.nr_parts= nr_parts;
- board_nand_data.devsize = nand_type;
+ board_nand_data.bussize = bus_type;
board_nand_data.ecc_opt = OMAP_ECC_HAMMING_CODE_DEFAULT;
gpmc_nand_init(board_nand_data);
@@ -185,7 +185,7 @@ unmap:
* @return - void.
*/
void __init board_flash_init(struct flash_partitions partition_info[],
- char chip_sel_board[][GPMC_CS_NUM], int nand_type)
+ char chip_sel_board[][GPMC_CS_NUM], int bus_type)
{
u8 cs = 0;
u8 norcs = GPMC_CS_NUM + 1;
@@ -238,5 +238,5 @@ void __init board_flash_init(struct flash_partitions
partition_info[],
pr_err(NAND: Unable to find configuration in GPMC\n);
else
board_nand_init(partition_info[2].parts,
- partition_info[2].nr_parts, nandcs, nand_type);
+ partition_info[2].nr_parts, nandcs, bus_type);
}
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 48d5e41..732f183 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -175,7 +175,7 @@ static void __init
Re: [PATCH 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
On Tuesday 06 November 2012 06:29 AM, Bedia, Vaibhav wrote: Hi Santosh, Kevin On Tue, Nov 06, 2012 at 03:22:16, Shilimkar, Santosh wrote: [...] + +/* + * This a subset of registers defined in drivers/memory/emif.h + * Move that to include/linux/? + */ I'd probably suggest just moving the register definitions you need into plat/emif_plat.h so they can be shared with the driver. Also, the EMIF stuff would benefit greatly from using symbolic defines for the values being written. Probably having those in plat/emif_plat.h would also help out here. Or, maybe the EMIF driver can provide some self-contained stubs that can be copied to OCP RAM for the functionality needed here? Santosh, what do you think of that? Thats what I mentioned in my comment. I also don't know why such a bad hardware choice was made when we have perfectly working EMIF IP across low power states. Even the self refresh control is managed inside hardware upon idle. My guess is DDR self-refresh might be the reason to use OCMC RAM. In either case, Keeping EMIF changes separate as part of EMIF driver/platform code is right way to go about it. May be the disable_selfrefresh() might need to kept in assembly files since it needs to be running from SRAM but rest need not be part of PM code. In the suspend path we do lot of I/O manipulations to lower final power number which must be done after the external memory has gone into self-refresh. So, these steps will have to be done from code in OCMC RAM. Only the DDR IO needs to be done after memory enters into self refresh. Rest of the IOs can be handled and moved to low power modes before DDR being in self refresh, No ? Other than saving the EMIF configuration the other thing that we do during suspend from assembly is to put the PLLs in bypass. We could possibly move the DISP PLL bypass to C code. MPU PLL is another candidate but this might add in more delays in the suspend and abort sequence (I don't have any delay numbers to justify this right now) So DPLLS doesn't support low power bypass mode which should take care of itself on clock gating ? Are the DPLL IPs different than what they are on OMAP ? The resume path undoes the I/O manipulations and then restores the EMIF configuration all of which I think is necessary before we can jump back to external memory. As I memtioned above, you should limit these IOs to only DDR IOs. So, I think we'll have just the EMIF context save and possibly the PLL bypass for DISP PLL during suspend that we can move out of assembly. EMIF context save also can be done in advance. Restore is what you need to take care in early resume before bringing out DDR out of self refresh. Coming to point of sharing the EMIF register definitions, with the recent changes to move around the header files out of plat-omap, is it ok to add in the required offsets and related bit-field definitions from the EMIF driver to plat-omap? We can have that in linux/include/* as well if the register defines can be shared. Regards Santosh -- 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 2/2] mailbox: split internal header from API header
On 11/06/2012 03:55 AM, Omar Ramirez Luna wrote:
Now internal structures can remain hidden to the user and just API
related functions and defines are made available.
Signed-off-by: Omar Ramirez Lunaomar.l...@linaro.org
---
drivers/mailbox/mailbox.c | 34
drivers/mailbox/mailbox.h | 48
+
include/linux/mailbox.h | 22 +++
I agree with the file split but I think mailbox framework API should be
more generic.
omap_ prefix should not be used. mailbox_ prefix will be better.
Message type must be more opened like for example:
struct mailbox_msg {
int size;
unsigned char header;
unsigned char *pdata;
};
Regards,
Loic--
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 15/15] ARM: OMAP2+: AM33XX: Basic suspend resume support
On Tue, Nov 06, 2012 at 18:08:36, Shilimkar, Santosh wrote: On Tuesday 06 November 2012 06:29 AM, Bedia, Vaibhav wrote: Hi Santosh, Kevin On Tue, Nov 06, 2012 at 03:22:16, Shilimkar, Santosh wrote: [...] + +/* + * This a subset of registers defined in drivers/memory/emif.h + * Move that to include/linux/? + */ I'd probably suggest just moving the register definitions you need into plat/emif_plat.h so they can be shared with the driver. Also, the EMIF stuff would benefit greatly from using symbolic defines for the values being written. Probably having those in plat/emif_plat.h would also help out here. Or, maybe the EMIF driver can provide some self-contained stubs that can be copied to OCP RAM for the functionality needed here? Santosh, what do you think of that? Thats what I mentioned in my comment. I also don't know why such a bad hardware choice was made when we have perfectly working EMIF IP across low power states. Even the self refresh control is managed inside hardware upon idle. My guess is DDR self-refresh might be the reason to use OCMC RAM. In either case, Keeping EMIF changes separate as part of EMIF driver/platform code is right way to go about it. May be the disable_selfrefresh() might need to kept in assembly files since it needs to be running from SRAM but rest need not be part of PM code. In the suspend path we do lot of I/O manipulations to lower final power number which must be done after the external memory has gone into self-refresh. So, these steps will have to be done from code in OCMC RAM. Only the DDR IO needs to be done after memory enters into self refresh. Rest of the IOs can be handled and moved to low power modes before DDR being in self refresh, No ? All the code is related to DDR IOs only. We have some code for changing the pull configuration of the DATA and CMD macros of the PHY and then some code for DDR VTP control. We also switch over the DDR IOs to mDDR mode to lower the leakage. Other than saving the EMIF configuration the other thing that we do during suspend from assembly is to put the PLLs in bypass. We could possibly move the DISP PLL bypass to C code. MPU PLL is another candidate but this might add in more delays in the suspend and abort sequence (I don't have any delay numbers to justify this right now) So DPLLS doesn't support low power bypass mode which should take care of itself on clock gating ? Are the DPLL IPs different than what they are on OMAP ? Same IP but no auto-mode :( The resume path undoes the I/O manipulations and then restores the EMIF configuration all of which I think is necessary before we can jump back to external memory. As I memtioned above, you should limit these IOs to only DDR IOs. So, I think we'll have just the EMIF context save and possibly the PLL bypass for DISP PLL during suspend that we can move out of assembly. EMIF context save also can be done in advance. Restore is what you need to take care in early resume before bringing out DDR out of self refresh. Yes I can move the context save earlier. Will try that out and put in the next version. Coming to point of sharing the EMIF register definitions, with the recent changes to move around the header files out of plat-omap, is it ok to add in the required offsets and related bit-field definitions from the EMIF driver to plat-omap? We can have that in linux/include/* as well if the register defines can be shared. Ok. 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: [PATCH 3/8] ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem
On Tue, Nov 06, 2012 at 15:39:11, Bedia, Vaibhav wrote:
On Mon, Nov 05, 2012 at 14:42:24, Philip, Avinash wrote:
[...]
+
+static struct omap_hwmod_ocp_if am33xx_epwmss0__ecap0 = {
+ .master = am33xx_epwmss0_hwmod,
+ .slave = am33xx_ecap0_hwmod,
+ .clk= l4ls_gclk,
+ .addr = am33xx_ecap0_addr_space,
+ .user = OCP_USER_MPU,
+};
Noticed this in another patch which is quite similar so commenting here
again. Is the user field required if you are just creating a parent-child
relationship here?
I think user field is not related to parent-child nodes, it defines the
initiator to interact with hwmod
Copy-pasted from arch/arm/plat-omap/include/plat/omap_hwmod.h
indicate the initiators that use this interface to interact with the
hwmod
And in this case, its MPU is the initiator to interact with this interface.
Thanks,
Vaibhav
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: [PATCH 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
On Tue, Nov 06, 2012 at 15:39:14, Bedia, Vaibhav wrote: On Tue, Nov 06, 2012 at 14:59:45, Hiremath, Vaibhav wrote: [...] Ok I checked this one. The change I made was indirectly fixing another issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two entries and the SYSC register is part of the second entry. The function _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with the flag ADDR_TYPE_RT flag. The change I made indirectly made the second entry in am33xx_cpgmac0_addr_space[] become the first memory space with the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct SYSC address of CPGMAC0 and the IP went to standby during bootup. After changing the order of the entries in am33xx_cpgmac0_addr_space[] things work fine. Good catch. Just a side note on this, driver expects the addresses in this order only, first SS and then WR. Sorry I didn't understand your comment. For HWMOD code to work as expected, we need to change the order. Why do you want to change the order? Just specify ADDR_TYPE_RT, that should be it. Thanks, 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: [PATCH 4/5] usb: musb: dsps: dt binding - add resources, example
On Fri, Nov 02, 2012 at 10:02:47PM +0530, Afzal Mohammed wrote:
OMAP2+ family of devices are now obtaining resources via DT, earlier
it was obtained from hwmod. Update binding document accrodingly, while
at it add example.
Signed-off-by: Afzal Mohammed af...@ti.com
---
.../devicetree/bindings/usb/am33xx-usb.txt | 21
+
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index a922505..6b7e3bd 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -1,5 +1,7 @@
AM33XX MUSB GLUE
- compatible : Should be ti,musb-am33xx
+ - reg : offset and length of register sets, first usbss, then for musb
instances
+ - interrupts : usbss, musb instance interrupts in order
- ti,hwmods : must be usb_otg_hs
- multipoint : Should be 1 indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
@@ -12,3 +14,22 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+Example:
+
+usb_otg_hs@4740 {
this should be usb@4740.
+ compatible = ti,musb-am33xx;
+ reg = 0x4740 0x1000/* usbss */
+0x47401000 0x800 /* musb instance 0 */
+0x47401800 0x800; /* musb instance 1 */
+ interrupts = 17/* usbss */
+ 18/* musb instance 0 */
+ 19; /* musb instance 1 */
+ multipoint = 1;
+ num-eps = 16;
+ ram-bits = 12;
+ port0-mode = 3;
+ port1-mode = 3;
+ power = 250;
+ ti,hwmods = usb_otg_hs;
+};
--
1.7.12
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 3/7] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio module
On 11/6/2012 3:39 PM, Bedia, Vaibhav wrote:
On Tue, Nov 06, 2012 at 13:42:21, N, Mugunthan V wrote:
[...]
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x4A101000,
+ .pa_end = 0x4A101000 + SZ_256 - 1,
+ .flags = ADDR_MAP_ON_INIT,
Based on the recent discussions and looking the hwmod code,
I guess ADDR_MAP_ON_INIT does not make sense here. Since you
are just creating a parent-child relationship here, maybe no
flag is needed?
Will remove this flag as it is a parrent-child relationship
+ },
+ { }
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+ .master = am33xx_cpgmac0_hwmod,
+ .slave = am33xx_mdio_hwmod,
+ .addr = am33xx_mdio_addr_space,
+ .user = OCP_USER_MPU,
Is this flag necessary? Shouldn't you just skip the
user field since there's nothing for the hwmod code
to do here?
This flag is necessary as MPU is going to access to device.
The patch will look like
@@ -2501,6 +2516,21 @@ static struct omap_hwmod_ocp_if
am33xx_l4_hs__cpgmac0 = {
.user = OCP_USER_MPU,
};
+struct omap_hwmod_addr_space am33xx_mdio_addr_space[] = {
+ {
+ .pa_start = 0x4A101000,
+ .pa_end = 0x4A101000 + SZ_256 - 1,
+ },
+ { }
+};
+
+struct omap_hwmod_ocp_if am33xx_cpgmac0__mdio = {
+ .master = am33xx_cpgmac0_hwmod,
+ .slave = am33xx_mdio_hwmod,
+ .addr = am33xx_mdio_addr_space,
+ .user = OCP_USER_MPU,
+};
+
static struct omap_hwmod_addr_space am33xx_elm_addr_space[] = {
{
.pa_start = 0x4808,
Regards
Mugunthan V N
--
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 12/12] OMAPDSS: DPI: always use DSI PLL if available
On 2012-11-05 16:21, Rob Clark wrote: On 11/05/2012 02:55 AM, Tomi Valkeinen wrote: But even then, choosing the manager is not easy, as whoever chooses the manager needs to observe all the possible displays used at the same time... Right. I was wondering if omapfb/omapdrm could understand the 'all possible displays information' better compared to a panel's probe. Even omapdrm/omafb can't be perfect because we could insert a panel driver module at any time, and omapfb/omapdrm may miss that out. True, omapdrm/fb may have a better idea. It's still unclear though. Currently we have quite strict order in the sequence the modules need to be loaded, which is quite bad and causes issues. We should make things more dynamic, so that the initialization of the drivers could happen more freely. But that creates more problems: when booting up, omapfb starts. But omapfb can't know if all the panel drivers have already been loaded. omapfb may see that DVI is the default display, but what should it do if DVI doesn't have a driver yet? It could wait, but perhaps the driver for DVI will never even be loaded. The encoder which is connected to the crtc (manager) is picked by combination of encoder-possible_crtcs bitmask and connector-best_encoder(). We could keep things limited so that the association of crtc to encoder (manager to output, roughly) never changes, but this isn't really the right thing to do. It is better that the dssdev not rely on knowing the manager it is attached to at probe time, but instead grab resources more dynamically. Also, at the moment we don't really have any notification to userspace about new encoders/connectors showing up (or conversely, being removed). Only about existing connectors being plugged/unplugged. The closest analogy is perhaps the USB display devices, but even there it is only the entire drm device that is plugged/unplugged. And TBH I don't really see the point in supporting panel drivers being dynamically loaded. It isn't like someone is dynamically soldering on a new display connector to some board that is running. I think omapfb or omapdrm probe should trigger registering the compiled-in panel drivers, so that it can be sure that the dssdev's pop up before it goes and creates drm connector objects. Currently we have to hack around this in omapdrm with late_initcall() to ensure the panel drivers are probed first, but that is an ugly hack that I'd like to get rid of. We have panel devices and panel drivers, each of which can appear at any time. Both are needed for the panel probe to happen. If we don't support device hotplugging (dynamic creation of devices), we need to use late_initcall for omapfb/drm. At least I don't see any other option. You say that omapdrm should trigger registering of the drivers. How would that work? Do you mean that the panel drivers would register themselves to some common list, and omapdrm would go through this list when drm is loaded, calling probe for the items in the list? I guess that's doable, but... It's not how kernel drivers are supposed to work, and so doesn't sound very clean approach to me. I think we should support proper hotplugging of the panels. This would fix the problem about init order, but it would also give us device hotplug support. Obviously nobody is going to solder panel to a running board, but I don't see any reason why panels, or, more likely, panels on an add-on boards (like the capes being discussed in omap ml) would not be hotpluggable using whatever connector is used on the particular use case. And even if we don't support removing of the devices, things like the add-on capes could cause the panel on the cape to be identified at some late time (the panel is not described in the board file or DT data, but found at runtime depending on the ID of the cape). This would add another step to the init sequence that should be just right, if we don't support hotplug. Yes, I know it's not simple =). And I'm fine with simpler approach for the time being, but I'd like full hotplug to be the future goal. At least the common panel framework should not create restrictions about this, even if drm wouldn't allow device hotplug. Tomi -- 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 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
On Tue, Nov 06, 2012 at 18:38:08, Hiremath, Vaibhav wrote: On Tue, Nov 06, 2012 at 15:39:14, Bedia, Vaibhav wrote: On Tue, Nov 06, 2012 at 14:59:45, Hiremath, Vaibhav wrote: [...] Ok I checked this one. The change I made was indirectly fixing another issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two entries and the SYSC register is part of the second entry. The function _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with the flag ADDR_TYPE_RT flag. The change I made indirectly made the second entry in am33xx_cpgmac0_addr_space[] become the first memory space with the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct SYSC address of CPGMAC0 and the IP went to standby during bootup. After changing the order of the entries in am33xx_cpgmac0_addr_space[] things work fine. Good catch. Just a side note on this, driver expects the addresses in this order only, first SS and then WR. Sorry I didn't understand your comment. For HWMOD code to work as expected, we need to change the order. Why do you want to change the order? Just specify ADDR_TYPE_RT, that should be it. The problem is that the memory space without the SYSC comes first and is labeled as ADDR_TYPE_RT. I think this is not correct and hence either we change the order or remove the flag from the first entry. If we do the latter then taking the logic of putting in the flag only for memory spaces with SYSC further we need to fixup the entries for ephrpwm0/1/2 and ecap0/1/2. 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
[PATCH RESEND 02/10] ARM: dts: AM33XX: Add matrix keypad device tree data to am335x-evm
Add matrix keypad device tree data to am335x-evm by adding all
the necessary parameters like keymap, row column gpios and etc.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 9199456..8076e66 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -110,6 +110,26 @@
regulator-name = lis3_reg;
regulator-boot-on;
};
+
+ matrix_keypad: matrix_keypad@0 {
+ compatible = gpio-matrix-keypad;
+ debounce-delay-ms = 5;
+ col-scan-delay-us = 2;
+
+ row-gpios = gpio2 25 0/* Bank1, pin25 */
+gpio2 26 0/* Bank1, pin26 */
+gpio2 27 0; /* Bank1, pin27 */
+
+ col-gpios = gpio2 21 0/* Bank1, pin21 */
+gpio2 22 0; /* Bank1, pin22 */
+
+ linux,keymap = 0x008b /* MENU */
+ 0x019e /* BACK */
+ 0x0269 /* LEFT */
+ 0x0001006a /* RIGHT */
+ 0x0101001c /* ENTER */
+ 0x0201006c;/* DOWN */
+ };
};
/include/ tps65910.dtsi
--
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 RESEND 06/10] ARM: dts: AM33XX: Add user-leds device tree data to am335x-bone
Add gpio-leds device tree data to am335x-bone device to enable gpio
based user-leds (USR0, USR1, USR2 and USR3) present on BeagleBone.
[k...@dominion.thruhere.net: led0, led1 suggested by koen]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 1aac58b..2c33888 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -53,6 +53,36 @@
};
};
+
+ leds {
+ compatible = gpio-leds;
+
+ led@2 {
+ label = beaglebone:green:heartbeat;
+ gpios = gpio2 21 0;
+ linux,default-trigger = heartbeat;
+ default-state = off;
+ };
+
+ led@3 {
+ label = beaglebone:green:mmc0;
+ gpios = gpio2 22 0;
+ linux,default-trigger = mmc0;
+ default-state = off;
+ };
+
+ led@4 {
+ label = beaglebone:green:usr2;
+ gpios = gpio2 23 0;
+ default-state = off;
+ };
+
+ led@5 {
+ label = beaglebone:green:usr3;
+ gpios = gpio2 24 0;
+ default-state = off;
+ };
+ };
};
/include/ tps65217.dtsi
--
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 RESEND 09/10] ARM: dts: AM33XX: Add pinmux configuration for gpio-keys to EVMSK
Add pinmux configurations for gpio based keys to am335x-evmsk. In
this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 7262fa8..0f825dd 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -32,7 +32,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = user_leds_s0;
+ pinctrl-0 = user_leds_s0 gpio_keys_s0;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins =
@@ -42,6 +42,15 @@
0x1c 0x7/* gpmc_ad7.gpio1_7, OUTPUT |
MODE7 */
;
};
+
+ gpio_keys_s0: gpio_keys_s0 {
+ pinctrl-single,pins =
+ 0x94 0x27 /* gpmc_oen_ren.gpio2_3, INPUT
| MODE7 */
+ 0x90 0x27 /* gpmc_advn_ale.gpio2_2, INPUT
| MODE7 */
+ 0x70 0x27 /* gpmc_wait0.gpio0_30, INPUT |
MODE7 */
+ 0x9c 0x27 /* gpmc_ben0_cle.gpio2_5, INPUT
| MODE7 */
+ ;
+ };
};
ocp {
--
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 RESEND 00/10] ARM: dts: AM33XX: Add device tree data
Add device tree date for GPIO based various drivers matrix keypad, volume keys, push buttons and use leds accross three AM33XX devices viz EVM, BeagleBone and Starter Kit. To make it functional this series also adds pinctrl data for all the GPIOs used by various drivers. In this series only default state pinmux/conf settings are added because of sleep/idle state pinctrl values are not available. These patches are based on linux-omap-dt:for_3.8/dts_part2 tree and these were tested on am33xx devices according to added functionality. Change log: - Rebased on for_3.8/dts_part2 AnilKumar Ch (10): ARM: dts: AM33XX: Add pinmux configuration for matrix keypad to EVM ARM: dts: AM33XX: Add matrix keypad device tree data to am335x-evm ARM: dts: AM33XX: Add pinmux configuration for volume-keys to EVM ARM: dts: AM33XX: Add volume-keys device tree data to am335x-evm ARM: dts: AM33XX: Add pinmux configuration for user-leds to BONE ARM: dts: AM33XX: Add user-leds device tree data to am335x-bone ARM: dts: AM33XX: Add pinmux configuration for gpio-leds to EVMSK ARM: dts: AM33XX: Add user-leds device tree data to am335x-evmsk ARM: dts: AM33XX: Add pinmux configuration for gpio-keys to EVMSK ARM: dts: AM33XX: Add push-buttons device tree data to am335x-evmsk arch/arm/boot/dts/am335x-bone.dts | 44 +++ arch/arm/boot/dts/am335x-evm.dts | 63 +++ arch/arm/boot/dts/am335x-evmsk.dts | 84 3 files changed, 191 insertions(+) -- 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 RESEND 04/10] ARM: dts: AM33XX: Add volume-keys device tree data to am335x-evm
Add gpio based volume keys device tree data to am335x-evm by adding
all the required parameters like keycode, gpios and etc.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e087b87..9f65f17 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -137,6 +137,27 @@
0x0101001c /* ENTER */
0x0201006c;/* DOWN */
};
+
+ gpio_keys: volume_keys@0 {
+ compatible = gpio-keys;
+ #address-cells = 1;
+ #size-cells = 0;
+ autorepeat;
+
+ switch@9 {
+ label = volume-up;
+ linux,code = 115;
+ gpios = gpio1 2 1;
+ gpio-key,wakeup;
+ };
+
+ switch@10 {
+ label = volume-down;
+ linux,code = 114;
+ gpios = gpio1 3 1;
+ gpio-key,wakeup;
+ };
+ };
};
/include/ tps65910.dtsi
--
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 RESEND 01/10] ARM: dts: AM33XX: Add pinmux configuration for matrix keypad to EVM
Add pinmux configurations for gpio matrix keypad. In this patch, only
single named mode/state is added and these pins are configured during
pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 513284f..9199456 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -24,6 +24,21 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am33xx_pinmux: pinmux@44e10800 {
+ pinctrl-names = default;
+ pinctrl-0 = matrix_keypad_s0;
+
+ matrix_keypad_s0: matrix_keypad_s0 {
+ pinctrl-single,pins =
+ 0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
MODE7 */
+ 0x58 0x7/* gpmc_a6.gpio1_22, OUTPUT |
MODE7 */
+ 0x64 0x27 /* gpmc_a9.gpio1_25, INPUT |
MODE7 */
+ 0x68 0x27 /* gpmc_a10.gpio1_26, INPUT |
MODE7 */
+ 0x6c 0x27 /* gpmc_a11.gpio1_27, INPUT |
MODE7 */
+ ;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = okay;
--
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 RESEND 03/10] ARM: dts: AM33XX: Add pinmux configuration for volume-keys to EVM
Add pinmux configurations for gpio volume keys. In this patch, only
single named mode/state is added and these pins are configured during
pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 8076e66..e087b87 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -26,7 +26,7 @@
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default;
- pinctrl-0 = matrix_keypad_s0;
+ pinctrl-0 = matrix_keypad_s0 volume_keys_s0;
matrix_keypad_s0: matrix_keypad_s0 {
pinctrl-single,pins =
@@ -37,6 +37,13 @@
0x6c 0x27 /* gpmc_a11.gpio1_27, INPUT |
MODE7 */
;
};
+
+ volume_keys_s0: volume_keys_s0 {
+ pinctrl-single,pins =
+ 0x150 0x27 /* spi0_sclk.gpio0_2, INPUT |
MODE7 */
+ 0x154 0x27 /* spi0_d0.gpio0_3, INPUT |
MODE7 */
+ ;
+ };
};
ocp {
--
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 RESEND 10/10] ARM: dts: AM33XX: Add push-buttons device tree data to am335x-evmsk
Add gpio based push buttons device tree data to am335x-evmsk device
by adding all the necessary parameters like key-code, gpios and etc.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 0f825dd..f5a6162 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -139,6 +139,37 @@
default-state = off;
};
};
+
+ gpio_buttons: gpio_buttons@0 {
+ compatible = gpio-keys;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ switch@1 {
+ label = button0;
+ linux,code = 0x100;
+ gpios = gpio3 3 0;
+ };
+
+ switch@2 {
+ label = button1;
+ linux,code = 0x101;
+ gpios = gpio3 2 0;
+ };
+
+ switch@3 {
+ label = button2;
+ linux,code = 0x102;
+ gpios = gpio1 30 0;
+ gpio-key,wakeup;
+ };
+
+ switch@4 {
+ label = button3;
+ linux,code = 0x103;
+ gpios = gpio3 5 0;
+ };
+ };
};
/include/ tps65910.dtsi
--
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 RESEND 07/10] ARM: dts: AM33XX: Add pinmux configuration for gpio-leds to EVMSK
Add pinmux configurations for gpio based volume keys to am335x-evmsk.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 6f53879..659ec5b 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -30,6 +30,20 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am33xx_pinmux: pinmux@44e10800 {
+ pinctrl-names = default;
+ pinctrl-0 = user_leds_s0;
+
+ user_leds_s0: user_leds_s0 {
+ pinctrl-single,pins =
+ 0x10 0x7/* gpmc_ad4.gpio1_4, OUTPUT |
MODE7 */
+ 0x14 0x7/* gpmc_ad5.gpio1_5, OUTPUT |
MODE7 */
+ 0x18 0x7/* gpmc_ad6.gpio1_6, OUTPUT |
MODE7 */
+ 0x1c 0x7/* gpmc_ad7.gpio1_7, OUTPUT |
MODE7 */
+ ;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = okay;
--
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 RESEND 05/10] ARM: dts: AM33XX: Add pinmux configuration for user-leds to BONE
Add pinmux configurations for gpio based user-keys to am335x-bone.
In this patch, only single named mode/state is added and these pins
are configured during pinctrl driver initialization.
Default mode is nothing but the values required for the module during
active state. With this configurations module is functional as
expected.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 91eee97..1aac58b 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -24,6 +24,20 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am33xx_pinmux: pinmux@44e10800 {
+ pinctrl-names = default;
+ pinctrl-0 = user_leds_s0;
+
+ user_leds_s0: user_leds_s0 {
+ pinctrl-single,pins =
+ 0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT |
MODE7 */
+ 0x58 0x17 /* gpmc_a6.gpio1_22,
OUTPUT_PULLUP | MODE7 */
+ 0x5c 0x7/* gpmc_a7.gpio1_23, OUTPUT |
MODE7 */
+ 0x60 0x17 /* gpmc_a8.gpio1_24,
OUTPUT_PULLUP | MODE7 */
+ ;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = okay;
--
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 RESEND 08/10] ARM: dts: AM33XX: Add user-leds device tree data to am335x-evmsk
Add gpio-leds device tree data to am335x-evmsk device to enable gpio
based user-leds (USR0, USR1, USR2 and USR3) present on am335x starter
kit.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-evmsk.dts | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 659ec5b..7262fa8 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -100,6 +100,36 @@
regulator-name = lis3_reg;
regulator-boot-on;
};
+
+ leds {
+ compatible = gpio-leds;
+
+ led@1 {
+ label = evmsk:green:usr0;
+ gpios = gpio2 4 0;
+ default-state = off;
+ };
+
+ led@2 {
+ label = evmsk:green:usr1;
+ gpios = gpio2 5 0;
+ default-state = off;
+ };
+
+ led@3 {
+ label = evmsk:green:mmc0;
+ gpios = gpio2 6 0;
+ linux,default-trigger = mmc0;
+ default-state = off;
+ };
+
+ led@4 {
+ label = evmsk:green:heartbeat;
+ gpios = gpio2 7 0;
+ linux,default-trigger = heartbeat;
+ default-state = off;
+ };
+ };
};
/include/ tps65910.dtsi
--
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 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
Hi Vaibhav Vaibhav, On 11/06/2012 02:46 PM, Bedia, Vaibhav wrote: On Tue, Nov 06, 2012 at 18:38:08, Hiremath, Vaibhav wrote: On Tue, Nov 06, 2012 at 15:39:14, Bedia, Vaibhav wrote: On Tue, Nov 06, 2012 at 14:59:45, Hiremath, Vaibhav wrote: [...] Ok I checked this one. The change I made was indirectly fixing another issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two entries and the SYSC register is part of the second entry. The function _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with the flag ADDR_TYPE_RT flag. The change I made indirectly made the second entry in am33xx_cpgmac0_addr_space[] become the first memory space with the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct SYSC address of CPGMAC0 and the IP went to standby during bootup. After changing the order of the entries in am33xx_cpgmac0_addr_space[] things work fine. Good catch. Just a side note on this, driver expects the addresses in this order only, first SS and then WR. Sorry I didn't understand your comment. For HWMOD code to work as expected, we need to change the order. Why do you want to change the order? Just specify ADDR_TYPE_RT, that should be it. The problem is that the memory space without the SYSC comes first and is labeled as ADDR_TYPE_RT. I think this is not correct and hence either we change the order or remove the flag from the first entry. If we do the latter then taking the logic of putting in the flag only for memory spaces with SYSC further we need to fixup the entries for ephrpwm0/1/2 and ecap0/1/2. The order should not matter, just use ADDR_TYPE_RT for the relevant entry. I have a patch ongoing to remove this flag for the non-SYSC entry to avoid this kind of confusion. The name should probably be changed as well to reflect that at some point. Since these entries will be removed anyway with pure DT boot, that should be a temporary issue. Regards, Benoit -- 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/3] capebus moving omap_devices to mach-omap2
Από το iPhone μου 6 Νοε 2012, 12:16, ο/η Grant Likely grant.lik...@secretlab.ca έγραψε: On Tue, Nov 6, 2012 at 8:14 AM, Pantelis Antoniou pa...@antoniou-consulting.com wrote: On Nov 6, 2012, at 4:06 AM, Joel A Fernandes wrote: Sure, so if we add data type supplementary properties to the tree to indicate the data type as indirect phandle, then kernel could refer to the index in the got-like table to fetch the actual phandle address (1-level of indirection), instead of directly using the address in the data field. I'm fine with this. But if the data about phandles is already in the tree, then the need for a GOT simply goes away. The phandles can be fixed up directly and it is so much better because it works with existing parsing code after the merge is applied. Either way works. It is your call after all. I agree that your method is simpler. g. Regards -- Pantelis-- 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] usb: musb: dsps: dt binding - add resources, example
OMAP2+ family of devices are now obtaining resources via DT, earlier
it was obtained from hwmod. Update binding document accrodingly, while
at it add example.
Signed-off-by: Afzal Mohammed af...@ti.com
---
v2: node name changed to usb
.../devicetree/bindings/usb/am33xx-usb.txt | 21 +
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index a922505..ea840f7 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -1,5 +1,7 @@
AM33XX MUSB GLUE
- compatible : Should be ti,musb-am33xx
+ - reg : offset and length of register sets, first usbss, then for musb
instances
+ - interrupts : usbss, musb instance interrupts in order
- ti,hwmods : must be usb_otg_hs
- multipoint : Should be 1 indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
@@ -12,3 +14,22 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+Example:
+
+usb@4740 {
+ compatible = ti,musb-am33xx;
+ reg = 0x4740 0x1000/* usbss */
+ 0x47401000 0x800 /* musb instance 0 */
+ 0x47401800 0x800; /* musb instance 1 */
+ interrupts = 17/* usbss */
+ 18/* musb instance 0 */
+ 19; /* musb instance 1 */
+ multipoint = 1;
+ num-eps = 16;
+ ram-bits = 12;
+ port0-mode = 3;
+ port1-mode = 3;
+ power = 250;
+ ti,hwmods = usb_otg_hs;
+};
--
1.7.12
--
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 08/15] ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
Hi Benoit, On Tue, Nov 06, 2012 at 19:20:46, Cousson, Benoit wrote: Hi Vaibhav Vaibhav, On 11/06/2012 02:46 PM, Bedia, Vaibhav wrote: On Tue, Nov 06, 2012 at 18:38:08, Hiremath, Vaibhav wrote: On Tue, Nov 06, 2012 at 15:39:14, Bedia, Vaibhav wrote: On Tue, Nov 06, 2012 at 14:59:45, Hiremath, Vaibhav wrote: [...] Ok I checked this one. The change I made was indirectly fixing another issue with the AM33xx hwmod data. am33xx_cpgmac0_addr_space[] has two entries and the SYSC register is part of the second entry. The function _find_mpu_rt_addr_space in omap_hwmod.c looks for the first entry with the flag ADDR_TYPE_RT flag. The change I made indirectly made the second entry in am33xx_cpgmac0_addr_space[] become the first memory space with the ADDR_TYPE_RT flag. Due to this the hwmod code wrote to the correct SYSC address of CPGMAC0 and the IP went to standby during bootup. After changing the order of the entries in am33xx_cpgmac0_addr_space[] things work fine. Good catch. Just a side note on this, driver expects the addresses in this order only, first SS and then WR. Sorry I didn't understand your comment. For HWMOD code to work as expected, we need to change the order. Why do you want to change the order? Just specify ADDR_TYPE_RT, that should be it. The problem is that the memory space without the SYSC comes first and is labeled as ADDR_TYPE_RT. I think this is not correct and hence either we change the order or remove the flag from the first entry. If we do the latter then taking the logic of putting in the flag only for memory spaces with SYSC further we need to fixup the entries for ephrpwm0/1/2 and ecap0/1/2. The order should not matter, just use ADDR_TYPE_RT for the relevant entry. I have a patch ongoing to remove this flag for the non-SYSC entry to avoid this kind of confusion. The name should probably be changed as well to reflect that at some point. Since these entries will be removed anyway with pure DT boot, that should be a temporary issue. Thanks for the clarification. I'll make the change accordingly. 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
[PATCH v2] ARM: dts: AM33XX: Add usbss node
From: Ajay Kumar Gupta ajay.gu...@ti.com
Device tree node for usbss on AM33XX. There are two musb
controllers on am33xx platform so have port0-mode and
port1-mode data.
[af...@ti.com: reg interrupt property addition]
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
---
v2: node named as usb
Depends on usb: musb: dsps: dt binding - add resources, example
(https://patchwork.kernel.org/patch/1704691/)
arch/arm/boot/dts/am33xx.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 5dfd682..20a3f29 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -321,5 +321,22 @@
ti,hwmods = spi1;
status = disabled;
};
+
+ usb@4740 {
+ compatible = ti,musb-am33xx;
+ reg = 0x4740 0x1000/* usbss */
+ 0x47401000 0x800 /* musb instance 0 */
+ 0x47401800 0x800; /* musb instance 1 */
+ interrupts = 17/* usbss */
+ 18/* musb instance 0 */
+ 19; /* musb instance 1 */
+ multipoint = 1;
+ num-eps = 16;
+ ram-bits = 12;
+ port0-mode = 3;
+ port1-mode = 3;
+ power = 250;
+ ti,hwmods = usb_otg_hs;
+ };
};
};
--
1.7.12
--
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 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX
Hi Kevin, On Mon, Nov 05, 2012 at 23:33:07, Kevin Hilman wrote: Bedia, Vaibhav vaibhav.be...@ti.com writes: On Sat, Nov 03, 2012 at 18:34:30, Kevin Hilman wrote: [...] Doesn't this also mean that you won't get timer wakeups in idle? Or are you keeping the domain where the clockevent is on during idle? The lowest idle state that we are targeting will have MPU powered off with external memory in self-refresh mode. Peripheral domain with the clockevent will be kept on. Is this a limitation of the hardware? or the software? Well, making the lowest idle state same as the suspend state will require us to involve WKUP_M3 in the idle path and wakeup sources get limited to the IPs in the WKUP domain alone. There's no IO daisy chaining in AM33XX so that's one big difference compared to OMAP. The other potential problem is that the IPC mechanism that we have uses interrupts. It can still interrupt the M3, it's only the interrupt back to the MPU that is the issue, right? That being said, there's no reason it couldn't use polling in the idle path, right? Yes we could use polling but I think we have a bigger problem in the chip architecture. Assuming that the lowest idle state, say Cx, is the same as the suspend state, we'll need to communicate with the WKUP_M3 using interrupts once we decide to enter Cx. I am not sure if we can do something in the cpuidle implementation to work around the interrupt for idle problem. We could probably not wait for an ACK when we want to enter Cx, why not? Are the response times from the M3 really up to 500ms (guessing based on the timeout you used in the suspend path.) That seems rather unlikely. No 500ms is too high. Actual delays would be much lower, I need to check with the design team on the expected number. Hmm, but as I think about it. Why does the MPU need to wait for an ACK at all? Why not just send the cmd and WFI? I have myself being going back and forth on this. There are lot of things that we do in software, DDR being one of them. We can't do some of the DDR related stuff unless memory enter self-refresh AND EMIF gets disabled. Doing so essentially means that the drivers have entered sort of suspend state. Given this h/w limitation I don't see how we could handle without impacting a running system. but the problem of limited wakeup sources remains. If we let the various drivers block the entry to Cx, since almost all the IPs are in the peripheral domain a system which uses anything other than UART and Timer in WKUP domain will probably never be able enter Cx. Even so, I think the system needs to be designed to hit the same power states in idle and suspend. Then, the states can be restricted based wakeup capabilities as you described. This would be easy to do in the runtime PM implementation for this device. IMO, assuming that idle will not be useful from the begining is leading down the path to poor design choices that will be much more difficult to fixup down the road in order to add idle support later. We need to design both idle and suspend at the same time. Getting PER to transition on a running system is something I can't figure out. Maybe MPU OFF is the lowest we can go. Also, don't forget about GPIO0. Systems could easily be built such that peripherals which want to wakeup but don't have native wakeup capabilities could use a GPIO in bank 0 to wake the system. Similarily, I2C0 is in WKUP, and brought out to capes, so some simple designs with with I2C devices on a cape might be perfectly capable of hitting deep power states in idle. Ok this is interesting. AFAIK I2C wakeup requires the device to be operating in slave mode. If so, is this something that's already supported on OMAP? 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: [PATCH v2] ARM: dts: AM33XX: Add usbss node
Hi,
On Tue, Nov 06, 2012 at 07:59:38PM +0530, Afzal Mohammed wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
Device tree node for usbss on AM33XX. There are two musb
controllers on am33xx platform so have port0-mode and
port1-mode data.
[af...@ti.com: reg interrupt property addition]
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
to my eyes, this looks ok.
Reviewed-by: Felipe Balbi ba...@ti.com
---
v2: node named as usb
Depends on usb: musb: dsps: dt binding - add resources, example
(https://patchwork.kernel.org/patch/1704691/)
arch/arm/boot/dts/am33xx.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 5dfd682..20a3f29 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -321,5 +321,22 @@
ti,hwmods = spi1;
status = disabled;
};
+
+ usb@4740 {
+ compatible = ti,musb-am33xx;
+ reg = 0x4740 0x1000/* usbss */
+0x47401000 0x800 /* musb instance 0 */
+0x47401800 0x800; /* musb instance 1 */
+ interrupts = 17/* usbss */
+ 18/* musb instance 0 */
+ 19; /* musb instance 1 */
+ multipoint = 1;
+ num-eps = 16;
+ ram-bits = 12;
+ port0-mode = 3;
+ port1-mode = 3;
+ power = 250;
+ ti,hwmods = usb_otg_hs;
+ };
};
};
--
1.7.12
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 4/5] usb: musb: dsps: dt binding - add resources, example
Hi Balbi,
On Tuesday 06 November 2012 06:32 PM, Felipe Balbi wrote:
On Fri, Nov 02, 2012 at 10:02:47PM +0530, Afzal Mohammed wrote:
+Example:
+
+usb_otg_hs@4740 {
this should be usb@4740.
Updated version with the above change has been posted.
Regards
Afzal
--
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 11/15] ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX
Hi Santosh, On Tue, Nov 06, 2012 at 03:29:22, Shilimkar, Santosh wrote: [...] IMO, assuming that idle will not be useful from the begining is leading down the path to poor design choices that will be much more difficult to fixup down the road in order to add idle support later. We need to design both idle and suspend at the same time. I agree with Kevin. Not supporting CPUIDLE deep states can hit the active power numbers dearly. I just don't know why the SOCs don't share the standard and must have design choices. But thats another discussion. Yes, active power numbers are not comparable to OMAP :( How about leaving the timer choices as is. PER timer for clock source and wakeuptimer for clock event. Anyway in suspend the clock-source can be suspended and that is evident from recent discussion. The only downside is you won't count time in suspend which is any way the case. Vaibhav, Do you guys see any implementation bottleneck for above ? Looking at the timekeeping code I see one more potential reason for making this change. OMAP registers the 32k sync timer as the persistent clock and since there's no 32k sync timer in AM33xx it doesn't register a persistent clock right now. Based on what I understood, we need to have to register one and DMTimer1 is the only clock that can serve as the persistent clock in suspend state. When we do so we might as well use it as the clocksource. A related question that I had was, is there a mechanism to handle the 32k counter (DMTimer or sync timer) wraparound condition in suspend? 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: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available
On Tue, Nov 6, 2012 at 7:41 AM, Tomi Valkeinen to...@iki.fi wrote: On 2012-11-05 16:21, Rob Clark wrote: On 11/05/2012 02:55 AM, Tomi Valkeinen wrote: But even then, choosing the manager is not easy, as whoever chooses the manager needs to observe all the possible displays used at the same time... Right. I was wondering if omapfb/omapdrm could understand the 'all possible displays information' better compared to a panel's probe. Even omapdrm/omafb can't be perfect because we could insert a panel driver module at any time, and omapfb/omapdrm may miss that out. True, omapdrm/fb may have a better idea. It's still unclear though. Currently we have quite strict order in the sequence the modules need to be loaded, which is quite bad and causes issues. We should make things more dynamic, so that the initialization of the drivers could happen more freely. But that creates more problems: when booting up, omapfb starts. But omapfb can't know if all the panel drivers have already been loaded. omapfb may see that DVI is the default display, but what should it do if DVI doesn't have a driver yet? It could wait, but perhaps the driver for DVI will never even be loaded. The encoder which is connected to the crtc (manager) is picked by combination of encoder-possible_crtcs bitmask and connector-best_encoder(). We could keep things limited so that the association of crtc to encoder (manager to output, roughly) never changes, but this isn't really the right thing to do. It is better that the dssdev not rely on knowing the manager it is attached to at probe time, but instead grab resources more dynamically. Also, at the moment we don't really have any notification to userspace about new encoders/connectors showing up (or conversely, being removed). Only about existing connectors being plugged/unplugged. The closest analogy is perhaps the USB display devices, but even there it is only the entire drm device that is plugged/unplugged. And TBH I don't really see the point in supporting panel drivers being dynamically loaded. It isn't like someone is dynamically soldering on a new display connector to some board that is running. I think omapfb or omapdrm probe should trigger registering the compiled-in panel drivers, so that it can be sure that the dssdev's pop up before it goes and creates drm connector objects. Currently we have to hack around this in omapdrm with late_initcall() to ensure the panel drivers are probed first, but that is an ugly hack that I'd like to get rid of. We have panel devices and panel drivers, each of which can appear at any time. Both are needed for the panel probe to happen. If we don't support device hotplugging (dynamic creation of devices), we need to use late_initcall for omapfb/drm. At least I don't see any other option. You say that omapdrm should trigger registering of the drivers. How would that work? Do you mean that the panel drivers would register themselves to some common list, and omapdrm would go through this list when drm is loaded, calling probe for the items in the list? I guess that's doable, but... It's not how kernel drivers are supposed to work, and so doesn't sound very clean approach to me. I mean, similar to how we handle the subdev for dmm.. the omap_drm_init() does the platform_driver_register() for the dmm device before the platform_driver_register() for omapdrm itself, so we know if there is a dmm device, the driver gets probed first before omapdrm. It could be a matter of iterating through a list, or something like this.. that is basically an implementation detail. But the end result is that the order the drivers are registered is controlled so the probe sequence works out properly (not to mention suspend/resume sequence). I think we should support proper hotplugging of the panels. This would fix the problem about init order, but it would also give us device hotplug support. Obviously nobody is going to solder panel to a running board, but I don't see any reason why panels, or, more likely, panels on an add-on boards (like the capes being discussed in omap ml) would not be hotpluggable using whatever connector is used on the particular use case. And even if we don't support removing of the devices, things like the add-on capes could cause the panel on the cape to be identified at some late time (the panel is not described in the board file or DT data, but found at runtime depending on the ID of the cape). This would add another step to the init sequence that should be just right, if we don't support hotplug. If capes are really hot-pluggable, then maybe it is worth thinking about how to make this more dynamic. Although it is a bigger problem, which involves userspace being aware that connectors can dynamically appear/disappear. And the dynamic disappearing is something I worry about more.. it adds the possibility of all sorts of interesting race conditions, such as connectors
Re: [PATCH RESEND 00/10] ARM: dts: AM33XX: Add device tree data
Hi Anil, On 11/06/2012 02:48 PM, AnilKumar Ch wrote: Add device tree date for GPIO based various drivers matrix keypad, volume keys, push buttons and use leds accross three AM33XX devices viz EVM, BeagleBone and Starter Kit. To make it functional this series also adds pinctrl data for all the GPIOs used by various drivers. In this series only default state pinmux/conf settings are added because of sleep/idle state pinctrl values are not available. These patches are based on linux-omap-dt:for_3.8/dts_part2 tree and these were tested on am33xx devices according to added functionality. Change log: - Rebased on for_3.8/dts_part2 Thanks for the update. Applied in for_3.8/dts_part2. BTW, I've just noticed that am335x-evmsk is not built with make dtbs. The target was missing from the arch/arm/boot/dts/Makefile. Please find below the patch to add it. Thanks, Benoit --- From 6990451aca80a5107206688308302241f799057a Mon Sep 17 00:00:00 2001 From: Benoit Cousson b-cous...@ti.com Date: Tue, 6 Nov 2012 15:52:23 +0100 Subject: [PATCH] ARM: dts: Makefile: Add the am335x-evmsk target in dtbs list The EVMSK was not built with the 'make dtbs' command. Add the missing antry in the dts Makefile. Signed-off-by: Benoit Cousson b-cous...@ti.com --- arch/arm/boot/dts/Makefile |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 634bd42..2458b69 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -73,6 +73,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \ omap4-sdp.dtb \ omap5-evm.dtb \ am335x-evm.dtb \ + am335x-evmsk.dtb \ am335x-bone.dtb dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb dtb-$(CONFIG_ARCH_U8500) += snowball.dtb -- 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
[PATCH/RESEND 0/2] usb: musb: am335x support part-2
Hi Balbi, This is a resend of remaining changes to get am335x usb working. These were sent on 31 Oct with subject, usb: musb: dsps: fixes for -rc. First one restores capability to support at least one instance of musb. Without it, even a single instance can't be supported as change which is reverted by it was made along with multi phy changes and nop transciever dt support, both other changes didn't make it to mainline. Second one corrects binding document; changes were made in driver as per review comments, but documentation was not updated. This is made on top of your musb branch. To get USB0 functional on am335x based boards like beagle bone, first one is required. Regards Afzal Afzal Mohammed (2): Revert usb: musb: dsps: remove explicit NOP device creation usb: musb: dsps: document dt bindings properly Documentation/devicetree/bindings/usb/am33xx-usb.txt | 8 drivers/usb/musb/musb_dsps.c | 3 ++- 2 files changed, 6 insertions(+), 5 deletions(-) -- 1.7.12 -- 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/RESEND 1/2] Revert usb: musb: dsps: remove explicit NOP device creation
This reverts commit d8c3ef256f88b7c6ecd673d03073b5645be9c5e4. Above mentioned change was made along with multi usb phy change and adding DT support for nop transceiver. But other two changes did not make it to mainline. This in effect makes dsps musb wrapper unusable even for single instance. Hence revert it so that at least single instance can be supported. Signed-off-by: Afzal Mohammed af...@ti.com --- drivers/usb/musb/musb_dsps.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index 6053af1..e770f79 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -411,7 +411,8 @@ static int dsps_musb_init(struct musb *musb) /* mentor core register starts at offset of 0x400 from musb base */ musb-mregs += wrp-musb_core_offset; - /* Get the NOP PHY */ + /* NOP driver needs change if supporting dual instance */ + usb_nop_xceiv_register(); musb-xceiv = usb_get_phy(USB_PHY_TYPE_USB2); if (IS_ERR_OR_NULL(musb-xceiv)) return -ENODEV; -- 1.7.12 -- 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/RESEND 2/2] usb: musb: dsps: document dt bindings properly
DT bindings normally use '-' (hyphens) instead of '_' (underscore), driver has it the proper way, but binding documentation does not reflect it, fix it. Signed-off-by: Afzal Mohammed af...@ti.com --- Documentation/devicetree/bindings/usb/am33xx-usb.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt index ca8fa56..a922505 100644 --- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt +++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt @@ -3,12 +3,12 @@ AM33XX MUSB GLUE - ti,hwmods : must be usb_otg_hs - multipoint : Should be 1 indicating the musb controller supports multipoint. This is a MUSB configuration-specific setting. - - num_eps : Specifies the number of endpoints. This is also a + - num-eps : Specifies the number of endpoints. This is also a MUSB configuration-specific setting. Should be set to 16 - - ram_bits : Specifies the ram address size. Should be set to 12 - - port0_mode : Should be 3 to represent OTG. 1 signifies HOST and 2 + - ram-bits : Specifies the ram address size. Should be set to 12 + - port0-mode : Should be 3 to represent OTG. 1 signifies HOST and 2 represents PERIPHERAL. - - port1_mode : Should be 1 to represent HOST. 3 signifies OTG and 2 + - port1-mode : Should be 1 to represent HOST. 3 signifies OTG and 2 represents PERIPHERAL. - power : Should be 250. This signifies the controller can supply upto 500mA when operating in host mode. -- 1.7.12 -- 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] ARM: dts: AM33XX: Add usbss node
On 11/06/2012 03:29 PM, Felipe Balbi wrote:
Hi,
On Tue, Nov 06, 2012 at 07:59:38PM +0530, Afzal Mohammed wrote:
From: Ajay Kumar Gupta ajay.gu...@ti.com
Device tree node for usbss on AM33XX. There are two musb
controllers on am33xx platform so have port0-mode and
port1-mode data.
[af...@ti.com: reg interrupt property addition]
Signed-off-by: Ajay Kumar Gupta ajay.gu...@ti.com
Signed-off-by: Santhapuri, Damodar damodar.santhap...@ti.com
Signed-off-by: Ravi Babu ravib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
to my eyes, this looks ok.
Reviewed-by: Felipe Balbi ba...@ti.com
Thanks Felipe. Patch applied in for_3.8/dts_part2 branch.
Regards,
Benoit
---
v2: node named as usb
Depends on usb: musb: dsps: dt binding - add resources, example
(https://patchwork.kernel.org/patch/1704691/)
arch/arm/boot/dts/am33xx.dtsi | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 5dfd682..20a3f29 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -321,5 +321,22 @@
ti,hwmods = spi1;
status = disabled;
};
+
+usb@4740 {
+compatible = ti,musb-am33xx;
+reg = 0x4740 0x1000/* usbss */
+ 0x47401000 0x800 /* musb instance 0 */
+ 0x47401800 0x800; /* musb instance 1 */
+interrupts = 17/* usbss */
+ 18/* musb instance 0 */
+ 19; /* musb instance 1 */
+multipoint = 1;
+num-eps = 16;
+ram-bits = 12;
+port0-mode = 3;
+port1-mode = 3;
+power = 250;
+ti,hwmods = usb_otg_hs;
+};
};
};
--
1.7.12
--
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: [RFC/PATCH] mmc: omap_hsmmc: introduce omap_hsmmc_prepare/complete
On Mon, Oct 22, 2012 at 6:29 PM, Felipe Balbi ba...@ti.com wrote:
prepare() is supposed to prevent new children from
being registered. On the MMC subsystem, children
(new cards) registration starts with the card
detect IRQ.
Move card detect IRQ disabling to prepare() so that
no new cards will be registered while we're trying
to suspend.
Likewise, move card detect IRQ enabling to complete()
so we only try to register new children after our MMC
IP is back up.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Venkat, do you think the patch below makes sense ?
Except for the minor nit mentioned below, it works well.
I'll include it in my patch series.
cheers
drivers/mmc/host/omap_hsmmc.c | 45
---
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 54bfd0c..4c8b41e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2022,6 +2022,26 @@ static int __devexit omap_hsmmc_remove(struct
platform_device *pdev)
}
#ifdef CONFIG_PM
+static int omap_hsmmc_prepare(struct device *dev)
+{
+ struct omap_hsmmc_host *host = dev_get_drvdata(dev);
+
+ if (host-pdata-suspend)
+ return host-pdata-suspend(dev, host-slot_id);
+
+ return 0;
+}
+
+static int omap_hsmmc_complete(struct device *dev)
The .complete() function prototype requires to return void.
This one emits a compilation warning.
--
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: hdmi on 4430 (kernel 3.4)
On 11/06/2012 03:05 AM, Federico Fuga wrote: Hi Jon, Il giorno 06/nov/2012, alle ore 00:21, Jon Hunter jon-hun...@ti.com ha scritto: I wanted to check the HDMI registers, but I didn't find the hdmi registers table on the TRM. Does someone have some hint, comment or previous experience on that? Where can I find the hdmi registers list on the manual or other documentation? Note that as far as i know, the 2.6.35 kernel was working correctly (I can't check right now, unfortunately). Thank you. I would recommend posting this query on the TI E2E forum for Linux [1]. You may get better help there seeing that this is with regard to a specific TI development kernel branch. Thank you very much for the suggestion! I'll post there. Can you confirm that the kernel version I am using works without problem with HDMI-1080p? Sorry, I have not tried. However, hopefully someone from the forum can help. 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 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
On 11/06/2012 01:32 AM, Bedia, Vaibhav wrote:
Hi Jon,
On Tue, Nov 06, 2012 at 02:34:05, Hunter, Jon wrote:
[...]
static struct clock_event_device clockevent_gpt = {
.name = gp_timer,
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
@@ -142,6 +171,8 @@ static struct clock_event_device clockevent_gpt = {
.rating = 300,
.set_next_event = omap2_gp_timer_set_next_event,
.set_mode = omap2_gp_timer_set_mode,
+ .suspend= omap_clkevt_suspend,
+ .resume = omap_clkevt_resume,
So these suspend/resume callbacks are going to be called for all OMAP2+
and AM devices? I don't think we want that. AFAIK OMAP timers will
idle on their own when stopped and don't require this.
IMO instead of skipping the callback registration we could have checks in the
suspend/resume callbacks to decide what to do.
I'll check if the idling part is AM33xx specific. If not, based on the recent
timer
changes that you did, perhaps checking if the clockevent selected doesn't
have the
ti,timer-alwon capability will be good enough. What do you think?
Yes, I was thinking along the same lines. If I get chance I will try and
test your scenario on an OMAP3 too.
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 12/15] ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
On 11/06/2012 03:38 AM, Bedia, Vaibhav wrote: Hi Jon, On Tue, Nov 06, 2012 at 02:50:50, Hunter, Jon wrote: [...] Why is this? How is the dmtimer TIOCP_CFG register configured on AM33xx? Is it using smart-idle? Yes, it is set to smart-idle with wakeup capable mode. (this needs a fixup since this timer is not wakeup capable) but unfortunately this is not sufficient. On AM33xx there's no HW_AUTO mode magic so unless the IPs in PER domain are disabled by s/w, PER domain can't transition. The next one is that the clockevent doesn't generate any further interrupts once the system resumes. We need to restore the pre-suspend configuration. I haven't tried but I guess we could have used the save and restore of timer registers here. It would be interesting to try using an non-wakeup domain timer on OMAP3/4 for clock events and seeing if suspend/resume works. Do you know what the exact problem here is? I understand that the timer context could get lost, but exactly what is not getting restarted by the kernel? For example, the only place we set the interrupt enable is during the clock event init and so if the context is lost, then I could see no more interrupts occurring. So is it enough to just restore the interrupt enable register, do you really need to program the timer again? Just restoring the interrupt enable register works. But since there's no logic retention I think a context save-restore would be better. Ok, we may need to check the order in which events occur following resume. The kernel will restart the clock-events and we just need to make sure we do not restore the context after the clock-events has been restarted. 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: OMAP baseline test results for v3.7-rc1
On Tue, 6 Nov 2012, Jean Pihet wrote: On Tue, Nov 6, 2012 at 1:01 AM, Kevin Hilman khil...@deeprootsystems.com wrote: FYI... I just ran across what appears to be the same bug on 3430/n900 during suspend/resume testing. With CPUidle enabled, this happens every time. Reverting the I2C QoS patch makes it work again. That makes sense with CPU_IDLE enabled and suspend. ... For the records here are the patches that have been submitted to support the OMAP PM QoS: - func power states [1], - OMAP PM QoS support [2], which includes the latency figures update and which depends on [1], - the conversion of I2C to PM QoS [3], - the removal of the old no-op OMAP PM API [4], which depends on [3], The chicken-and-egg problem is clearly visible since [3] depends on [2]. Well it's definitely time for a revert, then. #3 should not have been sent until #2 was merged. Will send this in a new thread, please ack it. - Paul -- 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] i2c: omap: Move the remove constraint
Hi Shubhrajyoti, On Tue, Nov 6, 2012 at 10:54 AM, Shubhrajyoti D shubhrajy...@ti.com wrote: Currently we just queue the transfer and release the qos constraints, however we donot wait for the transfer to complete to release the constraint. Move the remove constraint after the bus busy as we are sure that the transfers are completed by then. Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Good catch, the change definitely makes sense. Feel free to add: Acked-by: Jean Pihet j-pi...@ti.com Thanks, Jean. --- drivers/i2c/busses/i2c-omap.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 94ff685..8b079d7 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -655,13 +655,13 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) break; } - if (dev-latency) - pm_qos_remove_request(dev-pm_qos_request); - if (r == 0) r = num; omap_i2c_wait_for_bb(dev); + + if (dev-latency) + pm_qos_remove_request(dev-pm_qos_request); out: pm_runtime_mark_last_busy(dev-dev); pm_runtime_put_autosuspend(dev-dev); -- 1.7.5.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 -- 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] Revert ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints
This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc.
This commit causes I2C timeouts to appear on several OMAP3430/3530-based
boards:
http://marc.info/?l=linux-arm-kernelm=135071372426971w=2
http://marc.info/?l=linux-arm-kernelm=135067558415214w=2
http://marc.info/?l=linux-arm-kernelm=135216013608196w=2
and appears to have been sent for merging before one of its prerequisites
was merged:
http://marc.info/?l=linux-arm-kernelm=135219411617621w=2
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Jean Pihet jean.pi...@newoldbits.com
Cc: Kevin Hilman khil...@ti.com
Cc: Aaro Koskinen aaro.koski...@iki.fi
Cc: Felipe Balbi ba...@ti.com
---
Intended for 3.7-rc.
arch/arm/plat-omap/i2c.c | 21 +
drivers/i2c/busses/i2c-omap.c | 32 ++--
include/linux/i2c-omap.h |1 +
3 files changed, 36 insertions(+), 18 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a5683a8..6013831 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -26,12 +26,14 @@
#include linux/kernel.h
#include linux/platform_device.h
#include linux/i2c.h
+#include linux/i2c-omap.h
#include linux/slab.h
#include linux/err.h
#include linux/clk.h
#include mach/irqs.h
#include plat/i2c.h
+#include plat/omap-pm.h
#include plat/omap_device.h
#define OMAP_I2C_SIZE 0x3f
@@ -127,6 +129,16 @@ static inline int omap1_i2c_add_bus(int bus_id)
#ifdef CONFIG_ARCH_OMAP2PLUS
+/*
+ * XXX This function is a temporary compatibility wrapper - only
+ * needed until the I2C driver can be converted to call
+ * omap_pm_set_max_dev_wakeup_lat() and handle a return code.
+ */
+static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
+{
+ omap_pm_set_max_mpu_wakeup_lat(dev, t);
+}
+
static inline int omap2_i2c_add_bus(int bus_id)
{
int l;
@@ -158,6 +170,15 @@ static inline int omap2_i2c_add_bus(int bus_id)
dev_attr = (struct omap_i2c_dev_attr *)oh-dev_attr;
pdata-flags = dev_attr-flags;
+ /*
+* When waiting for completion of a i2c transfer, we need to
+* set a wake up latency constraint for the MPU. This is to
+* ensure quick enough wakeup from idle, when transfer
+* completes.
+* Only omap3 has support for constraints
+*/
+ if (cpu_is_omap34xx())
+ pdata-set_mpu_wkup_lat = omap_pm_set_max_mpu_wakeup_lat_compat;
pdev = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
NULL, 0, 0);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..0b02543 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -43,7 +43,6 @@
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
-#include linux/pm_qos.h
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -187,8 +186,9 @@ struct omap_i2c_dev {
int reg_shift; /* bit shift for I2C register
addresses */
struct completion cmd_complete;
struct resource *ioarea;
- u32 latency;/* maximum MPU wkup latency */
- struct pm_qos_request pm_qos_request;
+ u32 latency;/* maximum mpu wkup latency */
+ void(*set_mpu_wkup_lat)(struct device *dev,
+ long latency);
u32 speed; /* Speed of bus in kHz */
u32 dtrev; /* extra revision from DT */
u32 flags;
@@ -494,7 +494,9 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev,
u8 size, bool is_rx)
dev-b_hw = 1; /* Enable hardware fixes */
/* calculate wakeup latency constraint for MPU */
- dev-latency = (100 * dev-threshold) / (1000 * dev-speed / 8);
+ if (dev-set_mpu_wkup_lat != NULL)
+ dev-latency = (100 * dev-threshold) /
+ (1000 * dev-speed / 8);
}
/*
@@ -629,16 +631,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
if (r 0)
goto out;
- /*
-* When waiting for completion of a i2c transfer, we need to
-* set a wake up latency constraint for the MPU. This is to
-* ensure quick enough wakeup from idle, when transfer
-* completes.
-*/
- if (dev-latency)
- pm_qos_add_request(dev-pm_qos_request,
- PM_QOS_CPU_DMA_LATENCY,
- dev-latency);
+ if (dev-set_mpu_wkup_lat != NULL)
+ dev-set_mpu_wkup_lat(dev-dev, dev-latency);
for (i = 0; i num; i++) {
r = omap_i2c_xfer_msg(adap, msgs[i], (i == (num -
Re: [PATCH] Revert ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints
On Tue, Nov 6, 2012 at 5:31 PM, Paul Walmsley p...@pwsan.com wrote:
This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc.
This commit causes I2C timeouts to appear on several OMAP3430/3530-based
boards:
http://marc.info/?l=linux-arm-kernelm=135071372426971w=2
http://marc.info/?l=linux-arm-kernelm=135067558415214w=2
http://marc.info/?l=linux-arm-kernelm=135216013608196w=2
and appears to have been sent for merging before one of its prerequisites
was merged:
http://marc.info/?l=linux-arm-kernelm=135219411617621w=2
Indeed.
Acked-by: Jean Pihet j-pi...@ti.com
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Jean Pihet jean.pi...@newoldbits.com
Cc: Kevin Hilman khil...@ti.com
Cc: Aaro Koskinen aaro.koski...@iki.fi
Cc: Felipe Balbi ba...@ti.com
---
Intended for 3.7-rc.
arch/arm/plat-omap/i2c.c | 21 +
drivers/i2c/busses/i2c-omap.c | 32 ++--
include/linux/i2c-omap.h |1 +
3 files changed, 36 insertions(+), 18 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a5683a8..6013831 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -26,12 +26,14 @@
#include linux/kernel.h
#include linux/platform_device.h
#include linux/i2c.h
+#include linux/i2c-omap.h
#include linux/slab.h
#include linux/err.h
#include linux/clk.h
#include mach/irqs.h
#include plat/i2c.h
+#include plat/omap-pm.h
#include plat/omap_device.h
#define OMAP_I2C_SIZE 0x3f
@@ -127,6 +129,16 @@ static inline int omap1_i2c_add_bus(int bus_id)
#ifdef CONFIG_ARCH_OMAP2PLUS
+/*
+ * XXX This function is a temporary compatibility wrapper - only
+ * needed until the I2C driver can be converted to call
+ * omap_pm_set_max_dev_wakeup_lat() and handle a return code.
+ */
+static void omap_pm_set_max_mpu_wakeup_lat_compat(struct device *dev, long t)
+{
+ omap_pm_set_max_mpu_wakeup_lat(dev, t);
+}
+
static inline int omap2_i2c_add_bus(int bus_id)
{
int l;
@@ -158,6 +170,15 @@ static inline int omap2_i2c_add_bus(int bus_id)
dev_attr = (struct omap_i2c_dev_attr *)oh-dev_attr;
pdata-flags = dev_attr-flags;
+ /*
+* When waiting for completion of a i2c transfer, we need to
+* set a wake up latency constraint for the MPU. This is to
+* ensure quick enough wakeup from idle, when transfer
+* completes.
+* Only omap3 has support for constraints
+*/
+ if (cpu_is_omap34xx())
+ pdata-set_mpu_wkup_lat =
omap_pm_set_max_mpu_wakeup_lat_compat;
pdev = omap_device_build(name, bus_id, oh, pdata,
sizeof(struct omap_i2c_bus_platform_data),
NULL, 0, 0);
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..0b02543 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -43,7 +43,6 @@
#include linux/slab.h
#include linux/i2c-omap.h
#include linux/pm_runtime.h
-#include linux/pm_qos.h
/* I2C controller revisions */
#define OMAP_I2C_OMAP1_REV_2 0x20
@@ -187,8 +186,9 @@ struct omap_i2c_dev {
int reg_shift; /* bit shift for I2C register
addresses */
struct completion cmd_complete;
struct resource *ioarea;
- u32 latency;/* maximum MPU wkup latency */
- struct pm_qos_request pm_qos_request;
+ u32 latency;/* maximum mpu wkup latency */
+ void(*set_mpu_wkup_lat)(struct device *dev,
+ long latency);
u32 speed; /* Speed of bus in kHz */
u32 dtrev; /* extra revision from DT */
u32 flags;
@@ -494,7 +494,9 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev
*dev, u8 size, bool is_rx)
dev-b_hw = 1; /* Enable hardware fixes */
/* calculate wakeup latency constraint for MPU */
- dev-latency = (100 * dev-threshold) / (1000 * dev-speed / 8);
+ if (dev-set_mpu_wkup_lat != NULL)
+ dev-latency = (100 * dev-threshold) /
+ (1000 * dev-speed / 8);
}
/*
@@ -629,16 +631,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
if (r 0)
goto out;
- /*
-* When waiting for completion of a i2c transfer, we need to
-* set a wake up latency constraint for the MPU. This is to
-* ensure quick enough wakeup from idle, when transfer
-* completes.
-*/
- if (dev-latency)
- pm_qos_add_request(dev-pm_qos_request,
- PM_QOS_CPU_DMA_LATENCY,
-
[PATCH v2] mmc: omap_hsmmc: introduce omap_hsmmc_prepare/complete
prepare() is supposed to prevent new children from
being registered. On the MMC subsystem, children
(new cards) registration starts with the card
detect IRQ.
Move card detect IRQ disabling to prepare() so that
no new cards will be registered while we're trying
to suspend.
Likewise, move card detect IRQ enabling to complete()
so we only try to register new children after our MMC
IP is back up.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Fixed -complete() prototype.
drivers/mmc/host/omap_hsmmc.c | 43 +++
1 file changed, 23 insertions(+), 20 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 54bfd0c..d2d6a56 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2022,6 +2022,24 @@ static int __devexit omap_hsmmc_remove(struct
platform_device *pdev)
}
#ifdef CONFIG_PM
+static int omap_hsmmc_prepare(struct device *dev)
+{
+ struct omap_hsmmc_host *host = dev_get_drvdata(dev);
+
+ if (host-pdata-suspend)
+ return host-pdata-suspend(dev, host-slot_id);
+
+ return 0;
+}
+
+static void omap_hsmmc_complete(struct device *dev)
+{
+ struct omap_hsmmc_host *host = dev_get_drvdata(dev);
+
+ if (host-pdata-resume)
+ host-pdata-resume(dev, host-slot_id);
+}
+
static int omap_hsmmc_suspend(struct device *dev)
{
int ret = 0;
@@ -2035,23 +2053,10 @@ static int omap_hsmmc_suspend(struct device *dev)
pm_runtime_get_sync(host-dev);
host-suspended = 1;
- if (host-pdata-suspend) {
- ret = host-pdata-suspend(dev, host-slot_id);
- if (ret) {
- dev_dbg(dev, Unable to handle MMC board
-level suspend\n);
- host-suspended = 0;
- return ret;
- }
- }
ret = mmc_suspend_host(host-mmc);
if (ret) {
host-suspended = 0;
- if (host-pdata-resume) {
- if (host-pdata-resume(dev, host-slot_id))
- dev_dbg(dev, Unmask interrupt failed\n);
- }
goto err;
}
@@ -2088,12 +2093,6 @@ static int omap_hsmmc_resume(struct device *dev)
if (!(host-mmc-pm_flags MMC_PM_KEEP_POWER))
omap_hsmmc_conf_bus_power(host);
- if (host-pdata-resume) {
- ret = host-pdata-resume(dev, host-slot_id);
- if (ret)
- dev_dbg(dev, Unmask interrupt failed\n);
- }
-
omap_hsmmc_protect_card(host);
/* Notify the core to resume the host */
@@ -2109,8 +2108,10 @@ static int omap_hsmmc_resume(struct device *dev)
}
#else
+#define omap_hsmmc_prepare NULL
+#define omap_hsmmc_completeNULL
#define omap_hsmmc_suspend NULL
-#define omap_hsmmc_resume NULL
+#define omap_hsmmc_resume NULL
#endif
static int omap_hsmmc_runtime_suspend(struct device *dev)
@@ -2138,6 +2139,8 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.suspend= omap_hsmmc_suspend,
.resume = omap_hsmmc_resume,
+ .prepare= omap_hsmmc_prepare,
+ .complete = omap_hsmmc_complete,
.runtime_suspend = omap_hsmmc_runtime_suspend,
.runtime_resume = omap_hsmmc_runtime_resume,
};
--
1.8.0
--
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 2/3] mtd nand : get timings from onfi
We get from onfi param the max speed supported by the chip.
A precomputed table for ONFI timings is generated.
Signed-off-by: Matthieu CASTET matthieu.cas...@parrot.com
---
drivers/mtd/nand/Makefile |2 +-
drivers/mtd/nand/nand_base.c |1 +
drivers/mtd/nand/nand_timing.c | 170
include/linux/mtd/nand.h | 56 +
4 files changed, 228 insertions(+), 1 deletion(-)
create mode 100644 drivers/mtd/nand/nand_timing.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 2cbd091..2fc1a99 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -54,4 +54,4 @@ obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/
obj-$(CONFIG_MTD_NAND_XWAY)+= xway_nand.o
-nand-objs := nand_base.o nand_bbt.o
+nand-objs := nand_base.o nand_bbt.o nand_timing.o
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 8916bc6..0d6bd88 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3238,6 +3238,7 @@ static struct nand_flash_dev *nand_get_flash_type(struct
mtd_info *mtd,
if (*maf_id != NAND_MFR_SAMSUNG !type-pagesize)
chip-options = ~NAND_SAMSUNG_LP_OPTIONS;
ident_done:
+ nand_select_speed(chip, *maf_id, *dev_id);
/* Try to identify manufacturer */
for (maf_idx = 0; nand_manuf_ids[maf_idx].id != 0x0; maf_idx++) {
diff --git a/drivers/mtd/nand/nand_timing.c b/drivers/mtd/nand/nand_timing.c
new file mode 100644
index 000..7211c9c
--- /dev/null
+++ b/drivers/mtd/nand/nand_timing.c
@@ -0,0 +1,170 @@
+/*
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include linux/module.h
+#include linux/types.h
+#include linux/mtd/mtd.h
+#include linux/mtd/nand.h
+
+/*
+ * this table is precomputed from onfi timings with the following program
+ */
+#if 0
+int print_timing(const struct onfi_timings *timings, int edo_off)
+{
+ struct reduced_onfi t;
+ int tmp;
+ int edo = timings-tRC 30 !edo_off;
+
+ /* nWE low */
+ t.twp = max(timings-tWP, timings-tDS);
+
+ /* nCS low to nWE low */
+ tmp = max(timings-tCLS, timings-tCS);
+ tmp = max(tmp, timings-tALS);
+ t.twsetup = tmp - t.twp;
+ assert(t.twsetup = 0);
+
+ /* nWE high */
+ tmp = max(timings-tWH, timings-tDH); /* nWE high data hold */
+ tmp = max(tmp, timings-tCH); /* cs hold */
+ tmp = max(tmp, timings-tCLH); /* cmd hold */
+ t.twh = max(tmp, timings-tALH); /* addr hold */
+
+ assert(t.twp + t.twh = timings-tWC);
+ t.twc = timings-tWC;
+
+ t.edo = edo;
+ if (edo == 0) {
+
+ /* nRE low */
+ t.trp = max(timings-tRP, timings-tREA);
+
+ /* nRE high */
+ t.treh = timings-tREH;
+ t.trc = max(timings-tRC, t.trp + t.treh);
+ }
+ else {
+ /* nRE low */
+ t.trp = timings-tRP;
+
+ /* nRE high */
+ t.treh = timings-tREH;
+
+ t.trc = max(timings-tRC, timings-tREA);
+ }
+
+ /* nCS low to nRE low */
+ t.trsetup = max(timings-tCEA - timings-tREA, timings-tCLR);
+
+ /* Min time from rdn rising edge to output hi-Z */
+ t.bta = timings-tRHZ;
+
+ /* Min time from busy rising edge and rdn falling edge (read).*/
+ t.tbusy = timings-tRR;
+
+ /* Min time from wrn rising edge to rdn falling edge. */
+ t.twhr = timings-tWHR;
+ assert(t.twhr = 0);
+
+ t.tceh = 0;
+
+ printf({\n);
+ printf(/* %s edo=%d */\n, timings-name, t.edo);
+ printf(.twp = %3d, .twh = %3d, .twc = %3d, .twsetup = %d,\n,
+ t.twp, t.twh, t.twc, t.twsetup);
+ printf(.trp = %3d, .treh = %3d, .trc = %3d, .trsetup = %d,\n,
+ t.trp, t.treh, t.trc, t.trsetup);
+ printf(.twhr = %d, .tceh = %d, .bta = %d, .tbusy = %d, .edo = %d,\n,
+ t.twhr, t.tceh, t.bta, t.tbusy, t.edo);
+ printf(},\n);
+#endif
+
+static struct reduced_onfi nand_timing[] =
+{
+ {
+ /* onfi mode 0 edo=0 */
+ .twp = 50, .twh = 30, .twc = 100, .twsetup = 20,
+ .trp = 50, .treh = 30, .trc = 100, .trsetup = 60,
+ .twhr = 120, .tceh = 0, .bta = 200, .tbusy = 39, .edo = 0,
+ },
+ {
+ /* onfi mode 1 edo=0 */
+ .twp = 25, .twh = 15, .twc = 45, .twsetup = 10,
+ .trp = 30, .treh = 15, .trc = 50, .trsetup = 15,
+ .twhr = 80, .tceh = 0, .bta = 100, .tbusy = 20, .edo = 0,
+ },
+ {
+ /* onfi mode 2 edo=0 */
+ .twp = 17, .twh = 15, .twc = 35, .twsetup = 8,
[PATCH 3/3] omap nand : use onfi mode to compute optimized timings
If the platform data give us nand timings (in gpmc_t), we use
them and not use onfi timings.
Tested on omap 3630 (with onfi flash and mode {2, 4 , 5})
Signed-off-by: Matthieu CASTET matthieu.cas...@parrot.com
---
drivers/mtd/nand/omap2.c | 134 ++
1 file changed, 134 insertions(+)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 618cf42..6c45c59 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -29,6 +29,7 @@
#include plat/dma.h
#include plat/gpmc.h
+#include plat/cpu.h
#include linux/platform_data/mtd-nand-omap2.h
#defineDRIVER_NAME omap2-nand
@@ -153,6 +154,8 @@ struct omap_nand_info {
#endif
};
+static int optim_rd, optim_wr;
+
/**
* omap_prefetch_enable - configures and starts prefetch transfer
* @cs: cs (chip select) number
@@ -181,6 +184,13 @@ static int omap_prefetch_enable(int cs, int fifo_th, int
dma_mode,
val = ((cs PREFETCH_CONFIG1_CS_SHIFT) |
PREFETCH_FIFOTHRESHOLD(fifo_th) | ENABLE_PREFETCH |
(dma_mode DMA_MPU_MODE_SHIFT) | (0x1 is_write));
+ if (is_write) {
+ if (optim_wr)
+ val |= (1 27) /* ENABLEOPTIMIZEDACCESS */| (optim_wr
28);
+ } else {
+ if (optim_rd)
+ val |= (1 27) /* ENABLEOPTIMIZEDACCESS */| (optim_rd
28);
+ }
writel(val, info-reg.gpmc_prefetch_config1);
/* Start the prefetch engine */
@@ -1239,6 +1249,122 @@ static void omap3_free_bch(struct mtd_info *mtd)
}
#endif /* CONFIG_MTD_NAND_OMAP_BCH */
+/* Update hardware configuration after device geometry has been queried */
+static int omap_onfi_set(struct mtd_info* mtd, int mode)
+{
+ struct omap_nand_info *info = container_of(mtd,
+ struct omap_nand_info, mtd);
+
+const struct reduced_onfi *tn = nand_get_timing(mode, 1);
+ int tmp;
+ struct gpmc_timings t;
+
+ pr_info(omap nand : setting onfi mode %d\n, mode);
+
+
+ /* only tested on 3630 */
+ if (!cpu_is_omap3630()) {
+ /* wr_access is shared with access */
+ return -EINVAL;
+ }
+
+ memset(t, 0, sizeof(t));
+
+ /* all signal start at the same time :
+ we could delay nRE, nWE, but this won't
+ work with prefetcher optimisation...
+*/
+
+ t.cs_on = 0;
+ t.adv_on = 0;
+ t.oe_on = 0;
+ t.we_on = 0;
+
+ tmp = gpmc_round_ns_to_ticks(tn-twp);
+ /* nCS low to nWE high */
+ t.we_off = gpmc_round_ns_to_ticks(tn-twsetup) + tmp;
+
+ /* nCS low to end */
+ t.wr_cycle = t.we_off + max((int)tn-twh, tn-twc - tmp);
+
+ /* BCH need 4 cycles */
+ if (gpmc_ns_to_ticks(t.wr_cycle) 4)
+ t.wr_cycle = gpmc_ticks_to_ns(4);
+ else if (gpmc_ns_to_ticks(t.wr_cycle) 0x1f)
+ t.wr_cycle = gpmc_ticks_to_ns(0x1f);
+
+ t.cs_wr_off = t.wr_cycle;
+ t.adv_wr_off = t.wr_cycle;
+ t.wr_access = t.we_off;
+
+ tmp = gpmc_round_ns_to_ticks(tn-trp);
+ /* nCS low to nRE high */
+ t.oe_off = gpmc_round_ns_to_ticks(tn-trsetup) + tmp;
+
+ /* nCS low to end */
+ t.rd_cycle = t.oe_off + max((int)tn-treh, tn-trc - tmp);;
+
+ /* BCH need 4 cycles */
+ if (gpmc_ns_to_ticks(t.rd_cycle) 4)
+ t.rd_cycle = gpmc_ticks_to_ns(4);
+ else if (gpmc_ns_to_ticks(t.rd_cycle) 0x1f)
+ t.rd_cycle = gpmc_ticks_to_ns(0x1f);
+
+ t.cs_rd_off = t.rd_cycle;
+ t.adv_rd_off = t.rd_cycle; /* not used */
+ if (tn-edo)
+ t.access = t.rd_cycle;
+ else
+ t.access = t.oe_off;
+
+ t.page_burst_access = 0; /* not used */
+ t.wr_data_mux_bus = 0; /* not used not in MUXADDDATA mode */
+
+ /* we often overflow here ... */
+ tmp = gpmc_ns_to_ticks(tn-bta);
+ if (tmp 0xf)
+ tmp = 0xf;
+ t.busturnaround = gpmc_ticks_to_ns(tmp);
+
+ tmp = gpmc_ns_to_ticks(tn-twhr);
+ if (tmp 0xf)
+ tmp = 0xf;
+ t.cycle2cycledelay = gpmc_ticks_to_ns(tmp);
+
+ /*
+ XXX tbusy is not configurable
+ trm is not clear how much the gpmc wait between WAIT high and read.
+ But the linux driver doesn't use SYNCHROMODE in
GPMC_PREFETCH_CONFIG1,
+ so we should be safe
+*/
+ pr_debug(nand timings\n);
+ pr_debug(oe_off=%d, rd_cycle=%d\n, t.oe_off, t.rd_cycle);
+ pr_debug(we_off=%d, wr_cycle=%d\n, t.we_off, t.wr_cycle);
+
+ /* make sure timming register got sane default */
+ gpmc_cs_write_reg(info-gpmc_cs, GPMC_CS_CONFIG2, 0);
+ gpmc_cs_write_reg(info-gpmc_cs, GPMC_CS_CONFIG3, 0);
+ gpmc_cs_write_reg(info-gpmc_cs, GPMC_CS_CONFIG4, 0);
+ gpmc_cs_write_reg(info-gpmc_cs, GPMC_CS_CONFIG5, 0);
+ gpmc_cs_write_reg(info-gpmc_cs,
[PATCH 1/3] omap gpmc : add support of setting CYCLE2CYCLEDELAY and BUSTURNAROUND
Signed-off-by: Matthieu CASTET matthieu.cas...@parrot.com
---
arch/arm/mach-omap2/gpmc.c |7 ++-
arch/arm/plat-omap/include/plat/gpmc.h |2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 8ab1e1b..3957ffc 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -333,8 +333,13 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
if (gpmc_capability GPMC_HAS_WR_DATA_MUX_BUS)
GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
- if (gpmc_capability GPMC_HAS_WR_ACCESS)
+ if (gpmc_capability GPMC_HAS_WR_ACCESS) {
+ /* XXX check on which hardware it is supported */
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, busturnaround);
+ GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycledelay);
+
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
+ }
/* caller is expected to have initialized CONFIG1 to cover
* at least sync vs async
diff --git a/arch/arm/plat-omap/include/plat/gpmc.h
b/arch/arm/plat-omap/include/plat/gpmc.h
index 2e6e259..34ca454 100644
--- a/arch/arm/plat-omap/include/plat/gpmc.h
+++ b/arch/arm/plat-omap/include/plat/gpmc.h
@@ -131,6 +131,8 @@ struct gpmc_timings {
/* The following are only on OMAP3430 */
u16 wr_access; /* WRACCESSTIME */
u16 wr_data_mux_bus;/* WRDATAONADMUXBUS */
+ u16 cycle2cycledelay; /* CYCLE2CYCLEDELAY */
+ u16 busturnaround; /* BUSTURNAROUND */
};
struct gpmc_nand_regs {
--
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 3/3] omap3 nand : use NAND_BUSWIDTH_AUTO
Igor Grinberg a écrit : Cc: Tony Lindgren, Afzal Mohammed, On 11/06/12 12:51, Matthieu CASTET wrote: This allow to clean the omap nand driver that were trying in x8 and x16 bits mode. This also make work onfi detection on beagleboard : Before : [1.954803] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron NAND 256MiB 1,8V 16-bit), page size: 2048, OOB size: 64 After : [1.914825] ONFI param page 0 valid [1.919158] ONFI flash detected [1.922515] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xba (Micron MT29F2G16ABD), page size: 2048, OOB size: 64 platform data devsize is renamed bussize. It now indicate the maximun size of the nand bus. Signed-off-by: Matthieu CASTET matthieu.cas...@parrot.com I think, you should base on one of Tony's branches with that kind of patches. Because, for example the omap_nand_flash_init() function does not exist anymore in Tony's master and may be several more things will need to have adjustments. Also, the GPMC related stuff inside the NAND driver should probably be coordinated with Afzal, as he is reworking the whole GPMC related code. Thanks for the info. Where such tree could be found ? Matthieu -- 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] usb: musb: dsps: dt binding - add resources, example
Hi,
On Tue, Nov 06, 2012 at 07:26:06PM +0530, Afzal Mohammed wrote:
OMAP2+ family of devices are now obtaining resources via DT, earlier
it was obtained from hwmod. Update binding document accrodingly, while
at it add example.
Signed-off-by: Afzal Mohammed af...@ti.com
this looks fine to me:
Reviewed-by: Felipe Balbi ba...@ti.com
Benoit, do you take Documentation patches too ?
---
v2: node name changed to usb
.../devicetree/bindings/usb/am33xx-usb.txt | 21
+
1 file changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index a922505..ea840f7 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -1,5 +1,7 @@
AM33XX MUSB GLUE
- compatible : Should be ti,musb-am33xx
+ - reg : offset and length of register sets, first usbss, then for musb
instances
+ - interrupts : usbss, musb instance interrupts in order
- ti,hwmods : must be usb_otg_hs
- multipoint : Should be 1 indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
@@ -12,3 +14,22 @@ AM33XX MUSB GLUE
represents PERIPHERAL.
- power : Should be 250. This signifies the controller can supply upto
500mA when operating in host mode.
+
+Example:
+
+usb@4740 {
+ compatible = ti,musb-am33xx;
+ reg = 0x4740 0x1000/* usbss */
+0x47401000 0x800 /* musb instance 0 */
+0x47401800 0x800; /* musb instance 1 */
+ interrupts = 17/* usbss */
+ 18/* musb instance 0 */
+ 19; /* musb instance 1 */
+ multipoint = 1;
+ num-eps = 16;
+ ram-bits = 12;
+ port0-mode = 3;
+ port1-mode = 3;
+ power = 250;
+ ti,hwmods = usb_otg_hs;
+};
--
1.7.12
--
balbi
signature.asc
Description: Digital signature
[PATCH 0/5] mmc: omap_hsmmc: Few patches for omap_hsmmc
Hi Chris, Please review and merge the below patches. The first one is a bug fix that would be required to be sent for 3.7-rcX, others are intended for 3.8. Thanks, Venkat. = Felipe Balbi (1): mmc: omap_hsmmc: introduce omap_hsmmc_prepare/complete Hebbar, Gururaja (1): mmc: omap_hsmmc: Enable HSPE bit for high speed cards Venkatraman S (3): mmc: omap_hsmmc: Avoid host-cmd dereference during data transfer failures mmc: omap_hsmmc: cleanup the bitmap definitions of Interrupt Register mmc: omap_hsmmc: convert critical failure reports to dev_err .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 1 + arch/arm/plat-omap/include/plat/mmc.h | 1 + drivers/mmc/host/omap_hsmmc.c | 143 + 3 files changed, 94 insertions(+), 51 deletions(-) -- 1.8.0 -- 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/5] mmc: omap_hsmmc: Avoid host-cmd dereference during data transfer failures
Sometimes, a error occurs just after the Command has been reported
to be successful (CC=1) but before data transfer completes (TC=1).
Setting end_cmd=1 here leads to a NULL pointer dereference of
host-cmd as the command complete has previously been handled.
Set end_cmd only when command complete has not been handled
before, else a NULL pointer dereference occurs.
CC: sta...@vger.kernel.org
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5434fd8..06d2e03 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -996,7 +996,8 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host *host,
int status)
else if (status (CMD_CRC | DATA_CRC))
hsmmc_command_incomplete(host, -EILSEQ);
- end_cmd = 1;
+ if (host-cmd)
+ end_cmd = 1;
if (host-data || host-response_busy) {
end_trans = 1;
host-response_busy = 0;
--
1.8.0
--
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
