* [PATCH V2 3/6] ARM: davinci: da850: add DT node for I2C0
From: Vishwanathrao Badarkhe, Manish @ 2013-01-29 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359445134-13323-1-git-send-email-manishv.b@ti.com>
Add I2C0 device tree node information to da850-evm.
Also, add I2C0 pin muxing information in da850-evm.
Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
---
Changes since V1:
- Updated i2c0 node names in dts and dtsi file.
- Removed interrupt parent from i2c0 node.
- Handled i2c0 pin mux inside i2c0 node.
:100644 100644 433027f... c9ed683... M arch/arm/boot/dts/da850-evm.dts
:100644 100644 5e0eb5c... 245ab9a... M arch/arm/boot/dts/da850.dtsi
arch/arm/boot/dts/da850-evm.dts | 5 +++++
arch/arm/boot/dts/da850.dtsi | 15 +++++++++++++++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 433027f..c9ed683 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -27,6 +27,11 @@
serial2: serial at 1d0d000 {
status = "okay";
};
+ i2c0: i2c0 at 1c22000 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ };
};
nand_cs3 at 62000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 5e0eb5c..245ab9a 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -56,6 +56,12 @@
0x30 0x01100000 0x0ff00000
>;
};
+ i2c0_pins: pinmux_i2c0_pins {
+ pinctrl-single,bits = <
+ /* I2C0_SDA,I2C0_SCL */
+ 0x10 0x00002200 0x0000ff00
+ >;
+ };
};
serial0: serial at 1c42000 {
compatible = "ns16550a";
@@ -81,6 +87,15 @@
interrupts = <61>;
status = "disabled";
};
+ i2c0: i2c0 at 1c22000 {
+ compatible = "ti,davinci-i2c";
+ reg = <0x22000 0x1000>;
+ clock-frequency = <100000>;
+ interrupts = <15>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
nand_cs3 at 62000000 {
compatible = "ti,davinci-nand";
--
1.7.4.1
^ permalink raw reply related
* [PATCH V2 2/6] ARM: davinci: da850: add OF_DEV_AUXDATA entry for I2C0
From: Vishwanathrao Badarkhe, Manish @ 2013-01-29 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359445134-13323-1-git-send-email-manishv.b@ti.com>
Add OF_DEV_AUXDATA for I2C0 controller driver in da850 board
dt file to use I2C0 clock.
Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
---
Changes since V1:
- updated name for auxdata lookup
da850_evm_auxdata_lookup -> da850_auxdata_lookup
:100644 100644 37c27af... 95ca4e9... M arch/arm/mach-davinci/da8xx-dt.c
arch/arm/mach-davinci/da8xx-dt.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 37c27af..95ca4e9 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -37,11 +37,17 @@ static void __init da8xx_init_irq(void)
of_irq_init(da8xx_irq_match);
}
+struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA("ti,davinci-i2c", 0x01c22000, "i2c_davinci.1", NULL),
+ {}
+};
+
#ifdef CONFIG_ARCH_DAVINCI_DA850
static void __init da850_init_machine(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ of_platform_populate(NULL, of_default_bus_match_table,
+ da850_auxdata_lookup, NULL);
da8xx_uart_clk_enable();
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH V2 1/6] pinctrl: pinctrl-single: use arch_initcall and module_exit
From: Vishwanathrao Badarkhe, Manish @ 2013-01-29 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359445134-13323-1-git-send-email-manishv.b@ti.com>
Currently, I2C driver gets probed before pinctrl driver.
To achieve I2C pin muxing via pinctrl driver before I2C
probe get called, register pinctrl driver in arch_initcall.
Also, add module_exit to unregister pinctrl driver.
Signed-off-by: Vishwanathrao Badarkhe, Manish <manishv.b@ti.com>
---
:100644 100644 f6a360b... 3a96390... M drivers/pinctrl/pinctrl-single.c
drivers/pinctrl/pinctrl-single.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index f6a360b..3a96390 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -1089,7 +1089,17 @@ static struct platform_driver pcs_driver = {
},
};
-module_platform_driver(pcs_driver);
+static int __init pcs_pinctrl_init(void)
+{
+ return platform_driver_register(&pcs_driver);
+}
+arch_initcall(pcs_pinctrl_init);
+
+static void __exit pcs_pinctrl_exit(void)
+{
+ platform_driver_unregister(&pcs_driver);
+}
+module_exit(pcs_pinctrl_exit);
MODULE_AUTHOR("Tony Lindgren <tony@atomide.com>");
MODULE_DESCRIPTION("One-register-per-pin type device tree based pinctrl driver");
--
1.7.4.1
^ permalink raw reply related
* [PATCH V2 0/6] davinci: DT support for i2c0 and tps6507x
From: Vishwanathrao Badarkhe, Manish @ 2013-01-29 7:38 UTC (permalink / raw)
To: linux-arm-kernel
This patch series enables device tree support for I2C0
and for regulator via tps6507x mfd device on da850-evm.
Applies on top of v3.8-rc5 of linus tree.
Tested on da850-evm device.
Test procedure followed as below:
Once device boots up, issue command as:
$for reg in /sys/class/regulator/*; do echo $reg `cat $reg/name`
`cat $reg/state` `cat $reg/microvolts`; done
Depends on:
- ARM: davinci: da850: add interrupt-parent property in soc node
https://patchwork.kernel.org/patch/2044101/
- ARM: davinci: da850: add pinctrl support
http://comments.gmane.org/gmane.linux.davinci/25993
Changes since V1:
- Updated i2c0 node name in da850 dts and dtsi file.
- Removed interrupt parent from i2c0 node.
- Updated name for da850 auxdata lookup.
- Added a patch in series to update pin control driver
registration.
Vishwanathrao Badarkhe, Manish (6):
pinctrl: pinctrl-single: use arch_initcall and module_exit
ARM: davinci: da850: add OF_DEV_AUXDATA entry for I2C0
ARM: davinci: da850: add DT node for I2C0
mfd: tps6507x: add device-tree support.
ARM: regulator: add tps6507x device tree data
ARM: davinci: da850: add tps6507x regulator DT data
arch/arm/boot/dts/da850-evm.dts | 68 ++++++++++++++++++++++++++++++++++++++
arch/arm/boot/dts/da850.dtsi | 15 ++++++++
arch/arm/boot/dts/tps6507x.dtsi | 47 ++++++++++++++++++++++++++
arch/arm/mach-davinci/da8xx-dt.c | 8 ++++-
drivers/mfd/tps6507x.c | 9 +++++
drivers/pinctrl/pinctrl-single.c | 12 ++++++-
6 files changed, 157 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/boot/dts/tps6507x.dtsi
--
1.7.4.1
^ permalink raw reply
* [PATCH 2/2] drivers: net:ethernet: cpsw: add support for VLAN
From: Richard Cochran @ 2013-01-29 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359403945-28585-3-git-send-email-mugunthanvnm@ti.com>
On Tue, Jan 29, 2013 at 01:42:25AM +0530, Mugunthan V N wrote:
> @@ -947,6 +1042,10 @@ static const struct net_device_ops cpsw_netdev_ops = {
> #ifdef CONFIG_NET_POLL_CONTROLLER
> .ndo_poll_controller = cpsw_ndo_poll_controller,
> #endif
> +#ifdef VLAN_SUPPORT
> + .ndo_vlan_rx_add_vid = cpsw_ndo_vlan_rx_add_vid,
> + .ndo_vlan_rx_kill_vid = cpsw_ndo_vlan_rx_kill_vid,
> +#endif
These are not compile time conditionals in net_device_ops, so I wonder
(after reading Felipe's comments) whether you can simply keep the VLAN
code always present.
As long as the driver still compiles and loads, when VLAN is missing
from the stack, then I don't see why you can't just leave it in,
without all the ifdefs.
Thanks,
Richard
^ permalink raw reply
* [PATCH V2] ARM: davinci: da850: add RTC DT entries
From: Katepallewar, Mrugesh @ 2013-01-29 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5106A105.6030004@ti.com>
On Mon, Jan 28, 2013 at 21:32:13, Nori, Sekhar wrote:
> Hi Mrugesh,
>
> On 1/28/2013 1:17 PM, Mrugesh Katepallewar wrote:
> > Add RTC DT entries in da850 dts file.
> >
> > Signed-off-by: Mrugesh Katepallewar <mrugesh.mk@ti.com>
> > ---
> > Applies on top of v3.8-rc4 of linus tree.
> >
> > This patch is depending on
> > "ARM: davinci: da850: add interrupt-parent property in soc node"
> > https://patchwork.kernel.org/patch/2044101/
>
> > Tested on da850-evm device.
> >
> > Test Procedure:
> > date 2013.01.28-10:00:00 (usage: date[YYYY.]MM.DD-hh:mm[:ss]) hwclock
> > -w reset board and check system time.
>
> Queuing this for v3.9. The testing information above is useful and should be part of the changelog. I moved it there while committing.
>
> It will be nice to check the alarm functionality as well. Can you check that and let me know that works as well?
I tried to test RTC alarm using "rtcwake" command, however it is not working and returning following error
"rtcwake: /dev/rtc0 not enabled for wakeup events"
This is coming because we have not registered RTC device as a wakeup source yet.
For checking RTC alarm interrupt, I developed one simple program which opens RTC device, set alarm and exits.
Then by entering "cat /proc/interrupts" checked RTC interrupt count.
Using above test it confirms that RTC alarm functionality is working fine.
>
> Thanks,
> Sekhar
>
Regards,
Mrugesh
^ permalink raw reply
* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: Richard Cochran @ 2013-01-29 7:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128142510.68092e10.akpm@linux-foundation.org>
On Mon, Jan 28, 2013 at 02:25:10PM -0800, Andrew Morton wrote:
>
> It's a lot of code for a 50ms boot-time improvement. Does anyone have
> any opinions on whether or not the benefits are worth the cost?
In the embedded space, quick boot is a really important feature to
have. Many people resort to awful hacks in order to improve boot time,
and so I would welcome this option.
I have seen arm systems that boot in 300 ms. I would say that 50 ms is
maybe not such a small improvement after all.
Thanks,
Richard
^ permalink raw reply
* [GIT PULL] imx cleanup for 3.9
From: Sascha Hauer @ 2013-01-29 7:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129010853.GA24352@S2101-09.ap.freescale.net>
On Tue, Jan 29, 2013 at 09:08:55AM +0800, Shawn Guo wrote:
> On Mon, Jan 28, 2013 at 02:00:26PM -0800, Olof Johansson wrote:
> > Hi,
> >
> > On Tue, Jan 22, 2013 at 10:48:15PM +0800, Shawn Guo wrote:
> >
> > > Shawn Guo (4):
> > > ARM: dts: imx: use nodes label in board dts
> >
> > Hmm.
> >
> > This patch is 1000 lines of pure churn. Sure, the style on OMAP is different,
> > but there's no clear benefit from it -- it's actually advantageous to see some
> > of the bus hierarchies even on the leaf-level board nodes.
> >
> > Would you mind respinning with this left out, please? If you still want to
> > argue it to be included, we can do so, but I'd like to pick up the rest of the
> > branch meanwhile. :-)
>
> I will refresh the pull-request to leave it out, but meanwhile I'd like
> to argue too, as the approach has been agreed by IMX people and all the
> patches I queued on imx/dt are all in this way. And I will move the
> patch to imx/dt branch instead, if you're not strongly against the
> approach.
>
> The board level dts are mostly used to add/overwrite properties for
> nodes defined in soc dts. Therefore, what people who look at board
> dts care about is those properties, not really which bus the nodes
> are on. We go this way to have board dts focus on the things they
> are created for. It's much easer to read and edit those properties.
>
> I'm not sure why it's important to maintain the bus topology in board
> dts while we have the full one in soc dts. In the current way, people
> sometimes have to reassemble 3 or more levels bus hierarchies for only
> overwriting one property for one node.
>
> I'm pretty sure that people who work on board level dts would vote for
> this way. It makes their life easier without increasing the
> maintainer's burden. So why not?
I'm with Shawn here. With this board layout I'm now able to write board
dts files without looking much at the dtsi file at all. It's debatable
if existing boards have to be changed to use this layout, but since
people copy-paste all the time changing it increases the chance they
copy the right stuff.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* backport patches to 2.6.34 to remove __ARCH_WANT_INTERRUPTS_ON_CTXSW?
From: Li Zefan @ 2013-01-29 7:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi Catalin,
We got system crashes, and then we managed to trigger the bug within minutes,
and we found this in upstream, which also backported to 2.6.34 stable:
commit cb297a3e433dbdcf7ad81e0564e7b804c941ff0d
Author: Chanho Min <chanho0207@gmail.com>
Date: Thu Jan 5 20:00:19 2012 +0900
sched/rt: Fix task stack corruption under __ARCH_WANT_INTERRUPTS_ON_CTXSW
The bug described in this commit resembles to ours. Unfortunately After applying
the fix, we still get crash in hours. We tried to bind each real-time task to a
single cpu to make sure no cpu migration will happen, and it ran without any
problem for ~20 hours.
We're still investigating this issue. One thing I'm doing is backporting patches
that removes __ARCH_WANT_INTERRUPTS_ON_CTXSW. With those patches, I can boot
the kernel, but it hung up when the system automatically start nfs and later
soft-lockup was reported. Things are fine if I disable nfs startup and start it
manually.
So did I miss something when backporting, or is it infeasible to backport them
to 2.6.34? We're using ARMv7. I've attached the patches I backported.
Thanks,
Li Zefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-Use-TTBR1-instead-of-reserved-context-ID.patch
Type: text/x-diff
Size: 3488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130129/eed6464f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-sched-arch-Introduce-the-finish_arch_post_lock_switc.patch
Type: text/x-diff
Size: 1733 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130129/eed6464f/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-ARM-Remove-__ARCH_WANT_INTERRUPTS_ON_CTXSW-on-ASID-c.patch
Type: text/x-diff
Size: 6790 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130129/eed6464f/attachment-0002.bin>
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Viresh Kumar @ 2013-01-29 7:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359410300-26113-2-git-send-email-arnd@arndb.de>
On 29 January 2013 03:28, Arnd Bergmann <arnd@arndb.de> wrote:
> The original device tree binding for this driver, from Viresh Kumar
> unfortunately conflicted with the generic DMA binding, and did not allow
> to completely seperate slave device configuration from the controller.
>
> This is an attempt to replace it with an implementation of the generic
> binding, but it is currently completely untested, because I do not have
> any hardware with this particular controller.
>
> The patch applies on top of linux-next, which contains both the base
> support for the generic DMA binding, as well as the earlier attempt from
> Viresh. Both of these are currently not merged upstream however.
This was really my work and i am feeling bad that i couldn't allocate any time
for it. Thanks for starting it.
> diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
> index 5bb3dfb..212d387 100644
> --- a/Documentation/devicetree/bindings/dma/snps-dma.txt
> +++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
> @@ -3,59 +3,62 @@
> Required properties:
> - compatible: "snps,dma-spear1340"
> - reg: Address range of the DMAC registers
> -- interrupt-parent: Should be the phandle for the interrupt controller
> - that services interrupts for this device
> - interrupt: Should contain the DMAC interrupt number
> -- nr_channels: Number of channels supported by hardware
> -- is_private: The device channels should be marked as private and not for by the
> - general purpose DMA channel allocator. False if not passed.
> +- dma-channels: Number of channels supported by hardware
> +- dma-requests: Number of DMA request lines supported
> +- dma-masters: Number of AHB masters supported by the controller
> +- #dma-cells: must be <3>
Shouldn't this be 4? Would be better to mention what fields are these,
right here.
I have seen them below though.
> +DMA clients connected to the Designware DMA controller must use the format
> +described in the dma.txt file, using a five-cell specifier for each channel.
> +The five cells in order are:
> +
> +1. A phandle pointing to the DMA controller
> +2. The value for the cfg_hi register.
> +3. The value for the cfg_lo register.
> +4. Source master for transfers on allocated channel.
> +5. Destination master for transfers on allocated channel.
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index 8cfaaf8..88504c2 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -18,6 +18,7 @@
> #include <linux/interrupt.h>
> #include <linux/io.h>
> #include <linux/of.h>
> +#include <linux/of_dma.h>
> #include <linux/mm.h>
> #include <linux/module.h>
> #include <linux/platform_device.h>
> @@ -1179,49 +1180,69 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
> dev_vdbg(chan2dev(chan), "%s: done\n", __func__);
> }
>
> -bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
> +/* forward declaration used in filter */
> +static struct platform_driver dw_driver;
extern? This is not a declaration but definition.
> +
> +struct dw_dma_filter_args {
> + struct dw_dma *dw;
> + u32 cfg_lo;
> + u32 cfg_hi;
> + unsigned src;
Currently named as sms
> + unsigned dst;
dms
> +};
> +
> +static bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
> {
> struct dw_dma *dw = to_dw_dma(chan->device);
> - static struct dw_dma *last_dw;
> - static char *last_bus_id;
> - int i = -1;
> + struct dw_dma_filter_args *fargs = param;
> + struct dw_dma_slave *sd;
>
> - /*
> - * dmaengine framework calls this routine for all channels of all dma
> - * controller, until true is returned. If 'param' bus_id is not
> - * registered with a dma controller (dw), then there is no need of
> - * running below function for all channels of dw.
> - *
> - * This block of code does this by saving the parameters of last
> - * failure. If dw and param are same, i.e. trying on same dw with
> - * different channel, return false.
> - */
> - if ((last_dw == dw) && (last_bus_id == param))
> + /* both the driver and the device must match */
> + if (chan->device->dev->driver != &dw_driver.driver)
> + return false;
Can this ever happen? Isn't it the case that this routine would be called
only for dw_dmac?
> + if (dw != fargs->dw)
> return false;
> - /*
> - * Return true:
> - * - If dw_dma's platform data is not filled with slave info, then all
> - * dma controllers are fine for transfer.
> - * - Or if param is NULL
> - */
> - if (!dw->sd || !param)
> - return true;
>
> - while (++i < dw->sd_count) {
> - if (!strcmp(dw->sd[i].bus_id, param)) {
> - chan->private = &dw->sd[i];
> - last_dw = NULL;
> - last_bus_id = NULL;
> + /* FIXME: memory leak! could we put this into dw_dma_chan? */
> + sd = devm_kzalloc(dw->dma.dev, sizeof (*sd), GFP_KERNEL);
Yes.
> + if (!sd)
> + return false;
>
> - return true;
> - }
> - }
> + sd->dma_dev = dw->dma.dev;
> + sd->cfg_hi = fargs->cfg_hi;
> + sd->cfg_lo = fargs->cfg_lo;
> + sd->src_master = fargs->src;
> + sd->dst_master = fargs->dst;
> +
> + chan->private = sd;
>
> - last_dw = dw;
> - last_bus_id = param;
> - return false;
> + return true;
> +}
> +
> +static struct dma_chan *dw_dma_xlate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct dw_dma *dw = ofdma->of_dma_data;
> + struct dw_dma_filter_args fargs = {
> + .dw = dw,
> + };
> + dma_cap_mask_t cap;
> +
> + if (dma_spec->args_count != 4)
args_count contains count of all params leaving the phandle?
> + return NULL;
> +
> + /* FIXME: This binding is rather clumsy. Can't we use the
> + request line numbers here instead? */
yes.
> + fargs.cfg_lo = be32_to_cpup(dma_spec->args+0);
> + fargs.cfg_hi = be32_to_cpup(dma_spec->args+1);
> + fargs.src = be32_to_cpup(dma_spec->args+2);
> + fargs.dst = be32_to_cpup(dma_spec->args+3);
> +
> + dma_cap_zero(cap);
> + dma_cap_set(DMA_SLAVE, cap);
> + /* FIXME: there should be a simpler way to do this */
> + return dma_request_channel(cap, dw_dma_generic_filter, &dma_spec->args[0]);
don't you need to send &fargs as the last argument?
^ permalink raw reply
* [PATCH 2/2] drivers: net:ethernet: cpsw: add support for VLAN
From: Felipe Balbi @ 2013-01-29 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51075881.4050200@ti.com>
Hi,
On Tue, Jan 29, 2013 at 10:35:05AM +0530, Mugunthan V N wrote:
> On 1/29/2013 2:14 AM, Felipe Balbi wrote:
> >On Tue, Jan 29, 2013 at 01:42:25AM +0530, Mugunthan V N wrote:
> >>adding support for VLAN interface for cpsw.
> >>
> >>CPSW VLAN Capability
> >>* Can filter VLAN packets in Hardware
> >>
> >>Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> >>---
> >> Documentation/devicetree/bindings/net/cpsw.txt | 2 +
> >> drivers/net/ethernet/ti/cpsw.c | 108 +++++++++++++++++++++++-
> >> include/linux/platform_data/cpsw.h | 1 +
> >> 3 files changed, 110 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
> >>index 6ddd028..99696bf 100644
> >>--- a/Documentation/devicetree/bindings/net/cpsw.txt
> >>+++ b/Documentation/devicetree/bindings/net/cpsw.txt
> >>@@ -24,6 +24,8 @@ Required properties:
> >> Optional properties:
> >> - ti,hwmods : Must be "cpgmac0"
> >> - no_bd_ram : Must be 0 or 1
> >>+- default_vlan : Specifies Default VLAN for non tagged packets
> >>+ ALE processing
> >> Note: "ti,hwmods" field is used to fetch the base address and irq
> >> resources from TI, omap hwmod data base during device registration.
> >>diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> >>index b35e6a7..dee6951 100644
> >>--- a/drivers/net/ethernet/ti/cpsw.c
> >>+++ b/drivers/net/ethernet/ti/cpsw.c
> >>@@ -32,6 +32,7 @@
> >> #include <linux/of.h>
> >> #include <linux/of_net.h>
> >> #include <linux/of_device.h>
> >>+#include <linux/if_vlan.h>
> >> #include <linux/platform_data/cpsw.h>
> >>@@ -72,6 +73,11 @@ do { \
> >> dev_notice(priv->dev, format, ## __VA_ARGS__); \
> >> } while (0)
> >>+#if defined(CONFIG_VLAN_8021Q) || defined(CONFIG_VLAN_8021Q_MODULE)
> >use IS_ENABLED() instead.
> Will change this in next patch version.
> >
> >>+#define VLAN_SUPPORT
> >>+#define CPSW_VLAN_AWARE_MODE
> >>+#endif
> >>+
> >> #define ALE_ALL_PORTS 0x7
> >> #define CPSW_MAJOR_VERSION(reg) (reg >> 8 & 0x7)
> >>@@ -118,6 +124,14 @@ do { \
> >> #define TX_PRIORITY_MAPPING 0x33221100
> >> #define CPDMA_TX_PRIORITY_MAP 0x76543210
> >>+#ifdef CPSW_VLAN_AWARE_MODE
> >>+#define CPSW_VLAN_AWARE BIT(1)
> >>+#define CPSW_ALE_VLAN_AWARE 1
> >>+#else
> >>+#define CPSW_VLAN_AWARE 0x0
> >>+#define CPSW_ALE_VLAN_AWARE 0
> >>+#endif
> >you should really figure out a way of doing runtime detection for this.
> >Depending on driver recompilation just to enable/disable VLAN support
> >will be quite boring.
> I am not able to find a way to know whether stack is compiled with
> VLAN support or not
> without using VLAN_SUPPORT compiler option. Only way is to hack
> cpsw_ndo_vlan_rx_add_vid
> and know whether stack has VLAN capability or not which is not advisable.
you could use a module parameter or pass data to the driver. In any
case, relying completely on compile-time choices isn't very nice.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130129/b52c5863/attachment-0001.sig>
^ permalink raw reply
* [PATCH 2/3] ARM: dts: mxs: Add muxing options for the third PWM
From: Shawn Guo @ 2013-01-29 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359104048-26823-3-git-send-email-maxime.ripard@free-electrons.com>
On Fri, Jan 25, 2013 at 09:54:06AM +0100, Maxime Ripard wrote:
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Applied, thanks.
> ---
> arch/arm/boot/dts/imx28.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
> index 13b7053..7ba4966 100644
> --- a/arch/arm/boot/dts/imx28.dtsi
> +++ b/arch/arm/boot/dts/imx28.dtsi
> @@ -502,6 +502,16 @@
> fsl,pull-up = <0>;
> };
>
> + pwm3_pins_b: pwm3 at 1 {
> + reg = <1>;
> + fsl,pinmux-ids = <
> + 0x3141 /* MX28_PAD_SAIF0_MCLK__PWM3 */
> + >;
> + fsl,drive-strength = <0>;
> + fsl,voltage = <1>;
> + fsl,pull-up = <0>;
> + };
> +
> pwm4_pins_a: pwm4 at 0 {
> reg = <0>;
> fsl,pinmux-ids = <
> --
> 1.7.10.4
>
^ permalink raw reply
* [PATCH v2 9/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
From: Vaibhav Bedia @ 2013-01-29 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359442762-13697-1-git-send-email-vaibhav.bedia@ti.com>
Add minimal APIs for writing to the IPC and the M3_TXEV registers
in the Control module. These will be used in a subsequent patch which
adds suspend-resume support for AM33XX.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
v2: No change
arch/arm/mach-omap2/control.c | 20 ++++++++++++++++++++
arch/arm/mach-omap2/control.h | 41 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 61 insertions(+)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 2adb268..c5d54ae 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -604,3 +604,23 @@ int omap3_ctrl_save_padconf(void)
}
#endif /* CONFIG_ARCH_OMAP3 && CONFIG_PM */
+
+#if defined(CONFIG_SOC_AM33XX) && defined(CONFIG_PM)
+void am33xx_txev_eoi(void)
+{
+ omap_ctrl_writel(AM33XX_M3_TXEV_ACK, AM33XX_CONTROL_M3_TXEV_EOI);
+}
+
+void am33xx_txev_enable(void)
+{
+ omap_ctrl_writel(AM33XX_M3_TXEV_ENABLE, AM33XX_CONTROL_M3_TXEV_EOI);
+}
+
+void am33xx_wkup_m3_ipc_cmd(struct am33xx_ipc_data *data)
+{
+ omap_ctrl_writel(data->resume_addr, AM33XX_CONTROL_IPC_MSG_REG0);
+ omap_ctrl_writel(data->sleep_mode, AM33XX_CONTROL_IPC_MSG_REG1);
+ omap_ctrl_writel(data->param1, AM33XX_CONTROL_IPC_MSG_REG2);
+ omap_ctrl_writel(data->param2, AM33XX_CONTROL_IPC_MSG_REG3);
+}
+#endif /* CONFIG_SOC_AM33XX && CONFIG_PM */
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index e6c3281..cb85f0a 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -358,6 +358,37 @@
#define AM33XX_CONTROL_STATUS_SYSBOOT1_WIDTH 0x2
#define AM33XX_CONTROL_STATUS_SYSBOOT1_MASK (0x3 << 22)
+#define AM33XX_DDR_IO_CTRL 0x0E04
+#define AM33XX_VTP0_CTRL_REG 0x0E0C
+
+/* AM33XX VTP0_CTRL_REG bits */
+#define AM33XX_VTP_CTRL_START_EN (1 << 0)
+#define AM33XX_VTP_CTRL_LOCK_EN (1 << 4)
+#define AM33XX_VTP_CTRL_READY (1 << 5)
+#define AM33XX_VTP_CTRL_ENABLE (1 << 6)
+
+/* AM33XX M3_TXEV_EOI register */
+#define AM33XX_CONTROL_M3_TXEV_EOI 0x1324
+
+#define AM33XX_M3_TXEV_ACK (0x1 << 0)
+#define AM33XX_M3_TXEV_ENABLE (0x0 << 0)
+
+/* AM33XX IPC message registers */
+#define AM33XX_CONTROL_IPC_MSG_REG0 0x1328
+#define AM33XX_CONTROL_IPC_MSG_REG1 0x132C
+#define AM33XX_CONTROL_IPC_MSG_REG2 0x1330
+#define AM33XX_CONTROL_IPC_MSG_REG3 0x1334
+#define AM33XX_CONTROL_IPC_MSG_REG4 0x1338
+#define AM33XX_CONTROL_IPC_MSG_REG5 0x133C
+#define AM33XX_CONTROL_IPC_MSG_REG6 0x1340
+#define AM33XX_CONTROL_IPC_MSG_REG7 0x1344
+
+#define AM33XX_DDR_CMD0_IOCTRL 0x1404
+#define AM33XX_DDR_CMD1_IOCTRL 0x1408
+#define AM33XX_DDR_CMD2_IOCTRL 0x140C
+#define AM33XX_DDR_DATA0_IOCTRL 0x1440
+#define AM33XX_DDR_DATA1_IOCTRL 0x1444
+
/* CONTROL OMAP STATUS register to identify OMAP3 features */
#define OMAP3_CONTROL_OMAP_STATUS 0x044c
@@ -417,6 +448,16 @@ extern void omap3630_ctrl_disable_rta(void);
extern int omap3_ctrl_save_padconf(void);
extern void omap2_set_globals_control(void __iomem *ctrl,
void __iomem *ctrl_pad);
+struct am33xx_ipc_data {
+ u32 resume_addr;
+ u32 param1;
+ u32 param2;
+ u32 sleep_mode;
+};
+extern void am33xx_wkup_m3_ipc_cmd(struct am33xx_ipc_data *data);
+extern void am33xx_txev_eoi(void);
+extern void am33xx_txev_enable(void);
+
#else
#define omap_ctrl_base_get() 0
#define omap_ctrl_readb(x) 0
--
1.8.1
^ permalink raw reply related
* [PATCH v2 8/9] ARM: DTS: AM33XX: Add nodes for OCMC RAM and WKUP-M3
From: Vaibhav Bedia @ 2013-01-29 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359442762-13697-1-git-send-email-vaibhav.bedia@ti.com>
Since AM33XX supports only DT-boot, this is needed
for the appropriate device nodes to be created.
Note: OCMC RAM is part of the PER power domain and supports
retention. The assembly code for low power entry/exit will
run from OCMC RAM. To ensure that the OMAP PM code does not
attempt to disable the clock to OCMC RAM as part of the
suspend process add the no_idle_on_suspend flag.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
v2: Add reg property
arch/arm/boot/dts/am33xx.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index c2f14e8..423f898 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -385,5 +385,19 @@
mac-address = [ 00 00 00 00 00 00 ];
};
};
+
+ ocmcram: ocmcram at 40300000 {
+ compatible = "ti,ocmcram";
+ reg = <0x40300000 0x10000>;
+ ti,hwmods = "ocmcram";
+ ti,no_idle_on_suspend;
+ };
+
+ wkup_m3: wkup_m3 at 44d00000 {
+ compatible = "ti,wkup_m3";
+ reg = <0x44d00000 0x4000 /* M3 UMEM */
+ 0x44d80000 0x2000>; /* M3 DMEM */
+ ti,hwmods = "wkup_m3";
+ };
};
};
--
1.8.1
^ permalink raw reply related
* [PATCH v2 7/9] ARM: OMAP2+: AM33XX: Update the hardreset API
From: Vaibhav Bedia @ 2013-01-29 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359442762-13697-1-git-send-email-vaibhav.bedia@ti.com>
WKUP-M3 has a reset status bit (RM_WKUP_STST.WKUP_M3_LRST)
Update the hardreset API to ensure that the reset line properly
deasserted.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
v2: No change
arch/arm/mach-omap2/omap_hwmod.c | 5 +----
arch/arm/mach-omap2/prm33xx.c | 11 +++++++----
arch/arm/mach-omap2/prm33xx.h | 2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 4653efb..6549439 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3041,11 +3041,8 @@ static int _am33xx_assert_hardreset(struct omap_hwmod *oh,
static int _am33xx_deassert_hardreset(struct omap_hwmod *oh,
struct omap_hwmod_rst_info *ohri)
{
- if (ohri->st_shift)
- pr_err("omap_hwmod: %s: %s: hwmod data error: OMAP4 does not support st_shift\n",
- oh->name, ohri->name);
-
return am33xx_prm_deassert_hardreset(ohri->rst_shift,
+ ohri->st_shift,
oh->clkdm->pwrdm.ptr->prcm_offs,
oh->prcm.omap4.rstctrl_offs,
oh->prcm.omap4.rstst_offs);
diff --git a/arch/arm/mach-omap2/prm33xx.c b/arch/arm/mach-omap2/prm33xx.c
index 1ac7388..44c0d72 100644
--- a/arch/arm/mach-omap2/prm33xx.c
+++ b/arch/arm/mach-omap2/prm33xx.c
@@ -110,11 +110,11 @@ int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs)
* -EINVAL upon an argument error, -EEXIST if the submodule was already out
* of reset, or -EBUSY if the submodule did not exit reset promptly.
*/
-int am33xx_prm_deassert_hardreset(u8 shift, s16 inst,
+int am33xx_prm_deassert_hardreset(u8 shift, u8 st_shift, s16 inst,
u16 rstctrl_offs, u16 rstst_offs)
{
int c;
- u32 mask = 1 << shift;
+ u32 mask = 1 << st_shift;
/* Check the current status to avoid de-asserting the line twice */
if (am33xx_prm_is_hardreset_asserted(shift, inst, rstctrl_offs) == 0)
@@ -122,11 +122,14 @@ int am33xx_prm_deassert_hardreset(u8 shift, s16 inst,
/* Clear the reset status by writing 1 to the status bit */
am33xx_prm_rmw_reg_bits(0xffffffff, mask, inst, rstst_offs);
+
/* de-assert the reset control line */
+ mask = 1 << shift;
+
am33xx_prm_rmw_reg_bits(mask, 0, inst, rstctrl_offs);
- /* wait the status to be set */
- omap_test_timeout(am33xx_prm_is_hardreset_asserted(shift, inst,
+ /* wait the status to be set */
+ omap_test_timeout(am33xx_prm_is_hardreset_asserted(st_shift, inst,
rstst_offs),
MAX_MODULE_HARDRESET_WAIT, c);
diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h
index 1c40373..9b9918d 100644
--- a/arch/arm/mach-omap2/prm33xx.h
+++ b/arch/arm/mach-omap2/prm33xx.h
@@ -125,7 +125,7 @@ extern void am33xx_prm_global_warm_sw_reset(void);
extern int am33xx_prm_is_hardreset_asserted(u8 shift, s16 inst,
u16 rstctrl_offs);
extern int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs);
-extern int am33xx_prm_deassert_hardreset(u8 shift, s16 inst,
+extern int am33xx_prm_deassert_hardreset(u8 shift, u8 st_shift, s16 inst,
u16 rstctrl_offs, u16 rstst_offs);
#endif /* ASSEMBLER */
#endif
--
1.8.1
^ permalink raw reply related
* [PATCH v2 6/9] ARM: OMAP2+: AM33XX: hwmod: Update the WKUP-M3 hwmod with reset status bit
From: Vaibhav Bedia @ 2013-01-29 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359442762-13697-1-git-send-email-vaibhav.bedia@ti.com>
WKUP-M3 has a reset status bit (RM_WKUP_STST.WKUP_M3_LRST)
Update the WKUP-M3 hwmod data to reflect the same.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
---
v2: No change
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 40bfde3..9e34d4c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -269,6 +269,7 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
.omap4 = {
.clkctrl_offs = AM33XX_CM_WKUP_WKUP_M3_CLKCTRL_OFFSET,
.rstctrl_offs = AM33XX_RM_WKUP_RSTCTRL_OFFSET,
+ .rstst_offs = AM33XX_RM_WKUP_RSTST_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
},
},
--
1.8.1
^ permalink raw reply related
* [PATCH v2 5/9] ARM: OMAP2+: AM33XX: hwmod: Fixup cpgmac0 hwmod entry
From: Vaibhav Bedia @ 2013-01-29 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359442762-13697-1-git-send-email-vaibhav.bedia@ti.com>
The current HWMOD code expects the memory region with
the IP's SYSCONFIG register to be marked with ADDR_TYPE_RT
flag.
CPGMAC0 hwmod entry specifies two memory regions and marks
both with the flag ADDR_TYPE_RT although only the 2nd region
has the SYSCONFIG register. This leads to the HWMOD code
accessing the wrong memory address for idle and standby
operations. Fix this by removing the ADDR_TYPE_RT flag from
the 1st memory region in CPGMAC0 hwmod entry.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
---
v2: No change
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 94254e8..40bfde3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -2496,7 +2496,6 @@ static struct omap_hwmod_addr_space am33xx_cpgmac0_addr_space[] = {
{
.pa_start = 0x4a100000,
.pa_end = 0x4a100000 + SZ_2K - 1,
- .flags = ADDR_TYPE_RT,
},
/* cpsw wr */
{
--
1.8.1
^ permalink raw reply related
* [PATCH v2 4/9] ARM: OMAP2+: AM33XX: hwmod: Update TPTC0 hwmod with the right flags
From: Vaibhav Bedia @ 2013-01-29 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359442762-13697-1-git-send-email-vaibhav.bedia@ti.com>
Third Party Transfer Controller (TPTC0) needs to be idled and
put to standby under SW control. Add the appropriate flags in
the TPTC0 hwmod entry.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
v2: Drop unnecessary parens
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 8280f11..94254e8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1823,6 +1823,7 @@ static struct omap_hwmod am33xx_tptc0_hwmod = {
.class = &am33xx_tptc_hwmod_class,
.clkdm_name = "l3_clkdm",
.mpu_irqs = am33xx_tptc0_irqs,
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = "l3_gclk",
.prcm = {
.omap4 = {
--
1.8.1
^ permalink raw reply related
* [PATCH v2 3/9] ARM: OMAP2+: AM33XX: hwmod: Register OCMC RAM hwmod
From: Vaibhav Bedia @ 2013-01-29 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359442762-13697-1-git-send-email-vaibhav.bedia@ti.com>
OCMC RAM lies in the PER power domain and this memory
support retention.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
v2: No change
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 47 +++++++++++++++++-------------
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 646c14d..8280f11 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -414,7 +414,6 @@ static struct omap_hwmod am33xx_adc_tsc_hwmod = {
* - cEFUSE (doesn't fall under any ocp_if)
* - clkdiv32k
* - debugss
- * - ocmc ram
* - ocp watch point
* - aes0
* - sha0
@@ -481,25 +480,6 @@ static struct omap_hwmod am33xx_debugss_hwmod = {
},
};
-/* ocmcram */
-static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = {
- .name = "ocmcram",
-};
-
-static struct omap_hwmod am33xx_ocmcram_hwmod = {
- .name = "ocmcram",
- .class = &am33xx_ocmcram_hwmod_class,
- .clkdm_name = "l3_clkdm",
- .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
- .main_clk = "l3_gclk",
- .prcm = {
- .omap4 = {
- .clkctrl_offs = AM33XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
-};
-
/* ocpwp */
static struct omap_hwmod_class am33xx_ocpwp_hwmod_class = {
.name = "ocpwp",
@@ -570,6 +550,25 @@ static struct omap_hwmod am33xx_sha0_hwmod = {
#endif
+/* ocmcram */
+static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = {
+ .name = "ocmcram",
+};
+
+static struct omap_hwmod am33xx_ocmcram_hwmod = {
+ .name = "ocmcram",
+ .class = &am33xx_ocmcram_hwmod_class,
+ .clkdm_name = "l3_clkdm",
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
+ .main_clk = "l3_gclk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM33XX_CM_PER_OCMCRAM_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
/* 'smartreflex' class */
static struct omap_hwmod_class am33xx_smartreflex_hwmod_class = {
.name = "smartreflex",
@@ -3328,6 +3327,13 @@ static struct omap_hwmod_ocp_if am33xx_l3_s__usbss = {
.flags = OCPIF_SWSUP_IDLE,
};
+/* l3 main -> ocmc */
+static struct omap_hwmod_ocp_if am33xx_l3_main__ocmc = {
+ .master = &am33xx_l3_main_hwmod,
+ .slave = &am33xx_ocmcram_hwmod,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
&am33xx_l4_fw__emif_fw,
&am33xx_l3_main__emif,
@@ -3398,6 +3404,7 @@ static struct omap_hwmod_ocp_if *am33xx_hwmod_ocp_ifs[] __initdata = {
&am33xx_l3_main__tptc0,
&am33xx_l3_main__tptc1,
&am33xx_l3_main__tptc2,
+ &am33xx_l3_main__ocmc,
&am33xx_l3_s__usbss,
&am33xx_l4_hs__cpgmac0,
&am33xx_cpgmac0__mdio,
--
1.8.1
^ permalink raw reply related
* [PATCH v2 2/9] ARM: OMAP2+: AM33XX: CM/PRM: Use __ASSEMBLER__ macros in header files
From: Vaibhav Bedia @ 2013-01-29 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359442762-13697-1-git-send-email-vaibhav.bedia@ti.com>
This is necessary to ensure that macros declared here can
be reused from assembly files.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
v2: No change
arch/arm/mach-omap2/cm33xx.h | 2 ++
arch/arm/mach-omap2/prm33xx.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h
index 8009e13..64f4baf 100644
--- a/arch/arm/mach-omap2/cm33xx.h
+++ b/arch/arm/mach-omap2/cm33xx.h
@@ -376,6 +376,7 @@
#define AM33XX_CM_CEFUSE_CEFUSE_CLKCTRL AM33XX_CM_REGADDR(AM33XX_CM_CEFUSE_MOD, 0x0020)
+#ifndef __ASSEMBLER__
extern bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs);
extern void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs);
extern void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs);
@@ -412,4 +413,5 @@ static inline int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs,
}
#endif
+#endif /* ASSEMBLER */
#endif
diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h
index 3f25c56..1c40373 100644
--- a/arch/arm/mach-omap2/prm33xx.h
+++ b/arch/arm/mach-omap2/prm33xx.h
@@ -117,6 +117,7 @@
#define AM33XX_PM_CEFUSE_PWRSTST_OFFSET 0x0004
#define AM33XX_PM_CEFUSE_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_CEFUSE_MOD, 0x0004)
+#ifndef __ASSEMBLER__
extern u32 am33xx_prm_read_reg(s16 inst, u16 idx);
extern void am33xx_prm_write_reg(u32 val, s16 inst, u16 idx);
extern u32 am33xx_prm_rmw_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx);
@@ -126,4 +127,5 @@ extern int am33xx_prm_is_hardreset_asserted(u8 shift, s16 inst,
extern int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs);
extern int am33xx_prm_deassert_hardreset(u8 shift, s16 inst,
u16 rstctrl_offs, u16 rstst_offs);
+#endif /* ASSEMBLER */
#endif
--
1.8.1
^ permalink raw reply related
* [PATCH v2 1/9] ARM: OMAP2+: AM33XX: CM: Get rid of unnecessary header inclusions
From: Vaibhav Bedia @ 2013-01-29 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359442762-13697-1-git-send-email-vaibhav.bedia@ti.com>
cm33xx.h unnecessarily includes a lot of header files.
Get rid of these and directly include "iomap.h" which
is needed to keep things compiling.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
v2: Reword the changelog
arch/arm/mach-omap2/cm33xx.h | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h
index 5fa0b62..8009e13 100644
--- a/arch/arm/mach-omap2/cm33xx.h
+++ b/arch/arm/mach-omap2/cm33xx.h
@@ -17,16 +17,11 @@
#ifndef __ARCH_ARM_MACH_OMAP2_CM_33XX_H
#define __ARCH_ARM_MACH_OMAP2_CM_33XX_H
-#include <linux/delay.h>
-#include <linux/errno.h>
-#include <linux/err.h>
-#include <linux/io.h>
-
#include "common.h"
#include "cm.h"
#include "cm-regbits-33xx.h"
-#include "cm33xx.h"
+#include "iomap.h"
/* CM base address */
#define AM33XX_CM_BASE 0x44e00000
--
1.8.1
^ permalink raw reply related
* [PATCH v2 0/9] ARM: OMAP2+: AM33XX: Misc fixes/updates
From: Vaibhav Bedia @ 2013-01-29 6:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The following patches were earlier posted as part the AM33XX
suspend-resume support series [1]. Based on the suggestion
from Santosh Shilimkar <santosh.shilimkar@ti.com> i have split
out the changes which update the various data files related
to AM33XX support. This version addresses the comments
received from Sergei Shtylyov and Peter Korsgaard on the earlier
patchset [2].
These patches apply on top of v3.8-rc5
Regards,
Vaibhav
[1] http://marc.info/?l=linux-arm-kernel&m=135698501821074&w=2
[2] http://marc.info/?l=linux-omap&m=135849360005657&w=2
Vaibhav Bedia (9):
ARM: OMAP2+: AM33XX: CM: Get rid of unnecessary header inclusions
ARM: OMAP2+: AM33XX: CM/PRM: Use __ASSEMBLER__ macros in header files
ARM: OMAP2+: AM33XX: hwmod: Register OCMC RAM hwmod
ARM: OMAP2+: AM33XX: hwmod: Update TPTC0 hwmod with the right flags
ARM: OMAP2+: AM33XX: hwmod: Fixup cpgmac0 hwmod entry
ARM: OMAP2+: AM33XX: hwmod: Update the WKUP-M3 hwmod with reset status
bit
ARM: OMAP2+: AM33XX: Update the hardreset API
ARM: DTS: AM33XX: Add nodes for OCMC RAM and WKUP-M3
ARM: OMAP2+: AM33XX: control: Add some control module registers and
APIs
arch/arm/boot/dts/am33xx.dtsi | 14 +++++++++
arch/arm/mach-omap2/cm33xx.h | 9 ++----
arch/arm/mach-omap2/control.c | 20 ++++++++++++
arch/arm/mach-omap2/control.h | 41 ++++++++++++++++++++++++
arch/arm/mach-omap2/omap_hwmod.c | 5 +--
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 50 +++++++++++++++++-------------
arch/arm/mach-omap2/prm33xx.c | 11 ++++---
arch/arm/mach-omap2/prm33xx.h | 4 ++-
8 files changed, 118 insertions(+), 36 deletions(-)
--
1.8.1
^ permalink raw reply
* [PATCH v3 0/3] introduce static_vm for ARM-specific static mapped area
From: Joonsoo Kim @ 2013-01-29 6:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301281300250.6300@xanadu.home>
On Mon, Jan 28, 2013 at 01:04:24PM -0500, Nicolas Pitre wrote:
> On Mon, 28 Jan 2013, Will Deacon wrote:
>
> > Hello,
> >
> > On Thu, Jan 24, 2013 at 01:28:51AM +0000, Joonsoo Kim wrote:
> > > In current implementation, we used ARM-specific flag, that is,
> > > VM_ARM_STATIC_MAPPING, for distinguishing ARM specific static mapped area.
> > > The purpose of static mapped area is to re-use static mapped area when
> > > entire physical address range of the ioremap request can be covered
> > > by this area.
> > >
> > > This implementation causes needless overhead for some cases.
> > > For example, assume that there is only one static mapped area and
> > > vmlist has 300 areas. Every time we call ioremap, we check 300 areas for
> > > deciding whether it is matched or not. Moreover, even if there is
> > > no static mapped area and vmlist has 300 areas, every time we call
> > > ioremap, we check 300 areas in now.
> > >
> > > If we construct a extra list for static mapped area, we can eliminate
> > > above mentioned overhead.
> > > With a extra list, if there is one static mapped area,
> > > we just check only one area and proceed next operation quickly.
> > >
> > > In fact, it is not a critical problem, because ioremap is not frequently
> > > used. But reducing overhead is better idea.
> > >
> > > Another reason for doing this work is for removing vm_struct list management,
> > > entirely. For more information, look at the following link.
> > > http://lkml.org/lkml/2012/12/6/184
> >
> > First patch looks good (removing the unused vmregion stuff) but I'm not so
> > sure about the rest of it. If you really care about ioremap performance,
> > perhaps it would be better to have a container struct around the vm_struct
> > for static mappings and then stick them in an augmented rbtree so you can
> > efficiently find the mapping encompassing a particular physical address?
>
> How can ioremap performance be a problem is the question I had since the
> beginning.
>
> Firstly, ioremap is _not_ meant to be used in performance critical
> paths.
>
> Secondly, there shouldn't be _that_ many entries on the vmlist such as
> 300. That sounds a bit excessive.
>
> So please, can we discuss the reasons that motivated those patches in
> the first place? Maybe that's where the actual problem is.
Hello, Wiil and Nicolas.
First of all, thanks for reviewing.
There is another reason for doing this work.
As mentioned above, I try to remove list management for vm_struct(vmlist),
entirely. For that purpose, removing architecture dependency against vmlist
is needed. Below link is for my RFC patch trying to remove list management
for vm_struct.
http://lkml.org/lkml/2012/12/6/184
Removing dependency for other architectures is rather trivial, but for ARM,
it is not trivial case. So I prepared this patchset.
My description makes you missleading possibly.
Sorry for this.
Answer for your other questions is below.
I know ioremap is _not_ meant to be used in performance critical paths, and
I mentioned it earlier.
"In fact, it is not a critical problem, because ioremap is not frequently used.
But reducing overhead is better idea."
And, there are many entries on the vmlist for my test devices(Android phone).
I saw more than 300 entries in former days, but today, I re-check it and
find 230~250 entries.
Thanks.
^ permalink raw reply
* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Andrew Lunn @ 2013-01-29 6:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128182818.GC9436@obsidianresearch.com>
On Mon, Jan 28, 2013 at 11:28:18AM -0700, Jason Gunthorpe wrote:
> On Sun, Jan 27, 2013 at 03:53:53PM +0100, Sebastian Hesselbarth wrote:
>
> > I just want Simon to confirm that Kirkwood's gbe is really loosing the
> > contents of its MAC address registers during gated clocks, which is from
> > a HW point of view very unlikely.
>
> FWIW, there are two block power management controls on the kirkwood
> chips, one is documented to a clock gate, and one is documented to a
> be a power down.
Hi Jason
Are you referring to
Memory Power Management Control Register
Offset: 0x20118
Bit Field Type / Init Val Description
0 GE0_Mem_PD RW GbE0 Memory Power Down:
0x0 0 = Functional
1 = PowerDown
1 PEX0_Mem_PD RW PCI Express0 Memory Power Down;
0x0 0 = Functional
1 = PowerDown
2 USB0_Mem_PD RW USB0 Memory Power Down:
0x0 0 = Functional
1 = PowerDown
etc.
> I wouldn't expect the clock gate to have a problem
> with the MAC address, but the powerdown I would expect to wipe it..
As far as i know, we don't touch it. However, as a debug exercise, it
would be good to print its value at boot, at ethernet driver load
time, after unused clocks are disabled, when the ethernet clock is
enabled by the driver, etc.
Andrew
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: Santosh Shilimkar @ 2013-01-29 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5107114C.4070307@linaro.org>
Jon,
On Tuesday 29 January 2013 05:31 AM, John Stultz wrote:
> On 01/27/2013 10:08 PM, Santosh Shilimkar wrote:
>> On Tuesday 22 January 2013 08:35 PM, Santosh Shilimkar wrote:
>>> On Tuesday 22 January 2013 08:21 PM, Russell King - ARM Linux wrote:
>>>> On Tue, Jan 22, 2013 at 03:44:03PM +0530, Santosh Shilimkar wrote:
[..]
>>> Thanks for expanding it. It is really helpful.
>>>
>>>> And I think further discussion is pointless until such research has
>>>> been
>>>> done (or someone who _really_ knows the time keeping/timer/sched code
>>>> inside out comments.)
>>>>
>>> Fully agree about experimentation to re-asses the drift.
>>> From what I recollect from past, few OMAP customers did
>>> report the time drift issue and that is how the switch
>>> from 100 --> 128 happened.
>>>
>>> Anyway I have added the suggested task to my long todo list.
>>>
>> So I tried to see if any time drift with HZ = 100 on OMAP. I ran the
>> setup for 62 hours and 27 mins with time synced up once with NTP server.
>> I measure about ~174 millisecond drift which is almost noise considering
>> the observed duration was ~224820000 milliseconds.
>
> So 174ms drift doesn't sound great, as < 2ms (often much less - though
> that depends on how close the server is) can be expected with NTP.
> Although its not clear how you were measuring: Did you see a max 174ms
> offset while trying to sync with NTP? Was that offset shortly after
> starting NTP or after NTP converged down?
>
To avoid the server latency, we didn't do continuous sync. The time was
synced in the beginning and after 62.5 hours (#ntpd -qg) and the drift
of about 174 ms was observed. As you said this could be because of
server sync time along with probably some addition from system calls
from #ntpd. As mentioned, the other run with HZ = 128 which started
15 hours 20 mins is already showing about 24 mS drift now. I will
let it run for couple of more days just to have similar duration run.
Regards,
santosh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox