Re: [PATCH 0/5] Pass data lines and pixel format info from panel driver to interface
On Fri, 2012-08-10 at 16:07 +0530, Archit Taneja wrote: > This is a continuation of the work started in the series: > > http://marc.info/?l=linux-omap&m=134381744304672&w=2 > > This makes the panel driver call interface specific functions to configure the > data lines and pixel format requested by the panel. > > Configuration of data lines doesn't happen for DSI or HDMI. For DSI, this > information is more complex and is taken care by omapdss_dsi_configure_pins(), > for HDMI, the number of TMDS lines is always fixed. > > Configuration of pixel format is done only for DSI in command mode and RFBI. > Currently, these new functions take different arguments, > omapdss_dsi_set_pixel_format() takes pixel format of type > omap_dss_dsi_pixel_format enum, and RFBI omapdss_rfbi_set_pixel_size() takes > the pixel size directly. It would be good if these could be merged by using > some sort of MIPI standard for pixel formats. Having the same argument would > help in having a common interface op in the future. This series looks good. Tomi signature.asc Description: This is a digitally signed message part
RE: [PATCH-V3] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data
On Tue, Aug 14, 2012 at 13:59:12, Tony Lindgren wrote:
> Hi,
>
> * Paul Walmsley [120726 13:07]:
> > On Wed, 25 Jul 2012, Paul Walmsley wrote:
> >
> > > These IP blocks and the ECAP IP blocks have periods in their names.
> > > The rest of the IP block named in the file don't use periods -- which
> > > is also the style used by the rest of the OMAP SoCs. Is there
> > > some reason that these have periods in their names?
> >
> > I've changed those to match the rest of the names, and queued the
> > following for 3.7.
> >
> > Thanks again for all the hard work you all put into this. I realize that
> > with all the upstream changes, this was probably a little painful for you.
> > But from my perspective you've been a pleasure to work with through the
> > process.
>
> As am33xx and omap5 are DT only, we should start moving towards getting
> rid of grep -E "irq|pa_start|pa_end|dma" in this patch and get the standard
> data from .dtsi files instead.
>
It may not be so straight, given the fact that hwmod layer
requires these resources, as hwmod is responsible to configure SYSCONF
register of the device (happens very early at core_init level).
Somehow we have to have some mechanism to initialize " _mpu_rt_va" before
core_init call, which will take DT resources and initialize accordingly.
Another dependency we will have is on system timers, Jon has already done
some initial work on this, but I believe we did not concluded on the it.
I will re-start the thread again, since in any case DT support in timer is
required.
> Alternatively we could get rid of the names and match the module based on
> pa_start and pa_end.
>
Just FYI, from resource perspective, I have changed omap_device layer for DT
resources only (still need hwmod resources as explained above) and patch
looks something like (and it works) -
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index c490240..cb481fe 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -528,10 +528,15 @@ struct omap_device *omap_device_alloc(struct
platform_device *pdev,
* HACK: Ideally the resources from DT should match, and hwmod
* should just add the missing ones. Since the name is not
* properly populated by DT, stick to hwmod resources only.
+*
+* But in case of all new devices, like AM33XX and OMAP5, where
+* only DT boot is supported, stick to DT resources only.
*/
- if (pdev->num_resources && pdev->resource)
+ if (pdev->num_resources && pdev->resource) {
dev_warn(&pdev->dev, "%s(): resources already allocated %d\n",
__func__, pdev->num_resources);
+ goto skip_res_override;
+ }
res_count = omap_device_count_resources(od);
if (res_count > 0) {
@@ -550,6 +555,7 @@ struct omap_device *omap_device_alloc(struct
platform_device *pdev,
goto oda_exit3;
}
+skip_res_override:
if (!pm_lats) {
pm_lats = omap_default_latency;
pm_lats_cnt = ARRAY_SIZE(omap_default_latency);
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
On 7/23/2012 8:54 PM, Jon Hunter wrote:
> Hi Rob,
>
> On 07/16/2012 10:56 AM, Jon Hunter wrote:
>> Hi Rob,
>>
>> On 07/13/2012 09:15 PM, Rob Herring wrote:
>>> On 07/13/2012 05:26 PM, Jon Hunter wrote:
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add documentation for timer properties specific to OMAP.
For each timer an alias is being added. The purpose for doing this is
because
the OMAP dmtimer driver uses an ID to distinguish between the different
timer
instances. For example, a timer can be requested by its ID. By adding an
alias
for each timer we can then use the function of_alias_get_id() to extract
the
ID for each timer from the alias name. The same method is used for the TTY
serial devices. If it is preferred that such an alias is not added and
there
is a better way to pass an ID from device-tree let me know.
>>>
>>> I'm not sure this is really a good use of aliases. UARTs use aliases
>>> because it is important that the UART number to tty number is known and
>>> fixed. IIUC, as an example you are picking timer1 because it has
>>> properties X, Y and Z. If so, then you should describe those h/w
>>> properties within the timer nodes so you can pick which timer to use
>>> based on it's h/w properties.
>>
>> Thanks for the feedback. What you suggest could definitely work for most
>> timers. The only item that I would need to resolve here is the handling
>> of system timers (ie. those used for clockevents and clocksource). These
>> system timers (for OMAP) are reserved during early boot based upon the
>> timer ID today and so this is before the actual main timer driver has
>> been probed and all the attributes of the timers has been read for
>> device-tree.
>>
>> One thought would be to move the reservation of the system timers out of
>> the kernel and into device-tree itself. Then we query device tree on
>> start-up to see which we should use. I am wondering if this could be a
>> better use of alias? For example, say I want to use timer1 as my
>> clockevent timer and so I could have an alias of ...
>>
>> alias {
>> clockevent_timer = &timer1;
>> }
>>
>> However, I am not sure if this is even correct, because there does not
>> appear to be an API to search the aliases by name and return the
>> phandle, just of_alias_get_id(). Alternatively, I could add another
>> property called "ti,timer-clockevent" that is populated for the timer
>> used as the clockevent timer.
>
> Do you have any inputs on the above? Does it make sense to reserve timer
> resources for kernel system timers in device-tree?
>
Hey Jon,
Did we get conclude on this? I haven't got anything further on this
thread, this may block baseport support for the new devices in omap2
family, like AM33xx and OMAP5.
Thanks,
Vaibhav
> Cheers
> Jon
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC RESEND 2/4] ARM: OMAP3: Dynamically disable secure timer nodes for secure devices
On 7/14/2012 3:56 AM, Jon Hunter wrote:
> OMAP3 devices may or may not have security features enabled. Security enabled
> devices are known as high-secure (HS) and devices without security are known
> as
> general purpose (GP).
>
> For OMAP3 devices there are 12 general purpose timers available. On secure
> devices the 12th timer is reserved for secure usage and so cannot be used by
> the kernel, where as for a GP device it is available. We can detect the OMAP
> device type, secure or GP, at runtime via an on-chip register. Today, when not
> using DT, we do not register the 12th timer as a linux device if the device is
> secure.
>
> When using device tree, device tree is going to register all the timer devices
> it finds in the device tree blob. To prevent device tree from registering 12th
> timer on a secure OMAP3 device we can add a status property to the timer
> binding with the value "disabled" at boot time. Note that timer 12 on a OMAP3
> device has a property "ti,timer-secure" to indicate that it will not be
> available on a secure device and so for secure OMAP3 devices, we search for
> timers with this property and then disable them. Using the prom_add_property()
> function to dynamically add a property was a recommended approach suggested by
> Rob Herring [1].
>
> I have tested this on an OMAP3 GP device and faking it to pretend to be a
> secure device to ensure that any timers marked with "ti,timer-secure" are not
> registered on boot. I have also made sure that all timers are registered as
> expected on a GP device by default.
>
> [1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203
>
> Signed-off-by: Jon Hunter
> ---
> arch/arm/mach-omap2/board-generic.c |1 +
> arch/arm/mach-omap2/common.h|1 +
> arch/arm/mach-omap2/timer.c | 36
> +++
> 3 files changed, 38 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c
> index 6f93a20..20124d7 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -40,6 +40,7 @@ static struct of_device_id omap_dt_match_table[] __initdata
> = {
> static void __init omap_generic_init(void)
> {
> omap_sdrc_init(NULL, NULL);
> + omap_dmtimer_init();
>
> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
> }
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 1f65b18..d6a4875 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -326,6 +326,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params
> *sdrc_cs0,
> struct omap_sdrc_params *sdrc_cs1);
> struct omap2_hsmmc_info;
> extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
> +extern void omap_dmtimer_init(void);
>
> #endif /* __ASSEMBLER__ */
> #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 13d20c8..e3b9931 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -482,6 +483,41 @@ static int __init omap2_dm_timer_init(void)
> }
> arch_initcall(omap2_dm_timer_init);
>
> +static struct property timer_disabled = {
> + .name = "status",
> + .length = sizeof("disabled"),
> + .value = "disabled",
> +};
> +
> +static struct of_device_id omap3_timer_match[] __initdata = {
> + { .compatible = "ti,omap3-timer", },
> + { }
> +};
> +
> +/**
> + * omap_dmtimer_init - initialisation function when device tree is used
> + *
> + * For secure OMAP3 devices, timers with device type "timer-secure" cannot
> + * be used by the kernel as they are reserved. Therefore, to prevent the
> + * kernel registering these devices remove them dynamically from the device
> + * tree on boot.
> + */
> +void __init omap_dmtimer_init(void)
> +{
> + struct device_node *np;
> +
> + if (!cpu_is_omap34xx())
> + return;
> +
Sorry for responding so late, but why only omap34xx check here?
Isn't this applicable to all omap & non-omap devices?
Thanks,
Vaibhav
> + /* If we are a secure device, remove any secure timer nodes */
> + if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
> + for_each_matching_node(np, omap3_timer_match) {
> + if (of_get_property(np, "ti,timer-secure", NULL))
> + prom_add_property(np, &timer_disabled);
> + }
> + }
> +}
> +
> /**
> * omap2_override_clocksource - clocksource override with user configuration
> *
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: AM33XX: board-generic: Add of_dev_auxdata to fix dev_id for CAN module
On 8/8/2012 5:13 PM, Hiremath, Vaibhav wrote:
> On Wed, Aug 08, 2012 at 07:38:01, Rob Herring wrote:
>> On 08/07/2012 10:53 AM, Hiremath, Vaibhav wrote:
>>> On Tue, Aug 07, 2012 at 20:49:48, Rob Herring wrote:
On 08/07/2012 08:37 AM, Vaibhav Hiremath wrote:
> If the module requires only one clocksource to function, then
> driver can very well call clk_get() api with "con_id = NULL",
>
>clk = clk_get(dev, NULL);
>
> And platform code should respect this and return valid clk handle.
> That means, now the clk_get() api would rely on dev_id, and platform
> code should either have clk node with matching dev_id (with con_id=NULL)
> or return dummy clk node.
>
> With DT support, we can fix the dev_id for particular module
> using "struct of_dev_auxdata" to satisfy above clk framework requirement.
>
> In case of AM33XX, we required this for the DCAN module, so this
> patch adds "of_dev_auxdata" for both DCAN_0/1 instances.
>
> Signed-off-by: Vaibhav Hiremath
> Cc: Tony Lindgren
> Cc: Paul Walmsley
> Cc: Benoit Cousson
> Cc: Grant Likely
> ---
> This patch is boot tested on BeagleBone platform, and checked for
> clk_get() return value in d_can module driver.
>
> arch/arm/mach-omap2/board-generic.c | 18 +-
> 1 files changed, 17 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c
> index 6f93a20..c9b7903 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -37,11 +37,27 @@ static struct of_device_id omap_dt_match_table[]
> __initdata = {
> { }
> };
>
> +/*
> + * Lookup table for attaching a specific name and platform_data pointer
> to
> + * devices as they get created by of_platform_populate(). Ideally this
> table
> + * would not exist, but the current clock implementation depends on some
> devices
> + * having a specific name OR to satisfy NULL con_id requirement from
> driver.
> + */
> +static const struct of_dev_auxdata am33xx_auxdata_lookup[] __initconst =
> {
> + OF_DEV_AUXDATA("bosch,d_can", 0x481cc000, "d_can.0", NULL),
> + OF_DEV_AUXDATA("bosch,d_can", 0x481d, "d_can.1", NULL),
> + { },
> +};
Adding an additional clkdev lookup accomplishes the same thing and is a
cleaner solution.
>>>
>>> That is also required and I have submitted patch for the same -
>>>
>>> http://www.spinics.net/lists/arm-kernel/msg187998.html
>>
>> That only adds the non-DT name. What I'm saying is you can have 2 lookup
>> names for the same clock.
>>
>>>
>>> With DT support, I am getting dev_id as -
>>>
>>> - Without "reg" property: d_can.16 and d_can.17,
>>>(I believe it changes dynamically here)
>>>
>>> - With "reg" property: 481cc000.d_can and 481d.d_can
>>>
>>> Which is not so intuitive, I would like to see them as per Spec/TRM, so
>>> doesn't this patch make sense?
>>
>> The spec doesn't have a base address for the module? This name is going
>> to get used in sysfs anyway, and the old name should be going away.
>>
>
> This is certainly going to change user interface change, and I thought we
> should not change the user interface irrespective of whether it is DT or
> non-DT.
> Few points, which I do care about, are,
>
> 1. request_irq():
>For the driver if I am using dev_name(dev) as for the 3rd argument, which
>will now different with DT support - brings change in user interface.
>
>Non-DT:
> #cat /proc/interrupts
>CPU0
> 52: 0 INTC xxx0
> 55: 0 INTC xxx1
>
>DT:
> #cat /proc/interrupts
>CPU0
> 52: 0 INTC 481cc000.xxx
> 55: 0 INTC 481d.xxx
>
>
> 2. SYSFS:
>For example,
>Without auxdata:
> /sys/devices/481cc000.xxx/
> /sys/devices/481d.xxx/
>
>With auxdata:
> /sys/devices/xxx.0/
> /sys/devices/xxx.1/
>
>From user perspective, I still would not want to change the existing
>naming convention.
>
> 3. Certainly I don't want user to go back to spec everytime to find out
>which address is mapped to which instance of module.
>Also, in addition to that, in case of SoC's like AM33xx (for that matter,
>any embedded SoC) we have different domains and modules are placed in
>different domains as per use-cases.
>For example, in this case, can0 is places in wakeup domain and can1 is
>placed in per-domain. Some boards might use only one instance or some
>board might use both of them.
>
>I still would like to keep instance number wherever user interface comes
>into picture and populate base address as an additional info to user.
>
>
> I may be missing something, may be I am not able to see the bigger pictu
Re: [PATCH] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays
Hi,
On Tue, 2012-07-17 at 10:01 -0400, Raphael Assenat wrote:
> Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays.
>
This needed to be converted to work with latest kernel. See patch below.
I've applied the patch to my dev branch, mail me if it's not correct.
commit f4e491f283266b53a926eb3c9017505b04786b9b (HEAD, dev)
Author: Raphael Assenat
Date: Tue Jul 17 10:01:40 2012 -0400
OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays
Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays.
Signed-off-by: Raphael Assenat
Signed-off-by: Tomi Valkeinen
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index bc5af25..ae862bb 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -538,6 +538,82 @@ static struct panel_config generic_dpi_panels[] = {
},
.name = "primeview_pd104slf",
},
+
+ /* ChiMei G121S1-L01 */
+ {
+ {
+ .x_res = 800,
+ .y_res = 600,
+
+ .pixel_clock= 39700,
+
+ .hfp= 128,
+ .hsw= 1,
+ .hbp= 128,
+
+ .vfp= 28,
+ .vsw= 1,
+ .vbp= 28,
+
+ .vsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
+ .hsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
+ },
+ .name = "chimei_g121s1-l01",
+ },
+
+ /* ChiMei G121S1-L02 */
+ {
+ {
+ .x_res = 800,
+ .y_res = 600,
+
+ .pixel_clock= 4,
+
+ .hfp= 1,
+ .hsw= 256,
+ .hbp= 1,
+
+ .vfp= 1,
+ .vsw= 28,
+ .vbp= 1,
+
+ .vsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
+ .hsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
+ },
+ .name = "chimei_g121s1-l02",
+ },
+
+
+ /* ChiMei G121X1-L01 */
+ {
+ {
+ .x_res = 1024,
+ .y_res = 768,
+
+ .pixel_clock= 64900,
+
+ .hfp= 160,
+ .hsw= 1,
+ .hbp= 160,
+
+ .vfp= 38,
+ .vsw= 1,
+ .vbp= 38,
+
+ .vsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
+ .hsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
+ },
+ .name = "chimei_g121x1-l01",
+ },
};
struct panel_drv_data {
signature.asc
Description: This is a digitally signed message part
[PATCH v5 0/8] ARM: OMAP2+: PM: introduce the power domains functional states
Here is a re-spin after some comments and suggestions after review. Implement the functional states for the power domains: - unify the API to use the functional states. pwrdm_set_next_fpwrst now is the function to control the power domains power and logic states, - reorganize the powerdomain API in internal and external parts, in powerdomain.h [1] - protect the power domain state change by a lock in pwrdm_set_next_fpwrst, - introduce the functional states for power domains power states and logic power states, and the conversion functions between the functional and internal states, - program the logic power state of power domains from the functional states, in pwrdm_set_next_fpwrst - convert the OMAP2/3/4 PM code to use the updated API, - provide the power domains statistics by functional states, - provide ftrace tracepoints with the functional state, - provide error logs in critical code, which makes the development easier. Note: [1] the physical split of internal and external APIs into different header files is not part of this series, it comes as a separate patch set. Based on mainline kernel 3.6.0-rc1. Tested on OMAP3 Beagleboard, with suspend and cpuidle in RET and OFF modes. History: v5: - complete rework after review and suggestions, - improved locking on next state read/write; spinlock instead of mutex - added more error logging in critical code, v4: - reworked the code after internal review and testing with OMAP3&4 device OFF, - fixed the tracepoints generation code, - introduce a function that returns power domains achievable functional states, in order to return a valid state for power domains that only support some of the power states. Although it has been tested OK the code is in RFC state. v3: - fix a bug in OMAP3 cpuidle which prevented the IO wake-ups in PER v2: - add the logic power states, - provide the power domains statistics by functional states v1: - initial implementation, in RFC state Jean Pihet (7): ARM: OMAP2+: PM: introduce power domains functional states ARM: OMAP2+: PM: introduce power domains achievable functional states ARM: OMAP2+: PM: add a lock to protect the powerdomains next state ARM: OMAP2+: PM: use the functional power states API ARM: OMAP2+: PM: use power domain functional state in stats counters ARM: OMAP2+: PM debug: trace the functional power domains states ARM: OMAP2+: PM: reorganize the powerdomain API in public and private parts Nishanth Menon (1): ARM: OMAP2+: powerdomain: add error logs arch/arm/mach-omap2/cpuidle34xx.c | 58 ++-- arch/arm/mach-omap2/cpuidle44xx.c | 24 +- arch/arm/mach-omap2/omap-hotplug.c |2 +- arch/arm/mach-omap2/omap-mpuss-lowpower.c | 39 ++-- arch/arm/mach-omap2/pm-debug.c | 15 +- arch/arm/mach-omap2/pm24xx.c | 14 +- arch/arm/mach-omap2/pm34xx.c | 79 +++--- arch/arm/mach-omap2/pm44xx.c | 24 +- arch/arm/mach-omap2/powerdomain-common.c | 99 ++ arch/arm/mach-omap2/powerdomain.c | 456 +--- arch/arm/mach-omap2/powerdomain.h | 152 ++--- arch/arm/mach-omap2/powerdomain2xxx_3xxx.c |6 + arch/arm/mach-omap2/powerdomain44xx.c |3 + 13 files changed, 753 insertions(+), 218 deletions(-) -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] ARM: OMAP2+: PM: introduce power domains functional states
Introduce the functional states for power domains, which include
the power states and the logic states.
This patch provides the API functions to set and read the power
domains settings and to convert between the functional (i.e. logical)
and the internal (or registers) values.
OMAP2, OMAP3 and OMAP4 platforms are using common conversion routines.
In the new API only the function pwrdm_set_next_fpwrst shall be used
to change a power domain target state, along with the associated
PWRDM_FUNC_* and PWRDM_LOGIC_* macros as the state parameters.
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/powerdomain-common.c | 99
arch/arm/mach-omap2/powerdomain.c | 225 +++-
arch/arm/mach-omap2/powerdomain.h | 45 +-
arch/arm/mach-omap2/powerdomain2xxx_3xxx.c |6 +
arch/arm/mach-omap2/powerdomain44xx.c |3 +
5 files changed, 368 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain-common.c
b/arch/arm/mach-omap2/powerdomain-common.c
index c0aeabf..a0fcee3 100644
--- a/arch/arm/mach-omap2/powerdomain-common.c
+++ b/arch/arm/mach-omap2/powerdomain-common.c
@@ -108,3 +108,102 @@ u32 omap2_pwrdm_get_mem_bank_stst_mask(u8 bank)
return 0;
}
+/**
+ * omap2_pwrdm_fpwrst_to_pwrst - Convert functional (i.e. logical) to
+ * internal (i.e. registers) values for the power domains states.
+ * @struct powerdomain * to convert the values for
+ * @fpwrst: functional power state
+ *
+ * Returns the internal power state value for the power domain, or
+ * -EINVAL in case of invalid parameters passed in.
+ */
+int omap2_pwrdm_fpwrst_to_pwrst(struct powerdomain *pwrdm, u8 fpwrst)
+{
+ int ret;
+
+ switch (fpwrst) {
+ case PWRDM_FUNC_PWRST_ON:
+ ret = PWRDM_POWER_ON;
+ break;
+ case PWRDM_FUNC_PWRST_INACTIVE:
+ ret = PWRDM_POWER_INACTIVE;
+ break;
+ case PWRDM_FUNC_PWRST_CSWR:
+ case PWRDM_FUNC_PWRST_OSWR:
+ ret = PWRDM_POWER_RET;
+ break;
+ case PWRDM_FUNC_PWRST_OFF:
+ ret = PWRDM_POWER_OFF;
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
+/**
+ * omap2_pwrdm_fpwrst_to_logic_pwrst - Convert functional (i.e. logical) to
+ * internal (i.e. registers) values for the power domains logic states.
+ * @struct powerdomain * to convert the values for
+ * @pwrst: functional power state
+ *
+ * Returns the internal logic state value for the power domain, or
+ * -EINVAL in case of invalid parameters passed in.
+ */
+int omap2_pwrdm_fpwrst_to_logic_pwrst(struct powerdomain *pwrdm, u8 fpwrst)
+{
+ int ret;
+
+ switch (fpwrst) {
+ case PWRDM_FUNC_PWRST_ON:
+ case PWRDM_FUNC_PWRST_INACTIVE:
+ case PWRDM_FUNC_PWRST_CSWR:
+ ret = PWRDM_LOGIC_MEM_PWRST_RET;
+ break;
+ case PWRDM_FUNC_PWRST_OSWR:
+ case PWRDM_FUNC_PWRST_OFF:
+ ret = PWRDM_LOGIC_MEM_PWRST_OFF;
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
+/**
+ * omap2_pwrdm_pwrst_to_fpwrst - Convert internal (i.e. registers) to
+ * functional (i.e. logical) values for the power domains states.
+ * @struct powerdomain * to convert the values for
+ * @pwrst: internal power state
+ *
+ * Returns the functional power state value for the power domain, or
+ * -EINVAL in case of invalid parameters passed in.
+ */
+int omap2_pwrdm_pwrst_to_fpwrst(struct powerdomain *pwrdm, u8 pwrst, u8 logic)
+{
+ int ret;
+
+ switch (pwrst) {
+ case PWRDM_POWER_ON:
+ ret = PWRDM_FUNC_PWRST_ON;
+ break;
+ case PWRDM_POWER_INACTIVE:
+ ret = PWRDM_FUNC_PWRST_INACTIVE;
+ break;
+ case PWRDM_POWER_RET:
+ if (logic == PWRDM_LOGIC_MEM_PWRST_RET)
+ ret = PWRDM_FUNC_PWRST_CSWR;
+ else
+ ret = PWRDM_FUNC_PWRST_OSWR;
+ break;
+ case PWRDM_POWER_OFF:
+ ret = PWRDM_FUNC_PWRST_OFF;
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 69b36e1..6fc3c84 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -1,7 +1,7 @@
/*
* OMAP powerdomain control
*
- * Copyright (C) 2007-2008, 2011 Texas Instruments, Inc.
+ * Copyright (C) 2007-2008, 2011-2012 Texas Instruments, Inc.
* Copyright (C) 2007-2011 Nokia Corporation
*
* Written by Paul Walmsley
@@ -128,14 +128,14 @@ static void _update_logic_membank_counters(struct
powerdomain *pwrdm)
prev_logic_pwrst = pwrdm_read_prev_logic_pwrst(pwrdm);
if ((pwrdm->pwrsts_logic_ret == PWRSTS_OFF_RET) &&
- (prev_logic_pwrst == PWRDM_POWER_OFF))
+ (prev_
[PATCH 2/8] ARM: OMAP2+: PM: introduce power domains achievable functional states
Note: the patch is in RFC state because the state machine for setting
the next power domain states needs more discussion. Validated on OMAP3&4
with cpuidle and suspend/resume, though.
Power domains have varied capabilities. When attempting a low power
state such as OFF/RET, a specific min requested state may not be
supported on the power domain. This is because a combination
of system power states where the parent PD's state is not in line
with expectation can result in system instabilities.
This patch provides a function that returns the achievable functional
power state for a power domain and its use by pwrdm_set_next_fpwrst.
The achievable power state is first looked for in the lower power
states in order to maximize the power savings, then if not found
in the higher power states.
Inspired from Tero's work on OMAP4 device OFF support, generalized
to the functional power states and reworked as per Nishant's
suggestions.
Signed-off-by: Jean Pihet
Cc: Tero Kristo
Cc: Nishanth Menon
---
arch/arm/mach-omap2/powerdomain.c | 152 +++--
arch/arm/mach-omap2/powerdomain.h |1 +
2 files changed, 130 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 6fc3c84..3a1f56c 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -199,6 +199,53 @@ static int _pwrdm_post_transition_cb(struct powerdomain
*pwrdm, void *unused)
return 0;
}
+/**
+ * Search down then up for a valid state from a list of allowed states.
+ * Used by pwrdm_get_achievable_fpwrst to look for allowed power and
+ * logic states for a powerdomain.
+ *
+ * @pwrsts: list of allowed states, defined as a bitmask
+ * @pwrst: initial state to be used as a starting point
+ * @min: minimum allowed state
+ * @max: maximum allowed state
+ *
+ * Returns the matching allowed state.
+ */
+static inline int _match_pwrst(u32 pwrsts, int pwrst, int min, int max)
+{
+ int found = 1, new_pwrst = pwrst;
+
+ /*
+* Search lower: if the requested state is not supported
+* try the lower states, stopping at the minimum allowed
+* state
+*/
+ while (!(pwrsts & (1 << new_pwrst))) {
+ if (new_pwrst <= min) {
+ found = 0;
+ break;
+ }
+ new_pwrst--;
+ }
+
+ /*
+* Search higher: if no lower state found fallback to the higher
+* states, stopping at the maximum allowed state
+*/
+ if (!found) {
+ new_pwrst = pwrst;
+ while (!(pwrsts & (1 << new_pwrst))) {
+ if (new_pwrst >= max) {
+ new_pwrst = max;
+ break;
+ }
+ new_pwrst++;
+ }
+ }
+
+ return new_pwrst;
+}
+
/* Public functions */
/**
@@ -553,6 +600,57 @@ int pwrdm_pwrst_to_fpwrst(struct powerdomain *pwrdm, u8
pwrst, u8 logic)
return ret;
}
+/**
+ * pwrdm_get_achievable_fpwrst() - Provide achievable functional state
+ * @pwrdm: struct powerdomain * to set
+ * @fpwrst: minimum functional state we would like to hit
+ * (one of the PWRDM_FUNC_* macros)
+ *
+ * Power domains have varied capabilities. When attempting a low power
+ * state such as OFF/RET, a specific min requested state may not be
+ * supported on the power domain. This is because a combination
+ * of system power states where the parent PD's state is not in line
+ * with expectation can result in system instabilities.
+ *
+ * The achievable power state is first looked for in the lower power
+ * states in order to maximize the power savings, then if not found
+ * in the higher power states.
+ *
+ * Returns the achievable functional power state, or -EINVAL in case of
+ * invalid parameters.
+ */
+int pwrdm_get_achievable_fpwrst(struct powerdomain *pwrdm, u8 fpwrst)
+{
+ int pwrst = pwrdm_fpwrst_to_pwrst(pwrdm, fpwrst);
+ int logic = pwrdm_fpwrst_to_logic_pwrst(pwrdm, fpwrst);
+ int new_fpwrst, new_pwrst, new_logic;
+
+ if (!pwrdm || IS_ERR(pwrdm)) {
+ pr_debug("%s: invalid params: pwrdm=%p, fpwrst=%0x\n",
+__func__, pwrdm, fpwrst);
+ return -EINVAL;
+ }
+
+ if ((pwrst < 0) || (logic < 0)) {
+ pr_debug("%s: invalid params for pwrdm %s, fpwrst=%0x\n",
+__func__, pwrdm->name, fpwrst);
+ return PWRDM_FUNC_PWRST_ON;
+ }
+
+ new_pwrst = _match_pwrst(pwrdm->pwrsts, pwrst, PWRDM_POWER_OFF,
+PWRDM_POWER_ON);
+ new_logic = _match_pwrst(pwrdm->pwrsts_logic_ret, logic,
+PWRDM_LOGIC_MEM_PWRST_OFF,
+PWRDM_LOGIC_MEM_PWRST_RET);
+
+ new_fpwrst = pwrdm_pwrst_to_fpwrst(pwrdm, new_pwrst, new_logic);
+
+
[PATCH 3/8] ARM: OMAP2+: PM: add a lock to protect the powerdomains next state
pwrdm_set_next_fpwrst and pwrdm_read_next_fpwrst are intented
to be the only API to program and request the next state of a power
domain.
This patch protects the power domain next state settings and structs
from concurrent accesses by the use of a lock.
A spinlock is used since pwrdm_set_next_fpwrst and
pwrdm_read_next_fpwrst can be called from atomic context
(.i.e) either from cpuidle path or suspend path.
[ambr...@ti.com: reported the atomic context issue and suggested
to replace the mutex with a spinlock]
Signed-off-by: Jean Pihet
Reported-by: Ambresh K
---
arch/arm/mach-omap2/powerdomain.c | 36 +++-
arch/arm/mach-omap2/powerdomain.h |3 +++
2 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 3a1f56c..a8f7a81 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -102,6 +102,7 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
INIT_LIST_HEAD(&pwrdm->voltdm_node);
voltdm_add_pwrdm(voltdm, pwrdm);
+ spin_lock_init(&pwrdm->lock);
list_add(&pwrdm->node, &pwrdm_list);
/* Initialize the powerdomain's state counter */
@@ -601,6 +602,22 @@ int pwrdm_pwrst_to_fpwrst(struct powerdomain *pwrdm, u8
pwrst, u8 logic)
}
/**
+ * _pwrdm_read_next_fpwrst - get next powerdomain functional power state
+ * @pwrdm: struct powerdomain * to get power state
+ *
+ * Return the powerdomain @pwrdm's next functional power state.
+ * Returns -EINVAL if the powerdomain pointer is null or returns
+ * the next power state upon success.
+ */
+int _pwrdm_read_next_fpwrst(struct powerdomain *pwrdm)
+{
+ int next_pwrst = pwrdm_read_next_pwrst(pwrdm);
+ int next_logic = pwrdm_read_logic_retst(pwrdm);
+
+ return pwrdm_pwrst_to_fpwrst(pwrdm, next_pwrst, next_logic);
+}
+
+/**
* pwrdm_get_achievable_fpwrst() - Provide achievable functional state
* @pwrdm: struct powerdomain * to set
* @fpwrst: minimum functional state we would like to hit
@@ -670,6 +687,7 @@ int pwrdm_set_next_fpwrst(struct powerdomain *pwrdm,
int sleep_switch = -1, ret = 0, hwsup = 0;
int new_fpwrst, next_fpwrst, pwrst, logic;
u8 curr_pwrst;
+ unsigned long flags;
if (!pwrdm || IS_ERR(pwrdm)) {
pr_debug("%s: invalid params: pwrdm=%p\n", __func__, pwrdm);
@@ -678,13 +696,15 @@ int pwrdm_set_next_fpwrst(struct powerdomain *pwrdm,
pr_debug("%s(%s, fpwrst=%0x)\n", __func__, pwrdm->name, fpwrst);
+ spin_lock_irqsave(&pwrdm->lock, flags);
+
new_fpwrst = pwrdm_get_achievable_fpwrst(pwrdm, fpwrst);
pwrst = pwrdm_fpwrst_to_pwrst(pwrdm, new_fpwrst);
logic = pwrdm_fpwrst_to_logic_pwrst(pwrdm, new_fpwrst);
- next_fpwrst = pwrdm_read_next_fpwrst(pwrdm);
+ next_fpwrst = _pwrdm_read_next_fpwrst(pwrdm);
if (new_fpwrst == next_fpwrst)
- return ret;
+ goto out;
curr_pwrst = pwrdm_read_pwrst(pwrdm);
if (curr_pwrst < PWRDM_POWER_ON) {
@@ -732,6 +752,8 @@ int pwrdm_set_next_fpwrst(struct powerdomain *pwrdm,
break;
}
+out:
+ spin_unlock_irqrestore(&pwrdm->lock, flags);
return ret;
}
@@ -801,10 +823,14 @@ int pwrdm_read_next_pwrst(struct powerdomain *pwrdm)
*/
int pwrdm_read_next_fpwrst(struct powerdomain *pwrdm)
{
- int next_pwrst = pwrdm_read_next_pwrst(pwrdm);
- int next_logic = pwrdm_read_logic_retst(pwrdm);
+ int ret;
+ unsigned long flags;
- return pwrdm_pwrst_to_fpwrst(pwrdm, next_pwrst, next_logic);
+ spin_lock_irqsave(&pwrdm->lock, flags);
+ ret = _pwrdm_read_next_fpwrst(pwrdm);
+ spin_unlock_irqrestore(&pwrdm->lock, flags);
+
+ return ret;
}
/**
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 45c449d..23b9da9 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -17,6 +17,7 @@
#include
#include
+#include
#include
#include
@@ -109,6 +110,7 @@ struct powerdomain;
* @pwrdm_clkdms: Clockdomains in this powerdomain
* @node: list_head linking all powerdomains
* @voltdm_node: list_head linking all powerdomains in a voltagedomain
+ * @lock: powerdomain next state registers protection lock
* @pwrstctrl_offs: (AM33XX only) XXX_PWRSTCTRL reg offset from prcm_offs
* @pwrstst_offs: (AM33XX only) XXX_PWRSTST reg offset from prcm_offs
* @logicretstate_mask: (AM33XX only) mask for logic retention bitfield
@@ -142,6 +144,7 @@ struct powerdomain {
struct clockdomain *pwrdm_clkdms[PWRDM_MAX_CLKDMS];
struct list_head node;
struct list_head voltdm_node;
+ spinlock_t lock;
int state;
unsigned state_counter[PWRDM_MAX_PWRSTS];
unsigned ret_logic_off_counter;
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the
[PATCH 4/8] ARM: OMAP2+: PM: use the functional power states API
Use the functional power states as the API to control power
domains:
- use the PWRDM_FUNC_PWRST_* and PWRDM_LOGIC_MEM_PWRST_*
macros for the power states and logic settings,
- the pwrdm_set_next_fpwrst function, which controls
the power states and logic settings of power domains, shall
be used instead of pwrdm_set_next_pwrst to program the power
domains next states.
Note: the internal code for power domains state management still
uses the internal power states.
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/cpuidle34xx.c | 58 +++---
arch/arm/mach-omap2/cpuidle44xx.c | 24 +++--
arch/arm/mach-omap2/omap-hotplug.c|2 +-
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 39 +++---
arch/arm/mach-omap2/pm24xx.c | 14 ++---
arch/arm/mach-omap2/pm34xx.c | 79 +++--
arch/arm/mach-omap2/pm44xx.c | 24 +++--
arch/arm/mach-omap2/powerdomain.c |2 +-
8 files changed, 116 insertions(+), 126 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index f2a49a4..4ca37d2 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -44,32 +44,32 @@ struct omap3_idle_statedata {
static struct omap3_idle_statedata omap3_idle_data[] = {
{
- .mpu_state = PWRDM_POWER_ON,
- .core_state = PWRDM_POWER_ON,
+ .mpu_state = PWRDM_FUNC_PWRST_ON,
+ .core_state = PWRDM_FUNC_PWRST_ON,
},
{
- .mpu_state = PWRDM_POWER_ON,
- .core_state = PWRDM_POWER_ON,
+ .mpu_state = PWRDM_FUNC_PWRST_ON,
+ .core_state = PWRDM_FUNC_PWRST_ON,
},
{
- .mpu_state = PWRDM_POWER_RET,
- .core_state = PWRDM_POWER_ON,
+ .mpu_state = PWRDM_FUNC_PWRST_CSWR,
+ .core_state = PWRDM_FUNC_PWRST_ON,
},
{
- .mpu_state = PWRDM_POWER_OFF,
- .core_state = PWRDM_POWER_ON,
+ .mpu_state = PWRDM_FUNC_PWRST_OFF,
+ .core_state = PWRDM_FUNC_PWRST_ON,
},
{
- .mpu_state = PWRDM_POWER_RET,
- .core_state = PWRDM_POWER_RET,
+ .mpu_state = PWRDM_FUNC_PWRST_CSWR,
+ .core_state = PWRDM_FUNC_PWRST_CSWR,
},
{
- .mpu_state = PWRDM_POWER_OFF,
- .core_state = PWRDM_POWER_RET,
+ .mpu_state = PWRDM_FUNC_PWRST_OFF,
+ .core_state = PWRDM_FUNC_PWRST_CSWR,
},
{
- .mpu_state = PWRDM_POWER_OFF,
- .core_state = PWRDM_POWER_OFF,
+ .mpu_state = PWRDM_FUNC_PWRST_OFF,
+ .core_state = PWRDM_FUNC_PWRST_OFF,
},
};
@@ -84,8 +84,8 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
local_fiq_disable();
- pwrdm_set_next_pwrst(mpu_pd, mpu_state);
- pwrdm_set_next_pwrst(core_pd, core_state);
+ pwrdm_set_next_fpwrst(mpu_pd, mpu_state);
+ pwrdm_set_next_fpwrst(core_pd, core_state);
if (omap_irq_pending() || need_resched())
goto return_sleep_time;
@@ -100,7 +100,7 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
* Call idle CPU PM enter notifier chain so that
* VFP context is saved.
*/
- if (mpu_state == PWRDM_POWER_OFF)
+ if (mpu_state == PWRDM_FUNC_PWRST_OFF)
cpu_pm_enter();
/* Execute ARM wfi */
@@ -110,7 +110,7 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
* Call idle CPU PM enter notifier chain to restore
* VFP context.
*/
- if (pwrdm_read_prev_pwrst(mpu_pd) == PWRDM_POWER_OFF)
+ if (pwrdm_read_prev_fpwrst(mpu_pd) == PWRDM_FUNC_PWRST_OFF)
cpu_pm_exit();
/* Re-allow idle for C1 */
@@ -159,20 +159,20 @@ static int next_valid_state(struct cpuidle_device *dev,
struct cpuidle_driver *drv, int index)
{
struct omap3_idle_statedata *cx = &omap3_idle_data[index];
- u32 mpu_deepest_state = PWRDM_POWER_RET;
- u32 core_deepest_state = PWRDM_POWER_RET;
+ u32 mpu_deepest_state = PWRDM_FUNC_PWRST_CSWR;
+ u32 core_deepest_state = PWRDM_FUNC_PWRST_CSWR;
int idx;
int next_index = 0; /* C1 is the default value */
if (enable_off_mode) {
- mpu_deepest_state = PWRDM_POWER_OFF;
+ mpu_deepest_state = PWRDM_FUNC_PWRST_OFF;
/*
* Erratum i583: valable for ES rev < Es1.2 on 3630.
* CORE OFF mode is not supported in a stable form, restrict
* instead the CORE state to RET.
*/
if (!IS_PM34XX_ERRATUM(PM_SDRC_WAKEUP_ERRATUM_i583))
- core_deepest_state = PWRDM_POWER_OFF
[PATCH 6/8] ARM: OMAP2+: PM debug: trace the functional power domains states
Trace the power domain transitions using the functional power states,
which include the power and logic states.
While at it, fix the trace in the case a power domain did not hit
the desired state, as reported by Paul Walmsley.
Reported-by: Paul Walmsley
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/powerdomain.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 6b8580b..06a566b 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -144,7 +144,7 @@ static void _update_logic_membank_counters(struct
powerdomain *pwrdm)
static int _pwrdm_state_switch(struct powerdomain *pwrdm, int flag)
{
- int prev, state, trace_state = 0;
+ int prev, next, state, trace_state;
if (pwrdm == NULL)
return -EINVAL;
@@ -165,10 +165,10 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm,
int flag)
* If the power domain did not hit the desired state,
* generate a trace event with both the desired and hit states
*/
- if (state != prev) {
+ next = pwrdm_read_next_fpwrst(pwrdm);
+ if (next != prev) {
trace_state = (PWRDM_TRACE_STATES_FLAG |
- ((state & OMAP_POWERSTATE_MASK) << 8) |
- ((prev & OMAP_POWERSTATE_MASK) << 0));
+ (next << 8) | (prev << 0));
trace_power_domain_target(pwrdm->name, trace_state,
smp_processor_id());
}
@@ -781,13 +781,8 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8
pwrst)
pr_debug("powerdomain: setting next powerstate for %s to %0x\n",
pwrdm->name, pwrst);
- if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) {
- /* Trace the pwrdm desired target state */
- trace_power_domain_target(pwrdm->name, pwrst,
- smp_processor_id());
- /* Program the pwrdm desired target state */
+ if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst)
ret = arch_pwrdm->pwrdm_set_next_pwrst(pwrdm, pwrst);
- }
return ret;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] ARM: OMAP2+: PM: reorganize the powerdomain API in public and private parts
The newly added code for functional power states re-defines the
API to query and control the power domains settings.
The API is now split in the following parts in powerdomain.h:
- the public or external API, to be used by external PM components:
cpuidle, suspend, pm, clock* etc.
- the private or internal API, to be used by the low level PM code
only: powerdomain*, pm-debug, hwmod, voltage, clockdomain.
No functional change is introduced by this patch.
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/powerdomain.h | 119 -
1 files changed, 65 insertions(+), 54 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index df83c7c..0bf613c 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -24,6 +24,11 @@
#include "voltage.h"
+/***
+ * External API, to be used by external PM components: cpuidle,
+ * suspend, pm, clock* etc.
+ ***/
+
/* Powerdomain functional power states, used by the external API functions */
enum pwrdm_func_state {
PWRDM_FUNC_PWRST_OFF= 0x0,
@@ -44,6 +49,62 @@ enum pwrdm_logic_mem_state {
PWRDM_MAX_LOGIC_MEM_PWRST /* Last value, used as the max value */
};
+struct clockdomain;
+struct powerdomain;
+
+struct powerdomain *pwrdm_lookup(const char *name);
+
+int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm, void *user),
+ void *user);
+int pwrdm_for_each_nolock(int (*fn)(struct powerdomain *pwrdm, void *user),
+ void *user);
+
+int pwrdm_add_clkdm(struct powerdomain *pwrdm, struct clockdomain *clkdm);
+int pwrdm_del_clkdm(struct powerdomain *pwrdm, struct clockdomain *clkdm);
+int pwrdm_for_each_clkdm(struct powerdomain *pwrdm,
+int (*fn)(struct powerdomain *pwrdm,
+ struct clockdomain *clkdm));
+struct voltagedomain *pwrdm_get_voltdm(struct powerdomain *pwrdm);
+
+int pwrdm_get_mem_bank_count(struct powerdomain *pwrdm);
+
+/* Functions that query and control the power domain state setings */
+int pwrdm_get_achievable_fpwrst(struct powerdomain *pwrdm, u8 fpwrst);
+int pwrdm_set_next_fpwrst(struct powerdomain *pwrdm,
+ enum pwrdm_func_state fpwrst);
+int pwrdm_read_prev_fpwrst(struct powerdomain *pwrdm);
+int pwrdm_read_fpwrst(struct powerdomain *pwrdm);
+int pwrdm_read_next_fpwrst(struct powerdomain *pwrdm);
+int pwrdm_clear_all_prev_pwrst(struct powerdomain *pwrdm);
+int pwrdm_set_mem_onst(struct powerdomain *pwrdm, u8 bank, u8 pwrst);
+int pwrdm_set_mem_retst(struct powerdomain *pwrdm, u8 bank, u8 pwrst);
+int pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8 bank);
+int pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm, u8 bank);
+int pwrdm_read_mem_retst(struct powerdomain *pwrdm, u8 bank);
+
+int pwrdm_get_context_loss_count(struct powerdomain *pwrdm);
+bool pwrdm_can_ever_lose_context(struct powerdomain *pwrdm);
+
+int pwrdm_enable_hdwr_sar(struct powerdomain *pwrdm);
+int pwrdm_disable_hdwr_sar(struct powerdomain *pwrdm);
+bool pwrdm_has_hdwr_sar(struct powerdomain *pwrdm);
+
+int pwrdm_pre_transition(struct powerdomain *pwrdm);
+int pwrdm_post_transition(struct powerdomain *pwrdm);
+int pwrdm_state_switch(struct powerdomain *pwrdm);
+
+extern void omap242x_powerdomains_init(void);
+extern void omap243x_powerdomains_init(void);
+extern void omap3xxx_powerdomains_init(void);
+extern void am33xx_powerdomains_init(void);
+extern void omap44xx_powerdomains_init(void);
+
+
+/***
+ * Internal API, to be included by the low level PM code only:
+ * powerdomain*, pm-debug, hwmod, voltage, clockdomain
+ ***/
+
/* Powerdomain basic power states */
#define PWRDM_POWER_OFF0x0
#define PWRDM_POWER_RET0x1
@@ -92,9 +153,6 @@ enum pwrdm_logic_mem_state {
/* XXX A completely arbitrary number. What is reasonable here? */
#define PWRDM_TRANSITION_BAILOUT 10
-struct clockdomain;
-struct powerdomain;
-
/**
* struct powerdomain - OMAP powerdomain
* @name: Powerdomain name
@@ -221,67 +279,17 @@ int pwrdm_register_platform_funcs(struct pwrdm_ops
*custom_funcs);
int pwrdm_register_pwrdms(struct powerdomain **pwrdm_list);
int pwrdm_complete_init(void);
-struct powerdomain *pwrdm_lookup(const char *name);
-
-int pwrdm_for_each(int (*fn)(struct powerdomain *pwrdm, void *user),
- void *user);
-int pwrdm_for_each_nolock(int (*fn)(struct powerdomain *pwrdm, void *user),
- void *user);
-
-int pwrdm_add_clkdm(struct powerdomain *pwrdm, struct clockdomain *clkdm);
-int pwrdm_del_clkdm(struct powerdomain *pwrdm, struct clockdomain *clkdm);
-int pwrdm_for_each_clkdm(struct power
[PATCH 7/8] ARM: OMAP2+: powerdomain: add error logs
From: Nishanth Menon
Silent failure makes debug hard. So, provide rate limited error
messages in functional and oft-used code to prevent spam
when something goes wrong..
Signed-off-by: Nishanth Menon
---
arch/arm/mach-omap2/powerdomain.c | 72 +---
1 files changed, 58 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 06a566b..691247e 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include "cm2xxx_3xxx.h"
@@ -146,8 +147,12 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm,
int flag)
int prev, next, state, trace_state;
- if (pwrdm == NULL)
+ if (pwrdm == NULL) {
+ WARN_ONCE(1, "null pwrdm\n");
+ pr_err_ratelimited("%s: powerdomain: null pwrdm param\n",
+ __func__);
return -EINVAL;
+ }
state = pwrdm_read_fpwrst(pwrdm);
@@ -174,6 +179,8 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm,
int flag)
}
break;
default:
+ pr_err_ratelimited("%s: powerdomain %s: bad flag %d\n",
+ __func__, pwrdm->name, flag);
return -EINVAL;
}
@@ -690,7 +697,8 @@ int pwrdm_set_next_fpwrst(struct powerdomain *pwrdm,
unsigned long flags;
if (!pwrdm || IS_ERR(pwrdm)) {
- pr_debug("%s: invalid params: pwrdm=%p\n", __func__, pwrdm);
+ pr_err_ratelimited("%s: invalid params: pwrdm=%p\n",
+ __func__, pwrdm);
return -EINVAL;
}
@@ -775,8 +783,11 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8
pwrst)
if (!pwrdm)
return -EINVAL;
- if (!(pwrdm->pwrsts & (1 << pwrst)))
+ if (!(pwrdm->pwrsts & (1 << pwrst))) {
+ pr_err_ratelimited("%s: powerdomain %s: bad pwrst %d\n",
+ __func__, pwrdm->name, pwrst);
return -EINVAL;
+ }
pr_debug("powerdomain: setting next powerstate for %s to %0x\n",
pwrdm->name, pwrst);
@@ -924,8 +935,11 @@ int pwrdm_set_logic_retst(struct powerdomain *pwrdm, u8
pwrst)
if (!pwrdm)
return -EINVAL;
- if (!(pwrdm->pwrsts_logic_ret & (1 << pwrst)))
+ if (!(pwrdm->pwrsts_logic_ret & (1 << pwrst))) {
+ pr_err_ratelimited("%s: powerdomain %s: bad pwrst %d\n",
+ __func__, pwrdm->name, pwrst);
return -EINVAL;
+ }
pr_debug("powerdomain: setting next logic powerstate for %s to %0x\n",
pwrdm->name, pwrst);
@@ -958,11 +972,17 @@ int pwrdm_set_mem_onst(struct powerdomain *pwrdm, u8
bank, u8 pwrst)
if (!pwrdm)
return -EINVAL;
- if (pwrdm->banks < (bank + 1))
+ if (pwrdm->banks < (bank + 1)) {
+ pr_err_ratelimited("%s: powerdomain %s: bad bank %d\n",
+ __func__, pwrdm->name, bank);
return -EEXIST;
+ }
- if (!(pwrdm->pwrsts_mem_on[bank] & (1 << pwrst)))
+ if (!(pwrdm->pwrsts_mem_on[bank] & (1 << pwrst))) {
+ pr_err_ratelimited("%s: powerdomain %s: bank %d bad pwrst %d\n",
+ __func__, pwrdm->name, bank, pwrst);
return -EINVAL;
+ }
pr_debug("powerdomain: setting next memory powerstate for domain %s "
"bank %0x while pwrdm-ON to %0x\n", pwrdm->name, bank, pwrst);
@@ -996,11 +1016,17 @@ int pwrdm_set_mem_retst(struct powerdomain *pwrdm, u8
bank, u8 pwrst)
if (!pwrdm)
return -EINVAL;
- if (pwrdm->banks < (bank + 1))
+ if (pwrdm->banks < (bank + 1)) {
+ pr_err_ratelimited("%s: powerdomain %s: bad bank %d\n",
+ __func__, pwrdm->name, bank);
return -EEXIST;
+ }
- if (!(pwrdm->pwrsts_mem_ret[bank] & (1 << pwrst)))
+ if (!(pwrdm->pwrsts_mem_ret[bank] & (1 << pwrst))) {
+ pr_err_ratelimited("%s: powerdomain %s: bank %d bad pwrst %d\n",
+ __func__, pwrdm->name, bank, pwrst);
return -EINVAL;
+ }
pr_debug("powerdomain: setting next memory powerstate for domain %s "
"bank %0x while pwrdm-RET to %0x\n", pwrdm->name, bank, pwrst);
@@ -1092,8 +1118,11 @@ int pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8
bank)
if (!pwrdm)
return ret;
- if (pwrdm->banks < (bank + 1))
+ if (pwrdm->banks < (bank + 1)) {
+ pr_err_ratelimited("%s: powerdomain %s: bad bank %d\n",
+ __func__, pwrdm->name, bank);
[PATCH 5/8] ARM: OMAP2+: PM: use power domain functional state in stats counters
The PM code uses some counters to keep track of the power domains
transitions, in order to provide the information to drivers (in
pwrdm_get_context_loss_count) and to expose the information to
sysfs for debug purpose.
This patch provides the information for each functional state.
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/pm-debug.c| 15 ---
arch/arm/mach-omap2/powerdomain.c | 12 ++--
arch/arm/mach-omap2/powerdomain.h |4 ++--
3 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 814bcd9..8eaa3f2 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -53,9 +53,10 @@ enum {
DEBUG_FILE_TIMERS,
};
-static const char pwrdm_state_names[][PWRDM_MAX_PWRSTS] = {
+static const char pwrdm_state_names[][PWRDM_MAX_FUNC_PWRSTS] = {
"OFF",
- "RET",
+ "OSWR",
+ "CSWR",
"INA",
"ON"
};
@@ -102,13 +103,13 @@ static int pwrdm_dbg_show_counter(struct powerdomain
*pwrdm, void *user)
strncmp(pwrdm->name, "dpll", 4) == 0)
return 0;
- if (pwrdm->state != pwrdm_read_pwrst(pwrdm))
+ if (pwrdm->state != pwrdm_read_fpwrst(pwrdm))
printk(KERN_ERR "pwrdm state mismatch(%s) %d != %d\n",
- pwrdm->name, pwrdm->state, pwrdm_read_pwrst(pwrdm));
+ pwrdm->name, pwrdm->state, pwrdm_read_fpwrst(pwrdm));
seq_printf(s, "%s (%s)", pwrdm->name,
pwrdm_state_names[pwrdm->state]);
- for (i = 0; i < PWRDM_MAX_PWRSTS; i++)
+ for (i = 0; i < PWRDM_MAX_FUNC_PWRSTS; i++)
seq_printf(s, ",%s:%d", pwrdm_state_names[i],
pwrdm->state_counter[i]);
@@ -137,7 +138,7 @@ static int pwrdm_dbg_show_timer(struct powerdomain *pwrdm,
void *user)
seq_printf(s, "%s (%s)", pwrdm->name,
pwrdm_state_names[pwrdm->state]);
- for (i = 0; i < 4; i++)
+ for (i = 0; i < PWRDM_MAX_FUNC_PWRSTS; i++)
seq_printf(s, ",%s:%lld", pwrdm_state_names[i],
pwrdm->state_timer[i]);
@@ -211,7 +212,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm,
void *dir)
t = sched_clock();
- for (i = 0; i < 4; i++)
+ for (i = 0; i < PWRDM_MAX_FUNC_PWRSTS; i++)
pwrdm->state_timer[i] = 0;
pwrdm->timer = t;
diff --git a/arch/arm/mach-omap2/powerdomain.c
b/arch/arm/mach-omap2/powerdomain.c
index 1f9ed2c..6b8580b 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -106,7 +106,7 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
list_add(&pwrdm->node, &pwrdm_list);
/* Initialize the powerdomain's state counter */
- for (i = 0; i < PWRDM_MAX_PWRSTS; i++)
+ for (i = 0; i < PWRDM_MAX_FUNC_PWRSTS; i++)
pwrdm->state_counter[i] = 0;
pwrdm->ret_logic_off_counter = 0;
@@ -114,7 +114,7 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
pwrdm->ret_mem_off_counter[i] = 0;
pwrdm_wait_transition(pwrdm);
- pwrdm->state = pwrdm_read_pwrst(pwrdm);
+ pwrdm->state = pwrdm_read_fpwrst(pwrdm);
pwrdm->state_counter[pwrdm->state] = 1;
pr_debug("powerdomain: registered %s\n", pwrdm->name);
@@ -149,17 +149,17 @@ static int _pwrdm_state_switch(struct powerdomain *pwrdm,
int flag)
if (pwrdm == NULL)
return -EINVAL;
- state = pwrdm_read_pwrst(pwrdm);
+ state = pwrdm_read_fpwrst(pwrdm);
switch (flag) {
case PWRDM_STATE_NOW:
prev = pwrdm->state;
break;
case PWRDM_STATE_PREV:
- prev = pwrdm_read_prev_pwrst(pwrdm);
+ prev = pwrdm_read_prev_fpwrst(pwrdm);
if (pwrdm->state != prev)
pwrdm->state_counter[prev]++;
- if (prev == PWRDM_POWER_RET)
+ if (prev == PWRDM_FUNC_PWRST_OSWR)
_update_logic_membank_counters(pwrdm);
/*
* If the power domain did not hit the desired state,
@@ -1367,7 +1367,7 @@ int pwrdm_get_context_loss_count(struct powerdomain
*pwrdm)
return -ENODEV;
}
- count = pwrdm->state_counter[PWRDM_POWER_OFF];
+ count = pwrdm->state_counter[PWRDM_FUNC_PWRST_OFF];
count += pwrdm->ret_logic_off_counter;
for (i = 0; i < pwrdm->banks; i++)
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 23b9da9..df83c7c 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -146,7 +146,7 @@ struct powerdomain {
struct list_head voltdm_node;
spinlock_t lock;
int state;
- unsigned state_counter[PWRDM_MAX_PWRSTS];
+ unsigned state_counter[PWRDM_MAX_FUNC_PWR
[PATCH-V2] arm/dts: AM33XX: Set the default status of module to "disabled" state
Ideally in common SoC dtsi file should set all modules
to "disabled" state and it should get enabled in respective
EVM/Board dts file as per usage.
This patch sets default status of all modules to "disabled"
state in am33xx.dtsi file. Currently there are no modules
supported as part of Bone and EVM dts support, so care
to add entry "status = "okay"" while adding support for any
module.
Signed-off-by: Vaibhav Hiremath
Acked-by: Arnd Bergmann
Cc: Benoit Cousson
Cc: Grant Likely
Cc: Tony Lindgren
---
Changes from V1:
- Fixed indentation issue caused due to extra spaces.
arch/arm/boot/dts/am335x-bone.dts |6 ++
arch/arm/boot/dts/am335x-evm.dts |6 ++
arch/arm/boot/dts/am33xx.dtsi |9 +
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index a9af4db..a7906cb 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -17,4 +17,10 @@
device_type = "memory";
reg = <0x8000 0x1000>; /* 256 MB */
};
+
+ ocp {
+ uart1: serial@44E09000 {
+ status = "okay";
+ };
+ };
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index d6a97d9..5dd8a6b 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -17,4 +17,10 @@
device_type = "memory";
reg = <0x8000 0x1000>; /* 256 MB */
};
+
+ ocp {
+ uart1: serial@44E09000 {
+ status = "okay";
+ };
+ };
};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 59509c4..5f6c8e3 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -102,36 +102,42 @@
compatible = "ti,omap3-uart";
ti,hwmods = "uart1";
clock-frequency = <4800>;
+ status = "disabled";
};
uart2: serial@48022000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart2";
clock-frequency = <4800>;
+ status = "disabled";
};
uart3: serial@48024000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart3";
clock-frequency = <4800>;
+ status = "disabled";
};
uart4: serial@481A6000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart4";
clock-frequency = <4800>;
+ status = "disabled";
};
uart5: serial@481A8000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart5";
clock-frequency = <4800>;
+ status = "disabled";
};
uart6: serial@481AA000 {
compatible = "ti,omap3-uart";
ti,hwmods = "uart6";
clock-frequency = <4800>;
+ status = "disabled";
};
i2c1: i2c@44E0B000 {
@@ -139,6 +145,7 @@
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c1";
+ status = "disabled";
};
i2c2: i2c@4802A000 {
@@ -146,6 +153,7 @@
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c2";
+ status = "disabled";
};
i2c3: i2c@4819C000 {
@@ -153,6 +161,7 @@
#address-cells = <1>;
#size-cells = <0>;
ti,hwmods = "i2c3";
+ status = "disabled";
};
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for v3.6-rc1
On Tuesday 14 August 2012, Tony Lindgren wrote: > Here are some omap fixes, these are probably too late for -rc1, > we're fine getting them in for -rc2 as well. > > The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee: > > Linux 3.6-rc1 (2012-08-02 16:38:10 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-fixes-for-v3.6-rc1 > Applied, thanks! I'll probably send these out in the next few days, whichever -rc that ends up being. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] arm/dts: Add tps65910 regulator DT data to am335x-evm.dts
On Tue, Aug 14, 2012 at 02:25:18PM +, AnilKumar, Chimata wrote: > AM335x EVM have one dedicated input supply which provide supplies to all > the PMIC regulators. According to tps65910 "VDD1 regulator" input supply > is from vcc1 so we have to create a dummy/parent/some node to handle this. > Example below has the details. Your device tree should accurately reflect the hardware. > Similarly we have to add 7 more fixed regulators entries to provide input > supply to different PMIC regulators. If you have all these unrelated supplies in the system then your device tree should accurately reflect that. However this would be a very unusual hardware design. Usually there would be a very small set of system supply rails, frequently only one. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/11] usb: musb: adding multi instance support
On Thu, Aug 02, 2012 at 05:42:43PM +0530, Ravi Babu wrote: > This series of patches adds, > a) Multi instances support in musb driver > b) DT support for musb_dsps glue layer > c) DT support for NOP transceiver > > AM33xx and TI81xx has dual musb controller and has two usb PHY of same type. > This patch series uses 'phandle' based API devm_usb_get_phy_by_phandle() to > get the PHY of same type. This API support is being added by Kishon's patch > discussed at [1] > > The series applies to linux-omap (master branch) > + Vaibhav baseport patches on his tree at [3] > + Kishon's multi phy patches on Felipe's branch 'xceiv' > + Kishon's patch on phandle at [1] > + AM33xx musb glue compile and bugfix patches at [4], [5], [6] and [7] > + Damodar's recent patch at [2] > > and have been tested on Beaglebone board. Any hints as to if or when this will be applied to the following repository? http://arago-project.org/git/projects/linux-omap3.git?p=projects/linux-omap3.git;a=summary thanks, Chris -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] omap: remoteproc: set bootaddr support
Some remote processors (like Omap4's DSP) need to explicitly
set a boot address from which they start executing code when
taken out of reset.
Support for this has been added to remoteproc code through
a set_bootaddr function in the platform data which, if needed,
must be set according to the backend rproc.
For omap4's dsp we can use the next control funtion:
.set_bootaddr = omap_ctrl_write_dsp_boot_addr
Signed-off-by: Juan Gutierrez
Signed-off-by: Suman Anna
---
arch/arm/plat-omap/include/plat/remoteproc.h |2 ++
drivers/remoteproc/omap_remoteproc.c |3 +++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/remoteproc.h
b/arch/arm/plat-omap/include/plat/remoteproc.h
index b10eac8..3c1c644 100644
--- a/arch/arm/plat-omap/include/plat/remoteproc.h
+++ b/arch/arm/plat-omap/include/plat/remoteproc.h
@@ -30,6 +30,7 @@ struct platform_device;
* @ops: start/stop rproc handlers
* @device_enable: omap-specific handler for enabling a device
* @device_shutdown: omap-specific handler for shutting down a device
+ * @set_bootaddr: omap-specific handler for setting the rproc boot address
*/
struct omap_rproc_pdata {
const char *name;
@@ -40,6 +41,7 @@ struct omap_rproc_pdata {
const struct rproc_ops *ops;
int (*device_enable) (struct platform_device *pdev);
int (*device_shutdown) (struct platform_device *pdev);
+ void(*set_bootaddr)(u32);
};
#if defined(CONFIG_OMAP_REMOTEPROC) || defined(CONFIG_OMAP_REMOTEPROC_MODULE)
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index a1f7ac1..a0c168c 100644
--- a/drivers/remoteproc/omap_remoteproc.c
+++ b/drivers/remoteproc/omap_remoteproc.c
@@ -116,6 +116,9 @@ static int omap_rproc_start(struct rproc *rproc)
struct omap_rproc_pdata *pdata = pdev->dev.platform_data;
int ret;
+ if (pdata->set_bootaddr)
+ pdata->set_bootaddr(rproc->bootaddr);
+
oproc->nb.notifier_call = omap_rproc_mbox_callback;
/* every omap rproc is assigned a mailbox instance for messaging */
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays
Hi,
On 15/08/12 05:31 AM, Tomi Valkeinen wrote:
> Hi,
>
> On Tue, 2012-07-17 at 10:01 -0400, Raphael Assenat wrote:
>> Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays.
>>
>
> This needed to be converted to work with latest kernel. See patch below.
> I've applied the patch to my dev branch, mail me if it's not correct.
>
>
> commit f4e491f283266b53a926eb3c9017505b04786b9b (HEAD, dev)
> Author: Raphael Assenat
> Date: Tue Jul 17 10:01:40 2012 -0400
>
> OMAPDSS: Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays
>
> Add timings for ChiMei G121S1-L01/L02 and G121X1-L01 LCD displays.
>
> Signed-off-by: Raphael Assenat
> Signed-off-by: Tomi Valkeinen
>
> diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
> b/drivers/video/omap2/displays/panel-generic-dpi.c
> index bc5af25..ae862bb 100644
> --- a/drivers/video/omap2/displays/panel-generic-dpi.c
> +++ b/drivers/video/omap2/displays/panel-generic-dpi.c
> @@ -538,6 +538,82 @@ static struct panel_config generic_dpi_panels[] = {
> },
> .name = "primeview_pd104slf",
> },
> +
> + /* ChiMei G121S1-L01 */
> + {
> + {
...
> + .vsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
> + .hsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
> + .data_pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE,
> + .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
> + .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
Actually those 3 panels only use the DE signal. The hsync/vsync signals
are not used and on our system we mux them out to make sure they are
kept low as recommended in the panel datasheets.
Since vsync/hsync are not used, I think the vsync_level, hsync_level and
sync_pclk_edge entries could be removed. Otherwise the updated patch
works fine as is.
Best regards,
Raphaël Assénat
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.7] [media] media: rc: Introduce RX51 IR transmitter driver
Heippa, Thanks for the patch! I know Mauro has already applied this so any changes would make a separate patch. I have tested this up to the point I can see that the IR LED blinks --- using my phone's camera. :-) But I have no receivers so the testing ends to this. On Mon, Aug 13, 2012 at 09:53:45PM +0200, Mauro Carvalho Chehab wrote: > This is an automatic generated email to let you know that the following patch > were queued at the > http://git.linuxtv.org/media_tree.git tree: > > Subject: [media] media: rc: Introduce RX51 IR transmitter driver > Author: Timo Kokkonen > Date:Fri Aug 10 06:16:36 2012 -0300 > > This is the driver for the IR transmitter diode found on the Nokia > N900 (also known as RX51) device. The driver is mostly the same as > found in the original 2.6.28 based kernel that comes with the device. > > The following modifications have been made compared to the original > driver version: > > - Adopt to the changes that has happen in the kernel during the past > five years, such as the change in the include paths > > - The OMAP DM-timers require much more care nowadays. The timers need > to be enabled and disabled or otherwise many actions fail. Timers > must not be freed without first stopping them or otherwise the timer > cannot be requested again. > > The code has been tested with sending IR codes with N900 device > running Debian userland. The device receiving the codes was Anysee > DVB-C USB receiver. Just a general question: how much this driver actually depends on the N900? I can see there's a dependency to OMAP DM timers, but couldn't you use the same driver if you just wired the IR LED there? Even the timer configuration is there, so it looks a lot more generic than N900-specific. > Signed-off-by: Timo Kokkonen > Cc: Tony Lindgren > Cc: linux-omap@vger.kernel.org > Cc: Sakari Ailus > Signed-off-by: Mauro Carvalho Chehab > > drivers/media/rc/Kconfig | 10 + > drivers/media/rc/Makefile |1 + > drivers/media/rc/ir-rx51.c | 496 > > include/media/ir-rx51.h| 10 + > 4 files changed, 517 insertions(+), 0 deletions(-) > > --- > > http://git.linuxtv.org/media_tree.git?a=commitdiff;h=c332e8472d7db67766bcad33390c607fdd9ac5bc > > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig > index 64be610..016f9ab 100644 > --- a/drivers/media/rc/Kconfig > +++ b/drivers/media/rc/Kconfig > @@ -287,6 +287,16 @@ config IR_TTUSBIR > To compile this driver as a module, choose M here: the module will > be called ttusbir. > > +config IR_RX51 > + tristate "Nokia N900 IR transmitter diode > + depends on MACH_NOKIA_RX51 && OMAP_DM_TIMER You also should depend on LIRC. > + ---help--- > +Say Y or M here if you want to enable support for the IR > +transmitter diode built in the Nokia N900 (RX51) device. > + > +The driver uses omap DM timers for gereating the carrier s/gereating/renerating/ > +wave and pulses. > + > config RC_LOOPBACK > tristate "Remote Control Loopback Driver" > depends on RC_CORE > diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile > index 66c8bae..56bacf0 100644 > --- a/drivers/media/rc/Makefile > +++ b/drivers/media/rc/Makefile > @@ -23,6 +23,7 @@ obj-$(CONFIG_IR_FINTEK) += fintek-cir.o > obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o > obj-$(CONFIG_IR_ENE) += ene_ir.o > obj-$(CONFIG_IR_REDRAT3) += redrat3.o > +obj-$(CONFIG_IR_RX51) += ir-rx51.o > obj-$(CONFIG_IR_STREAMZAP) += streamzap.o > obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o > obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o > diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c > new file mode 100644 > index 000..9487dd3 > --- /dev/null > +++ b/drivers/media/rc/ir-rx51.c > @@ -0,0 +1,496 @@ > +/* > + * Copyright (C) 2008 Nokia Corporation > + * > + * Based on lirc_serial.c > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA > + * > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#define LIRC_RX51_DRIVER_FEATURES (LIRC_CAN_SET_SEND_DUTY_CYCLE |\ > +
Re: [PATCH v2 0/4] ASoC machine driver for simple SoC with twl4030
On Tue, Aug 14, 2012 at 12:07:55PM +0300, Peter Ujfalusi wrote: > Create new unified ASoC machine driver (with DT support) for boards using > simple > configuration for audio and using the twl4030 codec. > This driver will replace the following machine drivers (since they are > basically > the same): > igep0020, omap3beagle, omap3evm and overo. Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator: twl-regulator: fix up VINTANA1/VINTANA2
On Wed, Aug 15, 2012 at 01:10:04AM +0300, Aaro Koskinen wrote: > It seems commit 2098e95ce9bb039ff2e7bf836df358d18a176139 (regulator: twl: > adapt twl-regulator driver to dt) accidentally deleted VINTANA1. Also > the same commit defines VINTANA2 twice with TWL4030_ADJUSTABLE_LDO and > TWL4030_FIXED_LDO. This patch changes the fixed one to be VINTANA1. Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 3/4] arm/dts: Add tps65910 regulator DT data to am335x-evm.dts
Hi Mark, On Wed, Aug 15, 2012 at 18:23:39, Mark Brown wrote: > On Tue, Aug 14, 2012 at 02:25:18PM +, AnilKumar, Chimata wrote: > > > AM335x EVM have one dedicated input supply which provide supplies to all > > the PMIC regulators. According to tps65910 "VDD1 regulator" input supply > > is from vcc1 so we have to create a dummy/parent/some node to handle this. > > Example below has the details. > > Your device tree should accurately reflect the hardware. > > > Similarly we have to add 7 more fixed regulators entries to provide input > > supply to different PMIC regulators. > > If you have all these unrelated supplies in the system then your device > tree should accurately reflect that. However this would be a very In that case I have to add all these fixed regulators. > unusual hardware design. Usually there would be a very small set of > system supply rails, frequently only one. In case of AM335X-EVM one dedicated supply (5v) feeding to all the input supplies (vcc1-7 and vccio) of the regulators. tps65910 PMIC have vcc1-7 and vccio input supplies which are feeding to all the regulators. (like one - one and one - many). Tps65910 regulator drivers registration fails if we not providing the correct input supply with supply name. One option I can see is that fixed voltage regulators. If we do this then total 21 (8 input supply fixed regulators and others are out regulators) are present in the system. If this is the correct approach then I will submit next version of patch. Thanks AnilKumar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] arm/dts: Add tps65910 regulator DT data to am335x-evm.dts
On Wed, Aug 15, 2012 at 04:47:02PM +, AnilKumar, Chimata wrote: > On Wed, Aug 15, 2012 at 18:23:39, Mark Brown wrote: > > If you have all these unrelated supplies in the system then your device > > tree should accurately reflect that. However this would be a very > In that case I have to add all these fixed regulators. Why? You then immediately go on to say... > > unusual hardware design. Usually there would be a very small set of > > system supply rails, frequently only one. > In case of AM335X-EVM one dedicated supply (5v) feeding to all the input > supplies (vcc1-7 and vccio) of the regulators. ...that they all map onto the same physical supply? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/8] ARM: OMAP2+: PM: introduce the power domains functional states
Jean, On Wed, Aug 15, 2012 at 3:32 PM, Jean Pihet wrote: > > Here is a re-spin after some comments and suggestions after review. > > Implement the functional states for the power domains: > - unify the API to use the functional states. pwrdm_set_next_fpwrst > now is the function to control the power domains power and logic > states, > - reorganize the powerdomain API in internal and external parts, > in powerdomain.h [1] > - protect the power domain state change by a lock in > pwrdm_set_next_fpwrst, > - introduce the functional states for power domains power states and > logic power states, and the conversion functions between the > functional and internal states, > - program the logic power state of power domains from the functional > states, in pwrdm_set_next_fpwrst > - convert the OMAP2/3/4 PM code to use the updated API, > - provide the power domains statistics by functional states, > - provide ftrace tracepoints with the functional state, > - provide error logs in critical code, which makes the development > easier. > > Note: [1] the physical split of internal and external APIs into > different header files is not part of this series, it comes as > a separate patch set. > > > Based on mainline kernel 3.6.0-rc1. > > Tested on OMAP3 Beagleboard, with suspend and cpuidle in RET and > OFF modes. > I didn't find any mention here about why are we going in this path and not in the direction proposed in another RFC [1] I have already given my comments[2] against the introduction of another PD layer which can be avoided easily as demonstrated by the RFC[1]. The comments are still applicable for this series too. We really need to reduce OMAP specific framework overhead and move towards more generic PM frameworks. For me, this series is a step back-ward from that direction. Am really sorry for being critical again but I remain unconvinced about this series and the problem it is trying to solve. May be you have valid reasons not to follow the approach in [1] and in that case, it will be good to clarify that so that some of us get to know your rationale. Regards Santosh [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg71732.html [2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69081.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] OMAPDSS: Do not require a VDDS_DSI regulator on am35xx
On our AM3505 based board, dpi.c complains that there is no VDSS_DSI regulator
and the framebuffer cannot be enabled. However, this check does not seem to
apply to AM3505/17 chips.
Taking into account comments received after my first patch[1], I have added
entries to dss_features.c to support the am35xx soc. Then in dpi.c, instead
of using cpu_is_omap34xx() and soc_is_am35xx(), a call to dss_has_feature()
is used.
[1] http://marc.info/?l=linux-fbdev&m=134272967203409&w=2
Signed-off-by: Raphaël Assénat
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 3266be2..0e83054 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -31,9 +31,9 @@
#include
#include
-#include
#include "dss.h"
+#include "dss_features.h"
static struct {
struct regulator *vdds_dsi_reg;
@@ -169,11 +169,6 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
{
int r;
- if (cpu_is_omap34xx() && !dpi.vdds_dsi_reg) {
- DSSERR("no VDSS_DSI regulator\n");
- return -ENODEV;
- }
-
if (dssdev->manager == NULL) {
DSSERR("failed to enable display: no manager\n");
return -ENODEV;
@@ -185,7 +180,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
goto err_start_dev;
}
- if (cpu_is_omap34xx()) {
+ if (dpi.vdds_dsi_reg) {
r = regulator_enable(dpi.vdds_dsi_reg);
if (r)
goto err_reg_enable;
@@ -229,7 +224,7 @@ err_dsi_pll_init:
err_get_dsi:
dispc_runtime_put();
err_get_dispc:
- if (cpu_is_omap34xx())
+ if (dpi.vdds_dsi_reg)
regulator_disable(dpi.vdds_dsi_reg);
err_reg_enable:
omap_dss_stop_device(dssdev);
@@ -250,7 +245,7 @@ void omapdss_dpi_display_disable(struct omap_dss_device
*dssdev)
dispc_runtime_put();
- if (cpu_is_omap34xx())
+ if (dpi.vdds_dsi_reg)
regulator_disable(dpi.vdds_dsi_reg);
omap_dss_stop_device(dssdev);
@@ -329,7 +324,7 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
{
DSSDBG("init_display\n");
- if (cpu_is_omap34xx() && dpi.vdds_dsi_reg == NULL) {
+ if (dss_has_feature(FEAT_VDDS_DSI) && dpi.vdds_dsi_reg == NULL) {
struct regulator *vdds_dsi;
vdds_dsi = dss_get_vdds_dsi();
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 9387097..6d4b6c5 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -373,6 +373,26 @@ static const enum dss_feat_id omap3430_dss_feat_list[] = {
FEAT_ALPHA_FIXED_ZORDER,
FEAT_FIFO_MERGE,
FEAT_OMAP3_DSI_FIFO_BUG,
+ FEAT_VDDS_DSI,
+};
+
+static const enum dss_feat_id am35xx_dss_feat_list[] = {
+ FEAT_LCDENABLEPOL,
+ FEAT_LCDENABLESIGNAL,
+ FEAT_PCKFREEENABLE,
+ FEAT_FUNCGATED,
+ FEAT_LINEBUFFERSPLIT,
+ FEAT_ROWREPEATENABLE,
+ FEAT_RESIZECONF,
+ FEAT_DSI_PLL_FREQSEL,
+ FEAT_DSI_REVERSE_TXCLKESC,
+ FEAT_VENC_REQUIRES_TV_DAC_CLK,
+ FEAT_CPR,
+ FEAT_PRELOAD,
+ FEAT_FIR_COEF_V,
+ FEAT_ALPHA_FIXED_ZORDER,
+ FEAT_FIFO_MERGE,
+ FEAT_OMAP3_DSI_FIFO_BUG,
};
static const enum dss_feat_id omap3630_dss_feat_list[] = {
@@ -487,6 +507,27 @@ static const struct omap_dss_features
omap3430_dss_features = {
.burst_size_unit = 8,
};
+/* AM35xx DSS Features. This is basically OMAP3 DSS Features without
+ the vdds_dsi regulator. */
+static const struct omap_dss_features am35xx_dss_features = {
+ .reg_fields = omap3_dss_reg_fields,
+ .num_reg_fields = ARRAY_SIZE(omap3_dss_reg_fields),
+
+ .features = am35xx_dss_feat_list,
+ .num_features = ARRAY_SIZE(am35xx_dss_feat_list),
+
+ .num_mgrs = 2,
+ .num_ovls = 3,
+ .supported_displays = omap3430_dss_supported_displays,
+ .supported_color_modes = omap3_dss_supported_color_modes,
+ .overlay_caps = omap3430_dss_overlay_caps,
+ .clksrc_names = omap3_dss_clk_source_names,
+ .dss_params = omap3_dss_param_range,
+ .supported_rotation_types = OMAP_DSS_ROT_DMA | OMAP_DSS_ROT_VRFB,
+ .buffer_size_unit = 1,
+ .burst_size_unit = 8,
+};
+
static const struct omap_dss_features omap3630_dss_features = {
.reg_fields = omap3_dss_reg_fields,
.num_reg_fields = ARRAY_SIZE(omap3_dss_reg_fields),
@@ -694,8 +735,12 @@ void dss_features_init(void)
omap_current_dss_features = &omap2_dss_features;
else if (cpu_is_omap3630())
omap_current_dss_features = &omap3630_dss_features;
- else if (cpu_is_omap34xx())
- omap_current_dss_features = &omap3430_dss_features;
+ else if (cpu_is_omap34xx()) {
+ if (soc_is_am35xx())
+ omap
Re: [git:v4l-dvb/for_v3.7] [media] media: rc: Introduce RX51 IR transmitter driver
Terve Sakari, Long time no see. On 08/15/12 19:06, Sakari Ailus wrote: > Heippa, > > Thanks for the patch! I know Mauro has already applied this so any changes > would make a separate patch. > Patches are cheap :) I'll have also couple of changes from Sean's comments. > I have tested this up to the point I can see that the IR LED blinks --- > using my phone's camera. :-) But I have no receivers so the testing ends to > this. Thanks for your thorough review and testing. > > On Mon, Aug 13, 2012 at 09:53:45PM +0200, Mauro Carvalho Chehab wrote: >> This is an automatic generated email to let you know that the following >> patch were queued at the >> http://git.linuxtv.org/media_tree.git tree: >> >> Subject: [media] media: rc: Introduce RX51 IR transmitter driver >> Author: Timo Kokkonen >> Date:Fri Aug 10 06:16:36 2012 -0300 >> >> This is the driver for the IR transmitter diode found on the Nokia >> N900 (also known as RX51) device. The driver is mostly the same as >> found in the original 2.6.28 based kernel that comes with the device. >> >> The following modifications have been made compared to the original >> driver version: >> >> - Adopt to the changes that has happen in the kernel during the past >> five years, such as the change in the include paths >> >> - The OMAP DM-timers require much more care nowadays. The timers need >> to be enabled and disabled or otherwise many actions fail. Timers >> must not be freed without first stopping them or otherwise the timer >> cannot be requested again. >> >> The code has been tested with sending IR codes with N900 device >> running Debian userland. The device receiving the codes was Anysee >> DVB-C USB receiver. > > Just a general question: how much this driver actually depends on the N900? > I can see there's a dependency to OMAP DM timers, but couldn't you use the > same driver if you just wired the IR LED there? Even the timer configuration > is there, so it looks a lot more generic than N900-specific. > Yeah, I was thinking that there are no other boards that have an IR diode connected to the PWM timer pin. But that doesn't stop anyone from soldering a diode one to his/her board. >> Signed-off-by: Timo Kokkonen >> Cc: Tony Lindgren >> Cc: linux-omap@vger.kernel.org >> Cc: Sakari Ailus >> Signed-off-by: Mauro Carvalho Chehab >> >> drivers/media/rc/Kconfig | 10 + >> drivers/media/rc/Makefile |1 + >> drivers/media/rc/ir-rx51.c | 496 >> >> include/media/ir-rx51.h| 10 + >> 4 files changed, 517 insertions(+), 0 deletions(-) >> >> --- >> >> http://git.linuxtv.org/media_tree.git?a=commitdiff;h=c332e8472d7db67766bcad33390c607fdd9ac5bc >> >> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig >> index 64be610..016f9ab 100644 >> --- a/drivers/media/rc/Kconfig >> +++ b/drivers/media/rc/Kconfig >> @@ -287,6 +287,16 @@ config IR_TTUSBIR >> To compile this driver as a module, choose M here: the module will >> be called ttusbir. >> >> +config IR_RX51 >> +tristate "Nokia N900 IR transmitter diode >> +depends on MACH_NOKIA_RX51 && OMAP_DM_TIMER > > You also should depend on LIRC. Yes. And if one had the diode in some other board than RX51, maybe this wouldn't need to depend on MACH_NOKIA_RX51 either. ... Which gave me an idea. We have this new PWM subsystem that I know nothing about. If the omap timer PWM routines were exposed through this API, we could modify this driver to a generic PWM lirc driver. I don't know how well the PWM api suits for that purpose, but it could be an interesting idea.. :) > >> +---help--- >> + Say Y or M here if you want to enable support for the IR >> + transmitter diode built in the Nokia N900 (RX51) device. >> + >> + The driver uses omap DM timers for gereating the carrier > > s/gereating/renerating/ > Uh oh, will fix.. >> + wave and pulses. >> + >> config RC_LOOPBACK >> tristate "Remote Control Loopback Driver" >> depends on RC_CORE >> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile >> index 66c8bae..56bacf0 100644 >> --- a/drivers/media/rc/Makefile >> +++ b/drivers/media/rc/Makefile >> @@ -23,6 +23,7 @@ obj-$(CONFIG_IR_FINTEK) += fintek-cir.o >> obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o >> obj-$(CONFIG_IR_ENE) += ene_ir.o >> obj-$(CONFIG_IR_REDRAT3) += redrat3.o >> +obj-$(CONFIG_IR_RX51) += ir-rx51.o >> obj-$(CONFIG_IR_STREAMZAP) += streamzap.o >> obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o >> obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o >> diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c >> new file mode 100644 >> index 000..9487dd3 >> --- /dev/null >> +++ b/drivers/media/rc/ir-rx51.c >> @@ -0,0 +1,496 @@ >> +/* >> + * Copyright (C) 2008 Nokia Corporation >> + * >> + * Based on lirc_serial.c >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the G
[PATCH 0/2] drm/omap: properties patches
From: Rob Clark Re-sending the earlier rotation property patch, plus Andre's z-order property patch rebased on latest staging-next. Andre Renaud (1): Expose the OMAP Z-Order property through DRM Rob Clark (1): staging: drm/omap: add rotation properties drivers/staging/omapdrm/omap_crtc.c | 10 +++ drivers/staging/omapdrm/omap_dmm_tiler.c | 47 +++-- drivers/staging/omapdrm/omap_dmm_tiler.h | 17 - drivers/staging/omapdrm/omap_drv.c | 17 + drivers/staging/omapdrm/omap_drv.h | 33 - drivers/staging/omapdrm/omap_fb.c| 99 ++ drivers/staging/omapdrm/omap_gem.c | 43 +++- drivers/staging/omapdrm/omap_plane.c | 111 -- 8 files changed, 331 insertions(+), 46 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] staging: drm/omap: add rotation properties
From: Rob Clark
Use tiled buffers for rotated/reflected scanout, with CRTC and plane
properties as the interface for userspace to configure rotation.
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_crtc.c | 10 +++
drivers/staging/omapdrm/omap_dmm_tiler.c | 47 --
drivers/staging/omapdrm/omap_dmm_tiler.h | 17 -
drivers/staging/omapdrm/omap_drv.c | 17 +
drivers/staging/omapdrm/omap_drv.h | 32 +-
drivers/staging/omapdrm/omap_fb.c| 99 +-
drivers/staging/omapdrm/omap_gem.c | 43 -
drivers/staging/omapdrm/omap_plane.c | 92 ---
8 files changed, 311 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_crtc.c
b/drivers/staging/omapdrm/omap_crtc.c
index 62e0022..98a10bc 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -191,10 +191,18 @@ static int omap_crtc_page_flip_locked(struct drm_crtc
*crtc,
return 0;
}
+static int omap_crtc_set_property(struct drm_crtc *crtc,
+ struct drm_property *property, uint64_t val)
+{
+ struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+ return omap_plane_set_property(omap_crtc->plane, property, val);
+}
+
static const struct drm_crtc_funcs omap_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
.destroy = omap_crtc_destroy,
.page_flip = omap_crtc_page_flip_locked,
+ .set_property = omap_crtc_set_property,
};
static const struct drm_crtc_helper_funcs omap_crtc_helper_funcs = {
@@ -231,6 +239,8 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
drm_crtc_init(dev, crtc, &omap_crtc_funcs);
drm_crtc_helper_add(crtc, &omap_crtc_helper_funcs);
+ omap_plane_install_properties(omap_crtc->plane, &crtc->base);
+
return crtc;
fail:
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index ec7a5c8..3ae3955 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -404,8 +404,26 @@ int tiler_release(struct tiler_block *block)
* Utils
*/
-/* calculate the tiler space address of a pixel in a view orientation */
-static u32 tiler_get_address(u32 orient, enum tiler_fmt fmt, u32 x, u32 y)
+/* calculate the tiler space address of a pixel in a view orientation...
+ * below description copied from the display subsystem section of TRM:
+ *
+ * When the TILER is addressed, the bits:
+ * [28:27] = 0x0 for 8-bit tiled
+ * 0x1 for 16-bit tiled
+ * 0x2 for 32-bit tiled
+ * 0x3 for page mode
+ * [31:29] = 0x0 for 0-degree view
+ * 0x1 for 180-degree view + mirroring
+ * 0x2 for 0-degree view + mirroring
+ * 0x3 for 180-degree view
+ * 0x4 for 270-degree view + mirroring
+ * 0x5 for 270-degree view
+ * 0x6 for 90-degree view
+ * 0x7 for 90-degree view + mirroring
+ * Otherwise the bits indicated the corresponding bit address to access
+ * the SDRAM.
+ */
+static u32 tiler_get_address(enum tiler_fmt fmt, u32 orient, u32 x, u32 y)
{
u32 x_bits, y_bits, tmp, x_mask, y_mask, alignment;
@@ -417,8 +435,11 @@ static u32 tiler_get_address(u32 orient, enum tiler_fmt
fmt, u32 x, u32 y)
x_mask = MASK(x_bits);
y_mask = MASK(y_bits);
- if (x < 0 || x > x_mask || y < 0 || y > y_mask)
+ if (x < 0 || x > x_mask || y < 0 || y > y_mask) {
+ DBG("invalid coords: %u < 0 || %u > %u || %u < 0 || %u > %u",
+ x, x, x_mask, y, y, y_mask);
return 0;
+ }
/* account for mirroring */
if (orient & MASK_X_INVERT)
@@ -439,11 +460,22 @@ dma_addr_t tiler_ssptr(struct tiler_block *block)
{
BUG_ON(!validfmt(block->fmt));
- return TILVIEW_8BIT + tiler_get_address(0, block->fmt,
+ return TILVIEW_8BIT + tiler_get_address(block->fmt, 0,
block->area.p0.x * geom[block->fmt].slot_w,
block->area.p0.y * geom[block->fmt].slot_h);
}
+dma_addr_t tiler_tsptr(struct tiler_block *block, uint32_t orient,
+ uint32_t x, uint32_t y)
+{
+ struct tcm_pt *p = &block->area.p0;
+ BUG_ON(!validfmt(block->fmt));
+
+ return tiler_get_address(block->fmt, orient,
+ (p->x * geom[block->fmt].slot_w) + x,
+ (p->y * geom[block->fmt].slot_h) + y);
+}
+
void tiler_align(enum tiler_fmt fmt, uint16_t *w, uint16_t *h)
{
BUG_ON(!validfmt(fmt));
@@ -451,11 +483,14 @@ void tiler_align(enum tiler_fmt fmt, uint16_t *w,
uint16_t *h)
*h = round_up(*h, geom[fmt].slot_h);
}
-uint32_t tiler_stride(enum tiler_fmt fmt)
+uint32_t tiler_stride(enum tiler_fmt fmt, uint32_t orient)
{
BUG_ON(!validfmt(fmt));
- return 1 << (CONT_WID
[PATCH 2/2] Expose the OMAP Z-Order property through DRM
From: Andre Renaud
Added support for zorder changes through DRM plane properties
Signed-off-by: Andre Renaud
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.h |1 +
drivers/staging/omapdrm/omap_plane.c | 19 +++
2 files changed, 20 insertions(+)
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index b103d28..9dc72d1 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -62,6 +62,7 @@ struct omap_drm_private {
/* properties: */
struct drm_property *rotation_prop;
+ struct drm_property *zorder_prop;
};
/* this should probably be in drm-core to standardize amongst drivers */
diff --git a/drivers/staging/omapdrm/omap_plane.c
b/drivers/staging/omapdrm/omap_plane.c
index 6931d06..4bde639 100644
--- a/drivers/staging/omapdrm/omap_plane.c
+++ b/drivers/staging/omapdrm/omap_plane.c
@@ -433,6 +433,15 @@ void omap_plane_install_properties(struct drm_plane *plane,
priv->rotation_prop = prop;
}
drm_object_attach_property(obj, prop, 0);
+
+prop = priv->zorder_prop;
+if (!prop) {
+ prop = drm_property_create_range(dev, 0, "zorder", 0, 3);
+ if (prop == NULL)
+ return;
+ priv->zorder_prop = prop;
+ }
+ drm_object_attach_property(obj, prop, 0);
}
int omap_plane_set_property(struct drm_plane *plane,
@@ -452,6 +461,16 @@ int omap_plane_set_property(struct drm_plane *plane,
ret = omap_plane_dpms(plane, DRM_MODE_DPMS_ON);
else
ret = 0;
+ } else if (property == priv->zorder_prop) {
+ struct omap_overlay *ovl = omap_plane->ovl;
+
+ DBG("%s: zorder: %d", ovl->name, (uint32_t)val);
+ omap_plane->info.zorder = val;
+
+ if (ovl->is_enabled(ovl))
+ ret = omap_plane_dpms(plane, DRM_MODE_DPMS_ON);
+ else
+ ret = 0;
}
return ret;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fate of OMAP3-Touchbook board
Hello, a few months ago, Always Innovating - a company behind their OMAP3 based product Touchbook basically stopped production. I've been porting some specific drivers for current kernels since then and I'd like to push at least some of them to the mainline. However, I found a bug in mainline that prevents this device from booting - and looks like noone has reported it for a few months. So, I'd like to ask - do you want to keep this board in mainline (in this case, I can send a few patches adding few drivers (backlight, accelerometer, soundcard, keyboard). Or do you want to remove it from the mainline altogether? Thanks for the answer Radek Pilar 0xE60DBF0D.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 04/14] ARM: OMAP5: Add minimal support for OMAP5430 SOC
Hi On Mon, 9 Jul 2012, Tony Lindgren wrote: > Below (untested) is what could be done in the short term. That's fine with me. Do you want to queue it or do you want me to queue it? > Heh these CK_ defines are now running out of the u16 cpu_mask. > > They really should be replaced with SoC specific lists of clocks > rather than bloating the cpu_mask and repeating it for every clock > that's compiled in for 800+ times. Frankly, an extra 1.6KB -- uncompressed -- is pretty low on my list of bloat concerns for multi-OMAP kernels. If it were up to me, I'd just change it to a u32 and be done with the problem for the foreseeable future. > I wonder if we could #define CK_OMAP_DUMMY 0 that's always set > for non-shared clocks if they only get set in some *_data.c > file in a unique way? > > Paul got any better ideas? Aside from using u32? Not really. As we've discussed in the past, at some point we should convert the clock initialization to using some kind of per-SoC list. But it doesn't seem worth spending too much time on that while the common clock framework conversion is higher priority. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/8] ARM: OMAP2+: PM: introduce the power domains functional states
Hi Santosh, On Wed, 15 Aug 2012, Shilimkar, Santosh wrote: > On Wed, Aug 15, 2012 at 3:32 PM, Jean Pihet wrote: > > I didn't find any mention here about why are we going in this path and not > in the direction proposed in another RFC [1] > I have already given my comments[2] against the introduction of another PD > layer which can be avoided easily as demonstrated by the RFC[1]. The comments > are still applicable for this series too. > > We really need to reduce OMAP specific framework overhead and > move towards more generic PM frameworks. For me, this series is > a step back-ward from that direction. Am really sorry for being critical > again but I remain unconvinced about this series and the problem it > is trying to solve. > > May be you have valid reasons not to follow the approach in [1] and in > that case, it will be good to clarify that so that some of us get > to know your rationale. I've asked Jean to handle the work of evaluating and/or integrating any feedback from you and Rajendra into this series. Jean, has this latest series fully considered those issues? Or are there still some areas of misalignment / lack of clarity? Anyway. If there's a problem with this process, it sounds like you, Rajendra, Jean, Benoît and I should schedule some time to talk over the same issues that you discussed with me on the phone. Perhaps next week? - Paul
RE: [PATCHv6 14/24] i2c: omap: always return IRQ_HANDLED
On Tue, Aug 14, 2012 at 19:48:56, Datta, Shubhrajyoti wrote:
> From: Felipe Balbi
>
> otherwise we could get our IRQ line disabled due
> to many spurious IRQs.
Patch description should be readable by itself. It is not a continuation of
subject line.
>
> Signed-off-by: Felipe Balbi
> Signed-off-by: Shubhrajyoti D
> ---
> drivers/i2c/busses/i2c-omap.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 80ebcf5..eb6898b 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -962,7 +962,7 @@ complete:
> }
> } while (stat);
>
> - return count ? IRQ_HANDLED : IRQ_NONE;
> + return IRQ_HANDLED;
> }
>
> static const struct i2c_algorithm omap_i2c_algo = {
> --
> 1.7.5.4
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
Regards,
Gururaja
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/8] ARM: OMAP2+: PM: introduce the power domains functional states
Paul, On Thu, Aug 16, 2012 at 6:18 AM, Paul Walmsley wrote: > > Hi Santosh, > > On Wed, 15 Aug 2012, Shilimkar, Santosh wrote: > > > On Wed, Aug 15, 2012 at 3:32 PM, Jean Pihet > > wrote: > > > > I didn't find any mention here about why are we going in this path and > > not > > in the direction proposed in another RFC [1] > > I have already given my comments[2] against the introduction of another > > PD > > layer which can be avoided easily as demonstrated by the RFC[1]. The > > comments > > are still applicable for this series too. > > > > We really need to reduce OMAP specific framework overhead and > > move towards more generic PM frameworks. For me, this series is > > a step back-ward from that direction. Am really sorry for being critical > > again but I remain unconvinced about this series and the problem it > > is trying to solve. > > > > May be you have valid reasons not to follow the approach in [1] and in > > that case, it will be good to clarify that so that some of us get > > to know your rationale. > > I've asked Jean to handle the work of evaluating and/or integrating any > feedback from you and Rajendra into this series. Jean, has this latest > series fully considered those issues? Or are there still some areas of > misalignment / lack of clarity? > Thanks for the information. The main objection to this series was to not add un-necessary glue layer which still remains. >From our discussion in past on and off list, your main intention for such a series was - 1. Need a way to support OSWR. - OSWR by definition is a RET with configurable logic and memory states. Its a true power state from PD point of view and its not a logical state. Now since we have agreed to make the OSWR as a static definition (in all products so far OSWR is used as a static definition with logic lost, memory retained kind of configuration.) - The above requirement can be easily fixed by adding the OSWR as an additional basic power state as demonstrated in RFC. - There is no need to add another glue layer for above. 2. Locking so that the low level APIs don't race and henec abstracting the exported API to 1 or 2 and making rest as private functions. -- Even before this series, except low level PM code, only one common API was used to set the PD low power state. int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 pwrst) -- Once we make OSWR as basic power state, we also avoid usage of pwrdm_set_logic_retst() API. -- We implement lock at this API and export only above API + may be omap_get_pwrdm_state() kind of API based on need. -- This solves the second requirement too. Even if we have more requirement, they can be addressed too without need of another layer. If you look at the diffstat alone between two approaches, it is evident how small piece of code is needed to support above. Am not too much into the lines of code but basic objection we have is not to add another glue layer. Thinking bit loud, for the logical layer for power domain we should move towards common device power domain APIs and if needed add/enhance them to support OMAP. drivers/base/power/domain.c May be this though is bit premature but the intetion is to move towards generic linux framework. > Anyway. If there's a problem with this process, it sounds like you, > Rajendra, Jean, Benoît and I should schedule some time to talk over the > same issues that you discussed with me on the phone. Perhaps next week? > We can surely do a call if needed. But the comments given so far and the RFC makes things more or less clear the contention point against the $subject series. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] ARM: OMAP3: Switch to use the unified audio driver (omap-twl4030) for selected boards
On 08/14/12 12:07, Peter Ujfalusi wrote: > These boards have similar audio setup and they can all use the same driver > for audio support if it is enabled in the kernel config. > > Signed-off-by: Peter Ujfalusi > Cc: Igor Grinberg > Acked-by: Tony Lindgren Acked-by: Igor Grinberg Thanks Peter! -- Regards, Igor. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
