* [PATCH 2/2] i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207
From: Shubhrajyoti D @ 2012-11-02 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351852785-16961-1-git-send-email-shubhrajyoti@ti.com>
The errata i207 is enabled for 2430 and 3xxx. Use the revision check
to enable the erratum instead.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/i2c/busses/i2c-omap.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d8e7709..44245d4 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1164,7 +1164,8 @@ omap_i2c_probe(struct platform_device *pdev)
dev->errata = 0;
- if (dev->flags & OMAP_I2C_FLAG_APPLY_ERRATA_I207)
+ if (dev->rev >= OMAP_I2C_REV_ON_2430 &&
+ dev->rev < OMAP_I2C_REV_ON_4430_PLUS)
dev->errata |= I2C_OMAP_ERRATA_I207;
if (dev->rev <= OMAP_I2C_REV_ON_3430_3530)
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
From: Jon Hunter @ 2012-11-02 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351794970-14675-5-git-send-email-zonque@gmail.com>
Hi Daniel,
On 11/01/2012 01:36 PM, Daniel Mack wrote:
> This patch adds basic DT bindings for OMAP GPMC.
>
> The actual peripherals are instanciated from child nodes within the GPMC
> node, and the only type of device that is currently supported is NAND.
>
> Code was added to parse the generic GPMC timing parameters and some
> documentation with examples on how to use them.
>
> Successfully tested on an AM33xx board.
>
> Signed-off-by: Daniel Mack <zonque@gmail.com>
> ---
> Documentation/devicetree/bindings/bus/ti-gpmc.txt | 73 +++++++++++
> .../devicetree/bindings/mtd/gpmc-nand.txt | 61 +++++++++
> arch/arm/mach-omap2/gpmc.c | 139 +++++++++++++++++++++
> 3 files changed, 273 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
> create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
> new file mode 100644
> index 0000000..6f44487
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
> @@ -0,0 +1,73 @@
> +Device tree bindings for OMAP general purpose memory controllers (GPMC)
> +
> +The actual devices are instantiated from the child nodes of a GPMC node.
> +
> +Required properties:
> +
> + - compatible: Should be set to "ti,gpmc"
> + - reg: A resource specifier for the register space
> + (see the example below)
> + - ti,hwmods: Should be set to "ti,gpmc" until the DT transition is
> + completed.
> + - #address-cells: Must be set to 2 to allow memory address translation
> + - #size-cells: Must be set to 1 to allow CS address passing
> + - ranges: Must be set up to reflect the memory layout
> + Note that this property is not currently parsed.
> + Calculated values derived from the contents of
> + GPMC_CS_CONFIG7 as set up by the bootloader. That will
> + change in the future, so be sure to fill the correct
> + values here.
I still think it would be good to add number of chip-selects and
wait-pins here.
> +Timing properties for child nodes. All are optional and default to 0.
> +
> + - gpmc,sync-clk: Minimum clock period for synchronous mode, in picoseconds
> +
> + Chip-select signal timings corresponding to GPMC_CS_CONFIG2:
> + - gpmc,cs-on: Assertion time
> + - gpmc,cs-rd-off: Read deassertion time
> + - gpmc,cs-wr-off: Write deassertion time
> +
> + ADV signal timings corresponding to GPMC_CONFIG3:
> + - gpmc,adv-on: Assertion time
> + - gpmc,adv-rd-off: Read deassertion time
> + - gpmc,adv-wr-off: Write deassertion time
Nit-pick, looks like you are mixing GPMC_CS_CONFIGx and GPMC_CONFIGx
naming conventions in the above and below. Would be good to make this
consistent.
> +
> + WE signals timings corresponding to GPMC_CONFIG4:
> + - gpmc,we-on: Assertion time
> + - gpmc,we-off: Deassertion time
> +
> + OE signals timings corresponding to GPMC_CONFIG4
> + - gpmc,oe-on: Assertion time
> + - gpmc,oe-off: Deassertion time
> +
> + Access time and cycle time timings corresponding to GPMC_CONFIG5
> + - gpmc,page-burst-access: Multiple access word delay
> + - gpmc,access: Start-cycle to first data valid delay
> + - gpmc,rd-cycle: Total read cycle time
> + - gpmc,wr-cycle: Total write cycle time
> +
> +The following are only on OMAP3430
> + - gpmc,wr-access
> + - gpmc,wr-data-mux-bus
> +
> +
> +Example for an AM33xx board:
> +
> + gpmc: gpmc at 50000000 {
> + compatible = "ti,gpmc";
> + ti,hwmods = "gpmc";
> + reg = <0x50000000 0x2000>;
> + interrupt-parent = <&intc>;
We should drop interrupt-parent. We are declaring the interrupt-parent
globally in the dts files and so no need to replicate in each individual
binding.
> + interrupts = <100>;
> +
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <0 0 0x08000000 0x10000000>; /* CS0 */
> +
> + /* child nodes go here */
> + };
> +
> +
> +
> +
> +
> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> new file mode 100644
> index 0000000..e0c1e67
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> @@ -0,0 +1,61 @@
> +Device tree bindings for GPMC connected NANDs
> +
> +GPMC connected NAND (found on OMAP boards) are represented as child nodes of
> +the GPMC controller with a name of "nand".
> +
> +All timing relevant properties as well as generic gpmc child properties are
> +explained in a separate documents - please refer to
> +Documentation/devicetree/bindings/bus/ti-gpmc.txt
> +
> +For NAND specific properties such as ECC modes or bus width, please refer to
> +Documentation/devicetree/bindings/mtd/nand.txt
> +
> +
> +Required properties:
> +
> + - reg: The CS line the peripheral is connected to
> +
> +For inline partiton table parsing (optional):
> +
> + - #address-cells: should be set to 1
> + - #size-cells: should be set to 1
> +
> +Example for an AM33xx board:
> +
> + gpmc: gpmc at 50000000 {
> + compatible = "ti,gpmc";
> + ti,hwmods = "gpmc";
> + reg = <0x50000000 0x1000000>;
> + interrupt-parent = <&intc>;
Remove interrupt-parent here too.
> + interrupts = <100>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
> +
> + nand at 0,0 {
> + reg = <0 0 0>; /* CS0, offset 0 */
The above description says that this is just the chip-select number. Are
the other fields used here? If so, what for?
> + nand-bus-width = <16>;
> + nand-ecc-mode = "none";
I am still wondering if the above needs to be mandatory. Or if not then
may be these should be documented as optional and if these a omitted
then what the default configuration would be.
> +
> + gpmc,sync-clk = <0>;
> + gpmc,cs-on = <0>;
> + gpmc,cs-rd-off = <36>;
> + gpmc,cs-wr-off = <36>;
> + gpmc,adv-on = <6>;
> + gpmc,adv-rd-off = <24>;
> + gpmc,adv-wr-off = <36>;
> + gpmc,we-off = <30>;
> + gpmc,oe-off = <48>;
> + gpmc,access = <54>;
> + gpmc,rd-cycle = <72>;
> + gpmc,wr-cycle = <72>;
> + gpmc,wr-access = <30>;
> + gpmc,wr-data-mux-bus = <0>;
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + /* partitions go here */
> + };
> + };
> +
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 1dcb30c..b028225 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -25,6 +25,10 @@
> #include <linux/module.h>
> #include <linux/interrupt.h>
> #include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_mtd.h>
> +#include <linux/of_device.h>
> +#include <linux/mtd/nand.h>
>
> #include <linux/platform_data/mtd-nand-omap2.h>
>
> @@ -37,6 +41,7 @@
> #include "soc.h"
> #include "common.h"
> #include "gpmc.h"
> +#include "gpmc-nand.h"
>
> #define DEVICE_NAME "omap-gpmc"
>
> @@ -751,6 +756,131 @@ static int __devinit gpmc_mem_init(void)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static struct of_device_id gpmc_dt_ids[] = {
> + { .compatible = "ti,gpmc" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, gpmc_dt_ids);
> +
> +static void gpmc_read_timings_dt(struct device_node *np,
> + struct gpmc_timings *gpmc_t)
> +{
> + u32 val;
> +
> + memset(gpmc_t, 0, sizeof(*gpmc_t));
> +
> + /* minimum clock period for syncronous mode */
> + if (!of_property_read_u32(np, "gpmc,sync-clk", &val))
> + gpmc_t->sync_clk = val;
> +
> + /* chip select timtings */
> + if (!of_property_read_u32(np, "gpmc,cs-on", &val))
> + gpmc_t->cs_on = val;
> +
> + if (!of_property_read_u32(np, "gpmc,cs-rd-off", &val))
> + gpmc_t->cs_rd_off = val;
> +
> + if (!of_property_read_u32(np, "gpmc,cs-wr-off", &val))
> + gpmc_t->cs_wr_off = val;
> +
> + /* ADV signal timings */
> + if (!of_property_read_u32(np, "gpmc,adv-on", &val))
> + gpmc_t->adv_on = val;
> +
> + if (!of_property_read_u32(np, "gpmc,adv-rd-off", &val))
> + gpmc_t->adv_rd_off = val;
> +
> + if (!of_property_read_u32(np, "gpmc,adv-wr-off", &val))
> + gpmc_t->adv_wr_off = val;
> +
> + /* WE signal timings */
> + if (!of_property_read_u32(np, "gpmc,we-on", &val))
> + gpmc_t->we_on = val;
> +
> + if (!of_property_read_u32(np, "gpmc,we-off", &val))
> + gpmc_t->we_off = val;
> +
> + /* OE signal timings */
> + if (!of_property_read_u32(np, "gpmc,oe-on", &val))
> + gpmc_t->oe_on = val;
> +
> + if (!of_property_read_u32(np, "gpmc,oe-off", &val))
> + gpmc_t->oe_off = val;
> +
> + /* access and cycle timings */
> + if (!of_property_read_u32(np, "gpmc,page-burst-access", &val))
> + gpmc_t->page_burst_access = val;
> +
> + if (!of_property_read_u32(np, "gpmc,access", &val))
> + gpmc_t->access = val;
> +
> + if (!of_property_read_u32(np, "gpmc,rd-cycle", &val))
> + gpmc_t->rd_cycle = val;
> +
> + if (!of_property_read_u32(np, "gpmc,wr-cycle", &val))
> + gpmc_t->wr_cycle = val;
> +
> + /* only for OMAP3430 */
> + if (!of_property_read_u32(np, "gpmc,wr-access", &val))
> + gpmc_t->wr_access = val;
> +
> + if (!of_property_read_u32(np, "gpmc,wr-data-mux-bus", &val))
> + gpmc_t->wr_data_mux_bus = val;
> +}
> +
> +static int gpmc_probe_dt(struct platform_device *pdev)
> +{
> + u32 val;
> + struct device_node *child;
> + struct gpmc_timings gpmc_t;
> + const struct of_device_id *of_id =
> + of_match_device(gpmc_dt_ids, &pdev->dev);
> +
> + if (!of_id)
> + return 0;
> +
> + for_each_node_by_name(child, "nand") {
> + struct omap_nand_platform_data *gpmc_nand_data;
> +
> + if (of_property_read_u32(child, "reg", &val) < 0) {
> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
> + child->full_name);
> + continue;
> + }
> +
> + gpmc_nand_data = devm_kzalloc(&pdev->dev,
> + sizeof(*gpmc_nand_data),
> + GFP_KERNEL);
> + if (!gpmc_nand_data) {
> + dev_err(&pdev->dev, "unable to allocate memory?");
> + return -ENOMEM;
> + }
> +
> + gpmc_nand_data->cs = val;
> + gpmc_nand_data->of_node = child;
> +
> + val = of_get_nand_ecc_mode(child);
> + if (val >= 0)
> + gpmc_nand_data->ecc_opt = val;
> +
> + val = of_get_nand_bus_width(child);
> + if (val == 16)
> + gpmc_nand_data->devsize = NAND_BUSWIDTH_16;
Do we need any error checking here? I believe we only support 8-bit and
16-bit width devices and so if 16-bit is not set then we default to 8-bit.
> +
> + gpmc_read_timings_dt(child, &gpmc_t);
> + gpmc_nand_init(gpmc_nand_data, &gpmc_t);
I believe that you need an "of_node_put()" when you are done with the child.
Thanks
Jon
^ permalink raw reply
* [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: N, Mugunthan V @ 2012-11-02 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121102085616.GB2486@netboy.at.omicron.at>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran at gmail.com]
> Sent: Friday, November 02, 2012 2:26 PM
> To: N, Mugunthan V
> Cc: Cousson, Benoit; Hiremath, Vaibhav; netdev at vger.kernel.org;
> paul at pwsan.com; linux-arm-kernel at lists.infradead.org; linux-
> omap at vger.kernel.org
> Subject: Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module
> nodes for AM33XX
>
> On Fri, Nov 02, 2012 at 08:46:46AM +0000, N, Mugunthan V wrote:
> > >
> > > Do you expect to have several instance of the same IP with
> different
> > > parameters here?
> >
> > Though CPSW is a single IP in AM335X, CPSW has sub modules like
> CPDMA, ALE,
> > SLIVER, CPTS and SLAVES where is IP integrator can locate it at
> different
> > offsets. For example comparing the CPSW ip in TI814X and AM335X all
> the
> > above offsets are changed. So I have kept all these offsets in DT as
> driver
> > should not hold any SoC related informations
>
> Did you see the two messages on this point from yesterday?
I saw those posts. The CPSW ip version changes tracks the internal IP
changes and there is no possible way to track the offset changes. For
example CPTS sub module offsets in DM814x and AM335x are different
though the CPTS version is same in both IP versions. So keeping these
offset in DT will make the same driver works directly with DT changes
for future SoC.
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH 1/1] ARM: oprofile: add A5/A7/A15 entries in op_perf_name
From: jgq516 at gmail.com @ 2012-11-02 10:43 UTC (permalink / raw)
To: linux-arm-kernel
From: Xiao Jiang <jgq516@gmail.com>
Add related name for A5/A7/A15 which are consistent with the OProfile
user ABI.
Signed-off-by: Xiao Jiang <jgq516@gmail.com>
---
arch/arm/oprofile/common.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 99c63d4b..ec10db1 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -37,8 +37,11 @@ static struct op_perf_name {
{ "xscale1", "arm/xscale2" },
{ "v6", "arm/armv6" },
{ "v6mpcore", "arm/mpcore" },
+ { "ARMv7 Cortex-A5", "arm/armv7-ca5" },
+ { "ARMv7 Cortex-A7", "arm/armv7-ca7" },
{ "ARMv7 Cortex-A8", "arm/armv7" },
{ "ARMv7 Cortex-A9", "arm/armv7-ca9" },
+ { "ARMv7 Cortex-A15", "arm/armv7-ca15" },
};
char *op_name_from_perf_id(void)
--
1.7.3
^ permalink raw reply related
* [RFC 3/6] sched: pack small tasks
From: Santosh Shilimkar @ 2012-11-02 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKfTPtC29LA15zkgi3gDcet2F841pnqza2_UBwEs6nYUpyKuOQ@mail.gmail.com>
On Monday 29 October 2012 06:42 PM, Vincent Guittot wrote:
> On 24 October 2012 17:20, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
>> Vincent,
>>
>> Few comments/questions.
>>
>>
>> On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
>>>
>>> During sched_domain creation, we define a pack buddy CPU if available.
>>>
>>> On a system that share the powerline at all level, the buddy is set to -1
>>>
>>> On a dual clusters / dual cores system which can powergate each core and
>>> cluster independantly, the buddy configuration will be :
>>> | CPU0 | CPU1 | CPU2 | CPU3 |
>>> -----------------------------------
>>> buddy | CPU0 | CPU0 | CPU0 | CPU2 |
>>
>> ^
>> Is that a typo ? Should it be CPU2 instead of
>> CPU0 ?
>
> No it's not a typo.
> The system packs at each scheduling level. It starts to pack in
> cluster because each core can power gate independently so CPU1 tries
> to pack its tasks in CPU0 and CPU3 in CPU2. Then, it packs at CPU
> level so CPU2 tries to pack in the cluster of CPU0 and CPU0 packs in
> itself
>
I get it. Though in above example a task may migrate from say
CPU3->CPU2->CPU0 as part of packing. I was just thinking whether
moving such task from say CPU3 to CPU0 might be best instead.
>>
>>> Small tasks tend to slip out of the periodic load balance.
>>> The best place to choose to migrate them is at their wake up.
>>>
>> I have tried this series since I was looking at some of these packing
>> bits. On Mobile workloads like OSIdle with Screen ON, MP3, gallary,
>> I did see some additional filtering of threads with this series
>> but its not making much difference in power. More on this below.
>
> Can I ask you which configuration you have used ? how many cores and
> cluster ? Can they be power gated independently ?
>
I have been trying with couple of setups. Dual Core ARM machine and
Quad core X86 box with single package thought most of the mobile
workload analysis I was doing on ARM machine. On both setups
CPUs can be gated independently.
>>
>>
>>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>>> ---
>>> kernel/sched/core.c | 1 +
>>> kernel/sched/fair.c | 109
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++
>>> kernel/sched/sched.h | 1 +
>>> 3 files changed, 111 insertions(+)
>>>
>>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>>> index dab7908..70cadbe 100644
>>> --- a/kernel/sched/core.c
>>> +++ b/kernel/sched/core.c
>>> @@ -6131,6 +6131,7 @@ cpu_attach_domain(struct sched_domain *sd, struct
>>> root_domain *rd, int cpu)
>>> rcu_assign_pointer(rq->sd, sd);
>>> destroy_sched_domains(tmp, cpu);
>>>
>>> + update_packing_domain(cpu);
>>> update_top_cache_domain(cpu);
>>> }
>>>
>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> index 4f4a4f6..8c9d3ed 100644
>>> --- a/kernel/sched/fair.c
>>> +++ b/kernel/sched/fair.c
>>> @@ -157,6 +157,63 @@ void sched_init_granularity(void)
>>> update_sysctl();
>>> }
>>>
>>> +
>>> +/*
>>> + * Save the id of the optimal CPU that should be used to pack small tasks
>>> + * The value -1 is used when no buddy has been found
>>> + */
>>> +DEFINE_PER_CPU(int, sd_pack_buddy);
>>> +
>>> +/* Look for the best buddy CPU that can be used to pack small tasks
>>> + * We make the assumption that it doesn't wort to pack on CPU that share
>>> the
>>
>> s/wort/worth
>
> yes
>
>>
>>> + * same powerline. We looks for the 1st sched_domain without the
>>> + * SD_SHARE_POWERLINE flag. Then We look for the sched_group witht the
>>> lowest
>>> + * power per core based on the assumption that their power efficiency is
>>> + * better */
>>
>> Commenting style..
>> /*
>> *
>> */
>>
>
> yes
>
>> Can you please expand the why the assumption is right ?
>> "it doesn't wort to pack on CPU that share the same powerline"
>
> By "share the same power-line", I mean that the CPUs can't power off
> independently. So if some CPUs can't power off independently, it's
> worth to try to use most of them to race to idle.
>
In that case I suggest we use different word here. Power line can be
treated as voltage line, power domain.
May be SD_SHARE_CPU_POWERDOMAIN ?
>>
>> Think about a scenario where you have quad core, ducal cluster system
>>
>> |Cluster1| |cluster 2|
>> | CPU0 | CPU1 | CPU2 | CPU3 | | CPU0 | CPU1 | CPU2 | CPU3 |
>>
>>
>> Both clusters run from same voltage rail and have same PLL
>> clocking them. But the cluster have their own power domain
>> and all CPU's can power gate them-self to low power states.
>> Clusters also have their own level2 caches.
>>
>> In this case, you will still save power if you try to pack
>> load on one cluster. No ?
>
> yes, I need to update the description of SD_SHARE_POWERLINE because
> I'm afraid I was not clear enough. SD_SHARE_POWERLINE includes the
> power gating capacity of each core. For your example above, the
> SD_SHARE_POWERLINE shoud be cleared at both MC and CPU level.
>
Thanks for clarification.
>>
>>
>>> +void update_packing_domain(int cpu)
>>> +{
>>> + struct sched_domain *sd;
>>> + int id = -1;
>>> +
>>> + sd = highest_flag_domain(cpu, SD_SHARE_POWERLINE);
>>> + if (!sd)
>>> + sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd);
>>> + else
>>> + sd = sd->parent;
>>> +
>>> + while (sd) {
>>> + struct sched_group *sg = sd->groups;
>>> + struct sched_group *pack = sg;
>>> + struct sched_group *tmp = sg->next;
>>> +
>>> + /* 1st CPU of the sched domain is a good candidate */
>>> + if (id == -1)
>>> + id = cpumask_first(sched_domain_span(sd));
>>> +
>>> + /* loop the sched groups to find the best one */
>>> + while (tmp != sg) {
>>> + if (tmp->sgp->power * sg->group_weight <
>>> + sg->sgp->power *
>>> tmp->group_weight)
>>> + pack = tmp;
>>> + tmp = tmp->next;
>>> + }
>>> +
>>> + /* we have found a better group */
>>> + if (pack != sg)
>>> + id = cpumask_first(sched_group_cpus(pack));
>>> +
>>> + /* Look for another CPU than itself */
>>> + if ((id != cpu)
>>> + || ((sd->parent) && !(sd->parent->flags &&
>>> SD_LOAD_BALANCE)))
>>
>> Is the condition "!(sd->parent->flags && SD_LOAD_BALANCE)" for
>> big.LITTLE kind of system where SD_LOAD_BALANCE may not be used ?
>
> No, packing small tasks is part of the load balance so if the
> LOAD_BALANCE flag is cleared, we will not try to pack which is a kind
> of load balance. There is no link with big.LITTLE
>
Now it make sense to me.
>>
>>
>>> + break;
>>> +
>>> + sd = sd->parent;
>>> + }
>>> +
>>> + pr_info(KERN_INFO "CPU%d packing on CPU%d\n", cpu, id);
>>> + per_cpu(sd_pack_buddy, cpu) = id;
>>> +}
>>> +
>>> #if BITS_PER_LONG == 32
>>> # define WMULT_CONST (~0UL)
>>> #else
>>> @@ -3073,6 +3130,55 @@ static int select_idle_sibling(struct task_struct
>>> *p, int target)
>>> return target;
>>> }
>>>
>>> +static inline bool is_buddy_busy(int cpu)
>>> +{
>>> + struct rq *rq = cpu_rq(cpu);
>>> +
>>> + /*
>>> + * A busy buddy is a CPU with a high load or a small load with a
>>> lot of
>>> + * running tasks.
>>> + */
>>> + return ((rq->avg.usage_avg_sum << rq->nr_running) >
>>> + rq->avg.runnable_avg_period);
>>
>> I agree busy CPU is the one with high load, but many small threads may
>> not make CPU fully busy, right ? Should we just stick to the load
>> parameter alone here ?
>
> IMO, the busy state of a CPU isn't only the load but also how many
> threads are waiting for running on it. This formula tries to take into
> account both inputs. If you have dozen of small tasks on a CPU, the
> latency can be large even if the tasks are small.
>
Sure. Your point is to avoid throttling and probably use race for
idle.
>>
>>
>>> +}
>>> +
>>> +static inline bool is_light_task(struct task_struct *p)
>>> +{
>>> + /* A light task runs less than 25% in average */
>>> + return ((p->se.avg.usage_avg_sum << 2) <
>>> p->se.avg.runnable_avg_period);
>>> +}
>>
>> Since the whole packing logic relies on the light threads only, the
>> overall effectiveness is not significant. Infact with multiple tries on
>> Dual core system, I didn't see any major improvement in power. I think
>> we need to be more aggressive here. From the cover letter, I noticed
>> that, you were concerned about any performance drop due to packing and
>> may be that is the reason you chose the conservative threshold. But the
>> fact is, if we want to save meaningful power, there will be slight
>> performance drop which is expected.
>
> I think that everybody agrees that packing small tasks will save power
> whereas it seems to be not so obvious for heavy task. But I may have
> set the threshold a bit too low
>
I agree on packing saves power part for sure.
> Up to which load, you would like to pack on 1 core of your dual core system ?
> Can you provide more details of your load ? Have you got a trace that
> you can share ?
>
More than how much load to pack, I was more looking from the power
savings delta we can achieve by doing it. Some of the usecases like
osidle, mp3, gallary are already very low power and that might be
the reason I didn't notice major mA delta. Though the perf
traces did show some filtering even at 25 % load. i tried upto
50 % threshold to see the effectiveness and there was more
improvement and hence the suggestion about aggressiveness.
May be you can try some of these use-cases on your setup instead of
synthetic workload and see the results.
Regards
Santosh
^ permalink raw reply
* [RFC 5/6] sched: pack the idle load balance
From: Santosh Shilimkar @ 2012-11-02 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKfTPtBsAJ4u265TzOz9qvL4d-eMmrVD-MtgG_Rri_2shGrPBQ@mail.gmail.com>
On Monday 29 October 2012 06:57 PM, Vincent Guittot wrote:
> On 24 October 2012 17:21, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
>> On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
>>>
>>> Look for an idle CPU close the pack buddy CPU whenever possible.
>>
>> s/close/close to
>
> yes
>
>>
>>> The goal is to prevent the wake up of a CPU which doesn't share the power
>>> line of the pack CPU
>>>
>>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>>> ---
>>> kernel/sched/fair.c | 18 ++++++++++++++++++
>>> 1 file changed, 18 insertions(+)
>>>
>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>> index 6df53b5..f76acdc 100644
>>> --- a/kernel/sched/fair.c
>>> +++ b/kernel/sched/fair.c
>>> @@ -5158,7 +5158,25 @@ static struct {
>>>
>>> static inline int find_new_ilb(int call_cpu)
>>> {
>>> + struct sched_domain *sd;
>>> int ilb = cpumask_first(nohz.idle_cpus_mask);
>>> + int buddy = per_cpu(sd_pack_buddy, call_cpu);
>>> +
>>> + /*
>>> + * If we have a pack buddy CPU, we try to run load balance on a
>>> CPU
>>> + * that is close to the buddy.
>>> + */
>>> + if (buddy != -1)
>>> + for_each_domain(buddy, sd) {
>>> + if (sd->flags & SD_SHARE_CPUPOWER)
>>> + continue;
>>
>> Do you mean SD_SHARE_POWERLINE here ?
>
> No, I just don't want to take hyperthread level for ILB
>
>>
>>> +
>>> + ilb = cpumask_first_and(sched_domain_span(sd),
>>> + nohz.idle_cpus_mask);
>>> +
>>> + if (ilb < nr_cpu_ids)
>>> + break;
>>> + }
>>>
>>> if (ilb < nr_cpu_ids && idle_cpu(ilb))
>>> return ilb;
>>>
>> Can you please expand "idle CPU _close_ the pack buddy CPU" ?
>
> The goal is to packed the tasks on the pack buddy CPU so when the
> scheduler needs to start ILB, I try to wake up a CPU that is close to
> the buddy and preferably in the same cluster
>
I see your point now. Thanks for clarification.
Regards
santosh
^ permalink raw reply
* [RFC 6/6] ARM: sched: clear SD_SHARE_POWERLINE
From: Santosh Shilimkar @ 2012-11-02 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKfTPtAZjLpwHYgj8JXku4sU0mPPf34MKkWp0=qiX5u-T0JVOA@mail.gmail.com>
On Monday 29 October 2012 06:58 PM, Vincent Guittot wrote:
> On 24 October 2012 17:21, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
>> On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
>>>
>>> The ARM platforms take advantage of packing small tasks on few cores.
>>> This is true even when the cores of a cluster can't be powergated
>>> independently.
>>>
>>>
>>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>>> ---
>>> arch/arm/kernel/topology.c | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
>>> index 26c12c6..00511d0 100644
>>> --- a/arch/arm/kernel/topology.c
>>> +++ b/arch/arm/kernel/topology.c
>>> @@ -226,6 +226,11 @@ static inline void update_cpu_power(unsigned int
>>> cpuid, unsigned int mpidr) {}
>>> */
>>> struct cputopo_arm cpu_topology[NR_CPUS];
>>>
>>> +int arch_sd_share_power_line(void)
>>> +{
>>> + return 0*SD_SHARE_POWERLINE;
>>> +}
>>
>>
>> Making this selection of policy based on sched domain will better. Just
>> gives the flexibility to choose a separate scheme for big and little
>> systems which will be very convenient.
>
> I agree that it would be more flexible to be able to set it for each level
>
Will you be addressing that in next version then ?
Regards
santosh
^ permalink raw reply
* [PATCH] i2c: at91: add a sanity check on i2c message length
From: ludovic.desroches @ 2012-11-02 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121101222922.GD22956@pengutronix.de>
Hi Wolfram,
Le 11/01/2012 11:29 PM, Wolfram Sang a ?crit :
> On Wed, Oct 10, 2012 at 04:25:58PM +0200, ludovic.desroches at atmel.com wrote:
>> From: Ludovic Desroches <ludovic.desroches@atmel.com>
>>
>> If the i2c message length is zero, i2c-at91 will directly return an error
>> instead of trying to send a zero-length message.
>>
>> Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
>
> What happens if you send a 0 byte message? Some hardware is able to do
> this and it will be used in SMBUS QUICK which the driver states to
> support according to at91_twi_func().
Without this I had some data corruption when writing to / reading from a
serial eeprom (depending on the IP version).
Yes SMBUS quick command is supported but is not managed in the driver,
we have to tell explicitly the IP that we want to send this command.
Regards
Ludovic
>
> Regards,
>
> Wolfram
>
^ permalink raw reply
* [PATCH 1/2] i2c: omap: Fix the revision register read
From: Felipe Balbi @ 2012-11-02 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351852785-16961-2-git-send-email-shubhrajyoti@ti.com>
Hi,
On Fri, Nov 02, 2012 at 04:09:44PM +0530, Shubhrajyoti D wrote:
> The revision register on OMAP4 is a 16-bit lo and a 16-bit
> hi. Currently the driver reads only the lower 8-bits.
> Fix the same by preventing the truncating of the rev register
> for OMAP4.
>
> Also use the scheme bit ie bit-14 of the hi register to know if it
> is OMAP_I2C_IP_VERSION_2.
>
> On platforms previous to OMAP4 the offset 0x04 is IE register whose
> bit-14 reset value is 0, the code uses the same to its advantage.
>
> Also since the omap_i2c_read_reg uses reg_map_ip_* a raw_readw is done
> to fetch the revision register.
>
> The dev->regs is populated after reading the rev_hi. A NULL check
> has been added in the resume handler to prevent the access before
> the setting of the regs.
tested on which platforms ?
> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> ---
> drivers/i2c/busses/i2c-omap.c | 59 ++++++++++++++++++++++++++++++++---------
> 1 files changed, 46 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index db31eae..d8e7709 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -49,9 +49,10 @@
> #define OMAP_I2C_OMAP1_REV_2 0x20
>
> /* I2C controller revisions present on specific hardware */
> -#define OMAP_I2C_REV_ON_2430 0x36
> -#define OMAP_I2C_REV_ON_3430_3530 0x3C
> -#define OMAP_I2C_REV_ON_3630_4430 0x40
> +#define OMAP_I2C_REV_ON_2430 0x00000036
are you sure this are the contents on 2430 ? Have you actually ran this
code on that platform ?
> +#define OMAP_I2C_REV_ON_3430_3530 0x0000003C
> +#define OMAP_I2C_REV_ON_3630 0x00000040
likewise for these two.
> +#define OMAP_I2C_REV_ON_4430_PLUS 0x50400002
what about 4460, 4470, 3530, etc etc etc ?
> @@ -490,7 +491,7 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev, u8 size, bool is_rx)
>
> omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
>
> - if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
> + if (dev->rev < OMAP_I2C_REV_ON_3630)
> dev->b_hw = 1; /* Enable hardware fixes */
>
> /* calculate wakeup latency constraint for MPU */
> @@ -1052,6 +1053,14 @@ static const struct of_device_id omap_i2c_of_match[] = {
> MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
> #endif
>
> +#define OMAP_I2C_SCHEME(rev) (rev & 0xc000) >> 14
you miss () there to make sure no other operations will take higher
precedence when using this macro.
> @@ -1130,7 +1136,31 @@ omap_i2c_probe(struct platform_device *pdev)
> if (IS_ERR_VALUE(r))
> goto err_free_mem;
>
> - dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
> + /*
> + * Read the Rev hi bit-[15:14] ie scheme this is 1 indicates ver2.
> + * On omap3 Offset 4 is IE Reg the bit [15:14] is XDR_IE which is 0
> + * at reset. Also since the omap_i2c_read_reg uses reg_map_ip_* a
> + * raw_readw is done.
> + */
> + rev = __raw_readw(dev->base + 0x04);
> +
> + switch (OMAP_I2C_SCHEME(rev)) {
> + case 0:
define macros for these two cases.
> + dev->regs = (u8 *)reg_map_ip_v1;
> + dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
> + minor = OMAP_I2C_REV_SCHEME_0_MAJOR(dev->rev);
> + major = OMAP_I2C_REV_SCHEME_0_MAJOR(dev->rev);
> + break;
wrong indentation.
--
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/20121102/37133f7c/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207
From: Felipe Balbi @ 2012-11-02 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351852785-16961-3-git-send-email-shubhrajyoti@ti.com>
On Fri, Nov 02, 2012 at 04:09:45PM +0530, Shubhrajyoti D wrote:
> The errata i207 is enabled for 2430 and 3xxx. Use the revision check
> to enable the erratum instead.
>
> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
very good. I haven't read the errata but from a code standpoint, it
looks good:
Reviewed-by: Felipe Balbi <balbi@ti.com>
> ---
> drivers/i2c/busses/i2c-omap.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index d8e7709..44245d4 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1164,7 +1164,8 @@ omap_i2c_probe(struct platform_device *pdev)
>
> dev->errata = 0;
>
> - if (dev->flags & OMAP_I2C_FLAG_APPLY_ERRATA_I207)
> + if (dev->rev >= OMAP_I2C_REV_ON_2430 &&
> + dev->rev < OMAP_I2C_REV_ON_4430_PLUS)
> dev->errata |= I2C_OMAP_ERRATA_I207;
>
> if (dev->rev <= OMAP_I2C_REV_ON_3430_3530)
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/20121102/78fc6173/attachment.sig>
^ permalink raw reply
* [PATCH v2 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
From: Daniel Mack @ 2012-11-02 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5093A36B.70101@ti.com>
Hi Jon,
as all comments so far focussed on patch 4/4, could we agree to merge
1-3 of this series already? These are all small and straight-forward
things that don't depend on 4/4. That way, I only need to resend the
last one under discussion.
On 02.11.2012 11:41, Jon Hunter wrote:
> Hi Daniel,
>
> On 11/01/2012 01:36 PM, Daniel Mack wrote:
>> This patch adds basic DT bindings for OMAP GPMC.
>>
>> The actual peripherals are instanciated from child nodes within the GPMC
>> node, and the only type of device that is currently supported is NAND.
>>
>> Code was added to parse the generic GPMC timing parameters and some
>> documentation with examples on how to use them.
>>
>> Successfully tested on an AM33xx board.
>>
>> Signed-off-by: Daniel Mack <zonque@gmail.com>
>> ---
>> Documentation/devicetree/bindings/bus/ti-gpmc.txt | 73 +++++++++++
>> .../devicetree/bindings/mtd/gpmc-nand.txt | 61 +++++++++
>> arch/arm/mach-omap2/gpmc.c | 139 +++++++++++++++++++++
>> 3 files changed, 273 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>>
>> diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> new file mode 100644
>> index 0000000..6f44487
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
>> @@ -0,0 +1,73 @@
>> +Device tree bindings for OMAP general purpose memory controllers (GPMC)
>> +
>> +The actual devices are instantiated from the child nodes of a GPMC node.
>> +
>> +Required properties:
>> +
>> + - compatible: Should be set to "ti,gpmc"
>> + - reg: A resource specifier for the register space
>> + (see the example below)
>> + - ti,hwmods: Should be set to "ti,gpmc" until the DT transition is
>> + completed.
>> + - #address-cells: Must be set to 2 to allow memory address translation
>> + - #size-cells: Must be set to 1 to allow CS address passing
>> + - ranges: Must be set up to reflect the memory layout
>> + Note that this property is not currently parsed.
>> + Calculated values derived from the contents of
>> + GPMC_CS_CONFIG7 as set up by the bootloader. That will
>> + change in the future, so be sure to fill the correct
>> + values here.
>
> I still think it would be good to add number of chip-selects and
> wait-pins here.
The number of chip-selects can be derived from the ranges property.
Namely, each 4-value entry to this property maps to one chip-select. I
can try and make the more clear in the documentation.
>> +Timing properties for child nodes. All are optional and default to 0.
>> +
>> + - gpmc,sync-clk: Minimum clock period for synchronous mode, in picoseconds
>> +
>> + Chip-select signal timings corresponding to GPMC_CS_CONFIG2:
>> + - gpmc,cs-on: Assertion time
>> + - gpmc,cs-rd-off: Read deassertion time
>> + - gpmc,cs-wr-off: Write deassertion time
>> +
>> + ADV signal timings corresponding to GPMC_CONFIG3:
>> + - gpmc,adv-on: Assertion time
>> + - gpmc,adv-rd-off: Read deassertion time
>> + - gpmc,adv-wr-off: Write deassertion time
>
> Nit-pick, looks like you are mixing GPMC_CS_CONFIGx and GPMC_CONFIGx
> naming conventions in the above and below. Would be good to make this
> consistent.
Ok, but these were just copied from arch/arm/mach-omap2/gpmc.h. So it's
wrong there, too.
>> + WE signals timings corresponding to GPMC_CONFIG4:
>> + - gpmc,we-on: Assertion time
>> + - gpmc,we-off: Deassertion time
>> +
>> + OE signals timings corresponding to GPMC_CONFIG4
>> + - gpmc,oe-on: Assertion time
>> + - gpmc,oe-off: Deassertion time
>> +
>> + Access time and cycle time timings corresponding to GPMC_CONFIG5
>> + - gpmc,page-burst-access: Multiple access word delay
>> + - gpmc,access: Start-cycle to first data valid delay
>> + - gpmc,rd-cycle: Total read cycle time
>> + - gpmc,wr-cycle: Total write cycle time
>> +
>> +The following are only on OMAP3430
>> + - gpmc,wr-access
>> + - gpmc,wr-data-mux-bus
>> +
>> +
>> +Example for an AM33xx board:
>> +
>> + gpmc: gpmc at 50000000 {
>> + compatible = "ti,gpmc";
>> + ti,hwmods = "gpmc";
>> + reg = <0x50000000 0x2000>;
>> + interrupt-parent = <&intc>;
>
> We should drop interrupt-parent. We are declaring the interrupt-parent
> globally in the dts files and so no need to replicate in each individual
> binding.
Right, will remove.
>> + interrupts = <100>;
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + ranges = <0 0 0x08000000 0x10000000>; /* CS0: NAND */
>> +
>> + nand at 0,0 {
>> + reg = <0 0 0>; /* CS0, offset 0 */
>
> The above description says that this is just the chip-select number. Are
> the other fields used here? If so, what for?
Thanks to the translation done by the 'ranges' mechanism, these just
denote the offset to the address range specified above. So they can be
left 0.
>> + nand-bus-width = <16>;
>> + nand-ecc-mode = "none";
>
> I am still wondering if the above needs to be mandatory. Or if not then
> may be these should be documented as optional and if these a omitted
> then what the default configuration would be.
In my docs, I referred to Documentation/devicetree/bindings/mtd/nand.txt
which states:
- nand-ecc-mode : String, operation mode of the NAND ecc mode.
Supported values are: "none", "soft", "hw", "hw_syndrome",
"hw_oob_first", "soft_bch".
- nand-bus-width : 8 or 16 bus width if not present 8
So ecc-mode is mandatory, even though the code currently really defaults
to 0 ("none"). nand-bus-width isn't. I don't know if it makes sense to
duplicate the Documentation here.
>> +static int gpmc_probe_dt(struct platform_device *pdev)
>> +{
>> + u32 val;
>> + struct device_node *child;
>> + struct gpmc_timings gpmc_t;
>> + const struct of_device_id *of_id =
>> + of_match_device(gpmc_dt_ids, &pdev->dev);
>> +
>> + if (!of_id)
>> + return 0;
>> +
>> + for_each_node_by_name(child, "nand") {
>> + struct omap_nand_platform_data *gpmc_nand_data;
>> +
>> + if (of_property_read_u32(child, "reg", &val) < 0) {
>> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
>> + child->full_name);
>> + continue;
>> + }
>> +
>> + gpmc_nand_data = devm_kzalloc(&pdev->dev,
>> + sizeof(*gpmc_nand_data),
>> + GFP_KERNEL);
>> + if (!gpmc_nand_data) {
>> + dev_err(&pdev->dev, "unable to allocate memory?");
>> + return -ENOMEM;
>> + }
>> +
>> + gpmc_nand_data->cs = val;
>> + gpmc_nand_data->of_node = child;
>> +
>> + val = of_get_nand_ecc_mode(child);
>> + if (val >= 0)
>> + gpmc_nand_data->ecc_opt = val;
>> +
>> + val = of_get_nand_bus_width(child);
>> + if (val == 16)
>> + gpmc_nand_data->devsize = NAND_BUSWIDTH_16;
>
> Do we need any error checking here? I believe we only support 8-bit and
> 16-bit width devices and so if 16-bit is not set then we default to 8-bit.
Yes, that's that the code does. If val != 16, ->devsize is left set to 0
(from kzalloc). There is no NAND_BUSWIDTH_8, so I think that should be ok?
>> +
>> + gpmc_read_timings_dt(child, &gpmc_t);
>> + gpmc_nand_init(gpmc_nand_data, &gpmc_t);
>
> I believe that you need an "of_node_put()" when you are done with the child.
Good point.
Thanks,
Daniel
^ permalink raw reply
* [PATCH] i2c: at91: add a sanity check on i2c message length
From: Wolfram Sang @ 2012-11-02 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5093A8CD.60006@atmel.com>
On Fri, Nov 02, 2012 at 12:04:45PM +0100, ludovic.desroches wrote:
> Hi Wolfram,
>
> Le 11/01/2012 11:29 PM, Wolfram Sang a ?crit :
> >On Wed, Oct 10, 2012 at 04:25:58PM +0200, ludovic.desroches at atmel.com wrote:
> >>From: Ludovic Desroches <ludovic.desroches@atmel.com>
> >>
> >>If the i2c message length is zero, i2c-at91 will directly return an error
> >>instead of trying to send a zero-length message.
> >>
> >>Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> >
> >What happens if you send a 0 byte message? Some hardware is able to do
> >this and it will be used in SMBUS QUICK which the driver states to
> >support according to at91_twi_func().
>
> Without this I had some data corruption when writing to / reading
> from a serial eeprom (depending on the IP version).
>
> Yes SMBUS quick command is supported but is not managed in the
> driver, we have to tell explicitly the IP that we want to send this
> command.
Ok, so unless you want to implement the support, please update this
patch with a comment that SMBUS_QUICK is a TODO and remove the
SMBUS_QUICK capability.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121102/48709ea9/attachment-0001.sig>
^ permalink raw reply
* [PATCH 2/2] i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207
From: Shubhrajyoti Datta @ 2012-11-02 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121102110713.GC19493@arwen.pp.htv.fi>
On Fri, Nov 2, 2012 at 4:37 PM, Felipe Balbi <balbi@ti.com> wrote:
> On Fri, Nov 02, 2012 at 04:09:45PM +0530, Shubhrajyoti D wrote:
>> The errata i207 is enabled for 2430 and 3xxx. Use the revision check
>> to enable the erratum instead.
>>
>> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
>
> very good. I haven't read the errata but from a code standpoint, it
> looks good:
>
> Reviewed-by: Felipe Balbi <balbi@ti.com>
>
Also I post to this the flag may be deleted.
From: Shubhrajyoti D <shubhrajyoti@ti.com>
Date: Fri, 2 Nov 2012 16:34:08 +0530
Subject: [PATCH] ARM: i2c: omap: Remove the i207 errata flag
The commit [i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207]
uses the revision id instead of the flag. So the flag can be safely removed.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 3 +--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 9 +++------
drivers/i2c/busses/i2c-omap.c | 3 +--
include/linux/i2c-omap.h | 1 -
4 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index c455e41..b79ccf6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -76,8 +76,7 @@ static struct omap_hwmod_class i2c_class = {
static struct omap_i2c_dev_attr i2c_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
- OMAP_I2C_FLAG_BUS_SHIFT_2 |
+ .flags = OMAP_I2C_FLAG_BUS_SHIFT_2 |
OMAP_I2C_FLAG_FORCE_19200_INT_CLK,
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f67b7ee..943222c4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -791,8 +791,7 @@ static struct omap_hwmod omap3xxx_dss_venc_hwmod = {
/* I2C1 */
static struct omap_i2c_dev_attr i2c1_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
- OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+ .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
OMAP_I2C_FLAG_BUS_SHIFT_2,
};
@@ -818,8 +817,7 @@ static struct omap_hwmod omap3xxx_i2c1_hwmod = {
/* I2C2 */
static struct omap_i2c_dev_attr i2c2_dev_attr = {
.fifo_depth = 8, /* bytes */
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
- OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+ .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
OMAP_I2C_FLAG_BUS_SHIFT_2,
};
@@ -845,8 +843,7 @@ static struct omap_hwmod omap3xxx_i2c2_hwmod = {
/* I2C3 */
static struct omap_i2c_dev_attr i2c3_dev_attr = {
.fifo_depth = 64, /* bytes */
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
- OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+ .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
OMAP_I2C_FLAG_BUS_SHIFT_2,
};
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index dd97c14..87970fa 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1029,8 +1029,7 @@ static const struct i2c_algorithm omap_i2c_algo = {
#ifdef CONFIG_OF
static struct omap_i2c_bus_platform_data omap3_pdata = {
.rev = OMAP_I2C_IP_VERSION_1,
- .flags = OMAP_I2C_FLAG_APPLY_ERRATA_I207 |
- OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
+ .flags = OMAP_I2C_FLAG_RESET_REGS_POSTIDLE |
OMAP_I2C_FLAG_BUS_SHIFT_2,
};
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
index df804ba..5c88187 100644
--- a/include/linux/i2c-omap.h
+++ b/include/linux/i2c-omap.h
@@ -21,7 +21,6 @@
#define OMAP_I2C_FLAG_SIMPLE_CLOCK BIT(1)
#define OMAP_I2C_FLAG_16BIT_DATA_REG BIT(2)
#define OMAP_I2C_FLAG_RESET_REGS_POSTIDLE BIT(3)
-#define OMAP_I2C_FLAG_APPLY_ERRATA_I207 BIT(4)
#define OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK BIT(5)
#define OMAP_I2C_FLAG_FORCE_19200_INT_CLK BIT(6)
/* how the CPU address bus must be translated for I2C unit access */
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/2] i2c: omap: Fix the revision register read
From: Shubhrajyoti Datta @ 2012-11-02 11:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121102110604.GB19493@arwen.pp.htv.fi>
On Fri, Nov 2, 2012 at 4:36 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Fri, Nov 02, 2012 at 04:09:44PM +0530, Shubhrajyoti D wrote:
>> The revision register on OMAP4 is a 16-bit lo and a 16-bit
>> hi. Currently the driver reads only the lower 8-bits.
>> Fix the same by preventing the truncating of the rev register
>> for OMAP4.
>>
>> Also use the scheme bit ie bit-14 of the hi register to know if it
>> is OMAP_I2C_IP_VERSION_2.
>>
>> On platforms previous to OMAP4 the offset 0x04 is IE register whose
>> bit-14 reset value is 0, the code uses the same to its advantage.
>>
>> Also since the omap_i2c_read_reg uses reg_map_ip_* a raw_readw is done
>> to fetch the revision register.
>>
>> The dev->regs is populated after reading the rev_hi. A NULL check
>> has been added in the resume handler to prevent the access before
>> the setting of the regs.
>
> tested on which platforms ?
omap4430 , 4460 and omap3.
>
>> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
>> ---
>> drivers/i2c/busses/i2c-omap.c | 59 ++++++++++++++++++++++++++++++++---------
>> 1 files changed, 46 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
>> index db31eae..d8e7709 100644
>> --- a/drivers/i2c/busses/i2c-omap.c
>> +++ b/drivers/i2c/busses/i2c-omap.c
>> @@ -49,9 +49,10 @@
>> #define OMAP_I2C_OMAP1_REV_2 0x20
>>
>> /* I2C controller revisions present on specific hardware */
>> -#define OMAP_I2C_REV_ON_2430 0x36
>> -#define OMAP_I2C_REV_ON_3430_3530 0x3C
>> -#define OMAP_I2C_REV_ON_3630_4430 0x40
>> +#define OMAP_I2C_REV_ON_2430 0x00000036
>
> are you sure this are the contents on 2430 ? Have you actually ran this
> code on that platform ?
I did not run on 2430. Will try to get a platform and run.
However the current code already has and uses the same value so
I feel it should be fine.:-)
>
>> +#define OMAP_I2C_REV_ON_3430_3530 0x0000003C
>> +#define OMAP_I2C_REV_ON_3630 0x00000040
>
> likewise for these two.
I verified that the 3630 returns 0x40 on my beaglexM.
>
>> +#define OMAP_I2C_REV_ON_4430_PLUS 0x50400002
>
> what about 4460, 4470, 3530, etc etc etc ?
>
>> @@ -490,7 +491,7 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev, u8 size, bool is_rx)
>>
>> omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
>>
>> - if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
>> + if (dev->rev < OMAP_I2C_REV_ON_3630)
>> dev->b_hw = 1; /* Enable hardware fixes */
>>
>> /* calculate wakeup latency constraint for MPU */
>> @@ -1052,6 +1053,14 @@ static const struct of_device_id omap_i2c_of_match[] = {
>> MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
>> #endif
>>
>> +#define OMAP_I2C_SCHEME(rev) (rev & 0xc000) >> 14
>
> you miss () there to make sure no other operations will take higher
> precedence when using this macro.
Indeed. Thanks.
>
>> @@ -1130,7 +1136,31 @@ omap_i2c_probe(struct platform_device *pdev)
>> if (IS_ERR_VALUE(r))
>> goto err_free_mem;
>>
>> - dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
>> + /*
>> + * Read the Rev hi bit-[15:14] ie scheme this is 1 indicates ver2.
>> + * On omap3 Offset 4 is IE Reg the bit [15:14] is XDR_IE which is 0
>> + * at reset. Also since the omap_i2c_read_reg uses reg_map_ip_* a
>> + * raw_readw is done.
>> + */
>> + rev = __raw_readw(dev->base + 0x04);
>> +
>> + switch (OMAP_I2C_SCHEME(rev)) {
>> + case 0:
>
> define macros for these two cases.
OK
>
>> + dev->regs = (u8 *)reg_map_ip_v1;
>> + dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
>> + minor = OMAP_I2C_REV_SCHEME_0_MAJOR(dev->rev);
>> + major = OMAP_I2C_REV_SCHEME_0_MAJOR(dev->rev);
>> + break;
>
> wrong indentation.
Yes will fix.
>
> --
> balbi
^ permalink raw reply
* gic_set_affinity
From: Robert Beckett @ 2012-11-02 11:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOmFF10StbsQ6WU6J=MFoM87zgD+XpZqQrr2dLsJHPnW0gVang@mail.gmail.com>
(CC maintainers)
On 1 November 2012 17:54, Robert Beckett <bob.beckett@gmail.com> wrote:
> Hello,
>
> I was looking through the arm gic code while debugging a problem I am
> having, and noticed something in gic_set_affinity.
>
> When something comes along and setts an irq affinity mask (e.g.
> through /proc/irq/<irq>/smp_affinity_mask), the calls goes like so :
>
> ...
> 1. irq_set_affinity : grabs the desc->lock
> 2. __irq_set_affinity_locked : calls chip->irq_set_affinity
> 3. gic_set_affinity : writes a new mask to the gic distributor
>
> my question is, what happens if an interrupt is raised between 1 and 3?
> To me, it looks like the interrupt could end up being handled on 2
> cpus. When it is raised, the handler will be called and sit spinning
> for desc->lock (e.g. in handle_fasteoi_irq). The mask will be set to
> set the affinity to the new cpu, the new cpu will receive the
> interrupt as it has not been ackd or disabled yet, and the handler
> will be called on the second cpu and will wait for the same lock in
> the handler. Once the affinity setting calls have finished, the lock
> is released, and whichever cpu gets the lock will handle the interrupt
> while still locking out the other cpu. Once it finishes, the other cpu
> will try to handle it leading to an interrupt handler call for an
> interrupt that no longer exists, which could lead to spurious
> interrupt if it returns IRQ_NONE because it cant see that the
> interrupt is raised.
>
> Is this what will happen? If so, the interrupt should be masked across
> the affinity setting so that it cant be raised on both cpus.
> if I have just missed something obvious, then please let me know...
>
> Cheers.
>
> Bob
^ permalink raw reply
* [PATCH v3 04/11] clk: davinci - add pll divider clock driver
From: Sekhar Nori @ 2012-11-02 11:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351181518-11882-5-git-send-email-m-karicheri2@ti.com>
On 10/25/2012 9:41 PM, Murali Karicheri wrote:
> pll dividers are present in the pll controller of DaVinci and Other
> SoCs that re-uses the same hardware IP. This has a enable bit for
> bypass the divider or enable the driver. This is a sub class of the
> clk-divider clock checks the enable bit to calculare the rate and
> invoke the recalculate() function of the clk-divider if enabled.
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> ---
> drivers/clk/davinci/clk-div.c | 124 +++++++++++++++++++++++++++++++++++++++++
> drivers/clk/davinci/clk-div.h | 42 ++++++++++++++
> 2 files changed, 166 insertions(+)
> create mode 100644 drivers/clk/davinci/clk-div.c
> create mode 100644 drivers/clk/davinci/clk-div.h
>
> diff --git a/drivers/clk/davinci/clk-div.c b/drivers/clk/davinci/clk-div.c
> new file mode 100644
> index 0000000..8147d99
> --- /dev/null
> +++ b/drivers/clk/davinci/clk-div.c
> @@ -0,0 +1,124 @@
> +/*
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2012 Texas instuments
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
incomplete sentence.
> +/**
> + * clk_register_davinci_plldiv - register function for DaVinci PLL divider clk
> + *
> + * @dev: device ptr
> + * @name: name of the clock
> + * @parent_name: name of parent clock
> + * @plldiv_data: ptr to pll divider data
> + * @lock: ptr to spinlock passed to divider clock
> + */
> +struct clk *clk_register_davinci_plldiv(struct device *dev,
Why do you need a dev pointer here and which device does it point to? In
the only usage of this API in the series, you pass a NULL here. I should
have probably asked this question on one of the earlier patches itself.
> + const char *name, const char *parent_name,
> + struct clk_plldiv_data *plldiv_data,
> + spinlock_t *lock)
> +{
> + struct clk_div *div;
> + struct clk *clk;
> + struct clk_init_data init;
> +
> + div = kzalloc(sizeof(*div), GFP_KERNEL);
> + if (!div)
> + return ERR_PTR(-ENOMEM);
> +
> + init.name = name;
> + init.ops = &clk_div_ops;
> + init.flags = plldiv_data->flags;
> + init.parent_names = (parent_name ? &parent_name : NULL);
> + init.num_parents = (parent_name ? 1 : 0);
> +
> + div->reg = plldiv_data->reg;
> + div->en_id = plldiv_data->en_id;
> +
> + div->divider.reg = plldiv_data->reg;
> + div->divider.shift = plldiv_data->shift;
> + div->divider.width = plldiv_data->width;
> + div->divider.flags = plldiv_data->divider_flags;
> + div->divider.lock = lock;
> + div->divider.hw.init = &init;
> + div->ops = &clk_divider_ops;
> +
> + clk = clk_register(NULL, &div->divider.hw);
Shouldn't you be calling clk_register_divider() here which in turn will
do clk_register()?
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM: S3C64XX: Fix up IRQ mapping for balblair on Cragganmore
From: Sergei Shtylyov @ 2012-11-02 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351852733-3346-1-git-send-email-dp@opensource.wolfsonmicro.com>
Hello.
On 02-11-2012 14:38, Dimitris Papastamos wrote:
> We are using S3C_EINT(4) instead of S3C_EINT(5).
> Change-Id: Ia197069ddc736813f2711c763469eaf655ea58ac
Remove this line please -- it has no place in the upstream patch.
> Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
WBR, Sergei
^ permalink raw reply
* [PATCH v2] ARM: plat-versatile: move FPGA irq driver to drivers/irqchip
From: Russell King - ARM Linux @ 2012-11-02 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121101232010.78269291@skate>
On Thu, Nov 01, 2012 at 11:20:10PM +0100, Thomas Petazzoni wrote:
> Linus,
>
> On Thu, 1 Nov 2012 22:28:49 +0100, Linus Walleij wrote:
>
> > +void fpga_handle_irq(struct pt_regs *regs);
>
> This function does not need to be exposed in a public header: as
> proposed for the bcm2835 and armada-370-xp IRQ controller drivers, the
> driver should directly do handle_arch_irq = fpga_handle_irq, and
> therefore there is no need for the machine desc structure to reference
> fpga_handle_irq anymore.
Err no, then you don't understand what's going on here. This may or may
not be a top-level IRQ handler. Some ARM platforms have three of these
cascaded, others have one of these cascaded off a VIC or GIC.
To override the top level IRQ handler unconditionally is going to break
platforms.
^ permalink raw reply
* [RFC 00/15] Add basic suspend-resume support for AM33XX
From: Vaibhav Bedia @ 2012-11-02 12:32 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds support for suspend-resume on AM33XX.
AM33XX family has a Cortex-M3 (WKUP_M3) which assists the
MPU in DeepSleep0 entry and exit. WKUP_M3 takes care of the
clockdomain and powerdomain transitions based on targeted
intended low power state. MPU needs to load the appropriate
WKUP_M3 binary onto the WKUP_M3 memory space before it can
leverage any of the PM features.
The various low power modes and the overall s/w sequence is
documented in section 8.1.4.3 of the AM335x TRM available
on the TI website[1].
DeepSleep0 mode offers the lowest power mode with limited
wakeup sources without a complete reboot and is mapped as
the suspend state in the kernel. In this state, MPU and PER
domains are turned off with the internal RAM held in retention
to facilitate resume process.
The IPC mechanism between MPU and WKUP_M3 uses a mailbox
sub-module and 8 IPC registers in the Control module. MPU
populates the IPC registers for the payload and uses the
assigned Mailbox for issuing an interrupt to WKUP_M3 which
then goes and checks the IPC registers for the payload.
WKUP_M3 has the ability to trigger on interrupt to MPU by
executing the "sev" instruction.
In the current implementation when the suspend process
is initiated MPU interrupts the WKUP_M3 to let about the
intent of entering DeepSleep0 and waits for an ACK. When
the ACK is received, MPU continues with its suspend process
to suspend all the drivers and then jumps to assembly code
in OCMC RAM to put the PLLs in bypass, put the external RAM
in self-refresh mode and then finally execute the WFI
instruction. The WFI instruction triggers another interrupt
to the WKUP_M3 which then continues wiht the power down
sequence wherein the clockdomain and powerdomain transition
takes place. As part of the sleep sequence, WKUP_M3 unmasks
the interrupt lines for the wakeup sources. When WKUP_M3
executes WFI, the hardware disables the main oscillator.
When a wakeup event occurs, WKUP_M3 starts the power-up
sequence by switching on the power domains and finally
enabling the clock to MPU. Since the MPU gets powered down
as part of the sleep sequence, in the resume path ROM code
starts executing. The ROM code detects a wakeup from sleep
and then jumps to the resume location in OCMC which was
populated in one of the IPC registers as part of the suspend
sequence.
The first patch adds an API in the OMAP mailbox code to
enable the MPU to clear the FIFO since WKUP_M3 does not
have any access to the mailbox module. Minimal support
for AM33XX family is added in the 2nd patch and the 3rd
patch changes the initcall level of the mailbox code since
the PM init happens very early in the boot process.
The fourth patch updates the reset API for AM33XX to reflect
the fact that there is a reset status bit to be checked.
The next four patches are update the AM33XX hwmod data
to register OCMCRAM, WKUP_M3 and fix up a couple of issues
related to TPTC and CPGMAC data.
The next patch gets rid of some header files included in
the AM33XX code and also adds the appropriate macro to ensure
that the files can be included in assembly code.
Some control module registers which are required in the assembly
code are added in the next patch.
The next two patches are related to the timer code. First the
clocksource and clockevent timers are interchanged to ensure that
have a free-running counter in suspend and then suspend-resume
support for the clockevent timers added.
The device tree data for AM33XX is updated to register the OCMC
and WKUP_M3 modules and then OMAP2 defconfig updated to include
mailbox support which is required by the PM code.
The last patch builds upon all the work done in the other
patches to implement suspend-resume functionality.
These patches apply on top the current linux-omap master branch
cc2b5d5 + the HWMOD patch for CPSW [3] and has been tested
on the AM335x EVM and the BeagleBone. Some of the patches will need
minor rework to address the changes to the header files
being done by Tony and the timer changes done by Jon Hunter.
With these dependencies met, the PM code uses the firmware interface
and expects the userspace to load the WKUP_M3 binary before the
suspend-resume functionality is made available. The binary file (and
the source-code for WKUP_M3) can be obtained from the HEAD of the
master branch at [2].
A sample usage of the suspend-resume process is shown below...
(the binary from [2] is renamed to binary_blob and is included in the
ramdisk used for booting)
[ 0.000000] Booting Linux on physical CPU 0
...
[ 1.873005] Power Management for AM33XX family
[ 1.878365] Trying to load am335x-pm-firmware.bin
[ 1.883264] ThumbEE CPU extension supported.
[ 1.900231] clock: disabling unused clocks to save power
[ 1.913804] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 1.924564] RAMDISK: gzip image found at block 0
[ 2.397241] VFS: Mounted root (ext2 filesystem) on device 1:0.
[ 2.404341] Freeing init memory: 324K
mount: mounting none on /var/shm failed: No such file or directory
::
:: Enabling hot-plug : [SUCCESS]
::
::
: Populating /dev : [SUCCESS]
[SUCCESS]
::
::
:: Setting PATH
::
: syslogd : [SUCCESS]
: telnetd : [SUCCESS]
Please press Enter to activate this console.
::
:: Setting shell environment ...
::
: Path
: Aliases
: Touch Screen
::
:: Done
::
[root at arago /]# echo 1 > ./sys/devices/ocp.2/wkup_m3.4/firmware/am335x-pm-firmware.bin/loading
[root at arago /]# cat binary_blob > ./sys/devices/ocp.2/wkup_m3.4/firmware/am335x-pm-firmware.bin/data
[root at arago /]# echo 0 > ./sys/devices/ocp.2/wkup_m3.4/firmware/am335x-pm-firmware.bin/loading
[ 28.770356] Copied the M3 firmware to UMEM
[ 28.778178] omap_hwmod: wkup_m3: _wait_target_disable failed
[root at arago /]# echo mem > /sys/power/state
[ 32.959753] PM: Syncing filesystems ... done.
[ 32.988434] Freezing user space processes ... (elapsed 0.02 seconds) done.
[ 33.016120] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[ 33.047607] Suspending console(s) (use no_console_suspend to debug)
[ 33.070420] PM: suspend of devices complete after 11.538 msecs
[ 33.074095] PM: late suspend of devices complete after 3.651 msecs
[ 33.079135] PM: noirq suspend of devices complete after 5.011 msecs
[ 33.079196] Disabling non-boot CPUs ...
[ 33.083923] GFX domain entered low power state
[ 33.083973] Successfully transitioned to low power state
[ 33.087132] PM: noirq resume of devices complete after 2.663 msecs
[ 33.090629] PM: early resume of devices complete after 2.346 msecs
[ 33.097607] PM: resume of devices complete after 6.951 msecs
[ 33.155869] Restarting tasks ... done.
[root at arago /]#
All the patches have been run through checkpatch and i have also
tried a few OMAP build configs that Paul uses to ensure that these
patches do not introduce any new build warnings/errors for the OMAP
family.
A few TODOs
0. Test all the patches on OMAP platforms like BeagleBoard
1. Add support for DDR3 in the assembly code
2. Update the DTB documentation for OCMCRAM and WKUP_M3 nodes.
Regards,
Vaibhav
[1] http://www.ti.com/litv/pdf/spruh73f
[2] http://arago-project.org/git/projects/?p=am33x-cm3.git;a=summary
[3] https://patchwork.kernel.org/patch/1661771/
Vaibhav Bedia (15):
ARM: OMAP2+: mailbox: Add an API for flushing the FIFO
ARM: OMAP2+: mailbox: Add support for AM33XX
ARM: OMAP: mailbox: Convert to device_initcall
ARM: OMAP2+: hwmod: Update the reset API for AM33XX
ARM: OMAP2+: AM33XX: Update WKUP_M3 hwmod entry for reset status
ARM: OMAP2+: hwmod: Enable OCMCRAM registration in AM33XX
ARM: OMAP2+: hwmod: Update the hwmod data for TPTCs in AM33XX
ARM: OMAP2+: hwmod: Fix the omap_hwmod_addr_space for CPGMAC0
ARM: OMAP: AM33XX: Remove unnecessary include and use __ASSEMBLER__
macros
ARM: OMAP2+: control: Add some AM33XX Control module registers
ARM: OMAP: timer: Interchange clksrc and clkevt for AM33XX
ARM: OMAP: timer: Add suspend-resume callbacks for clockevent device
ARM: DTS: AM33XX: Add nodes for OCMCRAM and Mailbox
ARM: OMAP2+: omap2plus_defconfig: Enable Mailbox
ARM: OMAP2+: AM33XX: Basic suspend resume support
arch/arm/boot/dts/am33xx.dtsi | 11 +
arch/arm/configs/omap2plus_defconfig | 2 +
arch/arm/mach-omap2/Makefile | 2 +
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/clock33xx_data.c | 1 +
arch/arm/mach-omap2/cm33xx.h | 10 +-
arch/arm/mach-omap2/common.h | 10 +
arch/arm/mach-omap2/control.h | 29 ++
arch/arm/mach-omap2/io.c | 7 +
arch/arm/mach-omap2/mailbox.c | 79 +++-
arch/arm/mach-omap2/omap_hwmod.c | 5 +-
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 15 +-
arch/arm/mach-omap2/pm.h | 7 +
arch/arm/mach-omap2/pm33xx.c | 429 +++++++++++++++++++++
arch/arm/mach-omap2/pm33xx.h | 100 +++++
arch/arm/mach-omap2/prm33xx.c | 15 +-
arch/arm/mach-omap2/prm33xx.h | 4 +-
arch/arm/mach-omap2/sleep33xx.S | 571 ++++++++++++++++++++++++++++
arch/arm/mach-omap2/timer.c | 33 ++-
arch/arm/plat-omap/include/plat/mailbox.h | 3 +
arch/arm/plat-omap/mailbox.c | 35 ++
arch/arm/plat-omap/sram.c | 10 +-
arch/arm/plat-omap/sram.h | 2 +
23 files changed, 1343 insertions(+), 38 deletions(-)
create mode 100644 arch/arm/mach-omap2/pm33xx.c
create mode 100644 arch/arm/mach-omap2/pm33xx.h
create mode 100644 arch/arm/mach-omap2/sleep33xx.S
^ permalink raw reply
* [PATCH 01/15] ARM: OMAP2+: mailbox: Add an API for flushing the FIFO
From: Vaibhav Bedia @ 2012-11-02 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351859566-24818-1-git-send-email-vaibhav.bedia@ti.com>
On AM33XX, the mailbox module between the MPU and the
WKUP-M3 co-processor facilitates a one-way communication.
MPU uses the assigned mailbox sub-module to issue the
interrupt to the WKUP-M3 co-processor which then goes
and reads the the IPC data from registers in the control
module.
WKUP-M3 is in the L4_WKUP and does not have any access to
the Mailbox module. Due to this limitation, the MPU is
completely responsible for FIFO maintenance and interrupt
generation. MPU needs to ensure that the FIFO does not
overflow by reading by the assigned mailbox sub-module.
This patch adds an API in the mailbox code which the MPU
can use to empty the FIFO by issuing a readback command.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
---
arch/arm/mach-omap2/mailbox.c | 42 ++++++++++++++++++++---------
arch/arm/plat-omap/include/plat/mailbox.h | 3 ++
arch/arm/plat-omap/mailbox.c | 35 ++++++++++++++++++++++++
3 files changed, 67 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 0d97456..f38b4fa 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -123,6 +123,20 @@ static int omap2_mbox_fifo_full(struct omap_mbox *mbox)
return mbox_read_reg(fifo->fifo_stat);
}
+static int omap2_mbox_fifo_needs_flush(struct omap_mbox *mbox)
+{
+ struct omap_mbox2_fifo *fifo =
+ &((struct omap_mbox2_priv *)mbox->priv)->tx_fifo;
+ return mbox_read_reg(fifo->msg_stat);
+}
+
+static mbox_msg_t omap2_mbox_fifo_readback(struct omap_mbox *mbox)
+{
+ struct omap_mbox2_fifo *fifo =
+ &((struct omap_mbox2_priv *)mbox->priv)->tx_fifo;
+ return (mbox_msg_t) mbox_read_reg(fifo->msg);
+}
+
/* Mailbox IRQ handle functions */
static void omap2_mbox_enable_irq(struct omap_mbox *mbox,
omap_mbox_type_t irq)
@@ -205,19 +219,21 @@ static void omap2_mbox_restore_ctx(struct omap_mbox *mbox)
}
static struct omap_mbox_ops omap2_mbox_ops = {
- .type = OMAP_MBOX_TYPE2,
- .startup = omap2_mbox_startup,
- .shutdown = omap2_mbox_shutdown,
- .fifo_read = omap2_mbox_fifo_read,
- .fifo_write = omap2_mbox_fifo_write,
- .fifo_empty = omap2_mbox_fifo_empty,
- .fifo_full = omap2_mbox_fifo_full,
- .enable_irq = omap2_mbox_enable_irq,
- .disable_irq = omap2_mbox_disable_irq,
- .ack_irq = omap2_mbox_ack_irq,
- .is_irq = omap2_mbox_is_irq,
- .save_ctx = omap2_mbox_save_ctx,
- .restore_ctx = omap2_mbox_restore_ctx,
+ .type = OMAP_MBOX_TYPE2,
+ .startup = omap2_mbox_startup,
+ .shutdown = omap2_mbox_shutdown,
+ .fifo_read = omap2_mbox_fifo_read,
+ .fifo_write = omap2_mbox_fifo_write,
+ .fifo_empty = omap2_mbox_fifo_empty,
+ .fifo_full = omap2_mbox_fifo_full,
+ .fifo_needs_flush = omap2_mbox_fifo_needs_flush,
+ .fifo_readback = omap2_mbox_fifo_readback,
+ .enable_irq = omap2_mbox_enable_irq,
+ .disable_irq = omap2_mbox_disable_irq,
+ .ack_irq = omap2_mbox_ack_irq,
+ .is_irq = omap2_mbox_is_irq,
+ .save_ctx = omap2_mbox_save_ctx,
+ .restore_ctx = omap2_mbox_restore_ctx,
};
/*
diff --git a/arch/arm/plat-omap/include/plat/mailbox.h b/arch/arm/plat-omap/include/plat/mailbox.h
index cc3921e..e136529 100644
--- a/arch/arm/plat-omap/include/plat/mailbox.h
+++ b/arch/arm/plat-omap/include/plat/mailbox.h
@@ -29,6 +29,8 @@ struct omap_mbox_ops {
void (*fifo_write)(struct omap_mbox *mbox, mbox_msg_t msg);
int (*fifo_empty)(struct omap_mbox *mbox);
int (*fifo_full)(struct omap_mbox *mbox);
+ int (*fifo_needs_flush)(struct omap_mbox *mbox);
+ mbox_msg_t (*fifo_readback)(struct omap_mbox *mbox);
/* irq */
void (*enable_irq)(struct omap_mbox *mbox,
omap_mbox_irq_t irq);
@@ -61,6 +63,7 @@ struct omap_mbox {
struct blocking_notifier_head notifier;
};
+int omap_mbox_msg_rx_flush(struct omap_mbox *mbox);
int omap_mbox_msg_send(struct omap_mbox *, mbox_msg_t msg);
void omap_mbox_init_seq(struct omap_mbox *);
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index 42377ef..cb9754a 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -59,6 +59,14 @@ static inline int mbox_fifo_full(struct omap_mbox *mbox)
{
return mbox->ops->fifo_full(mbox);
}
+static inline int mbox_fifo_needs_flush(struct omap_mbox *mbox)
+{
+ return mbox->ops->fifo_needs_flush(mbox);
+}
+static inline mbox_msg_t mbox_fifo_readback(struct omap_mbox *mbox)
+{
+ return mbox->ops->fifo_readback(mbox);
+}
/* Mailbox IRQ handle functions */
static inline void ack_mbox_irq(struct omap_mbox *mbox, omap_mbox_irq_t irq)
@@ -116,6 +124,33 @@ out:
}
EXPORT_SYMBOL(omap_mbox_msg_send);
+/*
+ * Flush the Rx FIFO by reading back the messages
+ * Since the normal expectation is that the Rx will do the
+ * reading, add a debug message to indicate if we really flush
+ *
+ * Returns the no. of messages read back
+ */
+int omap_mbox_msg_rx_flush(struct omap_mbox *mbox)
+{
+ int ret = 0;
+ mbox_msg_t msg;
+
+ while (mbox_fifo_needs_flush(mbox)) {
+ msg = mbox_fifo_readback(mbox);
+ ret++;
+ }
+
+ if (ret) {
+ /* no more messages in the fifo. clear IRQ source. */
+ ack_mbox_irq(mbox, IRQ_RX);
+ pr_debug("Flushed %s Rx FIFO by reading back\n", mbox->name);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(omap_mbox_msg_rx_flush);
+
static void mbox_tx_tasklet(unsigned long tx_data)
{
struct omap_mbox *mbox = (struct omap_mbox *)tx_data;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 02/15] ARM: OMAP2+: mailbox: Add support for AM33XX
From: Vaibhav Bedia @ 2012-11-02 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351859566-24818-1-git-send-email-vaibhav.bedia@ti.com>
Mailbox IP on AM33XX, is the same as that present
in OMAP4. The single instance of Mailbox module
contains 8 sub-modules and facilitates communication
between MPU, PRUs and WKUP_M3.
The first mailbox sub-module is assigned for
communication between MPU and WKUP-M3.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
---
arch/arm/mach-omap2/mailbox.c | 35 ++++++++++++++++++++++++++++++++++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index f38b4fa..7a343aa 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -155,7 +155,7 @@ static void omap2_mbox_disable_irq(struct omap_mbox *mbox,
struct omap_mbox2_priv *p = mbox->priv;
u32 bit = (irq == IRQ_TX) ? p->notfull_bit : p->newmsg_bit;
- if (!cpu_is_omap44xx())
+ if (!cpu_is_omap44xx() || !soc_is_am33xx())
bit = mbox_read_reg(p->irqdisable) & ~bit;
mbox_write_reg(bit, p->irqdisable);
@@ -358,6 +358,32 @@ struct omap_mbox mbox_2_info = {
struct omap_mbox *omap4_mboxes[] = { &mbox_1_info, &mbox_2_info, NULL };
#endif
+#if defined(CONFIG_SOC_AM33XX)
+static struct omap_mbox2_priv omap2_mbox_wkup_m3_priv = {
+ .tx_fifo = {
+ .msg = MAILBOX_MESSAGE(0),
+ .fifo_stat = MAILBOX_FIFOSTATUS(0),
+ .msg_stat = MAILBOX_MSGSTATUS(0),
+ },
+ .rx_fifo = {
+ .msg = MAILBOX_MESSAGE(1),
+ .msg_stat = MAILBOX_MSGSTATUS(1),
+ },
+ .irqenable = OMAP4_MAILBOX_IRQENABLE(3),
+ .irqstatus = OMAP4_MAILBOX_IRQSTATUS(3),
+ .irqdisable = OMAP4_MAILBOX_IRQENABLE_CLR(3),
+ .notfull_bit = MAILBOX_IRQ_NOTFULL(0),
+ .newmsg_bit = MAILBOX_IRQ_NEWMSG(0),
+};
+
+struct omap_mbox mbox_wkup_m3_info = {
+ .name = "wkup_m3",
+ .ops = &omap2_mbox_ops,
+ .priv = &omap2_mbox_wkup_m3_priv,
+};
+struct omap_mbox *am33xx_mboxes[] = { &mbox_wkup_m3_info, NULL };
+#endif
+
static int __devinit omap2_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
@@ -392,6 +418,13 @@ static int __devinit omap2_mbox_probe(struct platform_device *pdev)
list[0]->irq = list[1]->irq = platform_get_irq(pdev, 0);
}
#endif
+#if defined(CONFIG_SOC_AM33XX)
+ else if (soc_is_am33xx()) {
+ list = am33xx_mboxes;
+
+ list[0]->irq = platform_get_irq(pdev, 0);
+ }
+#endif
else {
pr_err("%s: platform not supported\n", __func__);
return -ENODEV;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 03/15] ARM: OMAP: mailbox: Convert to device_initcall
From: Vaibhav Bedia @ 2012-11-02 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351859566-24818-1-git-send-email-vaibhav.bedia@ti.com>
The power management code for AM33XX is a late_initcall
and the PM features depend on the mailbox for IPC.
In preparation for this, convert the mailbox init to
a device_initcall.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
---
arch/arm/mach-omap2/mailbox.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/mailbox.c b/arch/arm/mach-omap2/mailbox.c
index 7a343aa..8c63c86 100644
--- a/arch/arm/mach-omap2/mailbox.c
+++ b/arch/arm/mach-omap2/mailbox.c
@@ -469,7 +469,7 @@ static void __exit omap2_mbox_exit(void)
platform_driver_unregister(&omap2_mbox_driver);
}
-module_init(omap2_mbox_init);
+device_initcall(omap2_mbox_init);
module_exit(omap2_mbox_exit);
MODULE_LICENSE("GPL v2");
--
1.7.0.4
^ permalink raw reply related
* [PATCH 04/15] ARM: OMAP2+: hwmod: Update the reset API for AM33XX
From: Vaibhav Bedia @ 2012-11-02 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351859566-24818-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 take care of the same to ensure
that the reset line properly deasserted.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
---
arch/arm/mach-omap2/omap_hwmod.c | 5 +----
arch/arm/mach-omap2/prm33xx.c | 15 +++++++--------
arch/arm/mach-omap2/prm33xx.h | 2 +-
3 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 37eeb45..a1d5835 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2944,11 +2944,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 53ec9cb..0f29cb9 100644
--- a/arch/arm/mach-omap2/prm33xx.c
+++ b/arch/arm/mach-omap2/prm33xx.c
@@ -112,23 +112,22 @@ 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;
-
- /* Check the current status to avoid de-asserting the line twice */
- if (am33xx_prm_is_hardreset_asserted(shift, inst, rstctrl_offs) == 0)
- return -EEXIST;
+ u32 mask = 1 << st_shift;
/* 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 3f25c56..181fdab 100644
--- a/arch/arm/mach-omap2/prm33xx.h
+++ b/arch/arm/mach-omap2/prm33xx.h
@@ -124,6 +124,6 @@ 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
--
1.7.0.4
^ permalink raw reply related
* [PATCH 05/15] ARM: OMAP2+: AM33XX: Update WKUP_M3 hwmod entry for reset status
From: Vaibhav Bedia @ 2012-11-02 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351859566-24818-1-git-send-email-vaibhav.bedia@ti.com>
Add the reset status offset for WKUP_M3 in the hwmod data
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 3c235d8..2e470ce 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.7.0.4
^ permalink raw reply related
* [PATCH 06/15] ARM: OMAP2+: hwmod: Enable OCMCRAM registration in AM33XX
From: Vaibhav Bedia @ 2012-11-02 12:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351859566-24818-1-git-send-email-vaibhav.bedia@ti.com>
The hwmod data for OCMCRAM in AM33XX was commented out.
This data is needed by the power management code, hence
uncomment the same and register the OCP interface for it.
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 2e470ce..ec3fbb2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -415,7 +415,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,6 +480,7 @@ static struct omap_hwmod am33xx_debugss_hwmod = {
},
},
};
+#endif
/* ocmcram */
static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = {
@@ -501,6 +501,7 @@ static struct omap_hwmod am33xx_ocmcram_hwmod = {
},
};
+#if 0
/* ocpwp */
static struct omap_hwmod_class am33xx_ocpwp_hwmod_class = {
.name = "ocpwp",
@@ -3331,6 +3332,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,
@@ -3401,6 +3409,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.7.0.4
^ permalink raw reply related
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