Re: [PATCH 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
Hi,
On Tue, Jul 30, 2013 at 10:44:48AM +0530, Kishon Vijay Abraham I wrote:
On Mon, Jul 29, 2013 at 08:59:26PM +0530, Kishon Vijay Abraham I wrote:
Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while
creating
MUSB core device. So in usb_bind_phy (binds the controller with the
PHY), the
device name of the controller had *.auto* in it. Since with using
PLATFORM_DEVID_AUTO, there is no way to know the exact device name in
advance,
the data given in usb_bind_phy became obsolete and usb_get_phy was
failing.
So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO.
Corresponding
change is done in board file here.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3logic.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3stalker.c |2 +-
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
arch/arm/mach-omap2/board-overo.c|2 +-
arch/arm/mach-omap2/board-rm680.c|2 +-
arch/arm/mach-omap2/board-rx51.c |2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
16 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 244d8a5..17bb076 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
omap_hsmmc_init(mmc);
omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA |
OMAP_PULL_UP);
-usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
+usb_bind_phy(musb-hdrc.0, 0, twl4030_usb);
how about moving usb_bind_phy() calls to omap2430.c ?
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..b6abc1a 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device
*pdev)
pdata-board_data = data;
pdata-config = config;
+ } else {
+ /* bind the PHY */
+ usb_bind_phy(dev_name(musb-dev), 0, twl4030_usb);
This looks like a hack IMHO to workaround the usb phy library. otherwise
it is
similar to get_phy_by_name.
actually, this is a workaround to the fact that we're not creating all
platform_devices in arch/arm/mach-omap2/ :-)
If we had the musb allocation there, we could easily handle
usb_bind_phy()
so that's temporary. It might be better than to reintroduce the IDR in
musb_core.c.
that’s needed for generic phy framework anyway :-s
right, but generic phy framework can handle everything just fine, the
only problem is that names are changing.
right. But if the names change, PHY framework wouldn't be able to return the
reference to the PHY.
with my suggestion they can change whenever they want since we're using
dev_name() of the just-created musb platform_device. Right ?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 09/21] ARM: OMAP: devkit8000: use new display drivers
On 30/07/13 08:48, Archit Taneja wrote:
Hi,
On Friday 26 July 2013 12:38 PM, Tomi Valkeinen wrote:
Use new display drivers for devkit8000 board.
The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-devkit8000.c | 96
+++---
1 file changed, 65 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index f1d91ba..cdc4fb9 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -112,50 +112,81 @@ static struct regulator_consumer_supply
devkit8000_vio_supply[] = {
REGULATOR_SUPPLY(vcc, spi2.0),
};
-static struct panel_generic_dpi_data lcd_panel = {
-.name= innolux_at070tn83,
-/* gpios filled in code */
+static const struct display_timing devkit8000_lcd_videomode = {
+.pixelclock= { 0, 4000, 0 },
This is unrelated to the work being done here, but noticed that the
pixel clock for this panel seems to be too high for the given timings.
It puts the refresh rate around 90 Hz, which is odd.
So it does... Quick googling found the specs for the panel, but even
with the typical values in the spec I get somewhwat odd refresh rate.
Well, as you said, it's unrelated to these changes. I guess it's better
not to touch it.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: Linux kernel for OMAP5432 uEVM
On Jul 30, 2013, at 11:52 AM, Lokesh Vutla lokeshvu...@ti.com wrote: Hi Chen, On Tuesday 30 July 2013 09:08 AM, Chen Baozi wrote: Hi all, I'm trying to boot my OMAP5432 uEVM devboard with the lastest kernel of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git. Which branch are you using ? the master branch. However, after u-boot loading uImage DTB, there is no output message any more, such as: Clk data might be missing here. Try merging the below branch and test it https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=for_3.11/out_of_tree/omap5_clk_data Thanks, I'll have a try. Baozi You can also use Linus's kernel with the above clk data branch.( OMAP5 uEVM boots) Please let me know if you need more info. Thanks and regards, Lokesh ## Executing script at 8200 reading omap5-evm-omap.dtb 15280 bytes read in 6 ms (2.4 MiB/s) reading uImage-omap 3996552 bytes read in 250 ms (15.2 MiB/s) ## Booting kernel from Legacy Image at 8030 ... Image Name: Linux-3.10.0-rc6-12306-g0dbc346 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:3996488 Bytes = 3.8 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 825f Booting using the fdt blob at 0x825f Loading Kernel Image ... OK OK reserving fdt memory region: addr=9d00 size=300 Loading Device Tree to 83ff9000, end 83fffbaf ... OK Starting kernel ... Before trying this tree, I'm using the 3.8.4 kernel from TI. And it does support the board and can successfully boot. Anything that I may have missed when configuring the kernel? I use omap2plus_defconfig and add DEBUG_LL, DEBUG_OMAP2PLUS_UART, DEBUG_OMAP4UART3... Cheers, Chen Baozi -- 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 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
Hi,
On Tuesday 30 July 2013 11:31 AM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 10:44:48AM +0530, Kishon Vijay Abraham I wrote:
On Mon, Jul 29, 2013 at 08:59:26PM +0530, Kishon Vijay Abraham I wrote:
Previously MUSB wrapper (OMAP) device used PLATFORM_DEVID_AUTO while
creating
MUSB core device. So in usb_bind_phy (binds the controller with the
PHY), the
device name of the controller had *.auto* in it. Since with using
PLATFORM_DEVID_AUTO, there is no way to know the exact device name in
advance,
the data given in usb_bind_phy became obsolete and usb_get_phy was
failing.
So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO.
Corresponding
change is done in board file here.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-cm-t35.c |2 +-
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-omap3beagle.c |2 +-
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3logic.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |2 +-
arch/arm/mach-omap2/board-omap3stalker.c |2 +-
arch/arm/mach-omap2/board-omap3touchbook.c |2 +-
arch/arm/mach-omap2/board-overo.c|2 +-
arch/arm/mach-omap2/board-rm680.c|2 +-
arch/arm/mach-omap2/board-rx51.c |2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
16 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 244d8a5..17bb076 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
omap_hsmmc_init(mmc);
omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA |
OMAP_PULL_UP);
-usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
+usb_bind_phy(musb-hdrc.0, 0, twl4030_usb);
how about moving usb_bind_phy() calls to omap2430.c ?
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..b6abc1a 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device
*pdev)
pdata-board_data = data;
pdata-config = config;
+ } else {
+ /* bind the PHY */
+ usb_bind_phy(dev_name(musb-dev), 0, twl4030_usb);
This looks like a hack IMHO to workaround the usb phy library. otherwise
it is
similar to get_phy_by_name.
actually, this is a workaround to the fact that we're not creating all
platform_devices in arch/arm/mach-omap2/ :-)
If we had the musb allocation there, we could easily handle
usb_bind_phy()
so that's temporary. It might be better than to reintroduce the IDR in
musb_core.c.
that’s needed for generic phy framework anyway :-s
right, but generic phy framework can handle everything just fine, the
only problem is that names are changing.
right. But if the names change, PHY framework wouldn't be able to return the
reference to the PHY.
with my suggestion they can change whenever they want since we're using
dev_name() of the just-created musb platform_device. Right ?
right. But the PHY device can be created in a different place from where the
musb devices are created. And in the PHY framework, the PHY device should have
the list of controller device (names) it can support (PHY framework does not
maintain a separate list for binding like how we had in USB PHY library). e.g.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92817.html. In such
cases how do we pass the device names. Also will the MUSB core device be
created before twl4030-usb PHY device?
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
Hi,
On Tue, Jul 30, 2013 at 11:41:23AM +0530, Kishon Vijay Abraham I wrote:
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 244d8a5..17bb076 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
omap_hsmmc_init(mmc);
omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA |
OMAP_PULL_UP);
- usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
+ usb_bind_phy(musb-hdrc.0, 0, twl4030_usb);
how about moving usb_bind_phy() calls to omap2430.c ?
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..b6abc1a 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device
*pdev)
pdata-board_data = data;
pdata-config = config;
+ } else {
+ /* bind the PHY */
+ usb_bind_phy(dev_name(musb-dev), 0, twl4030_usb);
This looks like a hack IMHO to workaround the usb phy library. otherwise
it is
similar to get_phy_by_name.
actually, this is a workaround to the fact that we're not creating all
platform_devices in arch/arm/mach-omap2/ :-)
If we had the musb allocation there, we could easily handle
usb_bind_phy()
so that's temporary. It might be better than to reintroduce the IDR in
musb_core.c.
that’s needed for generic phy framework anyway :-s
right, but generic phy framework can handle everything just fine, the
only problem is that names are changing.
right. But if the names change, PHY framework wouldn't be able to return
the
reference to the PHY.
with my suggestion they can change whenever they want since we're using
dev_name() of the just-created musb platform_device. Right ?
right. But the PHY device can be created in a different place from where the
musb devices are created. And in the PHY framework, the PHY device should have
this shouldn't be a problem. As long as the phy is created, all should
be good.
the list of controller device (names) it can support (PHY framework does not
maintain a separate list for binding like how we had in USB PHY library). e.g.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92817.html. In such
this has nothing to do with $subject though. We talk about generic PHY
framework once all these PHY drivers are moved there :-)
cases how do we pass the device names. Also will the MUSB core device be
created before twl4030-usb PHY device?
and why would that be a problem ? We're telling the framework that the
musb device will use a phy with a name of 'twl4030'. If musb calls
usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and
try again later.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 06/21] ARM: OMAP: overo: use new display drivers
Hi,
On Friday 26 July 2013 12:38 PM, Tomi Valkeinen wrote:
Use the new display drivers for OMAP3 Overo board.
The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.
Note that the LCD add-on boards for lcd43 and lcd35 use the same GPIOs
for the panels. This means that both panel devices cannot be probed at
the same time.
DT will handle this correctly, i.e. the DT data will contain the panel
device only for the add-on board that is attached. However, for the
board file we need a hackish solution: We parse the kernel boot command
line, and see whether lcd43 or lcd35 is set as a default display, and
add the given one. Or, if neither is given, default to lcd43.
snip
static struct omap_dss_board_info overo_dss_data = {
- .num_devices= ARRAY_SIZE(overo_dss_devices),
- .devices= overo_dss_devices,
- .default_device = overo_dvi_device,
+ .default_display_name = lcd43,
};
The default display previously was the dvi device, if both lcd43 and
lcd35 are on add-on boards, then we should probably stick to dvi itself,
right? The hack won't work if dvi is the default device though.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
Hi,
On Tuesday 30 July 2013 11:48 AM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 11:41:23AM +0530, Kishon Vijay Abraham I wrote:
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 244d8a5..17bb076 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
omap_hsmmc_init(mmc);
omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA |
OMAP_PULL_UP);
- usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
+ usb_bind_phy(musb-hdrc.0, 0, twl4030_usb);
how about moving usb_bind_phy() calls to omap2430.c ?
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..b6abc1a 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device
*pdev)
pdata-board_data = data;
pdata-config = config;
+ } else {
+ /* bind the PHY */
+ usb_bind_phy(dev_name(musb-dev), 0, twl4030_usb);
This looks like a hack IMHO to workaround the usb phy library. otherwise
it is
similar to get_phy_by_name.
actually, this is a workaround to the fact that we're not creating all
platform_devices in arch/arm/mach-omap2/ :-)
If we had the musb allocation there, we could easily handle
usb_bind_phy()
so that's temporary. It might be better than to reintroduce the IDR in
musb_core.c.
that’s needed for generic phy framework anyway :-s
right, but generic phy framework can handle everything just fine, the
only problem is that names are changing.
right. But if the names change, PHY framework wouldn't be able to return
the
reference to the PHY.
with my suggestion they can change whenever they want since we're using
dev_name() of the just-created musb platform_device. Right ?
right. But the PHY device can be created in a different place from where the
musb devices are created. And in the PHY framework, the PHY device should
have
this shouldn't be a problem. As long as the phy is created, all should
be good.
the list of controller device (names) it can support (PHY framework does not
maintain a separate list for binding like how we had in USB PHY library).
e.g.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92817.html. In such
this has nothing to do with $subject though. We talk about generic PHY
framework once all these PHY drivers are moved there :-)
cases how do we pass the device names. Also will the MUSB core device be
created before twl4030-usb PHY device?
and why would that be a problem ? We're telling the framework that the
musb device will use a phy with a name of 'twl4030'. If musb calls
usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and
try again later.
I think we are talking about different problems here ;-) I'm trying to tell
using idr in MUSB core is needed for Generic PHY Framework. So in a way, the
Generic PHY Framework series depends on this patch series or else MUSB in OMAP3
platforms wont work after Generic PHY framework gets merged.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
Hi,
On Tue, Jul 30, 2013 at 11:55:04AM +0530, Kishon Vijay Abraham I wrote:
On Tue, Jul 30, 2013 at 11:41:23AM +0530, Kishon Vijay Abraham I wrote:
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 244d8a5..17bb076 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
omap_hsmmc_init(mmc);
omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA |
OMAP_PULL_UP);
-usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
+usb_bind_phy(musb-hdrc.0, 0, twl4030_usb);
how about moving usb_bind_phy() calls to omap2430.c ?
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..b6abc1a 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device
*pdev)
pdata-board_data = data;
pdata-config = config;
+ } else {
+ /* bind the PHY */
+ usb_bind_phy(dev_name(musb-dev), 0, twl4030_usb);
This looks like a hack IMHO to workaround the usb phy library.
otherwise it is
similar to get_phy_by_name.
actually, this is a workaround to the fact that we're not creating all
platform_devices in arch/arm/mach-omap2/ :-)
If we had the musb allocation there, we could easily handle
usb_bind_phy()
so that's temporary. It might be better than to reintroduce the IDR in
musb_core.c.
that’s needed for generic phy framework anyway :-s
right, but generic phy framework can handle everything just fine, the
only problem is that names are changing.
right. But if the names change, PHY framework wouldn't be able to return
the
reference to the PHY.
with my suggestion they can change whenever they want since we're using
dev_name() of the just-created musb platform_device. Right ?
right. But the PHY device can be created in a different place from where
the
musb devices are created. And in the PHY framework, the PHY device should
have
this shouldn't be a problem. As long as the phy is created, all should
be good.
the list of controller device (names) it can support (PHY framework does
not
maintain a separate list for binding like how we had in USB PHY library).
e.g.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92817.html. In
such
this has nothing to do with $subject though. We talk about generic PHY
framework once all these PHY drivers are moved there :-)
cases how do we pass the device names. Also will the MUSB core device be
created before twl4030-usb PHY device?
and why would that be a problem ? We're telling the framework that the
musb device will use a phy with a name of 'twl4030'. If musb calls
usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and
try again later.
I think we are talking about different problems here ;-) I'm trying to tell
using idr in MUSB core is needed for Generic PHY Framework. So in a way, the
Generic PHY Framework series depends on this patch series or else MUSB in
OMAP3
platforms wont work after Generic PHY framework gets merged.
then you just found a limitation in your framework, right ? :-) I mean,
imagine if now we have to add an IDR to every single user of your
framework because they could end up in systems with multiple instances
of the same IP ?
Now consider that you aim to have your framework be used by Network,
USB, SATA, Graphics, etc... Have you really only considered DT
platforms ? DT is quite easy since you can require folks to pass the
proper phandle, but drivers will want to use PLATFORM_DEVID_AUTO and
your framework needs to cope with that.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 06/21] ARM: OMAP: overo: use new display drivers
On 30/07/13 09:21, Archit Taneja wrote:
Hi,
On Friday 26 July 2013 12:38 PM, Tomi Valkeinen wrote:
Use the new display drivers for OMAP3 Overo board.
The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.
Note that the LCD add-on boards for lcd43 and lcd35 use the same GPIOs
for the panels. This means that both panel devices cannot be probed at
the same time.
DT will handle this correctly, i.e. the DT data will contain the panel
device only for the add-on board that is attached. However, for the
board file we need a hackish solution: We parse the kernel boot command
line, and see whether lcd43 or lcd35 is set as a default display, and
add the given one. Or, if neither is given, default to lcd43.
snip
static struct omap_dss_board_info overo_dss_data = {
-.num_devices= ARRAY_SIZE(overo_dss_devices),
-.devices= overo_dss_devices,
-.default_device= overo_dvi_device,
+.default_display_name = lcd43,
};
The default display previously was the dvi device, if both lcd43 and
lcd35 are on add-on boards, then we should probably stick to dvi itself,
right? The hack won't work if dvi is the default device though.
DVI is also on an add-on board, but it doesn't conflict with lcd43 or lcd35.
The hack works fine even if DVI is the default device. In that case, it
doesn't matter if lcd43 or lcd35 is added, because the user doesn't use
them (as long as only one of them is added, because otherwise there'll
be an error during probe).
If DVI is the default device, we could actually skip adding both lcd43
and lcd35. I just wanted to minimize the code in this hack, so I didn't
do that.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
Hi,
On Tuesday 30 July 2013 11:58 AM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 11:55:04AM +0530, Kishon Vijay Abraham I wrote:
On Tue, Jul 30, 2013 at 11:41:23AM +0530, Kishon Vijay Abraham I wrote:
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index 244d8a5..17bb076 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -233,7 +233,7 @@ static void __init omap_2430sdp_init(void)
omap_hsmmc_init(mmc);
omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA |
OMAP_PULL_UP);
-usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb);
+usb_bind_phy(musb-hdrc.0, 0, twl4030_usb);
how about moving usb_bind_phy() calls to omap2430.c ?
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..b6abc1a 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -544,6 +544,9 @@ static int omap2430_probe(struct platform_device
*pdev)
pdata-board_data = data;
pdata-config = config;
+ } else {
+ /* bind the PHY */
+ usb_bind_phy(dev_name(musb-dev), 0, twl4030_usb);
This looks like a hack IMHO to workaround the usb phy library.
otherwise it is
similar to get_phy_by_name.
actually, this is a workaround to the fact that we're not creating all
platform_devices in arch/arm/mach-omap2/ :-)
If we had the musb allocation there, we could easily handle
usb_bind_phy()
so that's temporary. It might be better than to reintroduce the IDR in
musb_core.c.
that’s needed for generic phy framework anyway :-s
right, but generic phy framework can handle everything just fine, the
only problem is that names are changing.
right. But if the names change, PHY framework wouldn't be able to return
the
reference to the PHY.
with my suggestion they can change whenever they want since we're using
dev_name() of the just-created musb platform_device. Right ?
right. But the PHY device can be created in a different place from where
the
musb devices are created. And in the PHY framework, the PHY device should
have
this shouldn't be a problem. As long as the phy is created, all should
be good.
the list of controller device (names) it can support (PHY framework does
not
maintain a separate list for binding like how we had in USB PHY library).
e.g.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92817.html. In
such
this has nothing to do with $subject though. We talk about generic PHY
framework once all these PHY drivers are moved there :-)
cases how do we pass the device names. Also will the MUSB core device be
created before twl4030-usb PHY device?
and why would that be a problem ? We're telling the framework that the
musb device will use a phy with a name of 'twl4030'. If musb calls
usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and
try again later.
I think we are talking about different problems here ;-) I'm trying to tell
using idr in MUSB core is needed for Generic PHY Framework. So in a way, the
Generic PHY Framework series depends on this patch series or else MUSB in
OMAP3
platforms wont work after Generic PHY framework gets merged.
then you just found a limitation in your framework, right ? :-) I mean,
imagine if now we have to add an IDR to every single user of your
framework because they could end up in systems with multiple instances
of the same IP ?
I raised a similar concern in the PHY framework discussion [1] :-) And since
it's used everywhere else regulators, clkdev, etc.. it's agreed to be used in
PHY as well. Btw if PLATFORM_DEVID_AUTO is used even regulator, clk_get should
fail IMO.
[1] - http://lkml.indiana.edu/hypermail/linux/kernel/1307.2/03573.html
Thanks
Kishon
--
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 0/3] ARM: dts: omap5-uevm: fixup wrong regulator configuration
* Benoit Cousson benoit.cous...@gmail.com [130729 15:24]: Hi Nishanth, Thanks for the quick update. On 29/07/2013 19:03, Nishanth Menon wrote: Due to wrong older revision of documentation used as reference, we seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This series is based power tree on production board 750-2628-XXX platform. Unfortunately, the wrong voltages may be detrimental to OMAP5 as they supply hardware blocks at voltages that are out of specification. Also available at: based on v3.11-rc1 tag http link: https://github.com/nmenon/linux-2.6-playground/commits/push/omap5-palmas-fixes-v2 git link: git://github.com/nmenon/linux-2.6-playground.git branch: push/omap5-palmas-fixes-v2 Changes since V1: - squash of patches - picked up Ack from Keerthy - based on v3.11-rc3 tag V1: http://marc.info/?t=13740798018r=1w=2 Nishanth Menon (3): ARM: dts: omap5-uevm: document regulator signals used on the actual board ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC ARM: dts: omap5-uevm: update optional/unused regulator configurations arch/arm/boot/dts/omap5-uevm.dts | 78 -- 1 file changed, 49 insertions(+), 29 deletions(-) Regards, Nishanth Menon For the whole series: Acked-by: Benoit Cousson benoit.cous...@gmail.com Thanks, I've applied these into omap-for-v3.11/fixes-omap5 and will send a pull request for these today as these seem quite urgent fixes. Regards, Tony -- 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/9] dma: edma: Find missed events and issue them
On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote: In an effort to move to using Scatter gather lists of any size with EDMA as discussed at [1] instead of placing limitations on the driver, we work through the limitations of the EDMAC hardware to find missed events and issue them. The sequence of events that require this are: For the scenario where MAX slots for an EDMA channel is 3: SG1 - SG2 - SG3 - SG4 - SG5 - SG6 - Null The above SG list will have to be DMA'd in 2 sets: (1) SG1 - SG2 - SG3 - Null (2) SG4 - SG5 - SG6 - Null After (1) is succesfully transferred, the events from the MMC controller donot stop coming and are missed by the time we have setup the transfer for (2). So here, we catch the events missed as an error condition and issue them manually. Are you sure there wont be any effect of these missed events on the peripheral side. For example, wont McASP get into an underrun condition when it encounters a null PaRAM set? Even UART has to transmit to a particular baud so I guess it cannot wait like the way MMC/SD can. Also, wont this lead to under-utilization of the peripheral bandwith? Meaning, MMC/SD is ready with data but cannot transfer because the DMA is waiting to be set-up. Did you consider a ping-pong scheme with say three PaRAM sets per channel? That way you can keep a continuous transfer going on from the peripheral over the complete SG list. Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: phy: rename nop_usb_xceiv = usb_phy_gen_xceiv
* Felipe Balbi ba...@ti.com [130729 05:27]: On Fri, Jul 26, 2013 at 10:15:54PM +0200, Sebastian Andrzej Siewior wrote: The nop driver isn't a do-nothing-stub but supports a couple functions like clock on/off or is able to use a voltage regulator. This patch simply renames the driver to generic since it is easy possible to extend it by a simple function istead of writing a complete driver. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de to me, this is great but I need Tony's Ack for it. Let's Cc Tony and linux-omap Looking at this patch there's a pretty high probability of introducing pointless merge conflicts. How about do the platform data related changes as a separate follow-up series? You can typically do this by keeping the old features around, then doing a separate series to rename or remove the users later on. This will remove the dependency between platform data and the driver changes. Regards, Tony -- 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 06/21] ARM: OMAP: overo: use new display drivers
On Tuesday 30 July 2013 12:09 PM, Tomi Valkeinen wrote:
On 30/07/13 09:21, Archit Taneja wrote:
Hi,
On Friday 26 July 2013 12:38 PM, Tomi Valkeinen wrote:
Use the new display drivers for OMAP3 Overo board.
The new OMAP display drivers were merged for 3.11, and we can now change
the board files to use the new ones and phase out the old ones.
Note that the LCD add-on boards for lcd43 and lcd35 use the same GPIOs
for the panels. This means that both panel devices cannot be probed at
the same time.
DT will handle this correctly, i.e. the DT data will contain the panel
device only for the add-on board that is attached. However, for the
board file we need a hackish solution: We parse the kernel boot command
line, and see whether lcd43 or lcd35 is set as a default display, and
add the given one. Or, if neither is given, default to lcd43.
snip
static struct omap_dss_board_info overo_dss_data = {
-.num_devices= ARRAY_SIZE(overo_dss_devices),
-.devices= overo_dss_devices,
-.default_device= overo_dvi_device,
+.default_display_name = lcd43,
};
The default display previously was the dvi device, if both lcd43 and
lcd35 are on add-on boards, then we should probably stick to dvi itself,
right? The hack won't work if dvi is the default device though.
DVI is also on an add-on board, but it doesn't conflict with lcd43 or lcd35.
The hack works fine even if DVI is the default device. In that case, it
doesn't matter if lcd43 or lcd35 is added, because the user doesn't use
them (as long as only one of them is added, because otherwise there'll
be an error during probe).
If DVI is the default device, we could actually skip adding both lcd43
and lcd35. I just wanted to minimize the code in this hack, so I didn't
do that.
Okay, thanks for the clarification, looks fine then.
Archit
--
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 01/15] drivers: phy: add generic PHY framework
On Sun, Jul 21, 2013 at 08:46:53AM -0700, Greg KH wrote:
On Sun, Jul 21, 2013 at 01:12:07PM +0200, Tomasz Figa wrote:
On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
Hi,
On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
Hi,
On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
On Sat, 20 Jul 2013, Greg KH wrote:
That should be passed using platform data.
Ick, don't pass strings around, pass pointers. If you have
platform
data you can get to, then put the pointer there, don't use a
name.
I don't think I understood you here :-s We wont have phy pointer
when we create the device for the controller no?(it'll be done in
board file). Probably I'm missing something.
Why will you not have that pointer? You can't rely on the name
as
the device id will not match up, so you should be able to rely on
the pointer being in the structure that the board sets up, right?
Don't use names, especially as ids can, and will, change, that is
going
to cause big problems. Use pointers, this is C, we are supposed to
be
doing that :)
Kishon, I think what Greg means is this: The name you are using
must
be stored somewhere in a data structure constructed by the board
file,
right? Or at least, associated with some data structure somehow.
Otherwise the platform code wouldn't know which PHY hardware
corresponded to a particular name.
Greg's suggestion is that you store the address of that data
structure
in the platform data instead of storing the name string. Have the
consumer pass the data structure's address when it calls phy_create,
instead of passing the name. Then you don't have to worry about two
PHYs accidentally ending up with the same name or any other similar
problems.
Close, but the issue is that whatever returns from phy_create()
should
then be used, no need to call any find functions, as you can just
use
the pointer that phy_create() returns. Much like all other class api
functions in the kernel work.
I think there is a confusion here about who registers the PHYs.
All platform code does is registering a platform/i2c/whatever device,
which causes a driver (located in drivers/phy/) to be instantiated.
Such drivers call phy_create(), usually in their probe() callbacks,
so platform_code has no way (and should have no way, for the sake of
layering) to get what phy_create() returns.
Why not put pointers in the platform data structure that can hold these
pointers? I thought that is why we created those structures in the
first place. If not, what are they there for?
heh, IMO we shouldn't pass pointers of any kind through platform_data,
we want to pass data :-)
Allowing to pass pointers through that, is one of the reasons which got
us in such a big mess in ARM land, well it was much easier for a
board-file/driver writer to pass a function pointer then to create a
generic framework :-)
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex cases
when passing just a name using platform data will not work. I would
second what Stephen said [1] and define a structure doing things in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods already
use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways when
devices get added to systems, making these strings constantly have to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes the
clock code wrong. Others have already said that this is wrong there as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we refuse to
learn from them...
So again, the find a phy by a string functions should be removed, the
device id should be automatically created by the phy core just to make
things unique in sysfs, and no driver code should _ever_ be reliant on
the number that is being created, and the pointer
Re: [PATCH 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
Hi, On Tue, Jul 30, 2013 at 12:16:20PM +0530, Kishon Vijay Abraham I wrote: the list of controller device (names) it can support (PHY framework does not maintain a separate list for binding like how we had in USB PHY library). e.g. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92817.html. In such this has nothing to do with $subject though. We talk about generic PHY framework once all these PHY drivers are moved there :-) cases how do we pass the device names. Also will the MUSB core device be created before twl4030-usb PHY device? and why would that be a problem ? We're telling the framework that the musb device will use a phy with a name of 'twl4030'. If musb calls usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and try again later. I think we are talking about different problems here ;-) I'm trying to tell using idr in MUSB core is needed for Generic PHY Framework. So in a way, the Generic PHY Framework series depends on this patch series or else MUSB in OMAP3 platforms wont work after Generic PHY framework gets merged. then you just found a limitation in your framework, right ? :-) I mean, imagine if now we have to add an IDR to every single user of your framework because they could end up in systems with multiple instances of the same IP ? I raised a similar concern in the PHY framework discussion [1] :-) And since it's used everywhere else regulators, clkdev, etc.. it's agreed to be used in PHY as well. Btw if PLATFORM_DEVID_AUTO is used even regulator, clk_get should fail IMO. [1] - http://lkml.indiana.edu/hypermail/linux/kernel/1307.2/03573.html look at Greg's and my reply to that email. -- balbi signature.asc Description: Digital signature
Re: [PATCHv6 1/2] drivers: spi: Add qspi flash controller
Hi Felipe,
On Monday 29 July 2013 06:05 PM, Felipe Balbi wrote:
Hi,
On Mon, Jul 29, 2013 at 04:45:02PM +0530, Sourav Poddar wrote:
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
+ dev_err(pdev-dev, no irq resource?\n);
+ return irq;
+ }
+
+ spin_lock_init(qspi-lock);
+
+ qspi-base = devm_ioremap_resource(pdev-dev, r);
+ if (IS_ERR(qspi-base)) {
+ ret = PTR_ERR(qspi-base);
+ goto free_master;
+ }
+
+ ret = devm_request_threaded_irq(pdev-dev, irq, ti_qspi_isr,
+ ti_qspi_threaded_isr, IRQF_NO_SUSPEND | IRQF_ONESHOT,
why do you need IRQF_NO_SUSPEND ?
I should get away with this.
why ? Do you need or do you *not* need it ? And in either case, why ?
I was thinking, this will keep the irqs up even when we are
hitting suspend, we will not be prepared to handle it. ?
won't be prepared in what way ?
Our driver will be down, so the irq might go un-serviced.
only if you wrote the driver that way. IRQ subsystem doesn't know the
state of the device, all it knows is that in case an IRQ fires, it needs
to call the registered IRQ handler.
Now the thing is:
Initially you had the flag setup, so I asked why you needed it. I
expected you to tell me why you think QSPI's IRQ shouldn't be disabled
during suspend and the implications of disabling it.
Instead you just changed your mind and decided to remove the flag.
Because you changed your mind with no explanation, that tells me you
haven't fully grasped how that flag works and what it means to set (or
not set) it.
My question now is simply: why don't you need that flag ? What are the
implications of setting that flag ? How would your driver behave if an
IRQ fired while your driver was suspended ? Unless you understand what
it does, how can you understand the behavior or the driver ?
cheers
We dont need IRQF_NO_SUSPEND flag in our qspi controller.
Qspi driver need to be prevented from receiving interrupts during system
wide suspend/hibernation.
suspend_device_irqs in kernel/irq/pm.c marks interrupt line in use and
sets IRQS_SUSPENDED
for them.
If we use IRQF_NO_SUSPEND, we will bypass setting this IRQS_SUSPENDED
flag, which is not.
desired
For this, interrupt lines need to
and this function is provided for this purpose.
* It marks all interrupt lines in use, except for the timer ones, as
disabled
* and sets the IRQS_SUSPENDED flag for each of them.
This flag gets used in __disable_irq api(kernel/irq/manage.c) which
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: phy: rename nop_usb_xceiv = usb_phy_gen_xceiv
On 07/30/2013 09:08 AM, Tony Lindgren wrote: Looking at this patch there's a pretty high probability of introducing pointless merge conflicts. How about do the platform data related changes as a separate follow-up series? You can typically do this by keeping the old features around, then doing a separate series to rename or remove the users later on. This will remove the dependency between platform data and the driver changes. I can do this. This will work of for the driver name but not for the name the platform_data struct. To address this part you could create a separate branch on top of -rc3 or so which contains only this change(s) and Felipe and you merge this branch so there won't be any conflicts. Regards, Tony Sebastian -- 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/4] usb: phy: phy-omap-control: Add API to power and wakeup
On 07/30/2013 06:53 AM, George Cherian wrote: Control module have 2 separate registers for phy on/off per instance (offset 0x620 and 0x628), where as wkup_ctrl is a shared control module register (offset 0x648). Currently the control module driver maps memory from 0x620 till beyond 0x648 and uses the same mapping for writing to wkup_reg. This I know about. My question is where do you remap this memory. You have to put the memory address somewhere. Sebastian -- 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: [PATCHv6 1/2] drivers: spi: Add qspi flash controller
Hi,
On Tue, Jul 30, 2013 at 01:04:28PM +0530, Sourav Poddar wrote:
Hi Felipe,
On Monday 29 July 2013 06:05 PM, Felipe Balbi wrote:
Hi,
On Mon, Jul 29, 2013 at 04:45:02PM +0530, Sourav Poddar wrote:
+ irq = platform_get_irq(pdev, 0);
+ if (irq 0) {
+ dev_err(pdev-dev, no irq resource?\n);
+ return irq;
+ }
+
+ spin_lock_init(qspi-lock);
+
+ qspi-base = devm_ioremap_resource(pdev-dev, r);
+ if (IS_ERR(qspi-base)) {
+ ret = PTR_ERR(qspi-base);
+ goto free_master;
+ }
+
+ ret = devm_request_threaded_irq(pdev-dev, irq, ti_qspi_isr,
+ ti_qspi_threaded_isr, IRQF_NO_SUSPEND |
IRQF_ONESHOT,
why do you need IRQF_NO_SUSPEND ?
I should get away with this.
why ? Do you need or do you *not* need it ? And in either case, why ?
I was thinking, this will keep the irqs up even when we are
hitting suspend, we will not be prepared to handle it. ?
won't be prepared in what way ?
Our driver will be down, so the irq might go un-serviced.
only if you wrote the driver that way. IRQ subsystem doesn't know the
state of the device, all it knows is that in case an IRQ fires, it needs
to call the registered IRQ handler.
Now the thing is:
Initially you had the flag setup, so I asked why you needed it. I
expected you to tell me why you think QSPI's IRQ shouldn't be disabled
during suspend and the implications of disabling it.
Instead you just changed your mind and decided to remove the flag.
Because you changed your mind with no explanation, that tells me you
haven't fully grasped how that flag works and what it means to set (or
not set) it.
My question now is simply: why don't you need that flag ? What are the
implications of setting that flag ? How would your driver behave if an
IRQ fired while your driver was suspended ? Unless you understand what
it does, how can you understand the behavior or the driver ?
cheers
We dont need IRQF_NO_SUSPEND flag in our qspi controller.
Qspi driver need to be prevented from receiving interrupts during
system wide suspend/hibernation.
suspend_device_irqs in kernel/irq/pm.c marks interrupt line in use
and sets IRQS_SUSPENDED
for them.
If we use IRQF_NO_SUSPEND, we will bypass setting this
IRQS_SUSPENDED flag, which is not.
desired
For this, interrupt lines need to
and this function is provided for this purpose.
* It marks all interrupt lines in use, except for the timer ones, as
disabled
* and sets the IRQS_SUSPENDED flag for each of them.
This flag gets used in __disable_irq api(kernel/irq/manage.c) which
some formatting issues in the mail, but good that you looked at the
code. Cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 1/4] usb: phy: rename nop_usb_xceiv = usb_phy_gen_xceiv
* Sebastian Andrzej Siewior bige...@linutronix.de [130730 00:41]: On 07/30/2013 09:08 AM, Tony Lindgren wrote: Looking at this patch there's a pretty high probability of introducing pointless merge conflicts. How about do the platform data related changes as a separate follow-up series? You can typically do this by keeping the old features around, then doing a separate series to rename or remove the users later on. This will remove the dependency between platform data and the driver changes. I can do this. This will work of for the driver name but not for the name the platform_data struct. To address this part you could create a separate branch on top of -rc3 or so which contains only this change(s) and Felipe and you merge this branch so there won't be any conflicts. A separate minimal branch against -rc3 sounds good to me. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
On Tuesday 30 July 2013 12:46 PM, Felipe Balbi wrote: Hi, On Tue, Jul 30, 2013 at 12:16:20PM +0530, Kishon Vijay Abraham I wrote: the list of controller device (names) it can support (PHY framework does not maintain a separate list for binding like how we had in USB PHY library). e.g. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92817.html. In such this has nothing to do with $subject though. We talk about generic PHY framework once all these PHY drivers are moved there :-) cases how do we pass the device names. Also will the MUSB core device be created before twl4030-usb PHY device? and why would that be a problem ? We're telling the framework that the musb device will use a phy with a name of 'twl4030'. If musb calls usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and try again later. I think we are talking about different problems here ;-) I'm trying to tell using idr in MUSB core is needed for Generic PHY Framework. So in a way, the Generic PHY Framework series depends on this patch series or else MUSB in OMAP3 platforms wont work after Generic PHY framework gets merged. then you just found a limitation in your framework, right ? :-) I mean, imagine if now we have to add an IDR to every single user of your framework because they could end up in systems with multiple instances of the same IP ? I raised a similar concern in the PHY framework discussion [1] :-) And since it's used everywhere else regulators, clkdev, etc.. it's agreed to be used in PHY as well. Btw if PLATFORM_DEVID_AUTO is used even regulator, clk_get should fail IMO. [1] - http://lkml.indiana.edu/hypermail/linux/kernel/1307.2/03573.html look at Greg's and my reply to that email. but finally Greg agreed to what Tomasz proposed no? Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
On Tue, Jul 30, 2013 at 01:41:23PM +0530, Kishon Vijay Abraham I wrote: On Tuesday 30 July 2013 12:46 PM, Felipe Balbi wrote: Hi, On Tue, Jul 30, 2013 at 12:16:20PM +0530, Kishon Vijay Abraham I wrote: the list of controller device (names) it can support (PHY framework does not maintain a separate list for binding like how we had in USB PHY library). e.g. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92817.html. In such this has nothing to do with $subject though. We talk about generic PHY framework once all these PHY drivers are moved there :-) cases how do we pass the device names. Also will the MUSB core device be created before twl4030-usb PHY device? and why would that be a problem ? We're telling the framework that the musb device will use a phy with a name of 'twl4030'. If musb calls usb_get_phy_dev() and doesn't find a phy, it'll return -EPROBE_DEFER and try again later. I think we are talking about different problems here ;-) I'm trying to tell using idr in MUSB core is needed for Generic PHY Framework. So in a way, the Generic PHY Framework series depends on this patch series or else MUSB in OMAP3 platforms wont work after Generic PHY framework gets merged. then you just found a limitation in your framework, right ? :-) I mean, imagine if now we have to add an IDR to every single user of your framework because they could end up in systems with multiple instances of the same IP ? I raised a similar concern in the PHY framework discussion [1] :-) And since it's used everywhere else regulators, clkdev, etc.. it's agreed to be used in PHY as well. Btw if PLATFORM_DEVID_AUTO is used even regulator, clk_get should fail IMO. [1] - http://lkml.indiana.edu/hypermail/linux/kernel/1307.2/03573.html look at Greg's and my reply to that email. but finally Greg agreed to what Tomasz proposed no? that's not what I see in the thread. I see Greg agreed to regulator's own IDs being sequentially created, but he mentions device names can change. -- balbi signature.asc Description: Digital signature
Re: [PATCH 7/9] ARM: edma: Don't clear EMR of channel in edma_stop
On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote: We certainly don't want error conditions to be cleared anywhere 'anywhere' is a really loaded term. as this will make us 'forget' about missed events. We depend on knowing which events were missed in order to be able to reissue them. This fixes a race condition where the EMR was being cleared by the transfer completion interrupt handler. Basically, what was happening was: Missed event | | V SG1-SG2-SG3-Null \ \__TC Interrupt (Almost same time as ARM is executing TC interrupt handler, an event got missed and also forgotten by clearing the EMR). Sorry, but I dont see how edma_stop() is coming into picture in the race you describe? The EMR is ultimately being cleared by the Error interrupt handler once it is handled so we don't have to do it in edma_stop. This, I agree with. edma_clean_channel() also there to re-initialize the channel so doing it in edma_stop() certainly seems superfluous. Thanks, Sekhar Signed-off-by: Joel Fernandes jo...@ti.com --- arch/arm/common/edma.c |1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 10995b2..dec772e 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1328,7 +1328,6 @@ void edma_stop(unsigned channel) edma_shadow0_write_array(ctlr, SH_EECR, j, mask); edma_shadow0_write_array(ctlr, SH_ECR, j, mask); edma_shadow0_write_array(ctlr, SH_SECR, j, mask); - edma_write_array(ctlr, EDMA_EMCR, j, mask); pr_debug(EDMA: EER%d %08x\n, j, edma_shadow0_read_array(ctlr, SH_EER, j)); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/4] phy: phy-amxxxx-usb: Add PHY driver for amxxxx platform
On 07/30/2013 07:19 AM, George Cherian wrote: So from what I see now, it is most likely the easiest thing to just add that wakeup to the phy driver I posted. Do you agree? The whole idea of writing a seperate phy driver was to use the generic phy framework and most of the am devices have the same phy (eg am335x, am437x). Now since the register is shared in am335x for phy_wkup (Not in the case of am437x) how are you planning to map it. I feel if omap_control_usb can delegate the writes to phy_wkup, phy_on and phy_off, it makes the life simpler. that omap-control driver looks a little strange. It has a compatible field saying ti,omap-control-usb and then it requires additionally a ti,type property which should have been avoided. But back to the initial problem. I don't really like the idea of touching in the control-module registers but others do it as well. So the idea of a control driver doesn't sound that bad. - an am335x-reset device - a phy driver with a reference to that reset device. - non-standard phy calls for power wak eup on/off. Let me think about it. Thoughts??? I think I buy it but give me a bit… Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] usb: phy: rename nop_usb_xceiv = usb_phy_gen_xceiv
On 07/30/2013 09:56 AM, Tony Lindgren wrote: A separate minimal branch against -rc3 sounds good to me. Great. Felipe, can you please put this change in a separate -rc3 based branch which you and Tony will pull in? Regards, Tony Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] serial: omap: enable PM runtime only when its fully configured
On Tue, 30 Jul 2013, Rajendra Nayak wrote: Looks like this one is already been queued by Greg. OK, thanks for letting me know; I've dropped 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] ARM: v6: prevent gcc from reordering extended CP15 reads above is_smp() test
Hi Will On Mon, 29 Jul 2013, Will Deacon wrote: I wouldn't worry about checking for CPU_V6. Besides, we probably need this to be re-evaluated across barrier() when we get CPU migration on a big-little platform anyway (we should probably also drop the __attribute_const__ for that). So you can just replace the cc (now that Nico kindly explained why those aren't needed the other day) with memory. An alternative is to add barrier() between is_smp() and the read_cpuid_ext() in all callers, adding a fake read from the stack to the latter (like I did for the per-cpu accessor). However, this relies on fixing all callers for very little gain, so I don't think it's worth the hassle. I can cook a patch if you're tied up with other things -- just let me know. Makes sense to me. Have respun the patch and will post it shortly. Thanks for the extra compiler research; it's been incorporated into the patch description and comments. - 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
[PATCH v2 3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
From: R Sricharan r.sricha...@ti.com The PRCM and MPUSS parts of DRA7 devices are quite identical to OMAP5 so as to reuse all the existing infrastructure around it. Makefile updates to do just that. Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/Makefile |8 1 file changed, 8 insertions(+) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index d4f6715..17fb8b7 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_ARCH_OMAP4) += prm44xx.o $(hwmod-common) $(secure-common) obj-$(CONFIG_SOC_AM33XX) += irq.o $(hwmod-common) obj-$(CONFIG_SOC_OMAP5) += prm44xx.o $(hwmod-common) $(secure-common) obj-$(CONFIG_SOC_AM43XX) += $(hwmod-common) $(secure-common) +obj-$(CONFIG_SOC_DRA7XX) += prm44xx.o $(hwmod-common) $(secure-common) ifneq ($(CONFIG_SND_OMAP_SOC_MCBSP),) obj-y += mcbsp.o @@ -39,6 +40,7 @@ omap-4-5-common = omap4-common.o omap-wakeupgen.o obj-$(CONFIG_ARCH_OMAP4) += $(omap-4-5-common) $(smp-y) sleep44xx.o obj-$(CONFIG_SOC_OMAP5)+= $(omap-4-5-common) $(smp-y) sleep44xx.o obj-$(CONFIG_SOC_AM43XX) += $(omap-4-5-common) +obj-$(CONFIG_SOC_DRA7XX) += $(omap-4-5-common) $(smp-y) plus_sec := $(call as-instr,.arch_extension sec,+sec) AFLAGS_omap-headsmp.o :=-Wa,-march=armv7-a$(plus_sec) @@ -87,6 +89,7 @@ obj-$(CONFIG_ARCH_OMAP2) += sleep24xx.o obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o obj-$(CONFIG_SOC_OMAP5)+= omap-mpuss-lowpower.o +obj-$(CONFIG_SOC_DRA7XX) += omap-mpuss-lowpower.o obj-$(CONFIG_PM_DEBUG) += pm-debug.o obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o @@ -114,6 +117,7 @@ omap-prcm-4-5-common= cminst44xx.o cm44xx.o prm44xx.o \ vc44xx_data.o vp44xx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common) obj-$(CONFIG_SOC_OMAP5)+= $(omap-prcm-4-5-common) +obj-$(CONFIG_SOC_DRA7XX) += $(omap-prcm-4-5-common) # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o @@ -143,6 +147,7 @@ obj-$(CONFIG_SOC_AM33XX)+= powerdomains33xx_data.o obj-$(CONFIG_SOC_AM43XX) += $(powerdomain-common) obj-$(CONFIG_SOC_OMAP5)+= $(powerdomain-common) obj-$(CONFIG_SOC_OMAP5)+= powerdomains54xx_data.o +obj-$(CONFIG_SOC_DRA7XX) += $(powerdomain-common) # PRCM clockdomain control clockdomain-common += clockdomain.o @@ -160,6 +165,7 @@ obj-$(CONFIG_SOC_AM33XX)+= clockdomains33xx_data.o obj-$(CONFIG_SOC_AM43XX) += $(clockdomain-common) obj-$(CONFIG_SOC_OMAP5)+= $(clockdomain-common) obj-$(CONFIG_SOC_OMAP5)+= clockdomains54xx_data.o +obj-$(CONFIG_SOC_DRA7XX) += $(clockdomain-common) # Clock framework obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)+= $(clock-common) dpll3xxx.o obj-$(CONFIG_SOC_AM33XX) += cclock33xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(clock-common) obj-$(CONFIG_SOC_OMAP5)+= dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_DRA7XX) += $(clock-common) +obj-$(CONFIG_SOC_DRA7XX) += dpll3xxx.o dpll44xx.o # OMAP2 clock rate set data (old OPP data) obj-$(CONFIG_SOC_OMAP2420) += opp2420_data.o -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
From: R Sricharan r.sricha...@ti.com
Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved. Also added in the board file are pin configuration
details for i2c, mcspi and uart devices on board.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/Makefile |3 +-
arch/arm/boot/dts/dra7-evm.dts | 163 ++
arch/arm/boot/dts/dra7.dtsi| 488
3 files changed, 653 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/dra7-evm.dts
create mode 100644 arch/arm/boot/dts/dra7.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..e2f8566 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -173,7 +173,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-bone.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
- am43x-epos-evm.dtb
+ am43x-epos-evm.dtb \
+ dra7-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
new file mode 100644
index 000..7b0b563
--- /dev/null
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -0,0 +1,163 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ dra7.dtsi
+
+/ {
+ model = TI DRA7;
+ compatible = ti,dra7-evm, ti,dra7;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x6000; /* 1536 MB */
+ };
+};
+
+dra7_pmx_core {
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins =
+ 0x400 0x6 /* i2c1_sda */
+ 0x404 0x6 /* i2c1_scl */
+ ;
+ };
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins =
+ 0x408 0x6 /* i2c2_sda */
+ 0x40c 0x6 /* i2c2_scl */
+ ;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins =
+ 0x410 0x6 /* i2c3_sda */
+ 0x414 0x6 /* i2c3_scl */
+ ;
+ };
+
+ mcspi1_pins: pinmux_mcspi1_pins {
+ pinctrl-single,pins =
+ 0x3a4 0x4 /* spi2_clk */
+ 0x3a8 0x4 /* spi2_d1 */
+ 0x3ac 0x4 /* spi2_d0 */
+ 0x3b0 0xc /* spi2_cs0 */
+ 0x3b4 0xc /* spi2_cs1 */
+ 0x3b8 0xe0006 /* spi2_cs2 */
+ 0x3bc 0xe0006 /* spi2_cs3 */
+ ;
+ };
+
+ mcspi2_pins: pinmux_mcspi2_pins {
+ pinctrl-single,pins =
+ 0x3c0 0x4 /* spi2_sclk */
+ 0x3c4 0xc /* spi2_d1 */
+ 0x3c8 0xc /* spi2_d1 */
+ 0x3cc 0xe /* spi2_cs0 */
+ ;
+ };
+
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins =
+ 0x3e0 0xe /* uart1_rxd */
+ 0x3e4 0xe /* uart1_txd */
+ 0x3e8 0x60003 /* uart1_ctsn */
+ 0x3ec 0x60003 /* uart1_rtsn */
+ ;
+ };
+
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins =
+ 0x3f0 0x6 /* uart2_rxd */
+ 0x3f4 0x6 /* uart2_txd */
+ 0x3f8 0x6 /* uart2_ctsn */
+ 0x3fc 0x6 /* uart2_rtsn */
+ ;
+ };
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x248 0xc /* uart3_rxd */
+ 0x24c 0xc /* uart3_txd */
+ ;
+ };
+};
+
+i2c1 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_pins;
+
+ clock-frequency = 40;
+};
+
+i2c2 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c2_pins;
+
+ clock-frequency = 40;
+};
+
+i2c3 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c3_pins;
+
+ clock-frequency = 340;
+};
+
+i2c4 {
+ status = disabled;
+};
+
+i2c5 {
+ status = disabled;
+};
+
+mcspi1 {
+ pinctrl-names = default;
+ pinctrl-0 = mcspi1_pins;
+};
+
+mcspi2 {
+ pinctrl-names =
[PATCH v2 5/8] ARM: DRA7: Resue the clocksource, clockevent support
From: R Sricharan r.sricha...@ti.com All of OMAP5 timer support for clocksource and clockevent is completely reused across DRA7. Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/mach-omap2/Kconfig |2 +- arch/arm/mach-omap2/timer.c |3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 3eed000..fc6ec23 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -132,7 +132,7 @@ config SOC_HAS_OMAP2_SDRC config SOC_HAS_REALTIME_COUNTER bool Real time free running counter - depends on SOC_OMAP5 + depends on SOC_OMAP5 || SOC_DRA7XX default y comment OMAP Core Type diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index b37e1fc..1e77f11 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -594,7 +594,8 @@ OMAP_SYS_GP_TIMER_INIT(3, 2, timer_sys_ck, NULL, 1, timer_sys_ck, ti,timer-alwon); #endif -#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) +#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \ + defined(CONFIG_SOC_DRA7XX) static OMAP_SYS_32K_TIMER_INIT(4, 1, timer_32k_ck, ti,timer-alwon, 2, sys_clkin_ck, NULL); #endif -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/8] ARM: DRA7: board-generic: Add basic DT support
From: R Sricharan r.sricha...@ti.com
Describe minimal DT boot machine details for DRA7xx based SoC's. DRA7xx
family is based on dual core ARM CORTEX A15 using GIC as the interrupt
controller.
The PRCM and timer infrastructure is reused from OMAP5 and so are the io
descriptor tables.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
.../devicetree/bindings/arm/omap/omap.txt |3 +++
arch/arm/mach-omap2/board-generic.c| 18 ++
2 files changed, 21 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 6d498c7..91b7049 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -59,3 +59,6 @@ Boards:
- AM43x EPOS EVM
compatible = ti,am43x-epos-evm, ti,am4372, ti,am43
+
+- DRA7 EVM: Software Developement Board for DRA7XX
+ compatible = ti,dra7-evm, ti,dra7
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index be5d005..b89e55b 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -222,3 +222,21 @@ DT_MACHINE_START(AM43_DT, Generic AM43 (Flattened Device
Tree))
.dt_compat = am43_boards_compat,
MACHINE_END
#endif
+
+#ifdef CONFIG_SOC_DRA7XX
+static const char *dra7xx_boards_compat[] __initdata = {
+ ti,dra7,
+ NULL,
+};
+
+DT_MACHINE_START(DRA7XX_DT, Generic DRA7XX (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .smp= smp_ops(omap4_smp_ops),
+ .map_io = omap5_map_io,
+ .init_early = dra7xx_init_early,
+ .init_irq = omap_gic_of_init,
+ .init_machine = omap_generic_init,
+ .init_time = omap5_realtime_timer_init,
+ .dt_compat = dra7xx_boards_compat,
+MACHINE_END
+#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/8] ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5
The soc_ops for dra7xx devices can be completed reused
from the ones used for omap4 and omap5 devices.
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 7341eff..f6eb29b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -4113,7 +4113,7 @@ void __init omap_hwmod_init(void)
soc_ops.assert_hardreset = _omap2_assert_hardreset;
soc_ops.deassert_hardreset = _omap2_deassert_hardreset;
soc_ops.is_hardreset_asserted = _omap2_is_hardreset_asserted;
- } else if (cpu_is_omap44xx() || soc_is_omap54xx()) {
+ } else if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
soc_ops.enable_module = _omap4_enable_module;
soc_ops.disable_module = _omap4_disable_module;
soc_ops.wait_target_ready = _omap4_wait_target_ready;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/8] DRA7xx core support
Changes in v2: -1- Fixed minor changelog details -2- Dropped the SRAM support patch since we need to move to drivers/misc/sram.c -3- Added DTS update patches to this series which were earlier posted as part of the data series (Since they don't have much objections as against the other in-kernel data files) -4- Updated the EVM dts file with pin config details for uart/mcspi and i2c DRA7xx based SoCs' are high-performance, infotainment application devices, based on enhanced OMAP architecture integrated on a 28nm technology. The DRA7xx family is composed of DRA75x and DRA74x devices. The current device for which the patches add support is the DRA752 SoC. Most of the core IPs are similar to those found on the OMAP5 devices, including the dual cortex-A15 based MPU subsystem, which has helped quite some reuse from existing OMAP5 support. This series contains only core support patches and none of the PRCM and hwmod data needed for the device to boot. The bootloader support for the platform is already available in mainline u-boot. The patches posted in this series are available at: git://github.com/rrnayak/linux.git for-3.12/dra-core-v2 The patches (including the ones for in-kernel data) which boot on dra7xx evm are available at: t://github.com/rrnayak/linux.git out-of-tree/dra-integrated-v2 R Sricharan (7): ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs' ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra ARM: DRA7: Reuse io tables and add a new .init_early ARM: DRA7: Resue the clocksource, clockevent support ARM: DRA7: board-generic: Add basic DT support ARM: DRA7: Kconfig: Make ARCH_NR_GPIO default to 512 ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board Rajendra Nayak (1): ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5 .../devicetree/bindings/arm/omap/omap.txt |3 + arch/arm/Kconfig |2 +- arch/arm/boot/dts/Makefile |3 +- arch/arm/boot/dts/dra7-evm.dts | 163 +++ arch/arm/boot/dts/dra7.dtsi| 488 arch/arm/mach-omap1/include/mach/soc.h |1 + arch/arm/mach-omap2/Kconfig|2 +- arch/arm/mach-omap2/Makefile |8 + arch/arm/mach-omap2/board-generic.c| 18 + arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/id.c | 30 +- arch/arm/mach-omap2/io.c | 22 +- arch/arm/mach-omap2/omap54xx.h |4 + arch/arm/mach-omap2/omap_hwmod.c |2 +- arch/arm/mach-omap2/soc.h | 39 ++ arch/arm/mach-omap2/timer.c|3 +- 16 files changed, 780 insertions(+), 9 deletions(-) create mode 100644 arch/arm/boot/dts/dra7-evm.dts create mode 100644 arch/arm/boot/dts/dra7.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 v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
From: R Sricharan r.sricha...@ti.com
The DRA7xx is a high-performance, infotainment application device,
based on enhanced OMAP architecture integrated on a 28-nm technology.
DRA7xx family is composed of DRA75x and DRA74x devices.
Adding the DRA752 ES1.0 cpu revision detection support.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap1/include/mach/soc.h |1 +
arch/arm/mach-omap2/id.c | 30 ++--
arch/arm/mach-omap2/soc.h | 39
3 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/include/mach/soc.h
b/arch/arm/mach-omap1/include/mach/soc.h
index 6cf9c1c..612bd1c 100644
--- a/arch/arm/mach-omap1/include/mach/soc.h
+++ b/arch/arm/mach-omap1/include/mach/soc.h
@@ -195,6 +195,7 @@ IS_OMAP_TYPE(1710, 0x1710)
#define cpu_is_omap34xx() 0
#define cpu_is_omap44xx() 0
#define soc_is_omap54xx() 0
+#define soc_is_dra7xx()0
#define soc_is_am33xx()0
#define cpu_class_is_omap1() 1
#define cpu_class_is_omap2() 0
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2dc62a2..332ae95 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -61,7 +61,7 @@ int omap_type(void)
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
} else if (cpu_is_omap44xx()) {
val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
- } else if (soc_is_omap54xx()) {
+ } else if (soc_is_omap54xx() || soc_is_dra7xx()) {
val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
val = OMAP5_DEVICETYPE_MASK;
val = 6;
@@ -116,7 +116,7 @@ static u16 tap_prod_id;
void omap_get_die_id(struct omap_die_id *odi)
{
- if (cpu_is_omap44xx() || soc_is_omap54xx()) {
+ if (cpu_is_omap44xx() || soc_is_omap54xx() || soc_is_dra7xx()) {
odi-id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0);
odi-id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1);
odi-id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2);
@@ -606,6 +606,32 @@ void __init omap5xxx_check_revision(void)
pr_info(%s %s\n, soc_name, soc_rev);
}
+void __init dra7xx_check_revision(void)
+{
+ u32 idcode;
+ u16 hawkeye;
+ u8 rev;
+
+ idcode = read_tap_reg(OMAP_TAP_IDCODE);
+ hawkeye = (idcode 12) 0x;
+ rev = (idcode 28) 0xff;
+ switch (hawkeye) {
+ case 0xb990:
+ switch (rev) {
+ case 0:
+ default:
+ omap_revision = DRA752_REV_ES1_0;
+ }
+ break;
+ default:
+ /* Unknown. Default to latest silicon revision */
+ omap_revision = DRA752_REV_ES1_0;
+ }
+
+ pr_info(DRA%03x ES%d.%d\n, omap_rev() 16,
+ ((omap_rev() 12) 0xf), ((omap_rev() 8) 0xf));
+}
+
/*
* Set up things for map_io and processor detection later on. Gets called
* pretty much first thing from board init. For multi-omap, this gets
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 8c616e4..0d242f1 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -8,6 +8,7 @@
* Written by Tony Lindgren tony.lindg...@nokia.com
*
* Added OMAP4/5 specific defines - Santosh Shilimkarsantosh.shilim...@ti.com
+ * Added DRA7xxx specific defines - Sricharan Rr.sricha...@ti.com
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -105,6 +106,15 @@
# endif
#endif
+#ifdef CONFIG_SOC_DRA7XX
+# ifdef OMAP_NAME
+# undef MULTI_OMAP2
+# define MULTI_OMAP2
+# else
+# define OMAP_NAME DRA7XX
+# endif
+#endif
+
/*
* Omap device type i.e. EMU/HS/TST/GP/BAD
*/
@@ -145,6 +155,7 @@ static inline int soc_is_omap(void)
* cpu_is_omap446x(): True for OMAP4460
* cpu_is_omap447x(): True for OMAP4470
* soc_is_omap543x(): True for OMAP5430, OMAP5432
+ * soc_is_dra75x():True for DRA752, DRA754, DRA756
*/
#define GET_OMAP_CLASS (omap_rev() 0xff)
@@ -170,6 +181,12 @@ static inline int is_ti ##class (void) \
return (GET_TI_CLASS == (id)) ? 1 : 0; \
}
+#define IS_DRA_CLASS(class, id)\
+static inline int is_dra ##class(void) \
+{ \
+ return (GET_OMAP_CLASS == (id)) ? 1 : 0;\
+}
+
#define GET_OMAP_SUBCLASS ((omap_rev() 20) 0x0fff)
#define IS_OMAP_SUBCLASS(subclass, id) \
@@ -190,6 +207,12 @@ static inline int is_am ##subclass (void) \
return (GET_OMAP_SUBCLASS == (id)) ? 1 : 0; \
}
+#define IS_DRA_SUBCLASS(subclass, id) \
+static inline int is_dra
[PATCH v2 4/8] ARM: DRA7: Reuse io tables and add a new .init_early
From: R Sricharan r.sricha...@ti.com
The IO descriptor tables for DRA7 are a complete reuse from OMAP5.
A new dra7xx_init_early() does the base address inits.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/io.c | 22 --
arch/arm/mach-omap2/omap54xx.h |4
3 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index dfcc182..4a5684b 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -110,6 +110,7 @@ void omap3630_init_late(void);
void am35xx_init_late(void);
void ti81xx_init_late(void);
int omap2_common_pm_late_init(void);
+void dra7xx_init_early(void);
#ifdef CONFIG_SOC_BUS
void omap_soc_device_init(void);
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4a3f06f..44aa4f0 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -251,7 +251,7 @@ static struct map_desc omap44xx_io_desc[] __initdata = {
};
#endif
-#ifdef CONFIG_SOC_OMAP5
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
static struct map_desc omap54xx_io_desc[] __initdata = {
{
.virtual= L3_54XX_VIRT,
@@ -333,7 +333,7 @@ void __init omap4_map_io(void)
}
#endif
-#ifdef CONFIG_SOC_OMAP5
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
void __init omap5_map_io(void)
{
iotable_init(omap54xx_io_desc, ARRAY_SIZE(omap54xx_io_desc));
@@ -653,6 +653,24 @@ void __init omap5_init_early(void)
}
#endif
+#ifdef CONFIG_SOC_DRA7XX
+void __init dra7xx_init_early(void)
+{
+ omap2_set_globals_tap(DRA7XX_CLASS,
+ OMAP2_L4_IO_ADDRESS(DRA7XX_TAP_BASE));
+ omap2_set_globals_control(OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
+ OMAP2_L4_IO_ADDRESS(DRA7XX_CTRL_BASE));
+ omap2_set_globals_prm(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE));
+ omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(DRA7XX_CM_CORE_AON_BASE),
+OMAP2_L4_IO_ADDRESS(OMAP54XX_CM_CORE_BASE));
+ omap2_set_globals_prcm_mpu(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRCM_MPU_BASE));
+ omap_prm_base_init();
+ omap_cm_base_init();
+ dra7xx_check_revision();
+}
+#endif
+
+
void __init omap_sdrc_init(struct omap_sdrc_params *sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1)
{
diff --git a/arch/arm/mach-omap2/omap54xx.h b/arch/arm/mach-omap2/omap54xx.h
index a086ba1..2d35c57 100644
--- a/arch/arm/mach-omap2/omap54xx.h
+++ b/arch/arm/mach-omap2/omap54xx.h
@@ -30,4 +30,8 @@
#define OMAP54XX_CTRL_BASE 0x4a002800
#define OMAP54XX_SAR_RAM_BASE 0x4ae26000
+#define DRA7XX_CM_CORE_AON_BASE0x4a005000
+#define DRA7XX_CTRL_BASE 0x4a003400
+#define DRA7XX_TAP_BASE0x4ae0c000
+
#endif /* __ASM_SOC_OMAP54XX_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/8] ARM: DRA7: Kconfig: Make ARCH_NR_GPIO default to 512
From: R Sricharan r.sricha...@ti.com DRA7xx has 8 GPIO banks so that there are 32x8 = 256 GPIOs. In order for the gpiolib to detect and initialize these and other TWL GPIOs, ARCH_NR_GPIO is set to 512 using the kconfig default for DRA7. Signed-off-by: R Sricharan r.sricha...@ti.com Signed-off-by: Rajendra Nayak rna...@ti.com --- arch/arm/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 37c0f4e..b9e64f2 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1600,7 +1600,7 @@ config LOCAL_TIMERS config ARCH_NR_GPIO int default 1024 if ARCH_SHMOBILE || ARCH_TEGRA - default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 + default 512 if ARCH_EXYNOS || ARCH_KEYSTONE || SOC_OMAP5 || SOC_DRA7XX default 392 if ARCH_U8500 default 352 if ARCH_VT8500 default 288 if ARCH_SUNXI -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: v6: prevent gcc 4.5 from reordering extended CP15 reads above is_smp() test
Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc (ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting) breaks
the boot on OMAP2430SDP with omap2plus_defconfig. Tracked to an
undefined instruction abort from the CP15 read in
cache_ops_need_broadcast(). It turns out that gcc 4.5 reorders the
extended CP15 read above the is_smp() test. This breaks ARM1136 r0
cores, since they don't support several CP15 registers that later ARM
cores do. ARM1136JF-S TRM section 3.2.1 Register allocation has the
details.
So mark the extended CP15 read as clobbering memory, which prevents
the compiler from reordering it before the is_smp() test. Russell
states that the code generated from this approach is preferable to
marking the inline asm as volatile. Remove the existing condition
code clobber as it's obsolete, per Nico's post:
http://www.spinics.net/lists/arm-kernel/msg261208.html
This patch is a collaboration with Will Deacon and Russell King.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Will Deacon will.dea...@arm.com
Cc: Russell King rmk+ker...@arm.linux.org.uk
Cc: Nicolas Pitre nicolas.pi...@linaro.org
Cc: Tony Lindgren t...@atomide.com
---
Intended for v3.11-rc.
Basic test logs available here:
http://www.pwsan.com/omap/testlogs/bisect_2430sdp_hang_v3.11-rc/20130730045715/
N.B., several boards have problems on v3.11-rc that are unrelated to this
patch.
arch/arm/include/asm/cputype.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
index 8c25dc4..9672e97 100644
--- a/arch/arm/include/asm/cputype.h
+++ b/arch/arm/include/asm/cputype.h
@@ -89,13 +89,18 @@ extern unsigned int processor_id;
__val; \
})
+/*
+ * The memory clobber prevents gcc 4.5 from reordering the mrc before
+ * any is_smp() tests, which can cause undefined instruction aborts on
+ * ARM1136 r0 due to the missing extended CP15 registers.
+ */
#define read_cpuid_ext(ext_reg)
\
({ \
unsigned int __val; \
asm(mrcp15, 0, %0, c0, ext_reg \
: =r (__val) \
: \
- : cc);\
+ : memory);\
__val; \
})
--
1.8.3.2
--
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
[GIT PULL] ARM: OMAP2+: hwmod fixes for v3.11-rc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 5ae90d8e467e625e447000cb4335c4db973b1095: Linux 3.11-rc3 (2013-07-28 20:53:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.11-rc/omap-fixes-b for you to fetch changes up to 50c2a3a1518befe992f868fc1fd867bdad9776ad: ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space (2013-07-30 05:13:37 -0600) - Some OMAP hwmod fixes for v3.11-rc. Mostly intended to fix an earlyprintk regression and an AM33xx cpgmac power management regression. Basic build, boot, and PM tests are available here: http://www.pwsan.com/omap/testlogs/hwmod_fixes_a_v3.11-rc/20130730042132/ The tests include temporary fixes for the unrelated 2430SDP and OMAP3 boot regressions, which are not part of this signed tag. - Afzal Mohammed (2): ARM: OMAP2+: hwmod: rt address space index for DT ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space Rajendra Nayak (3): ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL ARM: OMAP2+: Avoid idling memory controllers with no drivers ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device state arch/arm/mach-omap2/omap_device.c | 18 arch/arm/mach-omap2/omap_hwmod.c | 2 +- arch/arm/mach-omap2/omap_hwmod.h | 50 ++ arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 6 +-- arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 3 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 9 ++-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 5 +-- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 3 +- arch/arm/mach-omap2/serial.c | 11 - 9 files changed, 83 insertions(+), 24 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBAgAGBQJR96GBAAoJEMePsQ0LvSpLnDcP/Aw52rbj9buMgOsD9vcuL/N/ 7pthVnpdCZXoammCy42QaiBFrB56rhSP25MwCdsj1wThLDvcGDRWaplzHOUQvf8g K0t2aDzIjXlZZ4sGj16/3gX97RvDM+648skmReEISWpl0J93XRcb+8hwHh3GT7CA agnM8uWKBfBn8k453CGx24qCuo3Pa/XhCuqgSYqsRBuLyXDl9QuAgyrDE7GOGtET c1CapT7skrJGQKIg7ZuAN3P4iY2UwohL9kA3Fa5cGuIdDl31SKvK22ESnPrFOPX/ qJW+Bkw72j8PI68hVOIkUw2SDsjyIYXQ+fXKi3alLu98WMaA7e84KeC7Xo3yT9l5 Y7DkdsTCoLVirwVsiJx05ohPYkfs0NMJDS9pT28h2WQfmQxny5gEBAXXSyPk/mtG Cltc0gcDqlGO6MWh0PrpKU6TXR1aAN/QUK1n7EBTLtwNu+nFEArtn0g4WkqQlfrq yfLppVzDHUJnPe816g7DLt32V2qMLPJaPppC90pX+6G2+8+BampbL5Fj9OQ9tR2Q KDwT60kcKtq7xDD4po+W7c1lMBLcVlVbHMCjk4kbPvbI0NF8NBMyAcXYjgMVJmu0 BYBrp7M8WYRkon9XsYjlyBaGYrJ4IeLSW4TwxH48Ma/xPnatEFRkynvKVgFGZFi8 wogioQkMcv84GA3e6VmT =Qr73 -END PGP SIGNATURE- -- 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 0/3] ARM: dts: omap5-uevm: fixup wrong regulator configuration
On Tue, Jul 30, 2013 at 1:52 AM, Tony Lindgren t...@atomide.com wrote: * Benoit Cousson benoit.cous...@gmail.com [130729 15:24]: On 29/07/2013 19:03, Nishanth Menon wrote: Due to wrong older revision of documentation used as reference, we seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This series is based power tree on production board 750-2628-XXX platform. Unfortunately, the wrong voltages may be detrimental to OMAP5 as they supply hardware blocks at voltages that are out of specification. Also available at: based on v3.11-rc1 tag http link: https://github.com/nmenon/linux-2.6-playground/commits/push/omap5-palmas-fixes-v2 git link: git://github.com/nmenon/linux-2.6-playground.git branch: push/omap5-palmas-fixes-v2 Changes since V1: - squash of patches - picked up Ack from Keerthy - based on v3.11-rc3 tag V1: http://marc.info/?t=13740798018r=1w=2 Nishanth Menon (3): ARM: dts: omap5-uevm: document regulator signals used on the actual board ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC ARM: dts: omap5-uevm: update optional/unused regulator configurations arch/arm/boot/dts/omap5-uevm.dts | 78 -- 1 file changed, 49 insertions(+), 29 deletions(-) Regards, Nishanth Menon For the whole series: Acked-by: Benoit Cousson benoit.cous...@gmail.com Thanks, I've applied these into omap-for-v3.11/fixes-omap5 and will send a pull request for these today as these seem quite urgent fixes. yes they are. thanks for picking these up and the reviews. Regards, Nishanth Menon -- 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: Linux kernel for OMAP5432 uEVM
On 07/30/2013 01:07 AM, Chen Baozi wrote: On Jul 30, 2013, at 11:52 AM, Lokesh Vutla lokeshvu...@ti.com wrote: Hi Chen, On Tuesday 30 July 2013 09:08 AM, Chen Baozi wrote: Hi all, I'm trying to boot my OMAP5432 uEVM devboard with the lastest kernel of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git. Which branch are you using ? the master branch. However, after u-boot loading uImage DTB, there is no output message any more, such as: Clk data might be missing here. Try merging the below branch and test it https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=for_3.11/out_of_tree/omap5_clk_data Thanks, I'll have a try. There is also clock data dts support now in Tero's series: http://marc.info/?l=linux-omapm=137456411706971w=2 -- Regards, Nishanth Menon -- 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 3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
On 07/30/2013 06:25 AM, Rajendra Nayak wrote: From: R Sricharan r.sricha...@ti.com [...] # Clock framework obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)+= $(clock-common) dpll3xxx.o obj-$(CONFIG_SOC_AM33XX) += cclock33xx_data.o obj-$(CONFIG_SOC_OMAP5) += $(clock-common) obj-$(CONFIG_SOC_OMAP5) += dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_DRA7XX) += $(clock-common) +obj-$(CONFIG_SOC_DRA7XX) += dpll3xxx.o dpll44xx.o are these in sync with DRA7 support being introduced for clock data in [1]? [1] http://marc.info/?l=linux-omapm=137456411706971w=2 -- Regards, Nishanth Menon -- 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 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
From: R Sricharan r.sricha...@ti.com
Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved. Also added in the board file are pin configuration
details for i2c, mcspi and uart devices on board.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/Makefile |3 +-
arch/arm/boot/dts/dra7-evm.dts | 163 ++
arch/arm/boot/dts/dra7.dtsi| 488
3 files changed, 653 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/dra7-evm.dts
create mode 100644 arch/arm/boot/dts/dra7.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..e2f8566 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -173,7 +173,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-bone.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
- am43x-epos-evm.dtb
+ am43x-epos-evm.dtb \
+ dra7-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
new file mode 100644
index 000..7b0b563
--- /dev/null
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -0,0 +1,163 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ dra7.dtsi
+
+/ {
+ model = TI DRA7;
+ compatible = ti,dra7-evm, ti,dra7;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x6000; /* 1536 MB */
+ };
+};
+
+dra7_pmx_core {
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins =
+ 0x400 0x6 /* i2c1_sda */
+ 0x404 0x6 /* i2c1_scl */
+ ;
+ };
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins =
+ 0x408 0x6 /* i2c2_sda */
+ 0x40c 0x6 /* i2c2_scl */
+ ;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins =
+ 0x410 0x6 /* i2c3_sda */
+ 0x414 0x6 /* i2c3_scl */
+ ;
+ };
+
+ mcspi1_pins: pinmux_mcspi1_pins {
+ pinctrl-single,pins =
+ 0x3a4 0x4 /* spi2_clk */
+ 0x3a8 0x4 /* spi2_d1 */
+ 0x3ac 0x4 /* spi2_d0 */
+ 0x3b0 0xc /* spi2_cs0 */
+ 0x3b4 0xc /* spi2_cs1 */
+ 0x3b8 0xe0006 /* spi2_cs2 */
+ 0x3bc 0xe0006 /* spi2_cs3 */
+ ;
+ };
+
+ mcspi2_pins: pinmux_mcspi2_pins {
+ pinctrl-single,pins =
+ 0x3c0 0x4 /* spi2_sclk */
+ 0x3c4 0xc /* spi2_d1 */
+ 0x3c8 0xc /* spi2_d1 */
+ 0x3cc 0xe /* spi2_cs0 */
+ ;
+ };
+
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins =
+ 0x3e0 0xe /* uart1_rxd */
+ 0x3e4 0xe /* uart1_txd */
+ 0x3e8 0x60003 /* uart1_ctsn */
+ 0x3ec 0x60003 /* uart1_rtsn */
+ ;
+ };
+
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins =
+ 0x3f0 0x6 /* uart2_rxd */
+ 0x3f4 0x6 /* uart2_txd */
+ 0x3f8 0x6 /* uart2_ctsn */
+ 0x3fc 0x6 /* uart2_rtsn */
+ ;
+ };
+
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins =
+ 0x248 0xc /* uart3_rxd */
+ 0x24c 0xc /* uart3_txd */
+ ;
+ };
+};
+
+i2c1 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c1_pins;
+
+ clock-frequency = 40;
+};
+
+i2c2 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c2_pins;
+
+ clock-frequency = 40;
+};
+
+i2c3 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c3_pins;
+
+ clock-frequency = 340;
+};
+
+i2c4 {
+ status = disabled;
+};
+
+i2c5 {
+ status = disabled;
+};
+
+mcspi1 {
+ pinctrl-names = default;
+ pinctrl-0
Re: Linux kernel for OMAP5432 uEVM
Hi Lokesh list, On Jul 30, 2013, at 11:52 AM, Lokesh Vutla lokeshvu...@ti.com wrote: Clk data might be missing here. Try merging the below branch and test it https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=for_3.11/out_of_tree/omap5_clk_data You can also use Linus's kernel with the above clk data branch.( OMAP5 uEVM boots) Please let me know if you need more info. Thanks and regards, Lokesh I've ported the two patches on the top of clk data branch to both of linux-omap tree and Linus's kernel. They all work now. Thanks a lot. And a few more questions, ;-) I read the timer initialization codes in kernel. It looks like the Linux kernel does not use the architected timer of Cortex-A15 MPCore. I tried to use arch_timer_get_cntfrq() to get its rate, but failed(returned frequency is 0). I'm wondering if it is because of lack of initialization or other issues. Another question is about UART on OMAP5432. This is origin from my attempt to porting Xen to OMAP5432. Now Xen has already had a 8250 compatible driver. What I have done is to hook it with Xen's arm initialization codes (for example, hook it with device tree). Xen's original driver is rather simple compared to the Linux omap-serial.c. It enables receive and transmit interrupts in the end of initialization. Once the interrupt is enabled, it would generate nested interrupt of THRE and make the system dead loop in the interrupt handler. I have been digging this problem for nearly a month and haven't got a clue yet. I guess it might be caused by uninitialized architected timer, which then lead me to the previous question. Any idea? Cheers, Baozi-- 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 3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote: On 07/30/2013 06:25 AM, Rajendra Nayak wrote: From: R Sricharan r.sricha...@ti.com [...] # Clock framework obj-$(CONFIG_ARCH_OMAP2)+= $(clock-common) clock2xxx.o @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)+= $(clock-common) dpll3xxx.o obj-$(CONFIG_SOC_AM33XX)+= cclock33xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(clock-common) obj-$(CONFIG_SOC_OMAP5)+= dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_DRA7XX)+= $(clock-common) +obj-$(CONFIG_SOC_DRA7XX)+= dpll3xxx.o dpll44xx.o are these in sync with DRA7 support being introduced for clock data in [1]? I don't want to have a dependency on those patches since I am not sure of them making it into 3.12. [1] http://marc.info/?l=linux-omapm=137456411706971w=2 -- 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 3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
On 07/30/2013 07:38 AM, Rajendra Nayak wrote: On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote: On 07/30/2013 06:25 AM, Rajendra Nayak wrote: From: R Sricharan r.sricha...@ti.com [...] # Clock framework obj-$(CONFIG_ARCH_OMAP2)+= $(clock-common) clock2xxx.o @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)+= $(clock-common) dpll3xxx.o obj-$(CONFIG_SOC_AM33XX)+= cclock33xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(clock-common) obj-$(CONFIG_SOC_OMAP5)+= dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_DRA7XX)+= $(clock-common) +obj-$(CONFIG_SOC_DRA7XX)+= dpll3xxx.o dpll44xx.o are these in sync with DRA7 support being introduced for clock data in [1]? I don't want to have a dependency on those patches since I am not sure of them making it into 3.12. Then we have to undo these changes again in clock data support. the chip wont bootup anyways without clock data information, so why not try and keep the changes that Tero is doing independent of these changes? [1] http://marc.info/?l=linux-omapm=137456411706971w=2 -- Regards, Nishanth Menon -- 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: Linux kernel for OMAP5432 uEVM
On Jul 30, 2013, at 8:24 PM, Nishanth Menon n...@ti.com wrote: On 07/30/2013 01:07 AM, Chen Baozi wrote: On Jul 30, 2013, at 11:52 AM, Lokesh Vutla lokeshvu...@ti.com wrote: Hi Chen, On Tuesday 30 July 2013 09:08 AM, Chen Baozi wrote: Hi all, I'm trying to boot my OMAP5432 uEVM devboard with the lastest kernel of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git. Which branch are you using ? the master branch. However, after u-boot loading uImage DTB, there is no output message any more, such as: Clk data might be missing here. Try merging the below branch and test it https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=for_3.11/out_of_tree/omap5_clk_data Thanks, I'll have a try. There is also clock data dts support now in Tero's series: http://marc.info/?l=linux-omapm=137456411706971w=2 Thanks, I'll have a look though Lokesh's suggestion has already booted my board. Might be a stupid question. What's the different functionality between these two series of patch set? For it seems clk data patches have done the some of initialization that make the system boot. Cheers, Baozi-- 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 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
On Tuesday 30 July 2013 06:00 PM, Nishanth Menon wrote:
On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
From: R Sricharan r.sricha...@ti.com
Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved. Also added in the board file are pin configuration
details for i2c, mcspi and uart devices on board.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/Makefile |3 +-
arch/arm/boot/dts/dra7-evm.dts | 163 ++
arch/arm/boot/dts/dra7.dtsi| 488
3 files changed, 653 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/dra7-evm.dts
create mode 100644 arch/arm/boot/dts/dra7.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 641b3c9..e2f8566 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -173,7 +173,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
am335x-bone.dtb \
am3517-evm.dtb \
am3517_mt_ventoux.dtb \
-am43x-epos-evm.dtb
+am43x-epos-evm.dtb \
+dra7-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += orion5x-lacie-ethernet-disk-mini-v2.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += prima2-evb.dtb
dtb-$(CONFIG_ARCH_U8500) += snowball.dtb \
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
new file mode 100644
index 000..7b0b563
--- /dev/null
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -0,0 +1,163 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+/include/ dra7.dtsi
+
+/ {
+model = TI DRA7;
+compatible = ti,dra7-evm, ti,dra7;
+
+memory {
+device_type = memory;
+reg = 0x8000 0x6000; /* 1536 MB */
+};
+};
+
+dra7_pmx_core {
+i2c1_pins: pinmux_i2c1_pins {
+pinctrl-single,pins =
+0x400 0x6/* i2c1_sda */
+0x404 0x6/* i2c1_scl */
+;
+};
+
+i2c2_pins: pinmux_i2c2_pins {
+pinctrl-single,pins =
+0x408 0x6/* i2c2_sda */
+0x40c 0x6/* i2c2_scl */
+;
+};
+
+i2c3_pins: pinmux_i2c3_pins {
+pinctrl-single,pins =
+0x410 0x6/* i2c3_sda */
+0x414 0x6/* i2c3_scl */
+;
+};
+
+mcspi1_pins: pinmux_mcspi1_pins {
+pinctrl-single,pins =
+0x3a4 0x4/* spi2_clk */
+0x3a8 0x4/* spi2_d1 */
+0x3ac 0x4/* spi2_d0 */
+0x3b0 0xc/* spi2_cs0 */
+0x3b4 0xc/* spi2_cs1 */
+0x3b8 0xe0006/* spi2_cs2 */
+0x3bc 0xe0006/* spi2_cs3 */
+;
+};
+
+mcspi2_pins: pinmux_mcspi2_pins {
+pinctrl-single,pins =
+0x3c0 0x4/* spi2_sclk */
+0x3c4 0xc/* spi2_d1 */
+0x3c8 0xc/* spi2_d1 */
+0x3cc 0xe/* spi2_cs0 */
+;
+};
+
+uart1_pins: pinmux_uart1_pins {
+pinctrl-single,pins =
+0x3e0 0xe/* uart1_rxd */
+0x3e4 0xe/* uart1_txd */
+0x3e8 0x60003/* uart1_ctsn */
+0x3ec 0x60003/* uart1_rtsn */
+;
+};
+
+uart2_pins: pinmux_uart2_pins {
+pinctrl-single,pins =
+0x3f0 0x6 /* uart2_rxd */
+0x3f4 0x6 /* uart2_txd */
+0x3f8 0x6 /* uart2_ctsn */
+0x3fc 0x6 /* uart2_rtsn */
+;
+};
+
+uart3_pins: pinmux_uart3_pins {
+pinctrl-single,pins =
+0x248 0xc /* uart3_rxd */
+0x24c 0xc /* uart3_txd */
+;
+};
+};
+
+i2c1 {
+pinctrl-names = default;
+pinctrl-0 = i2c1_pins;
+
+clock-frequency = 40;
+};
+
+i2c2 {
+pinctrl-names = default;
+pinctrl-0 = i2c2_pins;
+
+clock-frequency = 40;
+};
+
+i2c3 {
+pinctrl-names = default;
+pinctrl-0 = i2c3_pins;
+
+clock-frequency = 340;
+};
+
+i2c4 {
+status = disabled;
+};
+
+i2c5 {
+status = disabled;
+};
+
+mcspi1 {
+pinctrl-names = default;
+pinctrl-0 = mcspi1_pins;
+};
+
+mcspi2 {
+pinctrl-names = default;
+pinctrl-0 = mcspi2_pins;
+};
+
+mcspi3 {
+status = disabled;
+};
+
+mcspi4 {
+status = disabled;
+};
+
+uart1 {
+pinctrl-names = default;
+pinctrl-0 = uart1_pins;
+};
+
+uart2 {
+
Re: [PATCH v2 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
On 07/30/2013 07:41 AM, Rajendra Nayak wrote:
On Tuesday 30 July 2013 06:00 PM, Nishanth Menon wrote:
On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
From: R Sricharan r.sricha...@ti.com
[...]
+mcspi4: spi@480ba000 {
+compatible = ti,omap4-mcspi;
+reg = 0x480ba000 0x200;
+interrupts = 0 48 0x4;
+#address-cells = 1;
+#size-cells = 0;
+ti,hwmods = mcspi4;
+ti,spi-num-cs = 1;
+dmas = sdma 70, sdma 71;
+dma-names = tx0, rx0;
+};
+};
+};
ref: [1], we discussed that we should now be able to introduce all instances of
h/w blocks into the dra7.dts. Further, considering [2]
hmm, thats a long discussion on crossbar driver that [1] points to. Do you want
to summarize what you mean by 'introduce all instances of h/w blocks'
I recommend reading the last few emails on the thread about how we could
do this with pinctrl. unfortunately, this patch is not informative
enough to indicate that not all instances of the potential IP blocks are
listed here.
would you not want to follow status = disabled for all modules by default and
enable required modules in board file, so that we dont have to respin this yet again?
Well, I was just following the convention of whats already followed on existing
OMAPs. See [3] for some views on these.
DRA7 case, I would not think it makes sense due to the number of product
variants being done, not all will use the same set. Further, rationale
for DRA7 and my suggestion for Grant's option (1) is mainly because the
product variants will require more dtsis rather than board files using
the product variants use just the necessary modules from a common dtsi.
Makes support of variants like OMAP57xx etc trivial and constrainted to
board file usage, rather than spinning off new dtsis.
[1] http://marc.info/?t=13741659941r=1w=2
[2] http://marc.info/?l=linux-omapm=137510358229479w=2
[3]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086297.html
--
Regards,
Nishanth Menon
--
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 3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
On Tuesday 30 July 2013 06:11 PM, Nishanth Menon wrote: On 07/30/2013 07:38 AM, Rajendra Nayak wrote: On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote: On 07/30/2013 06:25 AM, Rajendra Nayak wrote: From: R Sricharan r.sricha...@ti.com [...] # Clock framework obj-$(CONFIG_ARCH_OMAP2)+= $(clock-common) clock2xxx.o @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)+= $(clock-common) dpll3xxx.o obj-$(CONFIG_SOC_AM33XX)+= cclock33xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(clock-common) obj-$(CONFIG_SOC_OMAP5)+= dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_DRA7XX)+= $(clock-common) +obj-$(CONFIG_SOC_DRA7XX)+= dpll3xxx.o dpll44xx.o are these in sync with DRA7 support being introduced for clock data in [1]? I don't want to have a dependency on those patches since I am not sure of them making it into 3.12. Then we have to undo these changes again in clock data support. the chip wont bootup anyways without clock data information, so why not try and keep the changes that Tero is doing independent of these changes? I still have something with clock data information which boots which I am maintaining out of tree till the clock movement to DT is sorted out. Maybe what you are suggesting is quite trivial and I am unable to understand. Are you suggesting we do no compile $(clock-common) and the dpll files for DRA7? Is that what you are worried we might have to revert? [1] http://marc.info/?l=linux-omapm=137456411706971w=2 -- 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 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
On Tuesday 30 July 2013 06:16 PM, Nishanth Menon wrote:
On 07/30/2013 07:41 AM, Rajendra Nayak wrote:
On Tuesday 30 July 2013 06:00 PM, Nishanth Menon wrote:
On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
From: R Sricharan r.sricha...@ti.com
[...]
+mcspi4: spi@480ba000 {
+compatible = ti,omap4-mcspi;
+reg = 0x480ba000 0x200;
+interrupts = 0 48 0x4;
+#address-cells = 1;
+#size-cells = 0;
+ti,hwmods = mcspi4;
+ti,spi-num-cs = 1;
+dmas = sdma 70, sdma 71;
+dma-names = tx0, rx0;
+};
+};
+};
ref: [1], we discussed that we should now be able to introduce all
instances of h/w blocks into the dra7.dts. Further, considering [2]
hmm, thats a long discussion on crossbar driver that [1] points to. Do you
want to summarize what you mean by 'introduce all instances of h/w blocks'
I recommend reading the last few emails on the thread about how we could do
this with pinctrl. unfortunately, this patch is not informative enough to
indicate that not all instances of the potential IP blocks are listed here.
would you not want to follow status = disabled for all modules by default
and enable required modules in board file, so that we dont have to respin
this yet again?
Well, I was just following the convention of whats already followed on
existing OMAPs. See [3] for some views on these.
DRA7 case, I would not think it makes sense due to the number of product
variants being done, not all will use the same set. Further, rationale for
DRA7 and my suggestion for Grant's option (1) is mainly because the product
variants will require more dtsis rather than board files using the product
variants use just the necessary modules from a common dtsi. Makes support of
variants like OMAP57xx etc trivial and constrainted to board file usage,
rather than spinning off new dtsis.
Makes sense with the different product variants for DRA7, AM335x already does
it this way, but the rest of OMAP3/4/5 are doing it the other way.
I think its just too confusing to follow different conventions for different
SoCs. We should stick to just one, either this way or that.
[1] http://marc.info/?t=13741659941r=1w=2
[2] http://marc.info/?l=linux-omapm=137510358229479w=2
[3]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086297.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 v2 3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
On 07/30/2013 07:48 AM, Rajendra Nayak wrote: On Tuesday 30 July 2013 06:11 PM, Nishanth Menon wrote: On 07/30/2013 07:38 AM, Rajendra Nayak wrote: On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote: On 07/30/2013 06:25 AM, Rajendra Nayak wrote: From: R Sricharan r.sricha...@ti.com [...] # Clock framework obj-$(CONFIG_ARCH_OMAP2)+= $(clock-common) clock2xxx.o @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)+= $(clock-common) dpll3xxx.o obj-$(CONFIG_SOC_AM33XX)+= cclock33xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(clock-common) obj-$(CONFIG_SOC_OMAP5)+= dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_DRA7XX)+= $(clock-common) +obj-$(CONFIG_SOC_DRA7XX)+= dpll3xxx.o dpll44xx.o are these in sync with DRA7 support being introduced for clock data in [1]? I don't want to have a dependency on those patches since I am not sure of them making it into 3.12. Then we have to undo these changes again in clock data support. the chip wont bootup anyways without clock data information, so why not try and keep the changes that Tero is doing independent of these changes? I still have something with clock data information which boots which I am maintaining out of tree till the clock movement to DT is sorted out. Maybe what you are suggesting is quite trivial and I am unable to understand. Are you suggesting we do no compile $(clock-common) and the dpll files for DRA7? Is that what you are worried we might have to revert? yes - lets just drop that change. that allows what ever alignment we have for clock data/driver to handle it appropriately. IMHO, could also keeps your series independent from Tero's series. [1] http://marc.info/?l=linux-omapm=137456411706971w=2 -- Regards, Nishanth Menon -- 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 3/8] ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra
On Tuesday 30 July 2013 06:27 PM, Nishanth Menon wrote: On 07/30/2013 07:48 AM, Rajendra Nayak wrote: On Tuesday 30 July 2013 06:11 PM, Nishanth Menon wrote: On 07/30/2013 07:38 AM, Rajendra Nayak wrote: On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote: On 07/30/2013 06:25 AM, Rajendra Nayak wrote: From: R Sricharan r.sricha...@ti.com [...] # Clock framework obj-$(CONFIG_ARCH_OMAP2)+= $(clock-common) clock2xxx.o @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX)+= $(clock-common) dpll3xxx.o obj-$(CONFIG_SOC_AM33XX)+= cclock33xx_data.o obj-$(CONFIG_SOC_OMAP5)+= $(clock-common) obj-$(CONFIG_SOC_OMAP5)+= dpll3xxx.o dpll44xx.o +obj-$(CONFIG_SOC_DRA7XX)+= $(clock-common) +obj-$(CONFIG_SOC_DRA7XX)+= dpll3xxx.o dpll44xx.o are these in sync with DRA7 support being introduced for clock data in [1]? I don't want to have a dependency on those patches since I am not sure of them making it into 3.12. Then we have to undo these changes again in clock data support. the chip wont bootup anyways without clock data information, so why not try and keep the changes that Tero is doing independent of these changes? I still have something with clock data information which boots which I am maintaining out of tree till the clock movement to DT is sorted out. Maybe what you are suggesting is quite trivial and I am unable to understand. Are you suggesting we do no compile $(clock-common) and the dpll files for DRA7? Is that what you are worried we might have to revert? yes - lets just drop that change. that allows what ever alignment we have for clock data/driver to handle it appropriately. IMHO, could also keeps your series independent from Tero's series. I can drop those. no issues. [1] http://marc.info/?l=linux-omapm=137456411706971w=2 -- 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 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
On Tuesday 30 July 2013 06:29 PM, Nishanth Menon wrote:
On 07/30/2013 07:56 AM, Rajendra Nayak wrote:
On Tuesday 30 July 2013 06:16 PM, Nishanth Menon wrote:
On 07/30/2013 07:41 AM, Rajendra Nayak wrote:
On Tuesday 30 July 2013 06:00 PM, Nishanth Menon wrote:
On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
From: R Sricharan r.sricha...@ti.com
[...]
+mcspi4: spi@480ba000 {
+compatible = ti,omap4-mcspi;
+reg = 0x480ba000 0x200;
+interrupts = 0 48 0x4;
+#address-cells = 1;
+#size-cells = 0;
+ti,hwmods = mcspi4;
+ti,spi-num-cs = 1;
+dmas = sdma 70, sdma 71;
+dma-names = tx0, rx0;
+};
+};
+};
ref: [1], we discussed that we should now be able to introduce all
instances of h/w blocks into the dra7.dts. Further, considering [2]
hmm, thats a long discussion on crossbar driver that [1] points to. Do you
want to summarize what you mean by 'introduce all instances of h/w blocks'
I recommend reading the last few emails on the thread about how we could do
this with pinctrl. unfortunately, this patch is not informative enough to
indicate that not all instances of the potential IP blocks are listed here.
would you not want to follow status = disabled for all modules by
default and enable required modules in board file, so that we dont have
to respin this yet again?
Well, I was just following the convention of whats already followed on
existing OMAPs. See [3] for some views on these.
DRA7 case, I would not think it makes sense due to the number of product
variants being done, not all will use the same set. Further, rationale for
DRA7 and my suggestion for Grant's option (1) is mainly because the product
variants will require more dtsis rather than board files using the product
variants use just the necessary modules from a common dtsi. Makes support
of variants like OMAP57xx etc trivial and constrainted to board file usage,
rather than spinning off new dtsis.
Makes sense with the different product variants for DRA7, AM335x already
does it this way, but the rest of OMAP3/4/5 are doing it the other way.
I think its just too confusing to follow different conventions for different
SoCs. We should stick to just one, either this way or that.
I think bucketing DRA7(with multitude of SoC variants) with OMAP
family(usually with 5 variants) will be a wrong approach. we should choose
the approach appropriate for the SoC. hence, OMAPx having all default enabled
makes sense (as the delta is usually trivial), but on DRA7, the variants are
larger :(
just my 2 cents.
I can respin with the changes, but before I do so, Benoit do you agree with the
rationale for these and fine with the approach?
[1] http://marc.info/?t=13741659941r=1w=2
[2] http://marc.info/?l=linux-omapm=137510358229479w=2
[3]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/086297.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 v4 1/8] wl1251: split wl251 platform data to a separate structure
Move the wl1251 part of the wl12xx platform data structure into a new
structure specifically for wl1251. Change the platform data built-in
block and board files accordingly.
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Luciano Coelho coe...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-omap3pandora.c | 4 +--
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
drivers/net/wireless/ti/wilink_platform_data.c | 37 +-
drivers/net/wireless/ti/wl1251/sdio.c | 12 -
drivers/net/wireless/ti/wl1251/spi.c | 2 +-
include/linux/wl12xx.h | 22 ++-
6 files changed, 62 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index b1547a0..84d56e8 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -541,7 +541,7 @@ static struct spi_board_info omap3pandora_spi_board_info[]
__initdata = {
static void __init pandora_wl1251_init(void)
{
- struct wl12xx_platform_data pandora_wl1251_pdata;
+ struct wl1251_platform_data pandora_wl1251_pdata;
int ret;
memset(pandora_wl1251_pdata, 0, sizeof(pandora_wl1251_pdata));
@@ -555,7 +555,7 @@ static void __init pandora_wl1251_init(void)
goto fail_irq;
pandora_wl1251_pdata.use_eeprom = true;
- ret = wl12xx_set_platform_data(pandora_wl1251_pdata);
+ ret = wl1251_set_platform_data(pandora_wl1251_pdata);
if (ret 0)
goto fail_irq;
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9c2dd10..01e5711 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -80,7 +80,7 @@ enum {
RX51_SPI_MIPID, /* LCD panel */
};
-static struct wl12xx_platform_data wl1251_pdata;
+static struct wl1251_platform_data wl1251_pdata;
static struct tsc2005_platform_data tsc2005_pdata;
#if defined(CONFIG_SENSORS_LIS3_I2C) || defined(CONFIG_SENSORS_LIS3_I2C_MODULE)
diff --git a/drivers/net/wireless/ti/wilink_platform_data.c
b/drivers/net/wireless/ti/wilink_platform_data.c
index 998e958..a92bd3e 100644
--- a/drivers/net/wireless/ti/wilink_platform_data.c
+++ b/drivers/net/wireless/ti/wilink_platform_data.c
@@ -23,17 +23,17 @@
#include linux/err.h
#include linux/wl12xx.h
-static struct wl12xx_platform_data *platform_data;
+static struct wl12xx_platform_data *wl12xx_platform_data;
int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
{
- if (platform_data)
+ if (wl12xx_platform_data)
return -EBUSY;
if (!data)
return -EINVAL;
- platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
- if (!platform_data)
+ wl12xx_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!wl12xx_platform_data)
return -ENOMEM;
return 0;
@@ -41,9 +41,34 @@ int __init wl12xx_set_platform_data(const struct
wl12xx_platform_data *data)
struct wl12xx_platform_data *wl12xx_get_platform_data(void)
{
- if (!platform_data)
+ if (!wl12xx_platform_data)
return ERR_PTR(-ENODEV);
- return platform_data;
+ return wl12xx_platform_data;
}
EXPORT_SYMBOL(wl12xx_get_platform_data);
+
+static struct wl1251_platform_data *wl1251_platform_data;
+
+int __init wl1251_set_platform_data(const struct wl1251_platform_data *data)
+{
+ if (wl1251_platform_data)
+ return -EBUSY;
+ if (!data)
+ return -EINVAL;
+
+ wl1251_platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
+ if (!wl1251_platform_data)
+ return -ENOMEM;
+
+ return 0;
+}
+
+struct wl1251_platform_data *wl1251_get_platform_data(void)
+{
+ if (!wl1251_platform_data)
+ return ERR_PTR(-ENODEV);
+
+ return wl1251_platform_data;
+}
+EXPORT_SYMBOL(wl1251_get_platform_data);
diff --git a/drivers/net/wireless/ti/wl1251/sdio.c
b/drivers/net/wireless/ti/wl1251/sdio.c
index e2b3d9c..b75a37a 100644
--- a/drivers/net/wireless/ti/wl1251/sdio.c
+++ b/drivers/net/wireless/ti/wl1251/sdio.c
@@ -227,7 +227,7 @@ static int wl1251_sdio_probe(struct sdio_func *func,
struct wl1251 *wl;
struct ieee80211_hw *hw;
struct wl1251_sdio *wl_sdio;
- const struct wl12xx_platform_data *wl12xx_board_data;
+ const struct wl1251_platform_data *wl1251_board_data;
hw = wl1251_alloc_hw();
if (IS_ERR(hw))
@@ -254,11 +254,11 @@ static int wl1251_sdio_probe(struct sdio_func *func,
wl-if_priv = wl_sdio;
wl-if_ops = wl1251_sdio_ops;
- wl12xx_board_data = wl12xx_get_platform_data();
- if (!IS_ERR(wl12xx_board_data)) {
- wl-set_power =
[PATCH v4 7/8] wlcore: sdio: get clocks from device tree
Read the clock nodes from the device tree and use them to set the
frequency for the refclock and the tcxo clock.
Also, call sdio_set_drvdata() earlier, so the glue is already set in
the driver data when we call wlcore_get_pdata_from_of() and we don't
need to pass it as a parameter.
Signed-off-by: Luciano Coelho coe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/net/wireless/ti/wlcore/sdio.c | 36 +--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 980bf3d..60fce49 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -53,6 +53,7 @@ static bool dump = false;
struct wl12xx_sdio_glue {
struct device *dev;
struct platform_device *core;
+ struct clk *refclock, *tcxoclock;
};
static const struct sdio_device_id wl1271_devices[] = {
@@ -224,6 +225,7 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
struct wl12xx_platform_data *pdata;
struct device_node *np = dev-of_node;
struct device_node *clock_node;
+ struct wl12xx_sdio_glue *glue = sdio_get_drvdata(dev_to_sdio_func(dev));
if (!np) {
np = of_find_matching_node(NULL, dev-driver-of_match_table);
@@ -250,6 +252,26 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
of_fixed_clk_setup(clock_node);
+ /* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
+ glue-refclock = of_clk_get_by_name(np, refclock);
+ if (IS_ERR(glue-refclock)) {
+ dev_err(dev, couldn't find refclock on the device tree\n);
+ glue-refclock = NULL;
+ } else {
+ clk_prepare_enable(glue-refclock);
+ pdata-ref_clock_freq = clk_get_rate(glue-refclock);
+ }
+
+ /* TODO: make sure we have this when needed (ie. for WL7) */
+ glue-tcxoclock = of_clk_get_by_name(np, tcxoclock);
+ if (IS_ERR(glue-tcxoclock)) {
+ dev_err(dev, couldn't find tcxoclock on the device tree\n);
+ glue-tcxoclock = NULL;
+ } else {
+ clk_prepare_enable(glue-tcxoclock);
+ pdata-ref_clock_freq = clk_get_rate(glue-tcxoclock);
+ }
+
goto out;
out_free:
@@ -294,6 +316,8 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
+ sdio_set_drvdata(func, glue);
+
/* The pdata allocated here is freed when the device is freed,
* so we don't need an additional out label to free it in case
* of error further on.
@@ -319,8 +343,6 @@ static int wl1271_probe(struct sdio_func *func,
if (mmcflags MMC_PM_KEEP_POWER)
pdev_data-pwr_in_suspend = true;
- sdio_set_drvdata(func, glue);
-
/* Tell PM core that we don't need the card to be powered now */
pm_runtime_put_noidle(func-dev);
@@ -387,6 +409,16 @@ static void wl1271_remove(struct sdio_func *func)
{
struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
+ if (glue-refclock) {
+ clk_disable_unprepare(glue-refclock);
+ clk_put(glue-refclock);
+ }
+
+ if (glue-tcxoclock) {
+ clk_disable_unprepare(glue-tcxoclock);
+ clk_put(glue-tcxoclock);
+ }
+
/* Undo decrement done above in wl1271_probe */
pm_runtime_get_noresume(func-dev);
--
1.8.3.2
--
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 v4 8/8] wlcore/wl12xx: check if we got correct clock data from DT
The fref and the tcxo clocks settings are optional in some platforms.
WiLink8 doesn't need either, so we don't check the values. WiLink 6
only needs the fref clock, so we check that it is valid or return with
an error. WiLink7 needs both clocks, if either is not available we
return with an error.
Signed-off-by: Luciano Coelho coe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/net/wireless/ti/wl12xx/main.c | 20 +---
drivers/net/wireless/ti/wlcore/sdio.c | 4
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/ti/wl12xx/main.c
b/drivers/net/wireless/ti/wl12xx/main.c
index a6c2a14..60d2ff4 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -927,6 +927,11 @@ static int wl128x_boot_clk(struct wl1271 *wl, int
*selected_clock)
u16 sys_clk_cfg;
int ret;
+ if ((priv-ref_clock 0) || (priv-tcxo_clock 0)) {
+ wl1271_error(Missing fref and/or tcxo clock settings\n);
+ return -EINVAL;
+ }
+
/* For XTAL-only modes, FREF will be used after switching from TCXO */
if (priv-ref_clock == WL12XX_REFCLOCK_26_XTAL ||
priv-ref_clock == WL12XX_REFCLOCK_38_XTAL) {
@@ -976,6 +981,11 @@ static int wl127x_boot_clk(struct wl1271 *wl)
u32 clk;
int ret;
+ if (priv-ref_clock 0) {
+ wl1271_error(Missing fref clock settings\n);
+ return -EINVAL;
+ }
+
if (WL127X_PG_GET_MAJOR(wl-hw_pg_ver) 3)
wl-quirks |= WLCORE_QUIRK_END_OF_TRANSACTION;
@@ -1758,7 +1768,7 @@ static int wl12xx_setup(struct wl1271 *wl)
wlcore_set_ht_cap(wl, IEEE80211_BAND_5GHZ, wl12xx_ht_cap);
wl12xx_conf_init(wl);
- if (!fref_param) {
+ if (!fref_param (pdata-ref_clock_freq 0)) {
priv-ref_clock = wl12xx_get_clock_idx(wl12xx_refclock_table,
pdata-ref_clock_freq,
pdata-ref_clock_xtal);
@@ -1769,6 +1779,8 @@ static int wl12xx_setup(struct wl1271 *wl)
return priv-ref_clock;
}
+ } else if (!fref_param) {
+ priv-ref_clock = -EINVAL;
} else {
if (!strcmp(fref_param, 19.2))
priv-ref_clock = WL12XX_REFCLOCK_19;
@@ -1786,7 +1798,7 @@ static int wl12xx_setup(struct wl1271 *wl)
wl1271_error(Invalid fref parameter %s, fref_param);
}
- if (!tcxo_param) {
+ if (!fref_param (pdata-tcxo_clock_freq 0)) {
priv-tcxo_clock = wl12xx_get_clock_idx(wl12xx_tcxoclock_table,
pdata-tcxo_clock_freq,
true);
@@ -1796,7 +1808,9 @@ static int wl12xx_setup(struct wl1271 *wl)
return priv-tcxo_clock;
}
- } else {
+ } else if (!fref_param) {
+ priv-tcxo_clock = -EINVAL;
+ }else {
if (!strcmp(tcxo_param, 19.2))
priv-tcxo_clock = WL12XX_TCXOCLOCK_19_2;
else if (!strcmp(tcxo_param, 26))
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 60fce49..c76eb66 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -252,20 +252,16 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
of_fixed_clk_setup(clock_node);
- /* TODO: make sure we have this when needed (ie. for WL6 and WL7) */
glue-refclock = of_clk_get_by_name(np, refclock);
if (IS_ERR(glue-refclock)) {
- dev_err(dev, couldn't find refclock on the device tree\n);
glue-refclock = NULL;
} else {
clk_prepare_enable(glue-refclock);
pdata-ref_clock_freq = clk_get_rate(glue-refclock);
}
- /* TODO: make sure we have this when needed (ie. for WL7) */
glue-tcxoclock = of_clk_get_by_name(np, tcxoclock);
if (IS_ERR(glue-tcxoclock)) {
- dev_err(dev, couldn't find tcxoclock on the device tree\n);
glue-tcxoclock = NULL;
} else {
clk_prepare_enable(glue-tcxoclock);
--
1.8.3.2
--
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 v4 6/8] wlcore: sdio: add wilink clock providers
Add refclock and tcxoclock as clock providers in WiLink. These clocks
are not accesible outside the WiLink module, but they are registered
in the clock framework anyway. Only the WiLink chip consumes these
clocks.
In theory, the WiLink chip could be connected to external clocks
instead of using these internal clocks, so make the clock consumer
code generic enough. If external clocks are used, then the internal
clock device tree nodes are not necessary, but the external ones must
be specified.
Signed-off-by: Luciano Coelho coe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/net/wireless/ti/wlcore/sdio.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 9370d7e..980bf3d 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,7 @@
#include linux/wl12xx.h
#include linux/pm_runtime.h
#include linux/printk.h
+#include linux/clk-provider.h
#include wlcore.h
#include wl12xx_80211.h
@@ -214,10 +215,15 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
};
+static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
+ { .compatible = ti,wilink-clock },
+};
+
static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device
*dev)
{
struct wl12xx_platform_data *pdata;
struct device_node *np = dev-of_node;
+ struct device_node *clock_node;
if (!np) {
np = of_find_matching_node(NULL, dev-driver-of_match_table);
@@ -241,6 +247,9 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
goto out_free;
}
+ for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
+ of_fixed_clk_setup(clock_node);
+
goto out;
out_free:
--
1.8.3.2
--
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 v4 4/8] wl12xx: use frequency instead of enumerations for pdata clocks
Instead of defining an enumeration with the FW specific values for the
different clock rates, use the actual frequency instead. Also add a
boolean to specify whether the clock is XTAL or not.
Change all board files to reflect this.
Additionally, this reverts commit 26f45c (ARM: OMAP2+: Legacy support
for wl12xx when booted with devicetree), since this is not be needed
anymore, now that DT support for WiLink is implemented.
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-davinci/board-da850-evm.c | 3 +-
arch/arm/mach-omap2/board-omap3evm.c | 3 +-
arch/arm/mach-omap2/board-zoom-peripherals.c | 3 +-
arch/arm/mach-omap2/devices.c| 39 ---
drivers/net/wireless/ti/wl12xx/main.c| 58 +++-
drivers/net/wireless/ti/wl12xx/wl12xx.h | 28 ++
include/linux/wl12xx.h | 27 ++---
7 files changed, 93 insertions(+), 68 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 03de2e9..6b2768f 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1376,7 +1376,8 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
- .board_ref_clock= WL12XX_REFCLOCK_38,
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 9c7dfc5..4ccfcc0 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -460,7 +460,8 @@ static struct platform_device omap3evm_wlan_regulator = {
};
struct wl12xx_platform_data omap3evm_wlan_data __initdata = {
- .board_ref_clock = WL12XX_REFCLOCK_38, /* 38.4 MHz */
+ .ref_clock_freq = 3840,
+ .ref_clock_xtal = false,
};
#endif
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 4f84cf9..83a9a36 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -244,7 +244,8 @@ static struct platform_device *zoom_devices[] __initdata = {
};
static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
- .board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz */
+ .ref_clock_freq = 2600,
+ .ref_clock_xtal = false,
};
static struct omap2_hsmmc_info mmc[] = {
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 3c1279f..10e6126 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -8,7 +8,6 @@
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*/
-#include linux/gpio.h
#include linux/kernel.h
#include linux/init.h
#include linux/platform_device.h
@@ -19,7 +18,6 @@
#include linux/of.h
#include linux/pinctrl/machine.h
#include linux/platform_data/omap4-keypad.h
-#include linux/wl12xx.h
#include linux/platform_data/mailbox-omap.h
#include asm/mach-types.h
@@ -513,40 +511,6 @@ static void omap_init_vout(void)
static inline void omap_init_vout(void) {}
#endif
-#if IS_ENABLED(CONFIG_WL12XX)
-
-static struct wl12xx_platform_data wl12xx __initdata;
-
-void __init omap_init_wl12xx_of(void)
-{
- int ret;
-
- if (!of_have_populated_dt())
- return;
-
- if (of_machine_is_compatible(ti,omap4-sdp)) {
- wl12xx.board_ref_clock = WL12XX_REFCLOCK_26;
- wl12xx.board_tcxo_clock = WL12XX_TCXOCLOCK_26;
- wl12xx.irq = gpio_to_irq(53);
- } else if (of_machine_is_compatible(ti,omap4-panda)) {
- wl12xx.board_ref_clock = WL12XX_REFCLOCK_38;
- wl12xx.irq = gpio_to_irq(53);
- } else {
- return;
- }
-
- ret = wl12xx_set_platform_data(wl12xx);
- if (ret) {
- pr_err(error setting wl12xx data: %d\n, ret);
- return;
- }
-}
-#else
-static inline void omap_init_wl12xx_of(void)
-{
-}
-#endif
-
/*-*/
static int __init omap2_init_devices(void)
@@ -570,9 +534,6 @@ static int __init omap2_init_devices(void)
omap_init_mcspi();
omap_init_sham();
omap_init_aes();
- } else {
- /* These can be removed when bindings are done */
- omap_init_wl12xx_of();
}
omap_init_sti();
omap_init_rng();
diff --git a/drivers/net/wireless/ti/wl12xx/main.c
b/drivers/net/wireless/ti/wl12xx/main.c
index 1c627da..a6c2a14 100644
---
[PATCH v4 0/8] wilink: add device tree support
Hi, This patch series adds device tree support to the wlcore_sdio driver, which is used by WiLink6, WiLink7 and WiLink8. The first patches do some clean-up to make the data needed in the wilink device tree node smaller. The remaining patches implement the actual device tree node parsing in wlcore_sdio. Regarding the XTAL clock issues, for now we don't support XTAL mode with DT, but I have sent a proposal for a small change in the clock framework to support this, but it's still under discussions [1]. The DTS file changes will be sent separately, since they need to go via different trees. A new version of the bindings documentation has been sent [2] and, if no more comments are given to it, I'll apply it via my tree. [1] http://news.gmane.org/find-root.php?message_id=1372971912-10877-1-git-send-email-coe...@ti.com [2] http://news.gmane.org/find-root.php?message_id=1375109728-5931-1-git-send-email-coe...@ti.com Changes in v4: * Rebased on top of 3.11-rc3 (eg. no more changes on the board files that were removed); * Use the new irq_get_trigger_type() instead of irqd_get_trigger_type() (thanks Javier); * Added some missing const's (thanks Felipe); * Reverted Tony's workaround to get WiLink to work on Panda while DT was not supported yet. Please review. Luciano Coelho (8): wl1251: split wl251 platform data to a separate structure wlcore: set irq_flags in the board files instead of hiding behind a quirk wlcore: remove pwr_in_suspend from platform data wl12xx: use frequency instead of enumerations for pdata clocks wlcore: add initial device tree support to the sdio module wlcore: sdio: add wilink clock providers wlcore: sdio: get clocks from device tree wlcore/wl12xx: check if we got correct clock data from DT arch/arm/mach-davinci/board-da850-evm.c| 11 ++- arch/arm/mach-omap2/board-omap3evm.c | 22 - arch/arm/mach-omap2/board-omap3pandora.c | 4 +- arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +- arch/arm/mach-omap2/board-zoom-peripherals.c | 33 +++- arch/arm/mach-omap2/devices.c | 39 - drivers/net/wireless/ti/wilink_platform_data.c | 37 ++-- drivers/net/wireless/ti/wl1251/sdio.c | 12 +-- drivers/net/wireless/ti/wl1251/spi.c | 2 +- drivers/net/wireless/ti/wl12xx/main.c | 78 +++-- drivers/net/wireless/ti/wl12xx/wl12xx.h| 28 +++ drivers/net/wireless/ti/wlcore/debugfs.c | 2 +- drivers/net/wireless/ti/wlcore/main.c | 20 ++--- drivers/net/wireless/ti/wlcore/sdio.c | 112 +++-- drivers/net/wireless/ti/wlcore/wlcore.h| 5 +- drivers/net/wireless/ti/wlcore/wlcore_i.h | 1 + include/linux/wl12xx.h | 52 +--- 17 files changed, 340 insertions(+), 120 deletions(-) -- 1.8.3.2 -- 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 v4 3/8] wlcore: remove pwr_in_suspend from platform data
The pwr_in_suspend flag depends on the MMC settings which can be
retrieved from the SDIO subsystem, so it doesn't need to be part of
the platform data structure. Move it to the platform device data that
is passed from SDIO to wlcore.
Signed-off-by: Luciano Coelho coe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/net/wireless/ti/wlcore/main.c | 3 +--
drivers/net/wireless/ti/wlcore/sdio.c | 2 +-
drivers/net/wireless/ti/wlcore/wlcore_i.h | 1 +
include/linux/wl12xx.h| 1 -
4 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c
b/drivers/net/wireless/ti/wlcore/main.c
index 11dab9a..e771de0 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5900,7 +5900,6 @@ static void wlcore_nvs_cb(const struct firmware *fw, void
*context)
struct wl1271 *wl = context;
struct platform_device *pdev = wl-pdev;
struct wlcore_platdev_data *pdev_data = pdev-dev.platform_data;
- struct wl12xx_platform_data *pdata = pdev_data-pdata;
int ret;
@@ -5947,7 +5946,7 @@ static void wlcore_nvs_cb(const struct firmware *fw, void
*context)
if (!ret) {
wl-irq_wake_enabled = true;
device_init_wakeup(wl-dev, 1);
- if (pdata-pwr_in_suspend)
+ if (pdev_data-pwr_in_suspend)
wl-hw-wiphy-wowlan = wlcore_wowlan_support;
}
#endif
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 29ef249..4c7e8ac 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -260,7 +260,7 @@ static int wl1271_probe(struct sdio_func *func,
dev_dbg(glue-dev, sdio PM caps = 0x%x\n, mmcflags);
if (mmcflags MMC_PM_KEEP_POWER)
- pdev_data-pdata-pwr_in_suspend = true;
+ pdev_data-pwr_in_suspend = true;
sdio_set_drvdata(func, glue);
diff --git a/drivers/net/wireless/ti/wlcore/wlcore_i.h
b/drivers/net/wireless/ti/wlcore/wlcore_i.h
index e5e1464..f2c4227 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore_i.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore_i.h
@@ -209,6 +209,7 @@ struct wl1271_if_operations {
struct wlcore_platdev_data {
struct wl12xx_platform_data *pdata;
struct wl1271_if_operations *if_ops;
+ bool pwr_in_suspend;
};
#define MAX_NUM_KEYS 14
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 1bfcd19..ab90b1c 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -59,7 +59,6 @@ struct wl12xx_platform_data {
int irq;
int board_ref_clock;
int board_tcxo_clock;
- bool pwr_in_suspend;
};
#ifdef CONFIG_WILINK_PLATFORM_DATA
--
1.8.3.2
--
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 v4 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
The platform_quirk element in the platform data was used to change the
way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
the irqflags used and treat edge trigger differently from the rest.
Instead of hiding this irq flag setting behind the quirk, have the
board files set the flags during initialization. This will be more
meaningful than driver-specific quirks when we switch to DT.
Additionally, fix missing gpio_request() calls in the boarding files
(so that setting the flags actually works).
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-davinci/board-da850-evm.c | 8 +++-
arch/arm/mach-omap2/board-omap3evm.c | 19 ++
arch/arm/mach-omap2/board-zoom-peripherals.c | 30 +---
drivers/net/wireless/ti/wlcore/debugfs.c | 2 +-
drivers/net/wireless/ti/wlcore/main.c| 17
drivers/net/wireless/ti/wlcore/wlcore.h | 5 ++---
include/linux/wl12xx.h | 4
7 files changed, 64 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index bea6793..03de2e9 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1377,7 +1377,6 @@ static const short da850_wl12xx_pins[] __initconst = {
static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
.board_ref_clock= WL12XX_REFCLOCK_38,
- .platform_quirks= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
};
static __init int da850_wl12xx_init(void)
@@ -1408,6 +1407,13 @@ static __init int da850_wl12xx_init(void)
goto free_wlan_en;
}
+ ret = irq_set_irq_type(gpio_to_irq(DA850_WLAN_IRQ),
+ IRQ_TYPE_EDGE_RISING);
+ if (ret) {
+ pr_err(Could not set wl12xx irq type: %d\n, ret);
+ goto free;
+ }
+
da850_wl12xx_wlan_data.irq = gpio_to_irq(DA850_WLAN_IRQ);
ret = wl12xx_set_platform_data(da850_wl12xx_wlan_data);
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 8c02626..9c7dfc5 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -614,12 +614,31 @@ static void __init omap3_evm_wl12xx_init(void)
/* WL12xx WLAN Init */
omap3evm_wlan_data.irq = gpio_to_irq(OMAP3EVM_WLAN_IRQ_GPIO);
+
+ ret = gpio_request_one(OMAP3EVM_WLAN_IRQ_GPIO, GPIOF_IN,
+ OMAP3EVM_WLAN_IRQ_GPIO);
+ if (ret) {
+ pr_err(error requesting wl12xx gpio: %d\n, ret);
+ goto out;
+ }
+
+ ret = irq_set_irq_type(gpio_to_irq(OMAP3EVM_WLAN_IRQ_GPIO),
+ IRQ_TYPE_LEVEL_HIGH);
+ if (ret) {
+ pr_err(error setting wl12xx irq type: %d\n, ret);
+ goto free;
+ }
+
ret = wl12xx_set_platform_data(omap3evm_wlan_data);
if (ret)
pr_err(error setting wl12xx data: %d\n, ret);
ret = platform_device_register(omap3evm_wlan_regulator);
if (ret)
pr_err(error registering wl12xx device: %d\n, ret);
+out:
+ return;
+free:
+ gpio_free(OMAP3EVM_WLAN_IRQ_GPIO);
#endif
}
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index a90375d..4f84cf9 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -339,16 +339,40 @@ static void enable_board_wakeup_source(void)
OMAP_WAKEUP_EN | OMAP_PIN_INPUT_PULLUP);
}
-void __init zoom_peripherals_init(void)
+static void __init zoom_wilink_init(void)
{
int ret;
omap_zoom_wlan_data.irq = gpio_to_irq(OMAP_ZOOM_WLAN_IRQ_GPIO);
- ret = wl12xx_set_platform_data(omap_zoom_wlan_data);
- if (ret)
+ ret = gpio_request_one(OMAP_ZOOM_WLAN_IRQ_GPIO, GPIOF_IN,
+ OMAP_ZOOM_WLAN_IRQ_GPIO);
+ if (ret) {
+ pr_err(error requesting wl12xx gpio: %d\n, ret);
+ goto out;
+ }
+
+ ret = irq_set_irq_type(gpio_to_irq(OMAP_ZOOM_WLAN_IRQ_GPIO),
+ IRQ_TYPE_LEVEL_HIGH);
+ if (ret) {
+ pr_err(error setting wl12xx irq type: %d\n, ret);
+ goto free;
+ }
+
+ ret = wl12xx_set_platform_data(omap_zoom_wlan_data);
+ if (ret) {
pr_err(error setting wl12xx data: %d\n, ret);
+ goto free;
+ }
+out:
+ return;
+free:
+ gpio_free(OMAP_ZOOM_WLAN_IRQ_GPIO);
+}
+void __init zoom_peripherals_init(void)
+{
+ zoom_wilink_init();
omap_hsmmc_init(mmc);
Re: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
Hi,
On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
# define soc_is_omap543x() is_omap543x()
#endif
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx() is_dra7xx()
+# define soc_is_dra75x() is_dra75x()
since this platform is DT-only, couldn't we just believe DT-data to be
correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
I patched this for OMAP5 (compile-tested only, no boards available) and
came out with the patch below (still needs to be split):
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b3136e5 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -13,7 +13,7 @@
/ {
model = TI OMAP5 uEVM board;
- compatible = ti,omap5-uevm, ti,omap5;
+ compatible = ti,omap5-uevm, ti,omap5432-es2.0, ti,omap5;
memory {
device_type = memory;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 07be2cd..a7bc906 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -17,7 +17,7 @@
#address-cells = 1;
#size-cells = 1;
- compatible = ti,omap5;
+ compatible = ti,omap5432-es2.0, ti,omap5430-es2.0, ti,omap5;
interrupt-parent = gic;
aliases {
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2dc62a2..ee94309 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -563,49 +563,6 @@ void __init omap4xxx_check_revision(void)
pr_info(%s %s\n, soc_name, soc_rev);
}
-void __init omap5xxx_check_revision(void)
-{
- u32 idcode;
- u16 hawkeye;
- u8 rev;
-
- idcode = read_tap_reg(OMAP_TAP_IDCODE);
- hawkeye = (idcode 12) 0x;
- rev = (idcode 28) 0xff;
- switch (hawkeye) {
- case 0xb942:
- switch (rev) {
- case 0:
- omap_revision = OMAP5430_REV_ES1_0;
- break;
- case 1:
- default:
- omap_revision = OMAP5430_REV_ES2_0;
- }
- break;
-
- case 0xb998:
- switch (rev) {
- case 0:
- omap_revision = OMAP5432_REV_ES1_0;
- break;
- case 1:
- default:
- omap_revision = OMAP5432_REV_ES2_0;
- }
- break;
-
- default:
- /* Unknown default to latest silicon rev as default*/
- omap_revision = OMAP5430_REV_ES2_0;
- }
-
- sprintf(soc_name, OMAP%04x, omap_rev() 16);
- sprintf(soc_rev, ES%d.0, (omap_rev() 12) 0xf);
-
- pr_info(%s %s\n, soc_name, soc_rev);
-}
-
/*
* Set up things for map_io and processor detection later on. Gets called
* pretty much first thing from board init. For multi-omap, this gets
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4a3f06f..aa28940 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -633,8 +633,7 @@ void __init omap4430_init_late(void)
#ifdef CONFIG_SOC_OMAP5
void __init omap5_init_early(void)
{
- omap2_set_globals_tap(OMAP54XX_CLASS,
- OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
+ omap2_set_globals_tap(-1, OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
omap2_set_globals_control(OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE));
omap2_set_globals_prm(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE));
@@ -644,7 +643,6 @@ void __init omap5_init_early(void)
omap_prm_base_init();
omap_cm_base_init();
omap44xx_prm_init();
- omap5xxx_check_revision();
omap54xx_voltagedomains_init();
omap54xx_powerdomains_init();
omap54xx_clockdomains_init();
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 8c616e4..b8339ad 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -35,6 +35,7 @@
#ifndef __ASSEMBLY__
#include linux/bitops.h
+#include linux/of.h
/*
* Test if multicore OMAP support is needed
@@ -194,7 +195,6 @@ IS_OMAP_CLASS(24xx, 0x24)
IS_OMAP_CLASS(34xx, 0x34)
IS_OMAP_CLASS(44xx, 0x44)
IS_AM_CLASS(35xx, 0x35)
-IS_OMAP_CLASS(54xx, 0x54)
IS_AM_CLASS(33xx, 0x33)
IS_AM_CLASS(43xx, 0x43)
@@ -207,7 +207,6 @@ IS_OMAP_SUBCLASS(363x, 0x363)
IS_OMAP_SUBCLASS(443x, 0x443)
IS_OMAP_SUBCLASS(446x, 0x446)
IS_OMAP_SUBCLASS(447x, 0x447)
-IS_OMAP_SUBCLASS(543x, 0x543)
IS_TI_SUBCLASS(816x, 0x816)
IS_TI_SUBCLASS(814x, 0x814)
@@ -373,10 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430)
# endif
# if defined(CONFIG_SOC_OMAP5)
-# undef soc_is_omap54xx
-# undef soc_is_omap543x
-# define soc_is_omap54xx()
[PATCH v4 5/8] wlcore: add initial device tree support to the sdio module
If platform data is not available, try to get the required information
from the device tree. Register an OF match table and parse the
appropriate device tree nodes.
Parse interrupt property only, for now.
Signed-off-by: Luciano Coelho coe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
drivers/net/wireless/ti/wlcore/sdio.c | 69 ---
1 file changed, 63 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c
b/drivers/net/wireless/ti/wlcore/sdio.c
index 4c7e8ac..9370d7e 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -30,7 +30,7 @@
#include linux/mmc/sdio_ids.h
#include linux/mmc/card.h
#include linux/mmc/host.h
-#include linux/gpio.h
+#include linux/of_irq.h
#include linux/wl12xx.h
#include linux/pm_runtime.h
#include linux/printk.h
@@ -214,6 +214,43 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
};
+static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device
*dev)
+{
+ struct wl12xx_platform_data *pdata;
+ struct device_node *np = dev-of_node;
+
+ if (!np) {
+ np = of_find_matching_node(NULL, dev-driver-of_match_table);
+ if (!np) {
+ dev_notice(dev, device tree node not available\n);
+ pdata = ERR_PTR(-ENODEV);
+ goto out;
+ }
+ }
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(dev, can't allocate platform data\n);
+ pdata = ERR_PTR(-ENODEV);
+ goto out;
+ }
+
+ pdata-irq = irq_of_parse_and_map(np, 0);
+ if (pdata-irq 0) {
+ dev_err(dev, can't get interrupt gpio from the device tree\n);
+ goto out_free;
+ }
+
+ goto out;
+
+out_free:
+ kfree(pdata);
+ pdata = ERR_PTR(-ENODEV);
+
+out:
+ return pdata;
+}
+
static int wl1271_probe(struct sdio_func *func,
const struct sdio_device_id *id)
{
@@ -248,11 +285,22 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
+ /* The pdata allocated here is freed when the device is freed,
+* so we don't need an additional out label to free it in case
+* of error further on.
+*/
+
+ /* Try to get legacy platform data from the board file */
pdev_data-pdata = wl12xx_get_platform_data();
if (IS_ERR(pdev_data-pdata)) {
- ret = PTR_ERR(pdev_data-pdata);
- dev_err(glue-dev, missing wlan platform data: %d\n, ret);
- goto out_free_glue;
+ dev_info(func-dev,
+legacy platform data not found, trying device
tree\n);
+
+ pdev_data-pdata = wlcore_get_pdata_from_of(func-dev);
+ if (IS_ERR(pdev_data-pdata)) {
+ dev_err(func-dev, can't get platform data\n);
+ goto out_free_glue;
+ }
}
/* if sdio can keep power while host is suspended, enable wow */
@@ -386,16 +434,25 @@ static const struct dev_pm_ops wl1271_sdio_pm_ops = {
};
#endif
+static const struct of_device_id wlcore_sdio_of_match_table[] = {
+ { .compatible = ti,wilink6 },
+ { .compatible = ti,wilink7 },
+ { .compatible = ti,wilink8 },
+ { }
+};
+MODULE_DEVICE_TABLE(of, wlcore_sdio_of_match_table);
+
static struct sdio_driver wl1271_sdio_driver = {
.name = wl1271_sdio,
.id_table = wl1271_devices,
.probe = wl1271_probe,
.remove = wl1271_remove,
-#ifdef CONFIG_PM
.drv = {
+#ifdef CONFIG_PM
.pm = wl1271_sdio_pm_ops,
- },
#endif
+ .of_match_table = of_match_ptr(wlcore_sdio_of_match_table),
+ },
};
static int __init wl1271_init(void)
--
1.8.3.2
--
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: Linux kernel for OMAP5432 uEVM
On 07/30/2013 07:44 AM, Chen Baozi wrote: On Jul 30, 2013, at 8:24 PM, Nishanth Menon n...@ti.com wrote: On 07/30/2013 01:07 AM, Chen Baozi wrote: On Jul 30, 2013, at 11:52 AM, Lokesh Vutla lokeshvu...@ti.com wrote: Hi Chen, On Tuesday 30 July 2013 09:08 AM, Chen Baozi wrote: Hi all, I'm trying to boot my OMAP5432 uEVM devboard with the lastest kernel of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git. Which branch are you using ? the master branch. However, after u-boot loading uImage DTB, there is no output message any more, such as: Clk data might be missing here. Try merging the below branch and test it https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=for_3.11/out_of_tree/omap5_clk_data Thanks, I'll have a try. There is also clock data dts support now in Tero's series: http://marc.info/?l=linux-omapm=137456411706971w=2 Thanks, I'll have a look though Lokesh's suggestion has already booted my board. Might be a stupid question. What's the different functionality between these two series of patch set? For it seems clk data patches have done the some of initialization that make the system boot. two different approaches - one using clock data in kernel, other with clock data in dtb and generic clock drivers. Tero's approach is what is being massaged for upstream as we do not wish to add additional clock data into kernel source tree anymore. -- Regards, Nishanth Menon -- 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/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
On Tue, Jul 30, 2013 at 04:10:09PM +0300, Felipe Balbi wrote: Hi, On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote: @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430) # define soc_is_omap543x() is_omap543x() #endif +# if defined(CONFIG_SOC_DRA7XX) +# undef soc_is_dra7xx +# undef soc_is_dra75x +# define soc_is_dra7xx() is_dra7xx() +# define soc_is_dra75x() is_dra75x() since this platform is DT-only, couldn't we just believe DT-data to be correct of_machine_is_compatible() ? 2/3 of this patch would be removed. s/correct of_/correct and use of_ -- balbi signature.asc Description: Digital signature
[GIT PULL] urgent omap5 regulator updates against v3.11-rc3
The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092: Linux 3.11-rc1 (2013-07-14 15:18:27 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.11/fixes-omap5 for you to fetch changes up to bd3c5544a1e98a25d2d24c98779092e0f84373f7: ARM: dts: omap5-uevm: update optional/unused regulator configurations (2013-07-29 23:43:20 -0700) Fixes for omap5-uevm regulators from Nishanth Menon n...@ti.com: Due to wrong older revision of documentation used as reference, we seem to have a bunch of LDOs wrongly configured on OMAP5 uEVM. This series is based power tree on production board 750-2628-XXX platform. Unfortunately, the wrong voltages may be detrimental to OMAP5 as they supply hardware blocks at voltages that are out of specification. There is a chance that without these fixes there can be hardware damage to omap5-uevm boards with the v3.11-rc series. Nishanth Menon (3): ARM: dts: omap5-uevm: document regulator signals used on the actual board ARM: dts: omap5-uevm: fix regulator configurations mandatory for SoC ARM: dts: omap5-uevm: update optional/unused regulator configurations arch/arm/boot/dts/omap5-uevm.dts | 78 +--- 1 file changed, 49 insertions(+), 29 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: [GIT PULL] ARM: OMAP2+: hwmod fixes for v3.11-rc
Arnd Olof, Can you please take this pull request directly? Other than the omap5 regulator dts changes I just posted I don't yet have anything else queued up right now. Regards, Tony * Paul Walmsley p...@pwsan.com [130730 04:53]: Hi Tony The following changes since commit 5ae90d8e467e625e447000cb4335c4db973b1095: Linux 3.11-rc3 (2013-07-28 20:53:33 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.11-rc/omap-fixes-b for you to fetch changes up to 50c2a3a1518befe992f868fc1fd867bdad9776ad: ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space (2013-07-30 05:13:37 -0600) Some OMAP hwmod fixes for v3.11-rc. Mostly intended to fix an earlyprintk regression and an AM33xx cpgmac power management regression. Basic build, boot, and PM tests are available here: http://www.pwsan.com/omap/testlogs/hwmod_fixes_a_v3.11-rc/20130730042132/ The tests include temporary fixes for the unrelated 2430SDP and OMAP3 boot regressions, which are not part of this signed tag. Afzal Mohammed (2): ARM: OMAP2+: hwmod: rt address space index for DT ARM: OMAP2+: hwmod: AM335x: fix cpgmac address space Rajendra Nayak (3): ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL ARM: OMAP2+: Avoid idling memory controllers with no drivers ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device state arch/arm/mach-omap2/omap_device.c | 18 arch/arm/mach-omap2/omap_hwmod.c | 2 +- arch/arm/mach-omap2/omap_hwmod.h | 50 ++ arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 6 +-- arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 3 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 9 ++-- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 5 +-- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 3 +- arch/arm/mach-omap2/serial.c | 11 - 9 files changed, 83 insertions(+), 24 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 v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
* Felipe Balbi ba...@ti.com [130730 06:25]: On Tue, Jul 30, 2013 at 04:10:09PM +0300, Felipe Balbi wrote: Hi, On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote: @@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430) # define soc_is_omap543x() is_omap543x() #endif +# if defined(CONFIG_SOC_DRA7XX) +# undef soc_is_dra7xx +# undef soc_is_dra75x +# define soc_is_dra7xx() is_dra7xx() +# define soc_is_dra75x() is_dra75x() since this platform is DT-only, couldn't we just believe DT-data to be correct of_machine_is_compatible() ? 2/3 of this patch would be removed. s/correct of_/correct and use of_ Makes sense to me. AFAIK we no longer need to initialize much anything super early. Regards, Tony -- 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: Division by zero caused by CCF
Hi,
this is still broken on v3.11-rc3 and Luca got his Blaze (OMAP4) to fail
the same way
On Tue, Jul 16, 2013 at 10:45:38AM -0700, Mike Turquette wrote:
On Tue, Jul 16, 2013 at 6:10 AM, Eduardo Valentin
eduardo.valen...@ti.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Adding Mike's correct address.
On 16-07-2013 08:37, Felipe Balbi wrote:
Hi,
trying to get USB host verified on OMAP5 uEVM with v3.11-rc1. The
clk_set_rate() call ends up in a division by zero, which is quite
interesting provided the driver will only call clk_set_rate() if the
clock is valid and clk_rate is != 0.
[ 22.009238] Division by zero in kernel.
[ 22.009250] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
3.11.0-rc1-00081-g3310d44-dirty #118
[ 22.009275] [c001c83c] (unwind_backtrace+0x0/0xf0) from [c0018a1c]
(show_stack+0x10/0x14)
[ 22.009289] [c0018a1c] (show_stack+0x10/0x14) from [c057403c]
(dump_stack+0x70/0x8c)
[ 22.009304] [c057403c] (dump_stack+0x70/0x8c) from [c02e4154]
(Ldiv0+0x8/0x10)
[ 22.009319] [c02e4154] (Ldiv0+0x8/0x10) from [c048d460]
(clk_divider_set_rate+0x10/0xdc)
[ 22.009331] [c048d460] (clk_divider_set_rate+0x10/0xdc) from
[c048c124] (clk_change_rate+0x38/0xb0)
[ 22.009341] [c048c124] (clk_change_rate+0x38/0xb0) from [c048c20c]
(clk_set_rate+0x70/0xa8)
[ 22.009354] [c048c20c] (clk_set_rate+0x70/0xa8) from [c042b244]
(nop_usb_xceiv_probe+0x1fc/0x2f8)
[ 22.009369] [c042b244] (nop_usb_xceiv_probe+0x1fc/0x2f8) from
[c036b47c] (platform_drv_probe+0x18/0x1c)
[ 22.009380] [c036b47c] (platform_drv_probe+0x18/0x1c) from
[c0369f44] (really_probe+0x70/0x1f4)
[ 22.009390] [c0369f44] (really_probe+0x70/0x1f4) from [c036a1dc]
(driver_probe_device+0x30/0x48)
[ 22.009401] [c036a1dc] (driver_probe_device+0x30/0x48) from
[c036a288] (__driver_attach+0x94/0x98)
[ 22.009411] [c036a288] (__driver_attach+0x94/0x98) from [c0368748]
(bus_for_each_dev+0x54/0x88)
[ 22.009420] [c0368748] (bus_for_each_dev+0x54/0x88) from [c036972c]
(bus_add_driver+0xdc/0x29c)
[ 22.009430] [c036972c] (bus_add_driver+0xdc/0x29c) from [c036a760]
(driver_register+0x78/0x190)
[ 22.009440] [c036a760] (driver_register+0x78/0x190) from [c00087b0]
(do_one_initcall+0x34/0x164)
[ 22.009453] [c00087b0] (do_one_initcall+0x34/0x164) from [c07b18f4]
(do_basic_setup+0x90/0xc4)
[ 22.009466] [c07b18f4] (do_basic_setup+0x90/0xc4) from [c07b199c]
(kernel_init_freeable+0x74/0x110)
[ 22.009478] [c07b199c] (kernel_init_freeable+0x74/0x110) from
[c05676c4] (kernel_init+0x8/0xe4)
[ 22.009491] [c05676c4] (kernel_init+0x8/0xe4) from [c0014648]
(ret_from_fork+0x14/0x2c)
I believe the problem is the actual division reaching
clk_divider_set_rate().
drivers/clk/clk-divider.c::clk_divider_set_rate()
| static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
| unsigned long parent_rate)
| {
| struct clk_divider *divider = to_clk_divider(hw);
| unsigned int div, value;
| unsigned long flags = 0;
| u32 val;
|
| div = parent_rate / rate;
right here, but how come rate would zero provided driver checks for it
as below.
drivers/usb/phy/phy-nop.c::nop_usb_xceiv_probe()
| if (!IS_ERR(nop-clk) clk_rate) {
| err = clk_set_rate(nop-clk, clk_rate);
| if (err) {
| dev_err(pdev-dev, Error setting clock
rate\n);
| return err;
| }
| }
I've added a few prints around CCF to try and track what's going on:
[ 21.592690] nop_usb_xceiv_probe rate 1920
[ 21.592700] clk_set_rate rate 1920
[ 21.592707] clk_calc_new_rates rate 1920
[ 21.592713] clk_divider_round_rate rate 1920
[ 21.592719] clk_divider_bestdiv rate 1920
[ 21.592726] clk_change_rate best_parent_rate 0
or because we reach:
if (clk-ops-set_rate)
clk-ops-set_rate(clk-hw, clk-new_rate,
best_parent_rate);
with clk-new_rate == 0.
Hmm, I'll look into this. We used to have a check which would at least
WARN on division by zero, but looks like that was replaced by some
other code at some point.
Also does your clock have the CLK_SET_RATE_PARENT flag set? If so then
you could be propagating a rate request of zero up to the next parent,
which would be a neat trick... however based on the dump that doesn't
seem to be what is happening.
Regards,
Mike
[ 21.592732] clk_divider_set_rate rate 0
[ 21.592737] Division by zero in kernel.
[ 21.592747] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
3.11.0-rc1-00081-g3310d44-dirty #121
[ 21.592773] [c001c83c] (unwind_backtrace+0x0/0xf0) from [c0018a1c]
(show_stack+0x10/0x14)
[ 21.592787] [c0018a1c]
Re: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
# define soc_is_omap543x() is_omap543x()
#endif
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()is_dra7xx()
+# define soc_is_dra75x()is_dra75x()
since this platform is DT-only, couldn't we just believe DT-data to be
correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
I patched this for OMAP5 (compile-tested only, no boards available) and
came out with the patch below (still needs to be split):
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b3136e5 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -13,7 +13,7 @@
/ {
model = TI OMAP5 uEVM board;
- compatible = ti,omap5-uevm, ti,omap5;
+ compatible = ti,omap5-uevm, ti,omap5432-es2.0, ti,omap5;
ok, nice and simpler way.
But would this make different revisions, to appear the same ?
Regards,
Sricharan
memory {
device_type = memory;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 07be2cd..a7bc906 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -17,7 +17,7 @@
#address-cells = 1;
#size-cells = 1;
- compatible = ti,omap5;
+ compatible = ti,omap5432-es2.0, ti,omap5430-es2.0, ti,omap5;
interrupt-parent = gic;
aliases {
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2dc62a2..ee94309 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -563,49 +563,6 @@ void __init omap4xxx_check_revision(void)
pr_info(%s %s\n, soc_name, soc_rev);
}
-void __init omap5xxx_check_revision(void)
-{
- u32 idcode;
- u16 hawkeye;
- u8 rev;
-
- idcode = read_tap_reg(OMAP_TAP_IDCODE);
- hawkeye = (idcode 12) 0x;
- rev = (idcode 28) 0xff;
- switch (hawkeye) {
- case 0xb942:
- switch (rev) {
- case 0:
- omap_revision = OMAP5430_REV_ES1_0;
- break;
- case 1:
- default:
- omap_revision = OMAP5430_REV_ES2_0;
- }
- break;
-
- case 0xb998:
- switch (rev) {
- case 0:
- omap_revision = OMAP5432_REV_ES1_0;
- break;
- case 1:
- default:
- omap_revision = OMAP5432_REV_ES2_0;
- }
- break;
-
- default:
- /* Unknown default to latest silicon rev as default*/
- omap_revision = OMAP5430_REV_ES2_0;
- }
-
- sprintf(soc_name, OMAP%04x, omap_rev() 16);
- sprintf(soc_rev, ES%d.0, (omap_rev() 12) 0xf);
-
- pr_info(%s %s\n, soc_name, soc_rev);
-}
-
/*
* Set up things for map_io and processor detection later on. Gets called
* pretty much first thing from board init. For multi-omap, this gets
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4a3f06f..aa28940 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -633,8 +633,7 @@ void __init omap4430_init_late(void)
#ifdef CONFIG_SOC_OMAP5
void __init omap5_init_early(void)
{
- omap2_set_globals_tap(OMAP54XX_CLASS,
- OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
+ omap2_set_globals_tap(-1, OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE));
omap2_set_globals_control(OMAP2_L4_IO_ADDRESS(OMAP54XX_SCM_BASE),
OMAP2_L4_IO_ADDRESS(OMAP54XX_CTRL_BASE));
omap2_set_globals_prm(OMAP2_L4_IO_ADDRESS(OMAP54XX_PRM_BASE));
@@ -644,7 +643,6 @@ void __init omap5_init_early(void)
omap_prm_base_init();
omap_cm_base_init();
omap44xx_prm_init();
- omap5xxx_check_revision();
omap54xx_voltagedomains_init();
omap54xx_powerdomains_init();
omap54xx_clockdomains_init();
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 8c616e4..b8339ad 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -35,6 +35,7 @@
#ifndef __ASSEMBLY__
#include linux/bitops.h
+#include linux/of.h
/*
* Test if multicore OMAP support is needed
@@ -194,7 +195,6 @@ IS_OMAP_CLASS(24xx, 0x24)
IS_OMAP_CLASS(34xx, 0x34)
IS_OMAP_CLASS(44xx, 0x44)
IS_AM_CLASS(35xx, 0x35)
-IS_OMAP_CLASS(54xx, 0x54)
IS_AM_CLASS(33xx, 0x33)
IS_AM_CLASS(43xx, 0x43)
@@ -207,7 +207,6 @@ IS_OMAP_SUBCLASS(363x, 0x363)
IS_OMAP_SUBCLASS(443x, 0x443)
IS_OMAP_SUBCLASS(446x, 0x446)
IS_OMAP_SUBCLASS(447x, 0x447)
-IS_OMAP_SUBCLASS(543x, 0x543)
IS_TI_SUBCLASS(816x, 0x816)
IS_TI_SUBCLASS(814x, 0x814)
@@
Re: [PATCH 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
On Tue, Jul 30, 2013 at 11:15:20AM +0300, Felipe Balbi wrote: look at Greg's and my reply to that email. but finally Greg agreed to what Tomasz proposed no? that's not what I see in the thread. I see Greg agreed to regulator's own IDs being sequentially created, but he mentions device names can change. And that no one should _ever_ rely on them to be a specific name, the bus is responsible for creating the id, it could be random and everything should work just fine. thanks, 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
Re: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
Hi,
On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote:
On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
# define soc_is_omap543x()is_omap543x()
#endif
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx() is_dra7xx()
+# define soc_is_dra75x() is_dra75x()
since this platform is DT-only, couldn't we just believe DT-data to be
correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
I patched this for OMAP5 (compile-tested only, no boards available) and
came out with the patch below (still needs to be split):
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b3136e5 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -13,7 +13,7 @@
/ {
model = TI OMAP5 uEVM board;
- compatible = ti,omap5-uevm, ti,omap5;
+ compatible = ti,omap5-uevm, ti,omap5432-es2.0, ti,omap5;
ok, nice and simpler way.
But would this make different revisions, to appear the same ?
well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up,
it should be treated as such, then you can pass a different string to
that new board's compatible attribute.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 2/4] phy: phy-amxxxx-usb: Add PHY driver for amxxxx platform
On 7/30/2013 2:23 PM, Sebastian Andrzej Siewior wrote: On 07/30/2013 07:19 AM, George Cherian wrote: So from what I see now, it is most likely the easiest thing to just add that wakeup to the phy driver I posted. Do you agree? The whole idea of writing a seperate phy driver was to use the generic phy framework and most of the am devices have the same phy (eg am335x, am437x). Now since the register is shared in am335x for phy_wkup (Not in the case of am437x) how are you planning to map it. I feel if omap_control_usb can delegate the writes to phy_wkup, phy_on and phy_off, it makes the life simpler. that omap-control driver looks a little strange. It has a compatible field saying ti,omap-control-usb and then it requires additionally a ti,type property which should have been avoided. ti,type property is to differentiate between usb2 and usb3 phy for a single soc. for eg: OMAP5 has both usb2 and usb3 phy -- -George -- 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/4] phy: phy-amxxxx-usb: Add PHY driver for amxxxx platform
On Tue, Jul 30, 2013 at 07:54:55PM +0530, George Cherian wrote: On 7/30/2013 2:23 PM, Sebastian Andrzej Siewior wrote: On 07/30/2013 07:19 AM, George Cherian wrote: So from what I see now, it is most likely the easiest thing to just add that wakeup to the phy driver I posted. Do you agree? The whole idea of writing a seperate phy driver was to use the generic phy framework and most of the am devices have the same phy (eg am335x, am437x). Now since the register is shared in am335x for phy_wkup (Not in the case of am437x) how are you planning to map it. I feel if omap_control_usb can delegate the writes to phy_wkup, phy_on and phy_off, it makes the life simpler. that omap-control driver looks a little strange. It has a compatible field saying ti,omap-control-usb and then it requires additionally a ti,type property which should have been avoided. ti,type property is to differentiate between usb2 and usb3 phy for a single soc. for eg: OMAP5 has both usb2 and usb3 phy let's try not to add any new TI-specific DT bindings, can you figure that out by reading some revision register ? Or perhaps by using different compatible strings ? -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote:
On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
# define soc_is_omap543x()is_omap543x()
#endif
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx() is_dra7xx()
+# define soc_is_dra75x() is_dra75x()
since this platform is DT-only, couldn't we just believe DT-data to be
correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
I patched this for OMAP5 (compile-tested only, no boards available) and
came out with the patch below (still needs to be split):
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b3136e5 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -13,7 +13,7 @@
/ {
model = TI OMAP5 uEVM board;
- compatible = ti,omap5-uevm, ti,omap5;
+ compatible = ti,omap5-uevm, ti,omap5432-es2.0, ti,omap5;
ok, nice and simpler way.
But would this make different revisions, to appear the same ?
well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up,
it should be treated as such, then you can pass a different string to
that new board's compatible attribute.
Yes for OMAP5. I was thinking in general about this approach.
For example, for OMAP4 we have same board and
different revisions can be socketed there.
For OMAP5, this is good.
Regards,
Sricharan
--
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/4] phy: phy-amxxxx-usb: Add PHY driver for amxxxx platform
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/30/2013 04:33 PM, Felipe Balbi wrote: let's try not to add any new TI-specific DT bindings, can you figure that out by reading some revision register ? Or perhaps by using different compatible strings ? I would suggest to use a different binding. But I'm currently trying to come up with something for am335x with a device reference? Sebastian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCAAGBQJR99AZAAoJEHuW6BYqjPXRf5AP/jcMFUstlqqujRppC2gMsqh6 +xlpwh5hCHJPxQizwkG8kWW9XGMIMPmqODqoYwA9dFI3a5VgVVTRUkhnHEXlAt9A 8X0Sl+mdKx0XwvjxjRDPUEYqvpDFAPYxgnwvxEfjtnDgQs5ikxFj4zaMonAj5oK0 s7XnOImJmdoHbFfvR5Cx10zmfa0BjQETqk5bt/j8+8jnv86cZk8fEGE8XYoUnhFw BsEZgfSZH/pV6s339gTs+x4+zW0luJIhJdtQmh5Ylo+xt/3TYAmDuZ0v88A6gFV+ MZjJLh2L9Sr6g0Pl/Rk5aMZhe5GSSrZYuu4Vltpz2xF1SjRRqg6ykmw6sqnme2uj BWwq5qNG5EFPtyhZCupTZ/z388kKOhC54kbFwJW7Duv9TkDUOctVuUbehEN4Pu/u HljW3FoYvvB/7EOXJhBcG6qy+ClS7mKkJJHeavnzbtzeg2jO1ZSKV1S/bJfpY4F6 ualEKdC+A+UXYNHSnSkbdJPAfIQw9BOhdD3nszdzrB+0xUU1ul2V3Zdf0xKsUVPj 8qkK9IuHum/pUfUEK/3C/igOhtag24LOhiGu1MG8Axe4FdmiTixhnV4DZzGyAMcm 8Br/gtKVCuoU89y0mYhsAA5o+3e6YKE7lPQVULtrZO7/+wbOTrEaukvwCMB/NngL +qNzg8WzrRHCAQnSKni9 =712g -END PGP SIGNATURE- -- 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 4/4] ARM: dts: AM33XX: update rtc node compatibility
On Tue, Jul 30, 2013 at 06:05:52AM +0100, Gururaja Hebbar wrote:
Hi,
On 7/3/2013 2:17 PM, Hebbar Gururaja wrote:
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti,am3352-rtc to enable handling
of this feature inside rtc-omap driver.
The other 2 rtc driver related patches have been pulled up. If you have
no comments, can you please pull this up.
Regards
Gururaja
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
---
:100644 100644 77aa1b0... dde180a... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 77aa1b0..dde180a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -297,7 +297,7 @@
};
rtc@44e3e000 {
- compatible = ti,da830-rtc;
+ compatible = ti,am3352-rtc;
Given that this is backwards compatible with the old binding, it would
be nicer to have this as:
compatible = ti,am3352-rtc, ti,da830-rtc;
We must get into the habit of changing dts files in a
backwards-compatible fashion.
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 v2] ARM: v6: prevent gcc 4.5 from reordering extended CP15 reads above is_smp() test
On Tue, Jul 30, 2013 at 12:32:06PM +0100, Paul Walmsley wrote: Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc (ARM: 7757/1: mm: don't flush icache in switch_mm with hardware broadcasting) breaks the boot on OMAP2430SDP with omap2plus_defconfig. Tracked to an undefined instruction abort from the CP15 read in cache_ops_need_broadcast(). It turns out that gcc 4.5 reorders the extended CP15 read above the is_smp() test. This breaks ARM1136 r0 cores, since they don't support several CP15 registers that later ARM cores do. ARM1136JF-S TRM section 3.2.1 Register allocation has the details. So mark the extended CP15 read as clobbering memory, which prevents the compiler from reordering it before the is_smp() test. Russell states that the code generated from this approach is preferable to marking the inline asm as volatile. Remove the existing condition code clobber as it's obsolete, per Nico's post: http://www.spinics.net/lists/arm-kernel/msg261208.html This patch is a collaboration with Will Deacon and Russell King. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Will Deacon will.dea...@arm.com Cc: Russell King rmk+ker...@arm.linux.org.uk Cc: Nicolas Pitre nicolas.pi...@linaro.org Cc: Tony Lindgren t...@atomide.com --- Acked-by: Will Deacon will.dea...@arm.com Will -- 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: [PATCHv4 01/33] CLK: clkdev: add support for looking up clocks from DT
On 07/23/2013 02:19 AM, Tero Kristo wrote:
clk_get_sys / clk_get can now find clocks from device-tree. If a DT clock
is found, an entry is added to the clk_lookup list also for subsequent
searches.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Russell King li...@arm.linux.org.uk
---
drivers/clk/clkdev.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..e39f082 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -93,6 +93,18 @@ struct clk *of_clk_get_by_name(struct device_node *np, const
char *name)
EXPORT_SYMBOL(of_clk_get_by_name);
#endif
+/**
+ * clkdev_add_nolock - add lookup entry for a clock
+ * @cl: pointer to new clock lookup entry
+ *
+ * Non-locking version, used internally by clk_find() to add DT based
+ * clock lookup entries.
+ */
+static void clkdev_add_nolock(struct clk_lookup *cl)
+{
+ list_add_tail(cl-node, clocks);
+}
+
/*
* Find the correct struct clk for the device and connection ID.
* We do slightly fuzzy matching here:
@@ -106,6 +118,9 @@ static struct clk_lookup *clk_find(const char *dev_id,
const char *con_id)
{
struct clk_lookup *p, *cl = NULL;
int match, best_found = 0, best_possible = 0;
+ struct device_node *node;
+ struct clk *clk;
+ struct of_phandle_args clkspec;
if (dev_id)
best_possible += 2;
@@ -133,6 +148,23 @@ static struct clk_lookup *clk_find(const char *dev_id,
const char *con_id)
break;
}
}
+
+ if (cl)
+ return cl;
+
+ /* If clock was not found, attempt to look-up from DT */
+ node = of_find_node_by_name(NULL, con_id);
+
+ clkspec.np = node;
+
+ clk = of_clk_get_from_provider(clkspec);
+
+ if (!IS_ERR(clk)) {
+ /* We found a clock, add node to clkdev */
+ cl = clkdev_alloc(clk, con_id, dev_id);
clkdev_alloc may return NULL depending on vclkdev_alloc in which case
clkdev_add_nolock will crash trying to dereference it.
+ clkdev_add_nolock(cl);
+ }
+
return cl;
}
--
Regards,
Nishanth Menon
--
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: [PATCHv4 02/33] clk: omap: introduce clock driver
On 07/23/2013 02:19 AM, Tero Kristo wrote:
Parses OMAP clock data from DT and registers those clocks with the clock
framework. dt_omap_clk_init must be called early during boot for timer
initialization so it is exported and called from the existing clock code
instead of probing like a real driver. Based on initial work done by
Mike Turquette.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/Makefile |1 +
drivers/clk/omap/Makefile |1 +
drivers/clk/omap/clk.c| 39 +++
Minor suggestion - should we just start drivers/clk/ti/ instead of clk/omap?
AM335x/DRA7 are not strictly OMAP.. might also allow for some reuse
for other TI platforms..
include/linux/clk/omap.h | 24
4 files changed, 65 insertions(+)
create mode 100644 drivers/clk/omap/Makefile
create mode 100644 drivers/clk/omap/clk.c
create mode 100644 include/linux/clk/omap.h
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 4038c2b..d3c3733 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
obj-$(CONFIG_ARCH_ZYNQ) += zynq/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PLAT_SAMSUNG)+= samsung/
+obj-$(CONFIG_ARCH_OMAP)+= omap/
obj-$(CONFIG_X86) += x86/
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y += clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 000..4bf1929
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,39 @@
+/*
+ * OMAP PRCM clock driver
maybe then prcm-clk.c ?
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Tero Kristo t-kri...@ti.com
+ * Mike Turquette mturque...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/clk/omap.h
+#include linux/kernel.h
+#include linux/of_device.h
+
+/* FIXME - should the OMAP PRCM clock driver match generic types? */
should it? :)
+static const struct of_device_id clk_match[] = {
+ {.compatible = fixed-clock, .data = of_fixed_clk_setup, },
drivers/clk/clk-fixed-rate.c seems to already do this with
CLK_OF_DECLARE, or am I mistaken? and so on?
+ {.compatible = mux-clock, .data = of_mux_clk_setup, },
+ {.compatible = fixed-factor-clock,
+ .data = of_fixed_factor_clk_setup, },
+ {.compatible = divider-clock, .data = of_divider_clk_setup, },
+ {.compatible = gate-clock, .data = of_gate_clk_setup, },
+ {},
+};
+
+/* FIXME - need to initialize early; skip real driver registration probe */
+int __init dt_omap_clk_init(void)
Might be good to have kernel doc to explain the init requirement as
documented in commit message.
+{
+ of_clk_init(clk_match);
just doing of_clk_init(NULL); should do the job, no? that could even be
a static inline OR introduced in board_generic without additional headers?
+ return 0;
+}
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
new file mode 100644
index 000..647f02f
--- /dev/null
+++ b/include/linux/clk/omap.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
would you like to match licensing to that of the C file?
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __LINUX_CLK_OMAP_H_
+#define __LINUX_CLK_OMAP_H_
+
+int __init dt_omap_clk_init(void);
+
+#endif
--
Regards,
Nishanth Menon
--
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/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
Hi,
On Tue, Jul 30, 2013 at 08:06:31PM +0530, Sricharan R wrote:
On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote:
On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
# define soc_is_omap543x() is_omap543x()
#endif
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()is_dra7xx()
+# define soc_is_dra75x()is_dra75x()
since this platform is DT-only, couldn't we just believe DT-data to be
correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
I patched this for OMAP5 (compile-tested only, no boards available) and
came out with the patch below (still needs to be split):
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b3136e5 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -13,7 +13,7 @@
/ {
model = TI OMAP5 uEVM board;
- compatible = ti,omap5-uevm, ti,omap5;
+ compatible = ti,omap5-uevm, ti,omap5432-es2.0, ti,omap5;
ok, nice and simpler way.
But would this make different revisions, to appear the same ?
well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up,
it should be treated as such, then you can pass a different string to
that new board's compatible attribute.
Yes for OMAP5. I was thinking in general about this approach.
For example, for OMAP4 we have same board and
different revisions can be socketed there.
For OMAP5, this is good.
do we really production socketed boards? Well, at least Blaze has such
thing. But do we have too many differences that need to be trated at
arch/arm or should/could those be handled by reading IP's revision
register (e.g. usb host erratas)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCHv4 03/33] CLK: OMAP4: Add DPLL clock support
This patch probably was submitted in the wrong sequence - fails build
and few other issues below.
On 07/23/2013 02:19 AM, Tero Kristo wrote:
The OMAP clock driver now supports DPLL clock type. This patch also
adds support for DT DPLL nodes.
Then why is $subject specific to OMAP4? is that because of
of_omap4_dpll_setup?
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/clk.c|1 +
drivers/clk/omap/dpll.c | 295 +
Device Tree Binding documentation?
3 files changed, 297 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/omap/dpll.c
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 8195931..4cad480 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o
+obj-y += clk.o dpll.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index 4bf1929..1dafdaa 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -28,6 +28,7 @@ static const struct of_device_id clk_match[] = {
.data = of_fixed_factor_clk_setup, },
{.compatible = divider-clock, .data = of_divider_clk_setup, },
{.compatible = gate-clock, .data = of_gate_clk_setup, },
+ {.compatible = ti,omap4-dpll-clock, .data = of_omap4_dpll_setup, },
{},
};
you would not need this if you did just of_clk_init(NULL); ?
Further, at this patch, build fails with:
drivers/clk/omap/clk.c:31:55: error: undefined identifier
'of_omap4_dpll_setup'
drivers/clk/omap/clk.c:31:48: error: ‘of_omap4_dpll_setup’ undeclared
here (not in a function)
which makes sense since we did not export the function.
diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
new file mode 100644
index 000..66e82be
--- /dev/null
+++ b/drivers/clk/omap/dpll.c
@@ -0,0 +1,295 @@
+/*
+ * OMAP DPLL clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/err.h
+#include linux/string.h
+#include linux/log2.h
+#include linux/of.h
+#include linux/of_address.h
after a quick check, are all these required?
+#include linux/clk/omap.h
why?
+
+static const struct clk_ops dpll_m4xen_ck_ops = {
+ .enable = omap3_noncore_dpll_enable,
+ .disable= omap3_noncore_dpll_disable,
+ .recalc_rate= omap4_dpll_regm4xen_recalc,
+ .round_rate = omap4_dpll_regm4xen_round_rate,
+ .set_rate = omap3_noncore_dpll_set_rate,
+ .get_parent = omap2_init_dpll_parent,
+};
+
+static const struct clk_ops dpll_core_ck_ops = {
+ .recalc_rate= omap3_dpll_recalc,
+ .get_parent = omap2_init_dpll_parent,
+};
+
+static const struct clk_ops dpll_ck_ops = {
+ .enable = omap3_noncore_dpll_enable,
+ .disable= omap3_noncore_dpll_disable,
+ .recalc_rate= omap3_dpll_recalc,
+ .round_rate = omap2_dpll_round_rate,
+ .set_rate = omap3_noncore_dpll_set_rate,
+ .get_parent = omap2_init_dpll_parent,
+ .init = omap2_init_clk_clkdm,
+};
+
+static const struct clk_ops dpll_x2_ck_ops = {
+ .recalc_rate= omap3_clkoutx2_recalc,
+};
none of these are defined at this stage of the patch, generates a huge
build error for dpll.c
http://pastebin.com/GJucv1A5
+
+struct clk *omap_clk_register_dpll(struct device *dev, const char *name,
+ const char **parent_names, int num_parents, unsigned long flags,
+ struct dpll_data *dpll_data, const char *clkdm_name,
+ const struct clk_ops *ops)
why should this be public?
+{
+ struct clk *clk;
+ struct clk_init_data init;
init = { 0 }; just to future proof?
+ struct clk_hw_omap *clk_hw;
does not exist yet in generic header?
I am assuming you do not do parameter check as you expect clk_register
to do the same?
+
+ /* allocate the divider */
+ clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
checkpatch complained:
CHECK: Prefer kzalloc(sizeof(*clk_hw)...) over kzalloc(sizeof(struct
clk_hw_omap)...)
or given we have dev, devm_kzalloc?
+ if (!clk_hw) {
+ pr_err(%s: could not allocate clk_hw_omap\n, __func__);
+ return ERR_PTR(-ENOMEM);
+ }
+
+
Re: [Patch V2 4/4] ARM: dts: AM33XX: update rtc node compatibility
On 7/30/2013 8:25 PM, Mark Rutland wrote:
On Tue, Jul 30, 2013 at 06:05:52AM +0100, Gururaja Hebbar wrote:
Hi,
On 7/3/2013 2:17 PM, Hebbar Gururaja wrote:
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti,am3352-rtc to enable handling
of this feature inside rtc-omap driver.
The other 2 rtc driver related patches have been pulled up. If you have
no comments, can you please pull this up.
Regards
Gururaja
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
---
:100644 100644 77aa1b0... dde180a... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 77aa1b0..dde180a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -297,7 +297,7 @@
};
rtc@44e3e000 {
- compatible = ti,da830-rtc;
+ compatible = ti,am3352-rtc;
Given that this is backwards compatible with the old binding, it would
be nicer to have this as:
compatible = ti,am3352-rtc, ti,da830-rtc;
We must get into the habit of changing dts files in a
backwards-compatible fashion.
Right, I suggested this when v1 was posted. It turns out the current
kernel does not handle the compatilble list correctly and the string
selected actually depends on the order in which it appears in match
table in driver instead.
I saw there were patches being discussed to fix this issue, but until
that is fixed, we cannot really use what you (and I before) suggested.
Thanks,
Sekhar
--
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: EDMA: Fix clearing of unused list for DT DMA resources
On 7/30/2013 9:17 AM, Joel Fernandes wrote:
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index a432e6c..765d578 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
+ } else {
+ for (; i pdev-num_resources; i++) {
+ if ((pdev-resource[i].flags IORESOURCE_DMA)
+ (int)pdev-resource[i].start = 0) {
+ ctlr = EDMA_CTLR(pdev-resource[i].start);
+ clear_bit(EDMA_CHAN_SLOT(
+ pdev-resource[i].start),
+ edma_cc[ctlr]-edma_unused);
+ }
So there is very little in common between OF and non-OF versions of this
function. Why not have two different versions of this function for the
two cases? The OF version can reside under the CONFIG_OF conditional
already in use in the file. This will also save you the ugly line breaks
you had to resort to due to too deep indentation.
Actually those line breaks are not necessary and wouldn't result in
compilation errors. I was planning to drop them. I'll go ahead and split
it out anyway, now that also the OF version of the function is going to
be bit longer if we use the of_parse functions.
Thanks for your review,
It turns out, I gave a bad idea. What I suggested will break the case of
non-DT boot with CONFIG_OF enabled. So what you had was fine. May be
just return from if (dev-of_node) so you don't need to have an else
block and can save on the indentation.
Thanks,
Sekhar
--
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/4] ARM: dts: omap4-sdp: add MMC5 (WiLink WLAN) configuration
Add regulator, pin muxing and MMC5 configuration to be used by the
on-board WiLink6 module.
Signed-off-by: Luciano Coelho coe...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..3845615 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -140,6 +140,16 @@
DMic, Digital Mic,
Digital Mic, Digital Mic1 Bias;
};
+
+ wilink_wl_en: fixedregulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = wilink_wl_en;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ gpio = gpio2 22 0; /* gpio line 54 */
+ startup-delay-us = 7;
+ enable-active-high;
+ };
};
omap4_pmx_wkup {
@@ -166,6 +176,7 @@
mcbsp2_pins
dss_hdmi_pins
tpd12s015_pins
+ wilink_pins
;
uart2_pins: pinmux_uart2_pins {
@@ -295,6 +306,19 @@
0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c4_sda */
;
};
+
+ wilink_pins: pinmux_wilink_pins {
+ pinctrl-single,pins =
+ 0x7a 0x103 /* gpio_53 INPUT | MODE3 */
+ 0x7c 0x3/* gpio_54 OUTPUT | MODE3 */
+ 0x148 0x118 /* clk INPUT PULLUP | MODE0 */
+ 0x14a 0x118 /* cmd INPUT PULLUP | MODE0 */
+ 0x14c 0x118 /* dat0 INPUT PULLUP | MODE0 */
+ 0x14e 0x118 /* dat1 INPUT PULLUP | MODE0 */
+ 0x150 0x118 /* dat2 INPUT PULLUP | MODE0 */
+ 0x152 0x118 /* dat3 INPUT PULLUP | MODE0 */
+ ;
+ };
};
i2c1 {
@@ -420,8 +444,13 @@
};
mmc5 {
+ status = okay;
+ vmmc-supply = wilink_wl_en;
bus-width = 4;
+ cap-power-off-card;
+ keep-power-in-suspend;
ti,non-removable;
+ ti,needs-special-hs-handling;
};
emif1 {
--
1.8.3.2
--
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/4] arm: dts: omap4-panda-common: add WiLink6 device tree nodes
Add the WiLink device tree nodes. On omap4-panda, a WiLink6 module is
connected on MMC5 and a GPIO interrupt is used. The refclock
frequency is 38.4MHz.
Signed-off-by: Luciano Coelho coe...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index b3f6e1f..77e4a42 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -117,6 +117,20 @@
startup-delay-us = 7;
enable-active-high;
};
+
+ wlan {
+ compatible = ti,wilink6;
+ interrupt-parent = gpio2;
+ interrupts = 21 0x4; /* gpio line 53, high level triggered */
+ clocks = refclock;
+ clock-names = refclock;
+
+ refclock: refclock {
+ compatible = ti,wilink-clock;
+ #clock-cells = 0;
+ clock-frequency = 3840;
+ };
+};
};
omap4_pmx_wkup {
--
1.8.3.2
--
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/4] ARM: dts: add WiLink support to panda and omap4-sdp
Hi, These patches add the necessary DT configuration to use the WLAN part of WiLink on OMAP4 Pandaboard and on OMAP4-SDP (including Blaze). I've tested these changes on Panda and it works fine. But I couldn't test the OMAP4 SDP changes properly on 3.11-rc3 because I'm having problems with clocks and SDIO stuff. So it's pretty much just compiled tested. I've tried this (without the new clock definition stuff) on Blaze with 3.10 and it was working, though. Please take a look and let me know what you think. Luca. Luciano Coelho (4): ARM: dts: omap4-panda: add MMC5 (WiLink WLAN) configuration arm: dts: omap4-panda-common: add WiLink6 device tree nodes ARM: dts: omap4-sdp: add MMC5 (WiLink WLAN) configuration arm: dts: omap4-sdp: add WiLink7 device tree node arch/arm/boot/dts/omap4-panda-common.dtsi | 45 +++- arch/arm/boot/dts/omap4-sdp.dts | 49 +++ 2 files changed, 93 insertions(+), 1 deletion(-) -- 1.8.3.2 -- 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/4] arm: dts: omap4-sdp: add WiLink7 device tree node
Add appropriate device tree node for Blaze's WiLink7 module. It uses
a GPIO as interrupt, so configure the gpio2 node as interrupt parent
and assign the corresponding GPIO. Additionally, add the clock
frequencies used by the module.
Signed-off-by: Luciano Coelho coe...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 3845615..2fecca1 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -150,6 +150,26 @@
startup-delay-us = 7;
enable-active-high;
};
+
+ wlan {
+ compatible = ti,wilink7;
+ interrupt-parent = gpio2;
+ interrupts = 21 0x4; /* gpio line 53, high level triggered */
+ clocks = refclock tcxoclock;
+ clock-names = refclock tcxoclock;
+
+ refclock: refclock {
+ compatible = ti,wilink-clock;
+ #clock-cells = 0;
+ clock-frequency = 2600;
+ };
+
+ tcxoclock: tcxoclock {
+ compatible = ti,wilink-clock;
+ #clock-cells = 0;
+ clock-frequency = 2600;
+ };
+};
};
omap4_pmx_wkup {
--
1.8.3.2
--
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: [PATCHv4 04/33] CLK: omap: move part of the machine specific clock header contents to driver
this patch should be 3/33 to allow dpll.c to build.
On 07/23/2013 02:19 AM, Tero Kristo wrote:
Some of the clock.h contents are needed by the new OMAP clock driver,
including dpll_data and clk_hw_omap. Thus, move these to the generic
omap header file which can be accessed by the driver.
Looking at the change, I wonder what the rules are for the movement?
commit message was not clear.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clock.h | 151 +
include/linux/clk/omap.h| 157 ++-
2 files changed, 157 insertions(+), 151 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 7aa32cd..d1a3125 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -21,6 +21,7 @@
#include linux/clkdev.h
#include linux/clk-provider.h
+#include linux/clk/omap.h
struct omap_clk {
u16 cpu;
@@ -178,83 +179,6 @@ struct clksel {
const struct clksel_rate *rates;
};
-/**
- * struct dpll_data - DPLL registers and integration data
- * @mult_div1_reg: register containing the DPLL M and N bitfields
- * @mult_mask: mask of the DPLL M bitfield in @mult_div1_reg
- * @div1_mask: mask of the DPLL N bitfield in @mult_div1_reg
- * @clk_bypass: struct clk pointer to the clock's bypass clock input
- * @clk_ref: struct clk pointer to the clock's reference clock input
- * @control_reg: register containing the DPLL mode bitfield
- * @enable_mask: mask of the DPLL mode bitfield in @control_reg
- * @last_rounded_rate: cache of the last rate result of omap2_dpll_round_rate()
- * @last_rounded_m: cache of the last M result of omap2_dpll_round_rate()
- * @last_rounded_m4xen: cache of the last M4X result of
- * omap4_dpll_regm4xen_round_rate()
- * @last_rounded_lpmode: cache of the last lpmode result of
- * omap4_dpll_lpmode_recalc()
- * @max_multiplier: maximum valid non-bypass multiplier value (actual)
- * @last_rounded_n: cache of the last N result of omap2_dpll_round_rate()
- * @min_divider: minimum valid non-bypass divider value (actual)
- * @max_divider: maximum valid non-bypass divider value (actual)
- * @modes: possible values of @enable_mask
- * @autoidle_reg: register containing the DPLL autoidle mode bitfield
- * @idlest_reg: register containing the DPLL idle status bitfield
- * @autoidle_mask: mask of the DPLL autoidle mode bitfield in @autoidle_reg
- * @freqsel_mask: mask of the DPLL jitter correction bitfield in @control_reg
- * @idlest_mask: mask of the DPLL idle status bitfield in @idlest_reg
- * @lpmode_mask: mask of the DPLL low-power mode bitfield in @control_reg
- * @m4xen_mask: mask of the DPLL M4X multiplier bitfield in @control_reg
- * @auto_recal_bit: bitshift of the driftguard enable bit in @control_reg
- * @recal_en_bit: bitshift of the PRM_IRQENABLE_* bit for recalibration IRQs
- * @recal_st_bit: bitshift of the PRM_IRQSTATUS_* bit for recalibration IRQs
- * @flags: DPLL type/features (see below)
- *
- * Possible values for @flags:
- * DPLL_J_TYPE: J-type DPLL (only some 36xx, 4xxx DPLLs)
- *
- * @freqsel_mask is only used on the OMAP34xx family and AM35xx.
- *
- * XXX Some DPLLs have multiple bypass inputs, so it's not technically
- * correct to only have one @clk_bypass pointer.
- *
- * XXX The runtime-variable fields (@last_rounded_rate, @last_rounded_m,
- * @last_rounded_n) should be separated from the runtime-fixed fields
- * and placed into a different structure, so that the runtime-fixed data
- * can be placed into read-only space.
- */
-struct dpll_data {
- void __iomem*mult_div1_reg;
- u32 mult_mask;
- u32 div1_mask;
- struct clk *clk_bypass;
- struct clk *clk_ref;
- void __iomem*control_reg;
- u32 enable_mask;
- unsigned long last_rounded_rate;
- u16 last_rounded_m;
- u8 last_rounded_m4xen;
- u8 last_rounded_lpmode;
- u16 max_multiplier;
- u8 last_rounded_n;
- u8 min_divider;
- u16 max_divider;
- u8 modes;
- void __iomem*autoidle_reg;
- void __iomem*idlest_reg;
- u32 autoidle_mask;
- u32 freqsel_mask;
- u32 idlest_mask;
- u32 dco_mask;
- u32 sddiv_mask;
- u32 lpmode_mask;
- u32 m4xen_mask;
- u8 auto_recal_bit;
- u8 recal_en_bit;
- u8 recal_st_bit;
- u8 flags;
Re: [PATCH v2] Documentation: dt: bindings: TI WiLink modules
Hi Luciano,
Thank you for the patch.
On Monday 29 July 2013 17:55:28 Luciano Coelho wrote:
Add device tree bindings documentation for the TI WiLink modules.
Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8
modules is supported.
Signed-off-by: Luciano Coelho coe...@ti.com
---
Changes in v2:
Use generic clock definitions to get the clock data instead of passing
the frequencies directly. Also added definition for internal
ti,wilink-clock.
Please review.
The proposal looks good to me, I just have one small comment.
.../devicetree/bindings/net/wireless/ti-wilink.txt | 68 +++
1 file changed, 68 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt new file
mode 100644
index 000..5fd27dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
@@ -0,0 +1,68 @@
+TI WiLink Wireless Modules Device Tree Bindings
+===
+
+The WiLink modules provide wireless connectivity, such as WLAN,
+Bluetooth, FM and NFC.
+
+There are several different modules available, which can be grouped by
+their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not
+currently supported with device tree.
+
+Currently, only the WLAN portion of the modules is supported with
+device tree.
+
+Required properties:
+
+
+- compatible: should be ti,wilink6, ti,wilink7 or ti,wilink8
+- interrupt-parent: the interrupt controller
+- interrupts: out-of-band WLAN interrupt
+ See the interrupt controller's bindings documentation for
+ detailed definition.
+
+Optional properties:
+
+
+- clocks: list of clocks needed by the chip as follows:
+
+ refclock: the internal WLAN reference clock frequency (required for
+ WiLink6 and WiLink7; not used for WiLink8).
+
+ tcxoclock: the internal WLAN TCXO clock frequency (required for
+ WiLink7 not used for WiLink6 and WiLink8).
+
+ The clocks must be defined and named accordingly. For example:
+
+ clocks = refclock
+ clock-names = refclock;
+
+ refclock: refclock {
+ compatible = ti,wilink-clock;
+ #clock-cells = 0;
+ clock-frequency = 3840;
+ };
+
+ Some modules that contain the WiLink chip provide clocks in the
+ module itself. In this case, we define a ti,wilink-clock as shown
+ above. But any other clock could in theory be used, so the proper
+ clock definition should be used.
+
+
+Example:
+
+
+Example definition that can be used in OMAP4 Panda:
+
+wlan {
+ compatible = ti,wilink6;
+ interrupt-parent = gpio2;
+ interrupts = 21 0x4; /* gpio line 53, high level triggered */
Could you please use the IRQ_TYPE_LEVEL_HIGH macro (defined in dt-
bindings/interrupt-controller/irq.h) instead of the hardcode 0x4 constant ?
+ clocks = refclock;
+ clock-names = refclock;
+
+ refclock: refclock {
+ compatible = ti,wilink-clock;
+ #clock-cells = 0;
+ clock-frequency = 3840;
+ };
+};
--
Regards,
Laurent Pinchart
--
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/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
Hi,
On Tuesday 30 July 2013 09:02 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 08:06:31PM +0530, Sricharan R wrote:
On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote:
On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
# define soc_is_omap543x() is_omap543x()
#endif
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx()is_dra7xx()
+# define soc_is_dra75x()is_dra75x()
since this platform is DT-only, couldn't we just believe DT-data to be
correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
I patched this for OMAP5 (compile-tested only, no boards available) and
came out with the patch below (still needs to be split):
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b3136e5 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -13,7 +13,7 @@
/ {
model = TI OMAP5 uEVM board;
- compatible = ti,omap5-uevm, ti,omap5;
+ compatible = ti,omap5-uevm, ti,omap5432-es2.0, ti,omap5;
ok, nice and simpler way.
But would this make different revisions, to appear the same ?
well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up,
it should be treated as such, then you can pass a different string to
that new board's compatible attribute.
s
Yes for OMAP5. I was thinking in general about this approach.
For example, for OMAP4 we have same board and
different revisions can be socketed there.
For OMAP5, this is good.
do we really production socketed boards? Well, at least Blaze has such
thing. But do we have too many differences that need to be trated at
arch/arm or should/could those be handled by reading IP's revision
register (e.g. usb host erratas)
OMAP4 SDP is socketed as well.
Ya, revision checks used only in few places and as you said
we handle them using IP revisions, but that we have to look and clean
up those places, if we really intend to do this for other socs.
Regards,
Sricharan
--
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: [PATCHv4 05/33] CLK: omap: add DT duplicate clock registration mechanism
On 07/23/2013 02:20 AM, Tero Kristo wrote:
Some devices require their clocks to be available with a specific
dev-id con-id mapping. With DT, the clocks can be found by default
only with their name, or alternatively through the device node of
the consumer. With drivers, that don't support DT fully yet, add
mechanism to register specific clock names.
Signed-off-by: Tero Kristo t-kri...@ti.com
with this, should it not be enough to add clocks=phandle
I am not sure I understand what specific drivers should need to carry
this old hack forward. More importantly, why is it preferable to carry
the hack forward rather than fixing the drivers.
---
drivers/clk/omap/clk.c | 39 +++
include/linux/clk/omap.h | 17 +
2 files changed, 56 insertions(+)
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index 1dafdaa..cd31a81 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -32,6 +32,45 @@ static const struct of_device_id clk_match[] = {
{},
};
+ /**
+ * omap_dt_clocks_register - register DT duplicate clocks during boot
+ * @oclks: list of clocks to register
+ * @cnt: number of clocks
+ *
+ * Register duplicate or non-standard DT clock entries during boot. By
+ * default, DT clocks are found based on their node name. If any
+ * additional con-id / dev-id - clock mapping is required, use this
+ * function to list these.
+ */
+void __init omap_dt_clocks_register(struct omap_dt_clk oclks[], int cnt)
Cant we use a NULL terminated array? then we dont need to pass cnt.
+{
+ struct omap_dt_clk *c;
+ struct device_node *n;
+ struct clk *clk;
+ struct of_phandle_args clkspec;
+
+ for (c = oclks; c oclks + cnt; c++) {
+ n = of_find_node_by_name(NULL, c-node_name);
+
+ if (!n) {
+ pr_err(%s: %s not found!\n, __func__, c-node_name);
+ continue;
+ }
+
+ clkspec.np = n;
+
+ clk = of_clk_get_from_provider(clkspec);
+
+ if (!clk) {
+ pr_err(%s: %s has no clock!\n, __func__,
+ c-node_name);
+ continue;
+ }
+ c-lk.clk = clk;
+ clkdev_add(c-lk);
why not clk_add_alias ?
+ }
+}
+
/* FIXME - need to initialize early; skip real driver registration probe */
int __init dt_omap_clk_init(void)
{
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
index cba892a..c39e775 100644
--- a/include/linux/clk/omap.h
+++ b/include/linux/clk/omap.h
@@ -19,6 +19,8 @@
#ifndef __LINUX_CLK_OMAP_H_
#define __LINUX_CLK_OMAP_H_
+#include linux/clkdev.h
+
/**
* struct dpll_data - DPLL registers and integration data
* @mult_div1_reg: register containing the DPLL M and N bitfields
@@ -146,6 +148,20 @@ struct clk_hw_omap_ops {
void(*deny_idle)(struct clk_hw_omap *oclk);
};
+struct omap_dt_clk {
+ struct clk_lookup lk;
+ const char *node_name;
+};
+
documentation missing.
+#define DT_CLK(dev, con, name) \
+ { \
+ .lk = { \
+ .dev_id = dev, \
+ .con_id = con, \
+ }, \
+ .node_name = name, \
+ }
+
void omap2_init_clk_hw_omap_clocks(struct clk *clk);
int omap3_noncore_dpll_enable(struct clk_hw *hw);
void omap3_noncore_dpll_disable(struct clk_hw *hw);
@@ -174,6 +190,7 @@ extern const struct clk_hw_omap_ops clkhwops_omap4_dpllmx;
/* DT functions */
int dt_omap_clk_init(void);
+extern void omap_dt_clocks_register(struct omap_dt_clk *oclks, int cnt);
do you need the extern?
void of_omap4_dpll_setup(struct device_node *node);
#endif
--
Regards,
Nishanth Menon
--
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/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
On 07/30/2013 01:37 PM, Sricharan R wrote:
Hi,
On Tuesday 30 July 2013 09:02 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 08:06:31PM +0530, Sricharan R wrote:
On Tuesday 30 July 2013 07:53 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 07:48:23PM +0530, Sricharan R wrote:
On Tuesday 30 July 2013 06:40 PM, Felipe Balbi wrote:
Hi,
On Tue, Jul 30, 2013 at 04:55:39PM +0530, Rajendra Nayak wrote:
@@ -379,6 +407,13 @@ IS_OMAP_TYPE(3430, 0x3430)
# define soc_is_omap543x()is_omap543x()
#endif
+# if defined(CONFIG_SOC_DRA7XX)
+# undef soc_is_dra7xx
+# undef soc_is_dra75x
+# define soc_is_dra7xx() is_dra7xx()
+# define soc_is_dra75x() is_dra75x()
since this platform is DT-only, couldn't we just believe DT-data to be
correct of_machine_is_compatible() ? 2/3 of this patch would be removed.
I patched this for OMAP5 (compile-tested only, no boards available) and
came out with the patch below (still needs to be split):
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..b3136e5 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -13,7 +13,7 @@
/ {
model = TI OMAP5 uEVM board;
- compatible = ti,omap5-uevm, ti,omap5;
+ compatible = ti,omap5-uevm, ti,omap5432-es2.0, ti,omap5;
ok, nice and simpler way.
But would this make different revisions, to appear the same ?
well omap5-uevm is omap5432 es2.0 only, right ? If a new board comes up,
it should be treated as such, then you can pass a different string to
that new board's compatible attribute.
s
Yes for OMAP5. I was thinking in general about this approach.
For example, for OMAP4 we have same board and
different revisions can be socketed there.
For OMAP5, this is good.
do we really production socketed boards? Well, at least Blaze has such
thing. But do we have too many differences that need to be trated at
arch/arm or should/could those be handled by reading IP's revision
register (e.g. usb host erratas)
OMAP4 SDP is socketed as well.
a) OMAP4SDP is not production device
b) OMAP4SDP uses SOM (System On Module)
c) Socketted SOMs were used only during initial days of SoC
d) almost all latest OMAP4 SDP switched to using soldered in SOM
e) we claim compatibility of OMAP4 SDP with Blaze.
So, I dont think this is a rational argument for keeping soc checks with
dts.
Ya, revision checks used only in few places and as you said
we handle them using IP revisions, but that we have to look and clean
up those places, if we really intend to do this for other socs.
I agree this is the right approach :).
--
Regards,
Nishanth Menon
--
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] Documentation: dt: bindings: TI WiLink modules
(using the new devicetree mailing list address)
On Tue, 2013-07-30 at 20:24 +0200, Laurent Pinchart wrote:
Hi Luciano,
Thank you for the patch.
On Monday 29 July 2013 17:55:28 Luciano Coelho wrote:
Add device tree bindings documentation for the TI WiLink modules.
Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8
modules is supported.
Signed-off-by: Luciano Coelho coe...@ti.com
---
Changes in v2:
Use generic clock definitions to get the clock data instead of passing
the frequencies directly. Also added definition for internal
ti,wilink-clock.
Please review.
The proposal looks good to me, I just have one small comment.
Cool! Thanks for the review.
[...]
+Example:
+
+
+Example definition that can be used in OMAP4 Panda:
+
+wlan {
+ compatible = ti,wilink6;
+ interrupt-parent = gpio2;
+ interrupts = 21 0x4; /* gpio line 53, high level triggered */
Could you please use the IRQ_TYPE_LEVEL_HIGH macro (defined in dt-
bindings/interrupt-controller/irq.h) instead of the hardcode 0x4 constant ?
Ah, right, I saw this new header file recently but forgot to update my
example. I'll update the OMAP4 Panda and OMAP4 SDP dts files I just
sent out as well.
--
Cheers,
Luca.
--
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: [PATCHv4 06/33] CLK: omap: add autoidle support
On 07/23/2013 02:20 AM, Tero Kristo wrote:
OMAP clk driver now routes some of the basic clocks through own
registration routine to allow autoidle support. This routine just
checks a couple of device node properties and adds autoidle support
if required, and just passes the registration forward to basic clocks.
why not extend standard framework to support autoidle capable clocks OR
introduce our own clk node which depends on basic clocks?
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/clock.c |6 ++
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/autoidle.c | 130 +++
drivers/clk/omap/clk.c |4 +-
include/linux/clk/omap.h|4 ++
5 files changed, 143 insertions(+), 3 deletions(-)
create mode 100644 drivers/clk/omap/autoidle.c
I know it is getting a little stale, but anyways, device tree binding
missing.
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 0c38ca9..669d4c4 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
Not sure why, at this point in time we are going to calling drivers/clk
code.
@@ -520,6 +520,9 @@ int omap2_clk_enable_autoidle_all(void)
list_for_each_entry(c, clk_hw_omap_clocks, node)
if (c-ops c-ops-allow_idle)
c-ops-allow_idle(c);
+
+ of_omap_clk_allow_autoidle_all();
+
return 0;
}
@@ -539,6 +542,9 @@ int omap2_clk_disable_autoidle_all(void)
list_for_each_entry(c, clk_hw_omap_clocks, node)
if (c-ops c-ops-deny_idle)
c-ops-deny_idle(c);
+
+ of_omap_clk_deny_autoidle_all();
+
these are defined for CONFIG_OF.. anyways, without dt nodes (OMAP3 is
supposed to support non-DT boot even now), this would not work, would it?
return 0;
}
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index 4cad480..ca56700 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o dpll.o
+obj-y += clk.o dpll.o autoidle.o
diff --git a/drivers/clk/omap/autoidle.c b/drivers/clk/omap/autoidle.c
new file mode 100644
index 000..6424cb2
--- /dev/null
+++ b/drivers/clk/omap/autoidle.c
@@ -0,0 +1,130 @@
+/*
+ * OMAP clock autoidle support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/err.h
+#include linux/string.h
+#include linux/log2.h
+#include linux/of.h
+#include linux/of_address.h
at all of these required?
+
+#ifdef CONFIG_OF
+struct clk_omap_autoidle {
+ void __iomem*reg;
+ u8 shift;
+ u8 flags;
+ const char *name;
+ struct list_headnode;
+};
+
+#define AUTOIDLE_LOW 0x1
+
+static LIST_HEAD(autoidle_clks);
+
+static void omap_allow_autoidle(struct clk_omap_autoidle *clk)
+{
+ u32 val;
+
+ val = readl(clk-reg);
+
+ if (clk-flags AUTOIDLE_LOW)
+ val = ~(1 clk-shift);
+ else
+ val |= (1 clk-shift);
+
+ writel(val, clk-reg);
+}
+
+static void omap_deny_autoidle(struct clk_omap_autoidle *clk)
+{
+ u32 val;
+
+ val = readl(clk-reg);
+
+ if (clk-flags AUTOIDLE_LOW)
+ val |= (1 clk-shift);
+ else
+ val = ~(1 clk-shift);
+
+ writel(val, clk-reg);
+}
+
+void of_omap_clk_allow_autoidle_all(void)
+{
+ struct clk_omap_autoidle *c;
+
+ list_for_each_entry(c, autoidle_clks, node)
+ omap_allow_autoidle(c);
+}
+
+void of_omap_clk_deny_autoidle_all(void)
+{
+ struct clk_omap_autoidle *c;
+
+ list_for_each_entry(c, autoidle_clks, node)
+ omap_deny_autoidle(c);
+}
+
+static __init void of_omap_autoidle_setup(struct device_node *node)
+{
+ u32 shift;
+ void __iomem *reg;
+ struct clk_omap_autoidle *clk;
+
+ if (of_property_read_u32(node, ti,autoidle-shift, shift))
+ return;
+
+ reg = of_iomap(node, 0);
+
+ clk = kzalloc(sizeof(struct clk_omap_autoidle), GFP_KERNEL);
+
+ if (!clk) {
+ pr_err(%s: kzalloc failed\n, __func__);
+ return;
+ }
+
+ clk-shift = shift;
+ clk-name = node-name;
+ clk-reg = reg;
+
+ if
Re: [PATCHv4 07/33] CLK: omap: add support for OMAP gate clock
On 07/23/2013 02:20 AM, Tero Kristo wrote:
This node adds support for a clock node which allows control to the
clockdomain enable / disable.
Dont we have clkdm_enable/disable for the same? should we model
clockdomain as a clock node?
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/Makefile |2 +-
drivers/clk/omap/clk.c|1 +
drivers/clk/omap/gate.c | 88 +
include/linux/clk/omap.h |1 +
4 files changed, 91 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/omap/gate.c
my usual crib: device tree binding documentation is missing
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index ca56700..3d3ca30f 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1 +1 @@
-obj-y += clk.o dpll.o autoidle.o
+obj-y += clk.o dpll.o autoidle.o gate.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index c149097..8c89714 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -29,6 +29,7 @@ static const struct of_device_id clk_match[] = {
{.compatible = divider-clock, .data = of_omap_divider_setup, },
{.compatible = gate-clock, .data = of_gate_clk_setup, },
{.compatible = ti,omap4-dpll-clock, .data = of_omap4_dpll_setup, },
+ {.compatible = ti,gate-clock, .data = of_omap_gate_clk_setup, },
I am a little lost - is there any SoC dts that actually uses this? at
least this series does not seem to introduce any node that uses this
compatibility as per git grep :(
might as well drop the patch?
{},
};
diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
new file mode 100644
index 000..7186bb2
--- /dev/null
+++ b/drivers/clk/omap/gate.c
@@ -0,0 +1,88 @@
+/*
+ * OMAP gate clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/err.h
+#include linux/string.h
+#include linux/log2.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/clk/omap.h
+
+#ifdef CONFIG_OF
+
+static const struct clk_ops omap_gate_clk_ops = {
+ .init = omap2_init_clk_clkdm,
+ .enable = omap2_clkops_enable_clkdm,
+ .disable= omap2_clkops_disable_clkdm,
+};
+
+void __init of_omap_gate_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_init_data init;
init = { 0 };
+ struct clk_hw_omap *clk_hw;
+ const char *clk_name = node-name;
+ int num_parents;
+ const char **parent_names;
+ int i;
+
+ clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
kzalloc(sizeof(*clk_hw)...) over kzalloc(sizeof(struct clk_hw_omap)...)
+ if (!clk_hw) {
+ pr_err(%s: could not allocate clk_hw_omap\n, __func__);
+ return;
+ }
+
+ clk_hw-hw.init = init;
+
+ of_property_read_string(node, clock-output-names, clk_name);
+ of_property_read_string(node, ti,clkdm-name, clk_hw-clkdm_name);
+
+ init.name = clk_name;
+ init.ops = omap_gate_clk_ops;
+
+ num_parents = of_clk_get_parent_count(node);
+ if (num_parents 1) {
+ pr_err(%s: omap trace_clk %s must have parent(s)\n,
+ __func__, node-name);
CHECK: Alignment should match open parenthesis
+ goto cleanup;
+ }
+
+ parent_names = kzalloc(sizeof(char *) * num_parents, GFP_KERNEL);
+
+ for (i = 0; i num_parents; i++)
+ parent_names[i] = of_clk_get_parent_name(node, i);
+
+ init.num_parents = num_parents;
+ init.parent_names = parent_names;
+
+ clk = clk_register(NULL, clk_hw-hw);
+
+ if (!IS_ERR(clk)) {
+ of_clk_add_provider(node, of_clk_src_simple_get, clk);
+ return;
+ }
+
+cleanup:
kfree(parent_names)?
+ kfree(clk_hw);
+}
+EXPORT_SYMBOL(of_omap_gate_clk_setup);
+CLK_OF_DECLARE(omap_gate_clk, ti,omap-gate-clock, of_omap_gate_clk_setup);
+#endif
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
index 904bdad..58ebb80 100644
--- a/include/linux/clk/omap.h
+++ b/include/linux/clk/omap.h
@@ -194,6 +194,7 @@ extern void omap_dt_clocks_register(struct omap_dt_clk
*oclks, int cnt);
void of_omap4_dpll_setup(struct device_node *node);
void
Re: [PATCHv4 15/33] CLK: OMAP: DPLL: add support for DT property ti,dpll-no-gate
On 07/23/2013 02:20 AM, Tero Kristo wrote:
AM335x has DPLL clocks that should never be attempted to be gated. Adding
ti,dpll-no-gate property for them handles this situation.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/dpll.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
index 66e82be..1d24feada 100644
--- a/drivers/clk/omap/dpll.c
+++ b/drivers/clk/omap/dpll.c
@@ -54,6 +54,13 @@ static const struct clk_ops dpll_x2_ck_ops = {
.recalc_rate= omap3_clkoutx2_recalc,
};
+static const struct clk_ops dpll_no_gate_ck_ops = {
+ .recalc_rate= omap3_dpll_recalc,
+ .get_parent = omap2_init_dpll_parent,
+ .round_rate = omap2_dpll_round_rate,
+ .set_rate = omap3_noncore_dpll_set_rate,
+};
+
struct clk *omap_clk_register_dpll(struct device *dev, const char *name,
const char **parent_names, int num_parents, unsigned long flags,
struct dpll_data *dpll_data, const char *clkdm_name,
@@ -288,6 +295,9 @@ __init void of_omap4_dpll_setup(struct device_node *node)
return;
}
+ if (of_property_read_bool(node, ti,dpll-no-gate))
+ ops = dpll_no_gate_ck_ops;
+
of_omap_dpll_setup(node, ops);
}
EXPORT_SYMBOL_GPL(of_omap4_dpll_setup);
squash this to dpll patch?
--
Regards,
Nishanth Menon
--
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: [PATCHv4 08/33] ARM: dts: omap4 clock data
On 07/23/2013 02:20 AM, Tero Kristo wrote:
This patch creates a unique node for each clock in the OMAP4 power,
reset and clock manager (PRCM). OMAP443x and OMAP446x have slightly
different clock tree which is taken into account in the data.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/boot/dts/omap443x-clocks.dtsi | 17 +
arch/arm/boot/dts/omap443x.dtsi|8 +
arch/arm/boot/dts/omap4460.dtsi|8 +
arch/arm/boot/dts/omap446x-clocks.dtsi | 27 +
arch/arm/boot/dts/omap44xx-clocks.dtsi | 1654
arch/arm/boot/dts/omap44xx-common-clocks.dtsi ?
5 files changed, 1714 insertions(+)
create mode 100644 arch/arm/boot/dts/omap443x-clocks.dtsi
create mode 100644 arch/arm/boot/dts/omap446x-clocks.dtsi
create mode 100644 arch/arm/boot/dts/omap44xx-clocks.dtsi
diff --git a/arch/arm/boot/dts/omap443x-clocks.dtsi
b/arch/arm/boot/dts/omap443x-clocks.dtsi
new file mode 100644
index 000..2bd82b2
--- /dev/null
+++ b/arch/arm/boot/dts/omap443x-clocks.dtsi
@@ -0,0 +1,17 @@
+/*
+ * Device Tree Source for OMAP443x clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
Doing
/include/ omap44xx-clocks.dtsi might avoid including that header in
corresponding SoC dtsi,
OR:
+bandgap_fclk: bandgap_fclk@4a307888 {
+ #clock-cells = 0;
+ compatible = gate-clock;
+ clocks = sys_32k_ck;
+ bit-shift = 8;
+ reg = 0x4a307888 0x4;
+};
Since we already have omap443x.dtsi and omap446x.dtsi, do we need
clock.dtsi containing just a few entries?
instead we could define the delta clocks in the clocks section, and save
on two additional files, no?
[...]
diff --git a/arch/arm/boot/dts/omap44xx-clocks.dtsi
b/arch/arm/boot/dts/omap44xx-clocks.dtsi
new file mode 100644
index 000..ed6bc9b
--- /dev/null
+++ b/arch/arm/boot/dts/omap44xx-clocks.dtsi
[...]
+dpll_abe_m2x2_ck: dpll_abe_m2x2_ck@4a0041f0 {
+ #clock-cells = 0;
+ compatible = divider-clock;
+ clocks = dpll_abe_x2_ck;
+ ti,autoidle-shift = 8;
+ reg = 0x4a0041f0 0x4;
+ bit-mask = 0x1f;
+ index-starts-at-one;
+ ti,autoidle-low;
+};
+
+abe_24m_fclk: abe_24m_fclk {
+ #clock-cells = 0;
+ compatible = fixed-factor-clock;
+ clocks = dpll_abe_m2x2_ck;
+ clock-mult = 1;
+ clock-div = 8;
+};
+
+abe_clk: abe_clk@4a004108 {
+ #clock-cells = 0;
+ compatible = divider-clock;
+ clocks = dpll_abe_m2x2_ck;
+ reg = 0x4a004108 0x4;
+ bit-mask = 0x3;
+ index-power-of-two;
+};
+
+aess_fclk: aess_fclk@4a004528 {
is there a naming convention used here? abe_clk, fclk etc?
+ #clock-cells = 0;
+ compatible = divider-clock;
+ clocks = abe_clk;
+ bit-shift = 24;
+ reg = 0x4a004528 0x4;
+ bit-mask = 0x1;
+};
[...]
+
+ocp2scp_usb_phy_phy_48m: ocp2scp_usb_phy_phy_48m@4a0093e0 {
_ck?
[...]
--
Regards,
Nishanth Menon
--
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: [PATCHv4 09/33] CLK: omap: add omap4 clock init file
On 07/23/2013 02:20 AM, Tero Kristo wrote:
clk-44xx.c now contains the clock init functionality for omap4, including
DT clock registration and adding of static clkdev entries.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/omap/clk-44xx.c | 118 +++
1 file changed, 118 insertions(+)
create mode 100644 drivers/clk/omap/clk-44xx.c
diff --git a/drivers/clk/omap/clk-44xx.c b/drivers/clk/omap/clk-44xx.c
new file mode 100644
index 000..cc12134
--- /dev/null
+++ b/drivers/clk/omap/clk-44xx.c
@@ -0,0 +1,118 @@
+/*
+ * OMAP4 Clock data
+ *
+ * Copyright (C) 2009-2012 Texas Instruments, Inc.
+ * Copyright (C) 2009-2010 Nokia Corporation
+ *
+ * Paul Walmsley (p...@pwsan.com)
+ * Rajendra Nayak (rna...@ti.com)
+ * Benoit Cousson (b-cous...@ti.com)
+ * Mike Turquette (mturque...@ti.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * XXX Some of the ES1 clocks have been removed/changed; once support
+ * is added for discriminating clocks by ES level, these should be added back
+ * in.
+ *
+ * XXX All of the remaining MODULEMODE clock nodes should be removed
+ * once the drivers are updated to use pm_runtime or to use the appropriate
+ * upstream clock node for rate/parent selection.
+ */
+
+#include linux/kernel.h
+#include linux/list.h
+#include linux/clk-private.h
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/clk/omap.h
+
+/*
+ * OMAP4 ABE DPLL default frequency. In OMAP4460 TRM version V, section
+ * 3.6.3.2.3 CM1_ABE Clock Generator states that the DPLL_ABE_X2_CLK
+ * must be set to 196.608 MHz and hence, the DPLL locked frequency is
+ * half of this value.
+ */
+#define OMAP4_DPLL_ABE_DEFFREQ 98304000
+
+/*
+ * OMAP4 USB DPLL default frequency. In OMAP4430 TRM version V, section
+ * 3.6.3.9.5 DPLL_USB Preferred Settings shows that the preferred
+ * locked frequency for the USB DPLL is 960MHz.
+ */
+#define OMAP4_DPLL_USB_DEFFREQ 96000
+
+static struct omap_dt_clk omap44xx_clks[] = {
+ DT_CLK(smp_twd, NULL, mpu_periphclk),
+ DT_CLK(omapdss_dss, ick, dss_fck),
+ DT_CLK(usbhs_omap, fs_fck, usb_host_fs_fck),
+ DT_CLK(usbhs_omap, hs_fck, usb_host_hs_fck),
+ DT_CLK(usbhs_omap, usbtll_ick, usb_tll_hs_ick),
+ DT_CLK(usbhs_tll, usbtll_ick, usb_tll_hs_ick),
+ DT_CLK(NULL,timer_32k_ck, sys_32k_ck),
+ /* TODO: Remove omap_timer.X aliases once DT migration is complete */
+ DT_CLK(omap_timer.1,timer_sys_ck, sys_clkin_ck),
+ DT_CLK(omap_timer.2,timer_sys_ck, sys_clkin_ck),
+ DT_CLK(omap_timer.3,timer_sys_ck, sys_clkin_ck),
+ DT_CLK(omap_timer.4,timer_sys_ck, sys_clkin_ck),
+ DT_CLK(omap_timer.9,timer_sys_ck, sys_clkin_ck),
+ DT_CLK(omap_timer.10, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(omap_timer.11, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(omap_timer.5,timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(omap_timer.6,timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(omap_timer.7,timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(omap_timer.8,timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(4a318000.timer, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(48032000.timer, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(48034000.timer, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(48036000.timer, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(4803e000.timer, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(48086000.timer, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(48088000.timer, timer_sys_ck, sys_clkin_ck),
+ DT_CLK(40138000.timer, timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(4013a000.timer, timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(4013c000.timer, timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(4013e000.timer, timer_sys_ck, syc_clk_div_ck),
+ DT_CLK(NULL,cpufreq_ck, dpll_mpu_ck),
please remove cpufreq.
+};
+
+int __init omap4xxx_clk_init(void)
+{
+ int rc;
+ struct clk *abe_dpll_ref, *abe_dpll, *sys_32k_ck, *usb_dpll;
+
+ /* FIXME register clocks from DT first */
+ dt_omap_clk_init();
+
+ omap_dt_clocks_register(omap44xx_clks, ARRAY_SIZE(omap44xx_clks));
+
+ omap2_clk_disable_autoidle_all();
+
+ /*
+* On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
+* state when turning the ABE clock domain. Workaround this by
+* locking the ABE DPLL on boot.
+* Lock the ABE DPLL in any case to avoid issues with audio.
+*/
But this code will be called for 4430 and 4460. if the requirement
