Re: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
On Wednesday 31 July 2013 12:12 PM, Tony Lindgren wrote: > * Rajendra Nayak [130730 23:09]: >> >> Tony, what do you suggest we do for this series? Since we have just an es1.0 >> and one board >> at this point for dra7xx, things would be fine even if we do a dt based >> parsing to identify >> the device, and I am fine with it if thats what we feel is the right way >> forward. >> For the rest of the DT only platforms (omap4/5/am335x) anyway getting rid of >> these rev checks >> from the kernel and depending on DT parsing needs to be a separate series >> anyway and I dont >> plan to address those as part of this series. > > Well I'd say there's no need to drop the hardware revision checks > at this point at least for existing hardware. That's a very minimal > piece of code and there are way bigger issues to tackle. right, makes sense. > > For new SoCs, we could do it based on the compatible flag. If it > helps booting newer hardware with older kernels, then that's a good > reason to do it. Sure, we can have dra7xx use the compatible flag and not add all the rev checks. That said, I would be glad if the latest kernels at least boot on newer hardware let alone older kernels :) But I guess we have bigger issues to tackle before even that happens. Thanks for the quick response. regards, Rajendra > > 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] ARM: allow DEBUG_UNCOMPRESS for omap2plus
* Stephen Warren [130730 16:08]: > On 07/30/2013 04:52 PM, Russell King - ARM Linux wrote: > > On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote: > >> From: Stephen Warren > >> > >> DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to > >> omap2plus.S's use of .data, which is not allowed in the decompressor. > >> Solve this by placing that data into .text when building the file into > >> the decompressor. This relies on .text actually being writable in the > >> decompressor, which it is in practice. > > > > Unless you decide to use ZBOOT and flash the zImage. > > I knew there had to be a catch:-) > > I have no idea if ZBOOT is a use-case that's relevant to OMAP? > > On Tegra at least (the same issue applies to the other patch I just > sent), that use-case is almost impossible; even if the boot ROM directly > booted a kernel, the boot ROM is hard-coded to copy whatever it's > booting to SDRAM first, although I suppose if that was a boot-loader it > could just jump back to a ROM location. That said, NOR flash is > extremely rare on Tegra. So, I don't know if we care about this issue. > > Is it reasonable to just say "If you use ZBOOT, don't enable > DEBUG_UNCOMPRESS"? Perhaps these patches should not completely remove > the !DEBUG_TEGRA_UART from config DEBUG_UNCOMPRESS, but instead say: > > default y if DEBUG_LL && (!DEBUG_TEGRA_UART || !ZBOOT)? I think we're best off removing the remaining uncompress code configured port detection features as the port properties are now defined in kconfig anyways. That simplifies the code quite a bit. 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 v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
* Rajendra Nayak [130730 23:09]: > > Tony, what do you suggest we do for this series? Since we have just an es1.0 > and one board > at this point for dra7xx, things would be fine even if we do a dt based > parsing to identify > the device, and I am fine with it if thats what we feel is the right way > forward. > For the rest of the DT only platforms (omap4/5/am335x) anyway getting rid of > these rev checks > from the kernel and depending on DT parsing needs to be a separate series > anyway and I dont > plan to address those as part of this series. Well I'd say there's no need to drop the hardware revision checks at this point at least for existing hardware. That's a very minimal piece of code and there are way bigger issues to tackle. For new SoCs, we could do it based on the compatible flag. If it helps booting newer hardware with older kernels, then that's a good reason to do it. 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: [PATCHv4 29/33] CLK: omap: add omap3 clock init file
* Nishanth Menon [130730 13:26]: > On 07/23/2013 02:20 AM, Tero Kristo wrote: > >clk-3xxx.c now contains the clock init functionality for omap3, including > >DT clock registration and adding of static clkdev entries. > > > >This patch also splits the OMAP3 clock registration code under mach-omap2 > >to use OMAP3 subtype specific clk init functions. > > > >Signed-off-by: Tero Kristo > >--- > > arch/arm/mach-omap2/Makefile |2 +- > > arch/arm/mach-omap2/cclock3xxx_data.c | 3641 > > - > > Tony and a lot of people is not going to like removing support for > non-dt boot for OMAP3 before "it's time is due" ;) I think the only showstopper for that is that we need the pending pinctrl changes merged first to keep off-idle working. So the omap3 legacy code removal probably needs to wait until v3.13 merge window. For omap4 and am33xx we can do it now. 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 01/15] drivers: phy: add generic PHY framework
Hi,
On Wed, Jul 31, 2013 at 11:14:32AM +0530, Kishon Vijay Abraham I wrote:
> > 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 to the phy structure
> >> should be used everywhere instead.
> >>
> >> With those types of changes, I will consider merging this subsystem, but
> >> without them, sorry, I will not.
> >
> > I'll agree with Greg here, the very fact that we see people trying to
> > add a requirement of *NOT* using PLATFORM_DEVID_AUTO already points to a
> > big problem in the framework.
> >
> > The fact is that if we don't allow PLATFORM_DEVID_AUTO we will end up
> > adding similar infrastructure to the driver themselves to make sure we
> > don't end up with duplicate names in sysfs in case we have multiple
> > instances of the same IP in the SoC (or several of the same PCIe card).
> > I really don't want to go back to that.
>
> If we are using PLATFORM_DEVID_AUTO, then I dont see any way we can give the
> correct binding information to the PHY framework. I think we can drop having
> this non-dt support in PHY framework? I see only one platform (OMAP3) going to
> be needing this non-dt support and we can use the USB PHY library for it.
you shouldn't drop support for non-DT platform, in any case we lived
without DT (and still do) for years. Gotta find a better way ;-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
On Wednesday 31 July 2013 12:13 AM, Nishanth Menon wrote:
> 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.
What about OMAP4 pandas? I for instance, have an old 4430 panda and I have no
idea
if its a es2.1 or a es2.3 or something else. If we start relying on dt to pass
the
right revision check then (we need to create different dts files for these to
begin with) I
need to know exactly what silicon rev I am running on.
I know its good to completely get rid of all silicon rev checks and depend on
IP revisions
but we have had various IPs which do not have proper rev checks. We have I
guess most often
used these to identify PRCM differences.
Tony, what do you suggest we do for this series? Since we have just an es1.0
and one board
at this point for dra7xx, things would be fine even if we do a dt based parsing
to identify
the device, and I am fine with it if thats what we feel is the right way
forward.
For the rest of the DT only platforms (omap4/5/am335x) anyway getting rid of
these rev checks
from the kernel and depending on DT parsing needs to be a separate series
anyway and I dont
plan to address those as part of this series.
>
>> 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 :).
>
>
--
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
[PATCHv7 1/2] drivers: spi: Add qspi flash controller
The patch add basic support for the quad spi controller.
QSPI is a kind of spi module that allows single,
dual and quad read access to external spi devices. The module
has a memory mapped interface which provide direct interface
for accessing data form external spi devices.
The patch will configure controller clocks, device control
register and for defining low level transfer apis which
will be used by the spi framework to transfer data to
the slave spi device(flash in this case).
Test details:
-
Tested this on dra7 board.
Test1: Ran mtd_stesstest for 4 iterations.
- All iterations went through without failure.
Test2: Use mtd utilities:
- flash_erase to erase the flash device
- nanddump to read data back.
- nandwrite to write to the data flash.
diff between the write and read data shows zero.
Signed-off-by: Sourav Poddar
---
v6->v7:
- Use "completion timeout" variants
- remove "ONESHOT" and "NO_SUSPEND" flag.
- use put_sync in error path.
- few miscellaneous cleanup.
Documentation/devicetree/bindings/spi/ti_qspi.txt | 22 +
drivers/spi/Kconfig |8 +
drivers/spi/Makefile |1 +
drivers/spi/spi-ti-qspi.c | 545 +
4 files changed, 576 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/ti_qspi.txt
create mode 100644 drivers/spi/spi-ti-qspi.c
diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt
b/Documentation/devicetree/bindings/spi/ti_qspi.txt
new file mode 100644
index 000..398ef59
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -0,0 +1,22 @@
+TI QSPI controller.
+
+Required properties:
+- compatible : should be "ti,dra7xxx-qspi".
+- reg: Should contain QSPI registers location and length.
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+- ti,hwmods: Name of the hwmod associated to the QSPI
+
+Recommended properties:
+- spi-max-frequency: Definition as per
+ Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Example:
+
+qspi: qspi@4b30 {
+ compatible = "ti,dra7xxx-qspi";
+ reg = <0x4b30 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ spi-max-frequency = <2500>;
+ ti,hwmods = "qspi";
+};
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 92a9345..1c4e758 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -285,6 +285,14 @@ config SPI_OMAP24XX
SPI master controller for OMAP24XX and later Multichannel SPI
(McSPI) modules.
+config SPI_TI_QSPI
+ tristate "DRA7xxx QSPI controller support"
+ depends on ARCH_OMAP2PLUS || COMPILE_TEST
+ help
+ QSPI master controller for DRA7xxx used for flash devices.
+ This device supports single, dual and quad read support, while
+ it only supports single write mode.
+
config SPI_OMAP_100K
tristate "OMAP SPI 100K"
depends on ARCH_OMAP850 || ARCH_OMAP730
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 33f9c09..a174030 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SPI_OCTEON) += spi-octeon.o
obj-$(CONFIG_SPI_OMAP_UWIRE) += spi-omap-uwire.o
obj-$(CONFIG_SPI_OMAP_100K)+= spi-omap-100k.o
obj-$(CONFIG_SPI_OMAP24XX) += spi-omap2-mcspi.o
+obj-$(CONFIG_SPI_TI_QSPI) += spi-ti-qspi.o
obj-$(CONFIG_SPI_ORION)+= spi-orion.o
obj-$(CONFIG_SPI_PL022)+= spi-pl022.o
obj-$(CONFIG_SPI_PPC4xx) += spi-ppc4xx.o
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
new file mode 100644
index 000..3d10b69
--- /dev/null
+++ b/drivers/spi/spi-ti-qspi.c
@@ -0,0 +1,545 @@
+/*
+ * TI QSPI driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Sourav Poddar
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GPLv2.
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+struct ti_qspi_regs {
+ u32 clkctrl;
+};
+
+struct ti_qspi {
+ struct completion transfer_complete;
+
+ /* IRQ synchronization */
+ spinlock_t lock;
+
+ struct spi_master *master;
+ void __iomem*base;
+ struct clk *fclk;
+ struct device *dev;
+
+ struct ti_qspi_regs ctx_reg;
+
+ u32 spi_max_fre
[RFC/PATCH 2/2] driver: spi: Add quad spi read support
Since, qspi controller uses quad read.
Configuring the command register, if the transfer of data needs
dual or quad lines.
This patch has been done on top of the following patch[1], which is just the
basic idea of adding dual/quad support in spi framework.
$subject patch will undergo changes once the ongoing discussion in the
community is freezed.
This patch is posted to demonstrate how patch 1 of the series will support
quad read.
[1]: http://comments.gmane.org/gmane.linux.kernel.spi.devel/14047
Signed-off-by: Sourav Poddar
---
drivers/spi/spi-ti-qspi.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 02b67e9..a8c9587 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -273,6 +273,7 @@ static int qspi_read_msg(struct ti_qspi *qspi, struct
spi_transfer *t)
{
u8 *rxbuf;
int wlen, count, ret;
+ unsigned cmd = qspi->cmd;
count = t->len;
rxbuf = t->rx_buf;
@@ -282,8 +283,18 @@ static int qspi_read_msg(struct ti_qspi *qspi, struct
spi_transfer *t)
dev_dbg(qspi->dev, "rx cmd %08x dc %08x\n",
qspi->cmd | QSPI_RD_SNGL, qspi->dc);
ti_qspi_write(qspi, qspi->dc, QSPI_SPI_DC_REG);
- ti_qspi_write(qspi, qspi->cmd | QSPI_RD_SNGL,
- QSPI_SPI_CMD_REG);
+ switch (t->bitwidth) {
+ case SPI_BITWIDTH_QUAD:
+ cmd |= QSPI_RD_QUAD;
+ break;
+ case SPI_BITWIDTH_DUAL:
+ cmd |= QSPI_RD_DUAL;
+ break;
+ case SPI_BITWIDTH_SINGLE:
+ default:
+ cmd |= QSPI_RD_SNGL;
+ }
+ ti_qspi_write(qspi, cmd, QSPI_SPI_CMD_REG);
ret = wait_for_completion_timeout(&qspi->transfer_complete,
QSPI_COMPLETION_TIMEOUT);
if (ret == 0) {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv7 0/2] Add ti qspi controller
This patch series add support for ti qspi controller. Adapted this series on top of Mark brown series[1]: [1]: https://patchwork.kernel.org/patch/2834694/ And some other cleanups. Sourav Poddar (2): drivers: spi: Add qspi flash controller driver: spi: Add quad spi read support Documentation/devicetree/bindings/spi/ti_qspi.txt | 22 + drivers/spi/Kconfig |8 + drivers/spi/Makefile |1 + drivers/spi/spi-ti-qspi.c | 557 + 4 files changed, 588 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/spi/ti_qspi.txt create mode 100644 drivers/spi/spi-ti-qspi.c -- 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
Hi,
On Tuesday 30 July 2013 12:41 PM, Felipe Balbi wrote:
> 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
Re: [PATCH 3/9] ARM: edma: Add function to manually trigger an EDMA channel
On Wednesday 31 July 2013 10:00 AM, Joel Fernandes wrote:
> On 07/30/2013 12:18 AM, Sekhar Nori wrote:
>> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>>> Manual trigger for events missed as a result of splitting a
>>> scatter gather list and DMA'ing it in batches. Add a helper
>>> function to trigger a channel incase any such events are missed.
>>>
>>> Signed-off-by: Joel Fernandes
>>> ---
>>> arch/arm/common/edma.c | 21 +
>>> include/linux/platform_data/edma.h |2 ++
>>> 2 files changed, 23 insertions(+)
>>>
>>> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
>>> index 3567ba1..10995b2 100644
>>> --- a/arch/arm/common/edma.c
>>> +++ b/arch/arm/common/edma.c
>>> @@ -1236,6 +1236,27 @@ void edma_resume(unsigned channel)
>>> }
>>> EXPORT_SYMBOL(edma_resume);
>>>
>>> +int edma_manual_trigger(unsigned channel)
>>
>> edma_trigger_channel() maybe? Brings consistency with
>> edma_alloc_channel() edma_free_channel() etc.
>
> Ok, sure.
>
>>
>>> +{
>>> + unsigned ctlr;
>>> + int j;
>>> + unsigned int mask;
>>> +
>>> + ctlr = EDMA_CTLR(channel);
>>> + channel = EDMA_CHAN_SLOT(channel);
>>> + mask = BIT(channel & 0x1f);
>>> +
>>> + j = channel >> 5;
>>> +
>>> + /* EDMA channels without event association */
>>
>> May be actually check for no-event association before you trigger in
>> software? You can do that by looking at unused channel list, no?
>
> But, we want to trigger whether there is event association or not in
> this function. For ex, MMC has event associated but still this function
> is used to trigger event for it.
Okay, just drop the misleading comment then.
Regards,
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 3/9] ARM: edma: Add function to manually trigger an EDMA channel
On 07/30/2013 12:18 AM, Sekhar Nori wrote:
> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>> Manual trigger for events missed as a result of splitting a
>> scatter gather list and DMA'ing it in batches. Add a helper
>> function to trigger a channel incase any such events are missed.
>>
>> Signed-off-by: Joel Fernandes
>> ---
>> arch/arm/common/edma.c | 21 +
>> include/linux/platform_data/edma.h |2 ++
>> 2 files changed, 23 insertions(+)
>>
>> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
>> index 3567ba1..10995b2 100644
>> --- a/arch/arm/common/edma.c
>> +++ b/arch/arm/common/edma.c
>> @@ -1236,6 +1236,27 @@ void edma_resume(unsigned channel)
>> }
>> EXPORT_SYMBOL(edma_resume);
>>
>> +int edma_manual_trigger(unsigned channel)
>
> edma_trigger_channel() maybe? Brings consistency with
> edma_alloc_channel() edma_free_channel() etc.
Ok, sure.
>
>> +{
>> +unsigned ctlr;
>> +int j;
>> +unsigned int mask;
>> +
>> +ctlr = EDMA_CTLR(channel);
>> +channel = EDMA_CHAN_SLOT(channel);
>> +mask = BIT(channel & 0x1f);
>> +
>> +j = channel >> 5;
>> +
>> +/* EDMA channels without event association */
>
> May be actually check for no-event association before you trigger in
> software? You can do that by looking at unused channel list, no?
But, we want to trigger whether there is event association or not in
this function. For ex, MMC has event associated but still this function
is used to trigger event for it.
>
>> +edma_shadow0_write_array(ctlr, SH_ESR, j, mask);
>
> edma_shadow0_write_array(ctlr, SH_ESR, channel >> 5, mask) is no less
> readable, but I leave it to you.
Sure that's more readable, will changed it to that.
Thanks,
-Joel
--
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 7/9] ARM: edma: Don't clear EMR of channel in edma_stop
On 07/30/2013 03:29 AM, Sekhar Nori wrote: > 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? In edma_callback function, for the case of DMA_COMPLETE (Transfer completion interrupt), edma_stop() is called when all sets have been processed. This had the effect of clearing the EMR. This has 2 problems: 1. If error interrupt is also pending and TC interrupt clears the EMR. Due to this the ARM will execute the error interrupt even though the EMR is clear. As a result, the following if condition in dma_ccerr_handler will be true and IRQ_NONE is returned. if ((edma_read_array(ctlr, EDMA_EMR, 0) == 0) && (edma_read_array(ctlr, EDMA_EMR, 1) == 0) && (edma_read(ctlr, EDMA_QEMR) == 0) && (edma_read(ctlr, EDMA_CCERR) == 0)) return IRQ_NONE; If this happens enough number of times, IRQ subsystem disables the interrupt thinking its spurious which creates serious problems. 2. If the above if statement condition is removed, then EMR is 0 so the callback function will not be called in dma_ccerr_handler thus the event is forgotten, never triggered manually or never sets missed flag of the channel. So about the race: TC interrupt handler executing before the error interrupt handler can result in clearing the EMR and creates these problems. >> 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. Sure. Thanks, -Joel -- 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
Hi Sekhar, On 07/30/2013 02:05 AM, Sekhar Nori wrote: > 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 But it will not encounter null PaRAM set because McASP uses contiguous buffers for transfer which are not scattered across physical memory. This can be accomplished with an SG of size 1. For such SGs, this patch series leaves it linked Dummy and does not link to Null set. Null set is only used for SG lists that are > MAX_NR_SG in size such as those created for example by MMC and Crypto. > particular baud so I guess it cannot wait like the way MMC/SD can. Existing driver have to wait anyway if they hit MAX SG limit today. If they don't want to wait, they would have allocated a contiguous block of memory and DMA that in one stretch so they don't lose any events, and in such cases we are not linking to Null. > 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. But it is waiting anyway even today. Currently based on MAX segs, MMC driver/subsystem will make SG list of size max_segs. Between these sessions of creating such smaller SG-lists, if for some reason the MMC controller is sending events, these will be lost anyway. What will happen now with this patch series is we are simply accepting a bigger list than this, and handling all the max_segs stuff within the EDMA driver itself without outside world knowing. This is actually more efficient as for long transfers, we are not going back and forth much between the client and EDMA driver. > 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. Do you mean ping-pong scheme as used in the davinci-pcm driver today? This can be used only for buffers that are contiguous in memory, not those that are scattered across memory. Thanks, -Joel -- 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 07/30/2013 11:29 AM, Sekhar Nori wrote:
> 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.>
Ok, sure. I will go ahead and return from the if block.
Thanks,
-Joel
--
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: OMAP2430 SDP boot broken after Linus' rmk merge
On Tue, 23 Jul 2013, Jonathan Austin wrote: > I've just had a quick go at booting 3.11-rc2 on an integrator-cp (1136) in the > hope that we might be able to reproduce this on those boards, but I'm afraid > the integrator works... > > I took your config, modified it as little as possible to switch to Integrator > and turn on earlyprintk, and then tried to boot. That *did* require switching > away from ARCH_MULTIPLATFORM, so it isn't as similar as I'd like, though... > > So I think we can at least say that this is not 1136 specific... Sorry not to > be more helpful... Just saw this message - thanks for the test. What 1136 variant does the Integrator-CP have in it? Would assume an r1 or later? - 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
[no subject]
-- 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] RFC: interrupt consistency check for OF GPIO IRQs
On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely wrote: > On Mon, Jul 29, 2013 at 6:36 AM, Linus Walleij > wrote: >> To solve this dilemma, perform an interrupt consistency check >> when adding a GPIO chip: if the chip is both gpio-controller and >> interrupt-controller, walk all children of the device tree, >> check if these in turn reference the interrupt-controller, and >> if they do, loop over the interrupts used by that child and >> perform gpio_reques() and gpio_direction_input() on these, >> making them unreachable from the GPIO side. > > Ugh, that's pretty awful, and it doesn't actually solve the root > problem of the GPIO and IRQ subsystems not cooperating. It's also a > very DT-centric solution even though we're going to see the exact same > issue on ACPI machines. The problem is that the patches for OMAP that I applied and now have had to revert solves it in an even uglier way, leading to breaking boards, as was noticed. The approach in this patch has the potential to actually work without regressing a bunch of boards... Whether this is a problem in ACPI or not remains to be seen, but I'm not sure about that. Device trees allows for a GPIO line to be used as an interrupt source and GPIO line orthogonally, and that is the root of this problem. Does ACPI have the same problem, or does it impose natural restrictions on such use cases? > We have to solve the problem in a better way than that. Rearranging > your patch description, here are some of the points you brought up so > I can comment on them... > >> This has the following undesired effects: >> >> - The GPIOlib subsystem is not aware that the line is in use >> and willingly lets some other consumer perform gpio_request() >> on it, leading to a complex resource conflict if it occurs. > > If a gpio line is being both requested as a gpio and used as an > interrupt line, then either a) it's a bug, or b) the gpio line needs > to be used as input only so it is compatible with irq usage. b) should > be supportable. Yes this is what I'm saying too I think... The bug in (a) manifested itself in the OMAP patch with no real solution in sight. >> - The GPIO debugfs file claims this GPIO line is "free". > > Surely we can fix this. I still don't see a problem of having the > controller request the gpio when it is claimed as an irq if we can get > around the problem of another user performing a /valid/ request on the > same GPIO line. The solution may be to have a special form of request > or flag that allows it to be shared. I don't see how sharing works here, or how another user, i.e. another one than the user wanting to recieve the IRQ, can validly request such a line? What would the usecase for that valid request be? Basically I believe these two things need to be exclusive in the DT world: A: request_irq(a resource passed from "interrupts"); -> core implicitly performs gpio_request() gpio_direction_input() B: gpio_request(a resource passed from "gpios"); gpio_direction_input() request_irq(gpio_to_irq()) Never both. And IIUC that was what happened in the OMAP case. >> - The line direction of the interrupt GPIO line is not >> explicitly set as input, even though it is obvious that such >> a line need to be set up in this way, often making the system >> depend on boot-on defaults for this kind of settings. > > Should also be solvable if the gpio request problem is solved. Agreed... Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 6/8] wlcore: sdio: add wilink clock providers
On Tue, 2013-07-30 at 15:35 -0700, Mike Turquette wrote:
> Quoting Luciano Coelho (2013-07-30 06:04:34)
> > +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);
>
> Hi Luciano,
Hi Mike,
> Any reason for establishing your own compatible string if you just plan
> to use the fixed rate clock? You could just use "fixed-clock" compatible
> in your DTS.
The reason is that I can't call of_clk_init(), because this function is
not exported and my module can't use it. I would have to link with the
clk code to be able to call it.
Also, I reckoned that, since these clock cannot be used by anyone else
than the WiLink module itself, it would make sense to have a different
compatible string.
> I will be posting patches this week which makes the fixed-rate clock a
> proper driver and matches that compatible string to instantiate those
> clocks. That means that your driver could probably remove the clock
> setup code completely.
Okay, if this is done, then I could probably use "fixed-clock" directly,
since the driver itself will take care of going through the DT and
initializing all the fixed-clocks.
--
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: [PATCH] ARM: allow DEBUG_UNCOMPRESS for omap2plus
On 07/30/2013 04:52 PM, Russell King - ARM Linux wrote: > On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote: >> From: Stephen Warren >> >> DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to >> omap2plus.S's use of .data, which is not allowed in the decompressor. >> Solve this by placing that data into .text when building the file into >> the decompressor. This relies on .text actually being writable in the >> decompressor, which it is in practice. > > Unless you decide to use ZBOOT and flash the zImage. I knew there had to be a catch:-) I have no idea if ZBOOT is a use-case that's relevant to OMAP? On Tegra at least (the same issue applies to the other patch I just sent), that use-case is almost impossible; even if the boot ROM directly booted a kernel, the boot ROM is hard-coded to copy whatever it's booting to SDRAM first, although I suppose if that was a boot-loader it could just jump back to a ROM location. That said, NOR flash is extremely rare on Tegra. So, I don't know if we care about this issue. Is it reasonable to just say "If you use ZBOOT, don't enable DEBUG_UNCOMPRESS"? Perhaps these patches should not completely remove the !DEBUG_TEGRA_UART from config DEBUG_UNCOMPRESS, but instead say: default y if DEBUG_LL && (!DEBUG_TEGRA_UART || !ZBOOT)? -- 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: allow DEBUG_UNCOMPRESS for omap2plus
On Tue, Jul 30, 2013 at 04:49:18PM -0600, Stephen Warren wrote: > From: Stephen Warren > > DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to > omap2plus.S's use of .data, which is not allowed in the decompressor. > Solve this by placing that data into .text when building the file into > the decompressor. This relies on .text actually being writable in the > decompressor, which it is in practice. Unless you decide to use ZBOOT and flash the zImage. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: allow DEBUG_UNCOMPRESS for omap2plus
From: Stephen Warren DEBUG_UNCOMPRESS was previously disallowed for omap2plus due to omap2plus.S's use of .data, which is not allowed in the decompressor. Solve this by placing that data into .text when building the file into the decompressor. This relies on .text actually being writable in the decompressor, which it is in practice. Cc: Shawn Guo Signed-off-by: Stephen Warren --- Note that I have build-tested this with omap2plus_defconfig, but not run-time tested it in any way. --- arch/arm/Kconfig.debug | 2 +- arch/arm/include/debug/omap2plus.S | 4 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index d8ff7f7..8eb04b1 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -1046,7 +1046,7 @@ config DEBUG_UART_8250_FLOW_CONTROL config DEBUG_UNCOMPRESS bool depends on ARCH_MULTIPLATFORM - default y if DEBUG_LL && !DEBUG_OMAP2PLUS_UART + default y if DEBUG_LL help This option influences the normal decompressor output for multiplatform kernels. Normally, multiplatform kernels disable diff --git a/arch/arm/include/debug/omap2plus.S b/arch/arm/include/debug/omap2plus.S index 6d867ae..364ae35 100644 --- a/arch/arm/include/debug/omap2plus.S +++ b/arch/arm/include/debug/omap2plus.S @@ -58,11 +58,15 @@ #define UART_OFFSET(addr) ((addr) & 0x00ff) +#if !defined(ZIMAGE) .pushsection .data +#endif omap_uart_phys:.word 0 omap_uart_virt:.word 0 omap_uart_lsr: .word 0 +#if !defined(ZIMAGE) .popsection +#endif .macro addruart, rp, rv, tmp -- 1.8.1.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 6/8] wlcore: sdio: add wilink clock providers
Quoting Luciano Coelho (2013-07-30 06:04:34)
> +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);
Hi Luciano,
Any reason for establishing your own compatible string if you just plan
to use the fixed rate clock? You could just use "fixed-clock" compatible
in your DTS.
I will be posting patches this week which makes the fixed-rate clock a
proper driver and matches that compatible string to instantiate those
clocks. That means that your driver could probably remove the clock
setup code completely.
Regards,
Mike
> +
> 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 v2 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
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index b3f6e1f..59a797d 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -5,6 +5,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include
#include "elpida_ecb240abacn.dtsi"
/ {
@@ -117,6 +118,20 @@
startup-delay-us = <7>;
enable-active-high;
};
+
+ wlan {
+ compatible = "ti,wilink6";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 53 */
+ 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 v2 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
---
arch/arm/boot/dts/omap4-sdp.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 3845615..63f1af1 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -7,6 +7,7 @@
*/
/dts-v1/;
+#include
#include "omap443x.dtsi"
#include "elpida_ecb240abacn.dtsi"
@@ -150,6 +151,26 @@
startup-delay-us = <7>;
enable-active-high;
};
+
+ wlan {
+ compatible = "ti,wilink7";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 53 */
+ 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
[PATCH v2 1/4] ARM: dts: omap4-panda: 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
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..b3f6e1f 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -107,6 +107,16 @@
*/
clock-frequency = <1920>;
};
+
+ wilink_wl_en: fixedregulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "wilink_wl_en";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ gpio = <&gpio2 11 0>; /* gpio line 43 */
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
};
&omap4_pmx_wkup {
@@ -132,6 +142,7 @@
&dss_hdmi_pins
&tpd12s015_pins
&hsusbb1_pins
+ &wilink_pins
>;
twl6030_pins: pinmux_twl6030_pins {
@@ -235,6 +246,19 @@
0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
>;
};
+
+ wilink_pins: pinmux_wilink_pins {
+ pinctrl-single,pins = <
+ 0x7a 0x103 /* gpio_53 INPUT | MODE3 */
+ 0x66 0x3/* gpio_43 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 {
@@ -314,8 +338,13 @@
};
&mmc5 {
- ti,non-removable;
+ 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 v2 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
---
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 v2 0/4] ARM: dts: add WiLink support to panda and omap4-sdp
Hi, In v2: use IRQ_TYPE_LEVEL_HIGH when defining the interrupts, as suggested by Laurent. 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 | 46 +++- arch/arm/boot/dts/omap4-sdp.dts | 50 +++ 2 files changed, 95 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
Re: OMAP baseline test results for v3.10-rc6
On 07/30/2013 03:23 PM, Paul Walmsley wrote:
Do you know if anyone ever got serial cold-booting working well for, say,
OMAP3 and OMAP4 chips?
I had done configuration header based OMAP3 boot[1] once upon a time,
but serial boot straight to kernel, we need a second that gives control
there.. could be done, have'nt heard it done + I dont directly see a
customer usage model for it ("ROI for investment of time") - so doubt
any investment was done.
CH was the closest I could get to avoiding bootloaders in it's entirety.
but the level of interest fell off when there was no viable usage model
for the same.
[1] http://marc.info/?t=12723240113&r=1&w=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: [PATCHv4 23/33] CLK: OMAP: add interface clock support for OMAP3
On 07/23/2013 02:20 AM, Tero Kristo wrote:
OMAP3 has interface clocks in addition to functional clocks, which
is it just OMAP3?
require special handling for the autoidle and idle status register
offsets mainly.
Signed-off-by: Tero Kristo
---
drivers/clk/omap/Makefile|2 +-
drivers/clk/omap/clk.c |3 ++
drivers/clk/omap/interface.c | 110 ++
should this be isolated off for omap3?
3 files changed, 114 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/omap/interface.c
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
index c4e8825..faaeb62 100644
--- a/drivers/clk/omap/Makefile
+++ b/drivers/clk/omap/Makefile
@@ -1,3 +1,3 @@
obj-y += clk.o dpll.o autoidle.o gate.o \
clk-44xx.o clk-54xx.o clk-7xx.o \
- clk-33xx.o
+ clk-33xx.o interface.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
index 8c89714..5cbefde 100644
--- a/drivers/clk/omap/clk.c
+++ b/drivers/clk/omap/clk.c
@@ -30,6 +30,9 @@ static const struct of_device_id clk_match[] = {
{.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, },
+ {.compatible = "ti,interface-clock",
+ .data = of_omap_interface_clk_setup, },
+ {.compatible = "ti,omap3-dpll-clock", .data = of_omap3_dpll_setup, },
I dont see how this line has anything to do with the patch.
{},
};
diff --git a/drivers/clk/omap/interface.c b/drivers/clk/omap/interface.c
new file mode 100644
index 000..f1f1a1a
--- /dev/null
+++ b/drivers/clk/omap/interface.c
@@ -0,0 +1,110 @@
+/*
+ * OMAP interface clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_OF
+
+static const struct clk_ops omap_interface_clk_ops = {
+ .init = &omap2_init_clk_clkdm,
+ .enable = &omap2_dflt_clk_enable,
+ .disable= &omap2_dflt_clk_disable,
+ .is_enabled = &omap2_dflt_clk_is_enabled,
+};
+
+void __init of_omap_interface_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_init_data init;
+ struct clk_hw_omap *clk_hw;
+ const char *clk_name = node->name;
+ int num_parents;
+ const char **parent_names;
+ int i;
+ u32 val;
+
+ clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
+ if (!clk_hw) {
+ pr_err("%s: could not allocate clk_hw_omap\n", __func__);
+ return;
+ }
+
+ clk_hw->hw.init = &init;
+ clk_hw->ops = &clkhwops_iclk_wait;
+ clk_hw->enable_reg = of_iomap(node, 0);
+
+ if (!of_property_read_u32(node, "ti,enable-bit", &val))
+ clk_hw->enable_bit = val;
+
+ if (of_property_read_bool(node, "ti,iclk-no-wait"))
+ clk_hw->ops = &clkhwops_iclk;
+
+ if (of_property_read_bool(node, "ti,iclk-hsotgusb"))
+ clk_hw->ops = &clkhwops_omap3430es2_iclk_hsotgusb_wait;
+
+ if (of_property_read_bool(node, "ti,iclk-dss"))
+ clk_hw->ops = &clkhwops_omap3430es2_iclk_dss_usbhost_wait;
+
+ if (of_property_read_bool(node, "ti,iclk-ssi"))
+ clk_hw->ops = &clkhwops_omap3430es2_iclk_ssi_wait;
+
+ 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_interface_clk_ops;
+ init.flags = 0;
+
+ num_parents = of_clk_get_parent_count(node);
+ if (num_parents < 1) {
+ pr_err("%s: omap interface_clk %s must have parent(s)\n",
+ __func__, node->name);
+ 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_s
Re: OMAP baseline test results for v3.10-rc6
Hi Tom, On Mon, 29 Jul 2013, Tom Rini wrote: > On 07/29/2013 04:29 AM, Paul Walmsley wrote: > > On Wed, 26 Jun 2013, Tom Rini wrote: > >> > >> Well, me? I'm all in favor of people using latest release of U-Boot for > >> their board and yelling and screaming (or just reporting bugs) when > >> things don't work. I'm biased of course. > > > > That's exactly how bootloader developers should be testing their changes. > > But most of the rest of us kernel folks don't want to deal with constantly > > replacing bootloaders, and then dealing with the inevitable bootloader > > regressions, when what we're really trying to test is the kernel... > > The kernel should be completely independent of the bootloader used. > > And thus the chicken and egg problems we have today. The kernel should > be independent, but unless someone is also testing more recent U-Boots > as well, we may or may not have more hidden clock problems. It doesn't have to be this way :-) IMHO the only thing that the bootloader should be responsible for is the minimum that's needed to get the kernel started. Setting up RAM, maybe a handful of critical system clocks, and that's basically it. In fact it would be great if there was a bootloader option where it would return the rest of the bits on the chip that it tweaked to power-on reset status. That would let you guys off the hook for everything that we don't set up correctly in the kernel. And it would allow the kernel folks to see where the problems really are. And then for customer-targeted images, that bootloader option could be kept off so management doesn't freak out. You might not believe this, but we went to great pain on the OMAP Linux kernel to reset as much as we could, as early as possible. This was partially so that if kernel device driver authors assumed that the bootloader would configure their device, it would show up as a bug that would need to be fixed. We were even resetting and reprogramming the SDRAM controller for a while. Unfortunately we weren't able to reset the clocks... > I don't suspect what I'm going to say now will have a lot of traction, > but I really think that much like user space, every once in a while (6 > months? year?) one ought to update their environment and make sure > things are still working too. > > You folks don't need to test ever rev of U-Boot (that's my job), but it > often feels like there's this cycle of "U-Boot sucks and can't do ... !" > "We've had that fixed / improved / changed for years now, upgrade?" "No, > can't / won't!". And... I've always wanted to switch most of the devices in my test platform over to serial-booted bootloaders and MLOs/X-loaders/SPLs. That way any bootloader could be booted during automated test. This is what's happening now on the BeagleBone-black here; that's really easy to cold-boot from serial due to the Xmodem download code implemented in the ROM, plus the lack of flash: http://www.pwsan.com/omap/testlogs/test_v3.11-rc3/20130728224046/boot/am335xbonelt/am335x-bone/ Do you know if anyone ever got serial cold-booting working well for, say, OMAP3 and OMAP4 chips? > For shipping consumer product, or however you want to call those kind of > devices, yes, appended dtb needs to work since the bootloader is locked, > and making that boot something else to boot the kernel is an exercise > for us oddballs :) But the boards which are designed as reference > platform, we can make your lives easier, if you let us help. If > something is a pain to do, give us feedback. OK I would love it if you would add a bootloader option "ASSUME_WORKING_KERNEL" that would reset every non-essential device on the board to power-on reset, and reset any non-essential clock register bits etc. to their POR values. Unlock the USB DPLL, etc. To start with, you'd need to leave that disabled for shipping customer images, but we could start testing with it and prevent patches from going upstream that implicitly rely on the bootloader settings. - 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 v3] Documentation: dt: bindings: TI WiLink modules
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
---
In v3, use IRQ_TYPE_LEVEL_HIGH in the example, as suggested by Laurent.
.../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..aafebb1
--- /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 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 53 */
+ clocks = <&refclock>;
+ clock-names = "refclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <3840>;
+ };
+};
--
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 29/33] CLK: omap: add omap3 clock init file
On 07/23/2013 02:20 AM, Tero Kristo wrote: clk-3xxx.c now contains the clock init functionality for omap3, including DT clock registration and adding of static clkdev entries. This patch also splits the OMAP3 clock registration code under mach-omap2 to use OMAP3 subtype specific clk init functions. Signed-off-by: Tero Kristo --- arch/arm/mach-omap2/Makefile |2 +- arch/arm/mach-omap2/cclock3xxx_data.c | 3641 - Tony and a lot of people is not going to like removing support for non-dt boot for OMAP3 before "it's time is due" ;) -- 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 22/33] CLK: OMAP: update gate clock setup for OMAP3
On 07/23/2013 02:20 AM, Tero Kristo wrote:
OMAP3 gate clocks are handled through the clk driver now. Basic gate
clock can't be used as the OMAP3 gate clocks have some special features,
namely the idle status linkage which is on separate register.
Signed-off-by: Tero Kristo
---
drivers/clk/omap/gate.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/omap/gate.c b/drivers/clk/omap/gate.c
index 7186bb2..b560ff4 100644
--- a/drivers/clk/omap/gate.c
+++ b/drivers/clk/omap/gate.c
@@ -28,12 +28,19 @@
#ifdef CONFIG_OF
-static const struct clk_ops omap_gate_clk_ops = {
+static const struct clk_ops omap_gate_clkdm_clk_ops = {
.init = &omap2_init_clk_clkdm,
.enable = &omap2_clkops_enable_clkdm,
.disable= &omap2_clkops_disable_clkdm,
};
+static const struct clk_ops omap_gate_clk_ops = {
+ .init = &omap2_init_clk_clkdm,
+ .enable = &omap2_dflt_clk_enable,
+ .disable= &omap2_dflt_clk_disable,
+ .is_enabled = &omap2_dflt_clk_is_enabled,
+};
+
void __init of_omap_gate_clk_setup(struct device_node *node)
{
struct clk *clk;
@@ -43,6 +50,7 @@ void __init of_omap_gate_clk_setup(struct device_node *node)
int num_parents;
const char **parent_names;
int i;
+ u32 val;
clk_hw = kzalloc(sizeof(struct clk_hw_omap), GFP_KERNEL);
if (!clk_hw) {
@@ -56,7 +64,22 @@ void __init of_omap_gate_clk_setup(struct device_node *node)
of_property_read_string(node, "ti,clkdm-name", &clk_hw->clkdm_name);
init.name = clk_name;
- init.ops = &omap_gate_clk_ops;
+ init.flags = 0;
+
+ if (of_property_read_u32_index(node, "reg", 0, &val)) {
+ /* No register, clkdm control only */
+ init.ops = &omap_gate_clkdm_clk_ops;
+ } else {
+ init.ops = &omap_gate_clk_ops;
+ clk_hw->enable_reg = of_iomap(node, 0);
+ of_property_read_u32(node, "ti,enable-bit", &val);
+ clk_hw->enable_bit = val;
+
+ if (of_property_read_bool(node, "ti,dss-clk"))
+ clk_hw->ops = &clkhwops_omap3430es2_dss_usbhost_wait;
umm, it was going relatively ok so far, till i hit this :( it is
probably a quirk... but still..
+ else
+ clk_hw->ops = &clkhwops_wait;
+ }
num_parents = of_clk_get_parent_count(node);
if (num_parents < 1) {
but still no usage of "ti,omap-gate-clock" makes me question the need
for this file.
--
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 21/33] CLK: OMAP: DPLL: add omap3 dpll support
On 07/23/2013 02:20 AM, Tero Kristo wrote:
OMAP3 has slightly different DPLLs from those compared to OMAP4. Modified
code for the same.
Signed-off-by: Tero Kristo
---
drivers/clk/omap/dpll.c | 96 +--
1 file changed, 85 insertions(+), 11 deletions(-)
:) wont repeat the binding crib again..
diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c
index d8a958a..ecb1fbd 100644
--- a/drivers/clk/omap/dpll.c
+++ b/drivers/clk/omap/dpll.c
@@ -26,6 +26,11 @@
#include
#include
+enum {
+ SUBTYPE_OMAP3_DPLL,
+ SUBTYPE_OMAP4_DPLL,
+};
+
static const struct clk_ops dpll_m4xen_ck_ops = {
.enable = &omap3_noncore_dpll_enable,
.disable= &omap3_noncore_dpll_disable,
@@ -40,6 +45,13 @@ static const struct clk_ops dpll_core_ck_ops = {
.get_parent = &omap2_init_dpll_parent,
};
+static const struct clk_ops omap3_dpll_core_ck_ops = {
+ .init = &omap2_init_clk_clkdm,
+ .get_parent = &omap2_init_dpll_parent,
+ .recalc_rate= &omap3_dpll_recalc,
+ .round_rate = &omap2_dpll_round_rate,
+};
+
static const struct clk_ops dpll_ck_ops = {
.enable = &omap3_noncore_dpll_enable,
.disable= &omap3_noncore_dpll_disable,
@@ -50,6 +62,26 @@ static const struct clk_ops dpll_ck_ops = {
.init = &omap2_init_clk_clkdm,
};
+static const struct clk_ops omap3_dpll_ck_ops = {
+ .init = &omap2_init_clk_clkdm,
+ .enable = &omap3_noncore_dpll_enable,
+ .disable= &omap3_noncore_dpll_disable,
+ .get_parent = &omap2_init_dpll_parent,
+ .recalc_rate= &omap3_dpll_recalc,
+ .set_rate = &omap3_noncore_dpll_set_rate,
+ .round_rate = &omap2_dpll_round_rate,
+};
+
+static const struct clk_ops omap3_dpll_per_ck_ops = {
+ .init = &omap2_init_clk_clkdm,
+ .enable = &omap3_noncore_dpll_enable,
+ .disable= &omap3_noncore_dpll_disable,
+ .get_parent = &omap2_init_dpll_parent,
+ .recalc_rate= &omap3_dpll_recalc,
+ .set_rate = &omap3_dpll4_set_rate,
+ .round_rate = &omap2_dpll_round_rate,
+};
+
static const struct clk_ops dpll_x2_ck_ops = {
.recalc_rate= &omap3_clkoutx2_recalc,
};
@@ -144,7 +176,9 @@ struct clk *omap_clk_register_dpll_x2(struct device *dev,
const char *name,
* of_omap_dpll_setup() - Setup function for OMAP DPLL clocks
*/
static void __init of_omap_dpll_setup(struct device_node *node,
- const struct clk_ops *ops)
+ const struct clk_ops *ops, u32 freqsel,
+ u32 modes, u8 mul_div_shift,
+ int subtype)
{
struct clk *clk;
const char *clk_name = node->name;
@@ -157,8 +191,8 @@ static void __init of_omap_dpll_setup(struct device_node
*node,
u32 idlest_mask = 0x1;
u32 enable_mask = 0x7;
u32 autoidle_mask = 0x7;
- u32 mult_mask = 0x7ff << 8;
- u32 div1_mask = 0x7f;
+ u32 mult_mask = 0x7ff << (8 + mul_div_shift);
+ u32 div1_mask = 0x7f << mul_div_shift;
u32 max_multiplier = 2047;
u32 max_divider = 128;
u32 min_divider = 1;
@@ -193,7 +227,7 @@ static void __init of_omap_dpll_setup(struct device_node
*node,
clkspec.np = of_parse_phandle(node, "ti,clk-ref", 0);
dd->clk_ref = of_clk_get_from_provider(&clkspec);
- if (!dd->clk_ref) {
+ if (IS_ERR(dd->clk_ref)) {
belongs to original patch.
pr_err("%s: ti,clk-ref for %s not found\n", __func__,
clk_name);
goto cleanup;
@@ -201,7 +235,7 @@ static void __init of_omap_dpll_setup(struct device_node
*node,
clkspec.np = of_parse_phandle(node, "ti,clk-bypass", 0);
dd->clk_bypass = of_clk_get_from_provider(&clkspec);
- if (!dd->clk_bypass) {
+ if (IS_ERR(dd->clk_bypass)) {
same
pr_err("%s: ti,clk-bypass for %s not found\n", __func__,
clk_name);
goto cleanup;
@@ -225,14 +259,31 @@ static void __init of_omap_dpll_setup(struct device_node
*node,
dd->enable_mask = enable_mask;
dd->autoidle_mask = autoidle_mask;
- dd->modes = 0xa0;
+ if (!of_property_read_u32(node, "ti,recal-en-bit", &val))
+ dd->recal_en_bit = val;
+
+ if (!of_property_read_u32(node, "ti,recal-st-bit", &val))
+ dd->recal_st_bit = val;
+
+ if (!of_property_read_u32(node, "ti,auto-recal-bit", &val))
+ dd->auto_recal_bit = val;
now I understand what it means.
+
+ of_property_read_u32(node, "ti,modes", &modes);
i see we pass in modes, and read ti,modes to &modes. it is a bit sketchy
without bindings documentation.
+
+ dd->modes = mode
Re: [PATCHv4 19/33] CLK: omap: add am33xx clock init file
On 07/23/2013 02:20 AM, Tero Kristo wrote:
clk-33xx.c now contains the clock init functionality for am33xx, including
DT clock registration and adding of static clkdev entries.
This patch also moves the omap2_clk_enable_init_clocks declaration to
the driver include, as this is needed by the am33xx clock init code.
Signed-off-by: Tero Kristo
---
arch/arm/mach-omap2/clock.h |1 -
drivers/clk/omap/clk-33xx.c | 85 +++
include/linux/clk/omap.h|1 +
3 files changed, 86 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/omap/clk-33xx.c
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index d1a3125..6273f14 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -267,7 +267,6 @@ void omap2_clk_dflt_find_idlest(struct clk_hw_omap *clk,
void __iomem **idlest_reg,
u8 *idlest_bit, u8 *idlest_val);
int omap2_clk_enable_autoidle_all(void);
-void omap2_clk_enable_init_clocks(const char **clk_names, u8 num_clocks);
int omap2_clk_switch_mpurate_at_boot(const char *mpurate_ck_name);
void omap2_clk_print_new_rates(const char *hfclkin_ck_name,
const char *core_ck_name,
diff --git a/drivers/clk/omap/clk-33xx.c b/drivers/clk/omap/clk-33xx.c
new file mode 100644
index 000..3ada30e
--- /dev/null
+++ b/drivers/clk/omap/clk-33xx.c
[...]
+static const char *enable_init_clks[] = {
+ "dpll_ddr_m2_ck",
+ "dpll_mpu_m2_ck",
+ "l3_gclk",
+ "l4hs_gclk",
+ "l4fw_gclk",
+ "l4ls_gclk",
+ /* Required for external peripherals like, Audio codecs */
+ "clkout2_ck",
+};
should be a sort of dt property?
--
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 17/33] CLK: DT: add support for set-rate-parent flag
On 07/23/2013 02:20 AM, Tero Kristo wrote: Adding set-rate-parent to clock node now allows a node to forward clk_set_rate request to its parent clock. Apologies about previous comment of set-parent missing, the sequence of patches messed with me :(. had expected generic clk changes at the start of the series followed by the rest. Signed-off-by: Tero Kristo --- drivers/clk/clk-divider.c |6 +- drivers/clk/clk-fixed-factor.c |6 +- drivers/clk/clk-gate.c |8 ++-- drivers/clk/clk-mux.c |6 +- 4 files changed, 21 insertions(+), 5 deletions(-) Documentation/devicetree/bindings/clock/ needs update as well. [...] -- 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 16/33] CLK: OMAP: DPLL: do not of_iomap NULL autoidle register
On 07/23/2013 02:20 AM, Tero Kristo wrote: AM33xx series SoCs do not have autoidle support, and for these the autoidle register is marked as NULL. Check against a NULL pointer and do not attempt to of_iomap in this case, as this just creates a bogus pointer and causes a kernel crash during boot. Signed-off-by: Tero Kristo --- drivers/clk/omap/dpll.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/clk/omap/dpll.c b/drivers/clk/omap/dpll.c index 1d24feada..d8a958a 100644 --- a/drivers/clk/omap/dpll.c +++ b/drivers/clk/omap/dpll.c @@ -162,6 +162,7 @@ static void __init of_omap_dpll_setup(struct device_node *node, u32 max_multiplier = 2047; u32 max_divider = 128; u32 min_divider = 1; + u32 val; int i; dd = kzalloc(sizeof(struct dpll_data), GFP_KERNEL); @@ -210,7 +211,14 @@ static void __init of_omap_dpll_setup(struct device_node *node, dd->control_reg = of_iomap(node, 0); dd->idlest_reg = of_iomap(node, 1); - dd->autoidle_reg = of_iomap(node, 2); + /* +* AM33xx DPLLs have no autoidle support, and the autoidle reg +* for these is NULL. Do not attempt to of_iomap in this case, +* as this just creates a bogus pointer and crashes the kernel. +*/ + of_property_read_u32_index(node, "reg", 2 * 2, &val); + if (val) + dd->autoidle_reg = of_iomap(node, 2); should we not do that for all the parameters? OR: move this as index 3 which is optional and is not defined for am33xx? dd->mult_div1_reg = of_iomap(node, 3); dd->idlest_mask = idlest_mask; we could probably squash this in original dpll.c as a result? -- 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 10/33] ARM: OMAP4: remove old clock data and link in new clock init code
On 07/23/2013 02:20 AM, Tero Kristo wrote:
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
deleted file mode 100644
index 88e37a4..000
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ /dev/null
[...]
-
-int __init omap4xxx_clk_init(void)
-{
arch/arm/mach-omap2/clock44xx.h:int omap4xxx_clk_init(void);
arch/arm/mach-omap2/io.c: omap_clk_init = omap4xxx_clk_init;
code in drivers/clk/omap/clk-44xx.c
Seems goofy to me a little.
entire purpose of having a clk-44xx.c is:
a) doing a clk alias for device nodes
b) set_parent, rate
both of these seem to be an old style carry forward and should instead
be fixes with generic properties IMHO voiding the need for SoC specific
inits.
instead all we should be doing is call of_clk_init(NULL); at appropriate
init sequence.
--
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
---
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
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * 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.
+
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
---
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 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
---
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 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
---
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
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#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 of_omap_fixed_factor_setup(struct device_node *node);
void of_omap_divider_setup(struct device_node *node);
+void of_omap_gate_clk_setup(struct device_node *nod
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
---
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
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
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 (of_property_read_bool(node, "ti,autoidle-low"))
+ clk->flags |= AUTOIDLE_LOW;
+
+
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
> > ---
> >
> > 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 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: [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: [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
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
+
/**
* 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'
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: [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
> ---
>
> 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 ) 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: [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
---
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
#include
+#include
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;
-};
-
/*
* struct clk.flags possibilities
*
@@ -274,56
[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
---
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
---
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
---
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
[PATCH 1/4] ARM: dts: omap4-panda: 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
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..b3f6e1f 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -107,6 +107,16 @@
*/
clock-frequency = <1920>;
};
+
+ wilink_wl_en: fixedregulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "wilink_wl_en";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ gpio = <&gpio2 11 0>; /* gpio line 43 */
+ startup-delay-us = <7>;
+ enable-active-high;
+ };
};
&omap4_pmx_wkup {
@@ -132,6 +142,7 @@
&dss_hdmi_pins
&tpd12s015_pins
&hsusbb1_pins
+ &wilink_pins
>;
twl6030_pins: pinmux_twl6030_pins {
@@ -235,6 +246,19 @@
0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
>;
};
+
+ wilink_pins: pinmux_wilink_pins {
+ pinctrl-single,pins = <
+ 0x7a 0x103 /* gpio_53 INPUT | MODE3 */
+ 0x66 0x3/* gpio_43 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 {
@@ -314,8 +338,13 @@
};
&mmc5 {
- ti,non-removable;
+ 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
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
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
>>> ---
>>> :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: [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
---
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
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
after a quick check, are all these required?
+#include
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);
+ }
+
+ clk_hw->dpll_data = dpll_data;
+ clk_hw->ops = &clkhwops_omap3_dpll;
+ clk_hw->clkdm_name = clkdm_name;
+ clk_hw->hw.init = &ini
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 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
Cc: Mike Turquette
---
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
+ * Mike Turquette
+ *
+ * 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
+#include
+#include
+#include
+
+/* 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: [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
Cc: Russell King
---
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: [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
> Cc: Will Deacon
> Cc: Russell King
> Cc: Nicolas Pitre
> Cc: Tony Lindgren
> ---
Acked-by: Will Deacon
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: [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
> > ---
> > :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 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 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
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 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 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 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'
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
> +#include
>
> /*
> * 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,
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
> 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] [] (unwind_backtrace+0x0/0xf0) from []
> >> (show_stack+0x10/0x14)
> >> [ 22.009289] [] (show_stack+0x10/0x14) from []
> >> (dump_stack+0x70/0x8c)
> >> [ 22.009304] [] (dump_stack+0x70/0x8c) from []
> >> (Ldiv0+0x8/0x10)
> >> [ 22.009319] [] (Ldiv0+0x8/0x10) from []
> >> (clk_divider_set_rate+0x10/0xdc)
> >> [ 22.009331] [] (clk_divider_set_rate+0x10/0xdc) from
> >> [] (clk_change_rate+0x38/0xb0)
> >> [ 22.009341] [] (clk_change_rate+0x38/0xb0) from []
> >> (clk_set_rate+0x70/0xa8)
> >> [ 22.009354] [] (clk_set_rate+0x70/0xa8) from []
> >> (nop_usb_xceiv_probe+0x1fc/0x2f8)
> >> [ 22.009369] [] (nop_usb_xceiv_probe+0x1fc/0x2f8) from
> >> [] (platform_drv_probe+0x18/0x1c)
> >> [ 22.009380] [] (platform_drv_probe+0x18/0x1c) from
> >> [] (really_probe+0x70/0x1f4)
> >> [ 22.009390] [] (really_probe+0x70/0x1f4) from []
> >> (driver_probe_device+0x30/0x48)
> >> [ 22.009401] [] (driver_probe_device+0x30/0x48) from
> >> [] (__driver_attach+0x94/0x98)
> >> [ 22.009411] [] (__driver_attach+0x94/0x98) from []
> >> (bus_for_each_dev+0x54/0x88)
> >> [ 22.009420] [] (bus_for_each_dev+0x54/0x88) from []
> >> (bus_add_driver+0xdc/0x29c)
> >> [ 22.009430] [] (bus_add_driver+0xdc/0x29c) from []
> >> (driver_register+0x78/0x190)
> >> [ 22.009440] [] (driver_register+0x78/0x190) from []
> >> (do_one_initcall+0x34/0x164)
> >> [ 22.009453] [] (do_one_initcall+0x34/0x164) from []
> >> (do_basic_setup+0x90/0xc4)
> >> [ 22.009466] [] (do_basic_setup+0x90/0xc4) from []
> >> (kernel_init_freeable+0x74/0x110)
> >> [ 22.009478] [] (kernel_init_freeable+0x74/0x110) from
> >> [] (kernel_init+0x8/0xe4)
> >> [ 22.009491] [] (kernel_init+0x8/0xe4) from []
> >> (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] [] (unwind_backtrace+0x0/0xf0) from []
> >> (show_stack+0x10/0x14)
> >> [ 21.592787] [
Re: [PATCH v2 1/8] ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs'
* Felipe Balbi [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: [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 [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
[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 : 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: [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
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 wrote: On 07/30/2013 01:07 AM, Chen Baozi wrote: On Jul 30, 2013, at 11:52 AM, Lokesh Vutla 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-omap&m=137456411706971&w=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
[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
Reviewed-by: Felipe Balbi
---
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
#include
#include
-#include
+#include
#include
#include
#include
@@ -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: [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
+#include
/*
* 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
[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
Reviewed-by: Felipe Balbi
---
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
Cc: Sekhar Nori
Signed-off-by: Luciano Coelho
Reviewed-by: Felipe Balbi
Acked-by: Sekhar Nori
---
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);
omap_i2c_init();
pwm_add_table(zoom_pwm_look
[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
Reviewed-by: Felipe Balbi
---
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
#include
#include
+#include
#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
Cc: Sekhar Nori
Signed-off-by: Luciano Coelho
Reviewed-by: Felipe Balbi
---
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
#include
#include
#include
@@ -19,7 +18,6 @@
#include
#include
#include
-#include
#include
#include
@@ -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
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1701,6 +1701,43 @@ static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
},
};
+static const struct wl12xx_clock wl12xx_refclock_table[] = {
+ { 1
[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
Reviewed-by: Felipe Balbi
---
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 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
Reviewed-by: Felipe Balbi
---
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 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
Signed-off-by: Luciano Coelho
Acked-by: Tony Lindgren
Reviewed-by: Felipe Balbi
---
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
#include
-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 = wl12xx_board_data->set_power;
- wl->irq = wl12xx_board_data->i
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
>>> [...]
>> +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=13741659941&r=1&w=2
> [2] http://marc.info/?l=linux-omap&m=137510358229479&w=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 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
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
[...]
+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.
[1] http://marc.info/?t=13741659941&r=1&w=2
[2] http://marc.info/?l=linux-omap&m=137510358229479&w=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: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 > [...] >> # 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-omap&m=137456411706971&w=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: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 [...] # 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-omap&m=137456411706971&w=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 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
> [...]
+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=13741659941&r=1&w=2
>>> [2] http://marc.info/?l=linux-omap&m=137510358229479&w=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 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 >>> [...] # 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-omap&m=137456411706971&w=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 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
[...]
+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=13741659941&r=1&w=2
[2] http://marc.info/?l=linux-omap&m=137510358229479&w=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: Linux kernel for OMAP5432 uEVM
On Jul 30, 2013, at 8:24 PM, Nishanth Menon wrote: > On 07/30/2013 01:07 AM, Chen Baozi wrote: >> >> On Jul 30, 2013, at 11:52 AM, Lokesh Vutla 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-omap&m=137456411706971&w=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
>>
>> 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
>> Signed-off-by: Rajendra Nayak
>> Signed-off-by: Sourav Poddar
>> ---
>> 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";
>
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 [...] # 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-omap&m=137456411706971&w=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 05:56 PM, Nishanth Menon wrote: > On 07/30/2013 06:25 AM, Rajendra Nayak wrote: >> From: R Sricharan > [...] >> # 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-omap&m=137456411706971&w=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
Hi Lokesh & list, On Jul 30, 2013, at 11:52 AM, Lokesh Vutla 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 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
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
Signed-off-by: Rajendra Nayak
Signed-off-by: Sourav Poddar
---
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 = <&mcs
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 [...] # 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-omap&m=137456411706971&w=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
