Re: [PATCH] ARM: OMAP: dpll: enable bypass clock only when attempting dpll bypass

[Rajendra Nayak]

On Thursday 28 March 2013 10:02 PM, Mike Turquette wrote:
> Quoting Rajendra Nayak (2013-03-28 03:59:41)
>> omap3_noncore_dpll_set_rate() attempts an enable of bypass clk as well
>> as ref clk for every .set_rate attempt on a noncore DPLL, regardless of
>> whether the .set_rate results in the DPLL being locked or put in bypass.
>> Early at boot, while some of these DPLLs are programmed and locked
>> (using .set_rate for the DPLL), this causes an ordering issue.
>>
>> For instance, on OMAP5, the USB DPLL derives its bypass clk from ABE DPLL.
>> If a .set_rate of USB DPLL which programmes the M,N and locks it is called
>> before the one for ABE, the enable of USB bypass clk (derived from ABE DPLL)
>> then attempts to lock the ABE DPLL and fails as the M,N values for ABE
>> are yet to be programmed.
>>
>> To get rid of this ordering needs, enable bypass clk for a DPLL as part
>> of its .set_rate only when its being put in bypass, and only enable the
>> ref clk when its locked.
>>
> 
> Hi Rajendra,
> 
> Another way to solve this problem would be to model the DPLLs as mux
> clocks with a list of possible parents (e.g. clk->parents[2]).  Then set
> the CLK_SET_RATE_PARENT flag on the USB DPLL which will allow to

But isn't this applicable only to the _current_ parent? The bypass_clk isn't
the parent of DPLL USB when I try a .set_rate on it. Its the ref_clk.

> propagate the rate request up to the ABE DPLL.  This should set the MN
> dividers appropriately.
> 
>> Reported-by: Roger Quadros 
>> Signed-off-by: Rajendra Nayak 
>> ---
>>  arch/arm/mach-omap2/dpll3xxx.c |   19 +--
>>  1 file changed, 9 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
>> index 3aed4b0..6e9873f 100644
>> --- a/arch/arm/mach-omap2/dpll3xxx.c
>> +++ b/arch/arm/mach-omap2/dpll3xxx.c
>> @@ -480,20 +480,22 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, 
>> unsigned long rate,
>> if (!dd)
>> return -EINVAL;
>>  
>> -   __clk_prepare(dd->clk_bypass);
>> -   clk_enable(dd->clk_bypass);
>> -   __clk_prepare(dd->clk_ref);
>> -   clk_enable(dd->clk_ref);
> 
> Is this safe?  I always thought that the programming sequence in the TRM
> was to enable both the ref and bypass clocks during DPLL reprogramming.
> Maybe I am misremembering or assuming that the code strictly followed
> the TRM.

hmm, I didn't bother to check either. Will check, it would be strange though
if such a sequence is indeed needed.

regards,
Rajendra

> 
> Regards,
> Mike
> 
>> -
>> if (__clk_get_rate(dd->clk_bypass) == rate &&
>> (dd->modes & (1 << DPLL_LOW_POWER_BYPASS))) {
>> pr_debug("%s: %s: set rate: entering bypass.\n",
>>  __func__, __clk_get_name(hw->clk));
>>  
>> +   __clk_prepare(dd->clk_bypass);
>> +   clk_enable(dd->clk_bypass);
>> ret = _omap3_noncore_dpll_bypass(clk);
>> if (!ret)
>> new_parent = dd->clk_bypass;
>> +   clk_disable(dd->clk_bypass);
>> +   __clk_unprepare(dd->clk_bypass);
>> } else {
>> +   __clk_prepare(dd->clk_ref);
>> +   clk_enable(dd->clk_ref);
>> +
>> if (dd->last_rounded_rate != rate)
>> rate = __clk_round_rate(hw->clk, rate);
>>  
>> @@ -514,6 +516,8 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, 
>> unsigned long rate,
>> ret = omap3_noncore_dpll_program(clk, freqsel);
>> if (!ret)
>> new_parent = dd->clk_ref;
>> +   clk_disable(dd->clk_ref);
>> +   __clk_unprepare(dd->clk_ref);
>> }
>> /*
>> * FIXME - this is all wrong.  common code handles reparenting and
>> @@ -525,11 +529,6 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, 
>> unsigned long rate,
>> if (!ret)
>> __clk_reparent(hw->clk, new_parent);
>>  
>> -   clk_disable(dd->clk_ref);
>> -   __clk_unprepare(dd->clk_ref);
>> -   clk_disable(dd->clk_bypass);
>> -   __clk_unprepare(dd->clk_bypass);
>> -
>> return 0;
>>  }
>>  
>> -- 
>> 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

--
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 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options

[Tomi Valkeinen]

On 2013-03-28 23:28, Tony Lindgren wrote:
> * Tomi Valkeinen  [130328 10:16]:
>> On 2013-03-28 18:53, Tony Lindgren wrote:
>>>
>>> Yes that's not nice from usability point of view. Can we still switch
>>> between LCD and DVI during the runtime? I thought the issue was registering
>>> multiple LCD panels where only one can exist at a time?
>>
>> I guess I could've been more verbose in my descriptions. And I agree
>> this is not a nice change.
>>
>> No, we can't switch between the LCD and DVI. But that's not strictly DSS
>> issue. The selection between LCD and DVI (or any other displays on the
>> same bus) are board specific things, sometimes requiring board specific
>> gpios or even things like i2c commands to muxes.
>>
>> It works now because we have custom callbacks in the board files to do
>> those things, but it'll break with DT.
> 
> Well people are already used to changing between LCD and DVI.. So we
> need some way of doing it with DT also.
> 
> How do you plan to change between LCD and DVI with DT? By using some
> custom driver modules?

I don't know, but I guess we need board specific drivers.

Do you know if there are other similar cases for other busses? I mean, I
think this is a similar case than, say, having two i2c devices with the
same i2c-id on the same bus. Only one of the devices can be enabled, the
other must be disconnected. And how the connect/disconnect is made is
board specific.

> There's the capebus coming that can be used for that too, but in most
> cases all the hardware is permanently connected with LCD and DVI. So
> sounds like capebus should only be needed for the add on boards.

True.

Well, depends on how you look at it. From one point of view there's no
real difference whether the disabled device is physically on the board
or not, as it has to be disconnected. The details depend on the bus, but
for example for DSI I think the disabled device has to be totally
removed from the DSI bus with some mux or such.

But, from the other point of view, the devices are there, on the board,
and in some cases the HW has been designed to support switching the
displays during runtime.

So what I wish is that I could make the linux device for the display to
be removed when it's disabled. I believe that can be done, but I guess
it requires a board specific driver, with some custom user interface to
do that.

And it would be different user interface than currently, which is again
not so nice. Currently the devices are always there, with their sysfs
files, and those sysfs files are used to enable/disable the devices. If
the device is removed, the sysfs files get removed also...

But I would really like to get rid of the current model, which I think
was a very bad design decision.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

[Viresh Kumar]

On Fri, Mar 29, 2013 at 3:22 AM, Nishanth Menon  wrote:
> As multi-platform build is being adopted by more and more ARM platforms,
> initcall function should be used very carefully.  For example, when
> CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
> will be called on all the platforms to initialize omap-cpufreq driver.
>
> Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
> tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
> for OMAP in a single image, we need to ensure the following:
> 1. With device tree boot, we use cpufreq-cpu0
> 2. With non device tree boot, we use omap-cpufreq
>
> In the case of (1), we will have cpu OPPs and regulator registered
> as part of the device tree nodes, to ensure that omap-cpufreq
> and cpufreq-cpu0 don't conflict in managing the frequency of the
> same CPU, we should not permit omap-cpufreq to be probed.
>
> In the case of (2), we will not have the cpufreq-cpu0 device, hence
> only omap-cpufreq will be active.
>
> To eliminate this undesired these effects, we change omap-cpufreq
> driver to have it instantiated as a platform_driver and register
> "omap-cpufreq" device only when booted without device tree nodes on
> OMAP platforms.
>
> This allows the following:
> a) Will only run on platforms that create the platform_device
>"omap-cpufreq".
> b) Since the platform_device is registered only when device tree nodes
>are *not* populated, omap-cpufreq driver does not conflict with
>the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
>device tree nodes are present.
>
> Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
> (cpufreq: instantiate cpufreq-cpu0 as a platform_driver)
>
> Cc: Kevin Hilman 
> Cc: Rajendra Nayak 
> Cc: Paul Walmsley 
> Cc: "Benoît Cousson" 
> Cc: Jon Hunter 
> Cc: Keerthy 
> Cc: Santosh Shilimkar 
> Cc: Shawn Guo 
> [robherri...@gmail.com: reported conflict of omap-cpufreq vs other
> driver in an non-device tree supported boot]
> Reported-by: Rob Herring 
> Signed-off-by: Nishanth Menon 
> ---
> Changes in V3:
> - converted to platform_driver to
> address https://patchwork.kernel.org/patch/2303491/ as well
> - modified CC list.
> V2: https://patchwork.kernel.org/patch/2303491/
> V1: https://patchwork.kernel.org/patch/2273681/
>
>  arch/arm/mach-omap2/pm.c   |9 +
>  drivers/cpufreq/omap-cpufreq.c |   19 ++-
>  2 files changed, 23 insertions(+), 5 deletions(-)

For cpufreq core:

Acked-by: Viresh Kumar 
--
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 5/6] ARM: OMAP3+: ABB: introduce ABB driver

[Nishanth Menon]

- ti internal list which got into the git send-email by error. Apologies
on the bounces which might have resulted...

On 14:27-20130328, Mike Turquette wrote:
> Quoting Andrii Tseglytskyi (2013-03-28 10:16:07)
> > From: "Andrii.Tseglytskyi" 
Ownership of ABB driver patch probably still belongs to Mike as the original
author of the code and working out all the details to entitle ABB on OMAP
platforms :)
> > 
[..]
> You should probably post this as an RFC.  It remains to be seen if using
> the clk rate-change notifiers will be the mechanism for scaling voltage
> in The Future.  This patch is helpful for the purposes of that
> discussion but shouldn't be merged until there is more consensus.
I agree. + include linux-arm-kernel and lkml in CC on the next *public*
revision :).

[..]
> 
> > +/*
> > + * struct omap_abb_data - common data for each instance of ABB ldo
> > + *
> > + * @opp_sel_mask:  selects Fast/Nominal/Slow OPP for ABB
> > + * @opp_change_mask:   selects OPP_CHANGE bit value
> > + * @sr2_wtcnt_value_mask:  LDO settling time for active-mode OPP change
> > + * @sr2en_mask:enables/disables ABB
> > + * @fbb_sel_mask:  selects FBB mode
> > + * @rbb_sel_mask:  selects RBB mode
> > + * @settling_time: IRQ handle used to resolve IRQSTATUS offset & masks
> > + * @clock_cycles:  value needed for LDO setting time calculation
> > + * @setup_offs:PRM_LDO_ABB_XXX_SETUP register offset
> > + * @control_offs:  PRM_LDO_ABB_IVA_CTRL register offset
> 
> Can you align all of these?
We should check up on AM and DM series as well - if the bit offsets are
precisely the same, we could stick with macros instead of having the
masks and register offsets in a device specific manner.

[..]
> > +/**
> > + * omap_abb_readl() - reads ABB control memory
> > + * @abb:   pointer to the abb instance
> > + * @offs:  offset to read
> > + *
> > + * Returns @offs value
> > + */
> > +static u32 omap_abb_readl(struct omap_abb *abb, u32 offs)
> > +{
> > +   return __raw_readl(abb->control + offs);
> > +}
> 
> readl instead of __raw_readl?
Ack. readl/writel should be used..

> > +/**
> > + * omap_abb_clock_rate_change() - ABB clock notifier callback
> > + * @nb:notifier block
> > + * @flags: notifier event type
> > + * @data:  notifier data, contains clock rates
> > + *
> > + * Returns NOTIFY_OK
> > + */
> > +static int omap_abb_clock_rate_change(struct notifier_block *nb,
> > + unsigned long flags, void *data)
> > +{
> > +   struct clk_notifier_data *cnd = data;
> > +   struct omap_abb *abb = container_of(nb, struct omap_abb, 
> > abb_clk_nb);
> > +
> > +   switch (flags) {
> > +   case PRE_RATE_CHANGE:
> > +   omap_abb_pre_scale(abb, cnd->old_rate, cnd->new_rate);
> > +   break;
> > +   case POST_RATE_CHANGE:
> > +   omap_abb_post_scale(abb, cnd->old_rate, cnd->new_rate);
> > +   break;
> > +   }
> > +
> > +   return NOTIFY_OK;
> > +}
> 
> How does this synchronize with the VC/VP voltage transition?  Ordering
> is important here and if the clk rate-change notifiers are used for both
> a VP force update and for an FBB transition there is no guarantee of the
> ordering.
I need to dig into this series deeper, but the requirement is as
follows:
Actual voltage change may occur with vc/vp - OMAP3,4,5 OR with i2c1- AM
series or the upcoming DRA SoCs, intent is to model the vc-vp->pmic as
regulators (some internal patches circulate for this, but not mature enough
to be send out in a public list yet)

Key however is:
* if we do as clock notifiers(as this series attempts I believe), we'd get ABB
settings around clock change boundary.
Alternative might be to do it around voltage change - we could, in
theory:
a) make an omap voltage regulator and provide notifier around the same
and hook ABB to it. the omap voltage regulator will in turn call the
appropriate voltage regulator (modelled from a regulator that controls
an PMIC over i2c1 OR over vc-vp regulator)
b) make ABB as an regulator by itself?
c) how might this work if we have DVFS capability in CCF itself[1]? it
might be better to have it as notifiers to regulator (the pseudo
omap-voltage regulator perhaps?)

[1] CCF DVFS patches:
https://patchwork.kernel.org/patch/2195431/
https://patchwork.kernel.org/patch/2195421/
https://patchwork.kernel.org/patch/2195451/
https://patchwork.kernel.org/patch/2195441/
https://patchwork.kernel.org/patch/2195461/

-- 
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] ARM: OMAP2+: Generic cleanups for 3.10

[Tony Lindgren]

* Kevin Hilman  [130328 10:13]:
> Santosh Shilimkar  writes:
> 
> > On Thursday 28 March 2013 01:39 AM, Shilimkar, Santosh wrote:
> >> Sorry for top posting ...
> >> I will pick the ack and update commit log to prepare new pull request
> >> for you. 
> >> 
> > I have updated the branch picking acks and updating changelogs and same
> > is available below. No change in code.
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git 
> > for_3.10/omap_generic_cleanup_v2
> >
> 
> Thanks for the changelog updates.  No more concerns from me.

Thanks pulled into omap-for-v3.10/cleanup-v2.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V3 1/2] ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot

[Nishanth Menon]

With OMAP3+ and AM33xx supported SoC having defined CPU device tree
entries with operating-points defined, we can now use the SoC
generic cpufreq-cpu0 driver by registering appropriate device.

As part of this change, add dummy clock node to use cpufreq-cpu0.
This is an suggested solution till we have OMAP clock nodes in device
tree.
Once the OMAP device tree conversion is complete, we can then do:
clocks = <&dpll_mpu_ck>; or the SoC specific equivalent.

Inspired by patch: https://patchwork.kernel.org/patch/2067841/
now made generic.

Cc: Kevin Hilman 
Cc: Rajendra Nayak 
Cc: Paul Walmsley 
Cc: "Benoît Cousson" 
Cc: Jon Hunter 
Cc: Keerthy 
Cc: Santosh Shilimkar 
Cc: Shawn Guo 
Signed-off-by: Nishanth Menon 
---
Changes in v3:
- modified CC list.
- no functional change
V2: https://patchwork.kernel.org/patch/2303471/
V1: https://patchwork.kernel.org/patch/2273571/

 arch/arm/mach-omap2/board-generic.c   |5 +
 arch/arm/mach-omap2/cclock33xx_data.c |2 +-
 arch/arm/mach-omap2/cclock3xxx_data.c |3 ++-
 arch/arm/mach-omap2/cclock44xx_data.c |3 ++-
 4 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-generic.c 
b/arch/arm/mach-omap2/board-generic.c
index afa509a..5b147ef 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -49,6 +49,11 @@ static void __init omap_generic_init(void)
omap4_panda_display_init_of();
else if (of_machine_is_compatible("ti,omap4-sdp"))
omap_4430sdp_display_init_of();
+
+   if (IS_ENABLED(CONFIG_GENERIC_CPUFREQ_CPU0)) {
+   struct platform_device_info devinfo = { .name = "cpufreq-cpu0", 
};
+   platform_device_register_full(&devinfo);
+   }
 }
 
 #ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c 
b/arch/arm/mach-omap2/cclock33xx_data.c
index 476b820..cf7e736 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -852,7 +852,7 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL,   "dpll_core_m5_ck",  &dpll_core_m5_ck,   
CK_AM33XX),
CLK(NULL,   "dpll_core_m6_ck",  &dpll_core_m6_ck,   
CK_AM33XX),
CLK(NULL,   "dpll_mpu_ck",  &dpll_mpu_ck,   CK_AM33XX),
-   CLK("cpu0", NULL,   &dpll_mpu_ck,   CK_AM33XX),
+   CLK("cpufreq-cpu0.0",   NULL,   &dpll_mpu_ck,   
CK_AM33XX),
CLK(NULL,   "dpll_mpu_m2_ck",   &dpll_mpu_m2_ck,
CK_AM33XX),
CLK(NULL,   "dpll_ddr_ck",  &dpll_ddr_ck,   CK_AM33XX),
CLK(NULL,   "dpll_ddr_m2_ck",   &dpll_ddr_m2_ck,
CK_AM33XX),
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c 
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..5a5b471 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3501,7 +3501,8 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL,   "uart4_ick",&uart4_ick_am35xx,  CK_AM35XX),
CLK(NULL,   "timer_32k_ck", &omap_32k_fck,  CK_3XXX),
CLK(NULL,   "timer_sys_ck", &sys_ck,CK_3XXX),
-   CLK(NULL,   "cpufreq_ck",   &dpll1_ck,  CK_3XXX),
+   CLK(NULL,   "cpufreq_ck",   &dpll1_ck,  CK_3XXX), /* used in 
non-device tree boot */
+   CLK("cpufreq-cpu0.0",   NULL,   &dpll1_ck,  CK_3XXX), /* used in 
device tree boot */
 };
 
 static const char *enable_init_clks[] = {
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c 
b/arch/arm/mach-omap2/cclock44xx_data.c
index 3d58f33..bcea785 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1660,7 +1660,8 @@ static struct omap_clk omap44xx_clks[] = {
CLK("4013a000.timer",   "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
CLK("4013c000.timer",   "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
CLK("4013e000.timer",   "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
-   CLK(NULL,   "cpufreq_ck",   &dpll_mpu_ck,   CK_443X),
+   CLK(NULL,   "cpufreq_ck",   &dpll_mpu_ck,   CK_443X), /* used in 
non-device tree boot */
+   CLK("cpufreq-cpu0.0",   NULL,   &dpll_mpu_ck,   CK_443X), /* used in 
device tree boot */
 };
 
 int __init omap4xxx_clk_init(void)
-- 
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 V3 2/2] cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

[Nishanth Menon]

As multi-platform build is being adopted by more and more ARM platforms,
initcall function should be used very carefully.  For example, when
CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
will be called on all the platforms to initialize omap-cpufreq driver.

Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
tree entries.  To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
for OMAP in a single image, we need to ensure the following:
1. With device tree boot, we use cpufreq-cpu0
2. With non device tree boot, we use omap-cpufreq

In the case of (1), we will have cpu OPPs and regulator registered
as part of the device tree nodes, to ensure that omap-cpufreq
and cpufreq-cpu0 don't conflict in managing the frequency of the
same CPU, we should not permit omap-cpufreq to be probed.

In the case of (2), we will not have the cpufreq-cpu0 device, hence
only omap-cpufreq will be active.

To eliminate this undesired these effects, we change omap-cpufreq
driver to have it instantiated as a platform_driver and register
"omap-cpufreq" device only when booted without device tree nodes on
OMAP platforms.

This allows the following:
a) Will only run on platforms that create the platform_device
   "omap-cpufreq".
b) Since the platform_device is registered only when device tree nodes
   are *not* populated, omap-cpufreq driver does not conflict with
   the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
   device tree nodes are present.

Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
(cpufreq: instantiate cpufreq-cpu0 as a platform_driver)

Cc: Kevin Hilman 
Cc: Rajendra Nayak 
Cc: Paul Walmsley 
Cc: "Benoît Cousson" 
Cc: Jon Hunter 
Cc: Keerthy 
Cc: Santosh Shilimkar 
Cc: Shawn Guo 
[robherri...@gmail.com: reported conflict of omap-cpufreq vs other
driver in an non-device tree supported boot]
Reported-by: Rob Herring 
Signed-off-by: Nishanth Menon 
---
Changes in V3:
- converted to platform_driver to
address https://patchwork.kernel.org/patch/2303491/ as well
- modified CC list.
V2: https://patchwork.kernel.org/patch/2303491/
V1: https://patchwork.kernel.org/patch/2273681/

 arch/arm/mach-omap2/pm.c   |9 +
 drivers/cpufreq/omap-cpufreq.c |   19 ++-
 2 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 673a4c1..8d15f9a 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -265,6 +265,12 @@ static void __init omap4_init_voltages(void)
omap2_set_init_voltage("iva", "dpll_iva_m5x2_ck", "iva");
 }
 
+static inline void omap_init_cpufreq(void)
+{
+   struct platform_device_info devinfo = { .name = "omap-cpufreq", };
+   platform_device_register_full(&devinfo);
+}
+
 static int __init omap2_common_pm_init(void)
 {
if (!of_have_populated_dt())
@@ -294,6 +300,9 @@ int __init omap2_common_pm_late_init(void)
 
/* Smartreflex device init */
omap_devinit_smartreflex();
+
+   /* cpufreq dummy device instantiation */
+   omap_init_cpufreq();
}
 
 #ifdef CONFIG_SUSPEND
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 9128c07..d4f84b8 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -252,7 +253,7 @@ static struct cpufreq_driver omap_driver = {
.attr   = omap_cpufreq_attr,
 };
 
-static int __init omap_cpufreq_init(void)
+static int omap_cpufreq_probe(struct platform_device *pdev)
 {
mpu_dev = get_cpu_device(0);
if (!mpu_dev) {
@@ -280,12 +281,20 @@ static int __init omap_cpufreq_init(void)
return cpufreq_register_driver(&omap_driver);
 }
 
-static void __exit omap_cpufreq_exit(void)
+static int omap_cpufreq_remove(struct platform_device *pdev)
 {
-   cpufreq_unregister_driver(&omap_driver);
+   return cpufreq_unregister_driver(&omap_driver);
 }
 
+static struct platform_driver omap_cpufreq_platdrv = {
+   .driver = {
+   .name   = "omap-cpufreq",
+   .owner  = THIS_MODULE,
+   },
+   .probe  = omap_cpufreq_probe,
+   .remove = omap_cpufreq_remove,
+};
+module_platform_driver(omap_cpufreq_platdrv);
+
 MODULE_DESCRIPTION("cpufreq driver for OMAP SoCs");
 MODULE_LICENSE("GPL");
-module_init(omap_cpufreq_init);
-module_exit(omap_cpufreq_exit);
-- 
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 V3 0/2] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

[Nishanth Menon]

The following version 3 of the series arose from trying to use BeagleBoard-XM
(OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the
generic cpufreq-cpu0 driver to be used in device tree enabled boot while
maintaining support of the legacy omap-cpufreq driver when used in non device
tree enabled boot.

However, in order to enable complete SoC entitlement for OMAP platforms, with
this series, key features are still pending on device tree adaptation for OMAP:
A) clock framework data transition to DT - this should happen soon, so this
series hacks the clock node for the time being as suggested in review of
original series[1].
B) On processors that use voltage controller, voltage processor (VC/VP hardware
loop using I2C_SR path) - we have started work on transitioning them to
regulator framework driven by DT.
C) Adaptive Body Bias and SmartReflex AVS conversion to DT. [2]

Note: At this point in time, we do not have DT entries for clock on OMAP
platforms. Common Clock Framework(CCF) could also control regulators[3].
Once these conversions are complete, there might be minimal cleanup work to
switch to the new data structure changes.

Key benefit of the series is to allow all relevant TI platforms now to use a
single cpufreq driver and equivalent frameworks in addition be part of the
transition to device tree.
NOTE: As a result of this series:
1. omap-cpufreq will be used only in non device tree boot scenario. we should
   delete this driver once the 100% DT conversion is complete.
2. Generic cpufreq-cpu0 will be used only in device tree boot scenario.
   boot systems.

Key changes in version 3:
- series now rebased on Device tree patches queued for OMAP 3.10
- DT patches introducing OPPs are now merged, so pending patches alone
  are part of the new series.
- omap-cpufreq is now converted to platform_device to address:
http://marc.info/?t=13643490191&r=1&w=2

version 2 of the series:
http://marc.info/?t=13637157023&r=1&w=2
available at:

https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v2

version 1 of the series:
http://marc.info/?t=13632948545&r=1&w=2
available at:

https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1

[1] Original discussion thread which triggered this series:
http://marc.info/?l=linux-pm&m=136304313700602&w=2
https://patchwork.kernel.org/patch/2251841/
https://patchwork.kernel.org/patch/2251851/
[2] ABB RFC: http://marc.info/?l=linux-omap&m=136449099409794&w=2 
[3] CCF DVFS patches:
https://patchwork.kernel.org/patch/2195431/
https://patchwork.kernel.org/patch/2195421/
https://patchwork.kernel.org/patch/2195451/
https://patchwork.kernel.org/patch/2195441/
https://patchwork.kernel.org/patch/2195461/

Version 3 is now based on for-3.10/dts branch from Benoit:

http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts
d114294 ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node

Version 3 is also available at:

https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v3
git link: git://github.com/nmenon/linux-2.6-playground.git
branch: cpufreq-cpu0-omap-all-v3

Test coverage:
test script: http://pastebin.com/zrr8ptge
Platforms verified:
beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/GVP2wDVr
beagleboard (rev C1D) - OMAP3430 compatible
- DT enabled boot: http://pastebin.com/2AY1F5Qa
- No DT enabled boot: http://pastebin.com/hDk0gbpU
omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/5tHAQcLZ
Pandaboard -(OMAP4430 ES2.2) - http://pastebin.com/6D9aDPXT
Pandaboard-ES -(OMAP4460 ES1.1) - http://pastebin.com/ExrBEczr

Nishanth Menon (2):
  ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot
  cpufreq: OMAP: instantiate omap-cpufreq as a platform_driver

 arch/arm/mach-omap2/board-generic.c   |5 +
 arch/arm/mach-omap2/cclock33xx_data.c |2 +-
 arch/arm/mach-omap2/cclock3xxx_data.c |3 ++-
 arch/arm/mach-omap2/cclock44xx_data.c |3 ++-
 arch/arm/mach-omap2/pm.c  |9 +
 drivers/cpufreq/omap-cpufreq.c|   19 ++-
 6 files changed, 33 insertions(+), 8 deletions(-)

Cc: Kevin Hilman 
Cc: Rajendra Nayak 
Cc: Paul Walmsley 
Cc: "Benoît Cousson" 
Cc: Jon Hunter 
Cc: Keerthy 
Cc: Santosh Shilimkar 
Cc: Shawn Guo 

Regards,
Nishanth Menon
-- 
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

Re: [PATCH] OMAP3 ROM Random Number Generator support

[Tony Lindgren]

* Pali Rohár  [130328 10:58]:
> 
> Here is new version of patch:
> 
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -486,6 +486,23 @@ static void omap_init_mcspi(void)
>  static inline void omap_init_mcspi(void) {}
>  #endif
>  
> +extern u32 *omap3_rom_rng_call(u32 id, u32 proc, u32 flags, u32 va_ptr);
> +
> +static struct platform_device omap3_rom_rng_device = {
> + .name   = "omap3-rom-rng",
> + .id = -1,
> + .dev= {
> + .platform_data  = omap3_rom_rng_call,
> + },
> +};
> +
> +static void omap_init_rom_rng(void)
> +{
> + if (!cpu_is_omap34xx() || omap_type() == OMAP2_DEVICE_TYPE_GP)
> + return;
> + platform_device_register(&omap3_rom_rng_device);
> +}
> +
>  /**
>   * omap_init_rng - bind the RNG hwmod to the RNG omap_device
>   *

This driver probably only works on Nokia boards because of the
different SMC call numbering. Until it's been verified on some
other HS omap34xx, I'd probably register this only from the
Nokia board-*.c file.

> --- /dev/null
> +++ b/drivers/char/hw_random/omap3-rom-rng.c
> +static int omap3_rom_rng_probe(struct platform_device *pdev)
> +{
> + printk(KERN_INFO "%s: initializing\n", omap3_rom_rng_name);
> +
> + omap3_rom_rng_call = pdev->dev.platform_data;
> + if (!omap3_rom_rng_call) {
> + printk(KERN_ERR "%s: omap3_rom_rng_call is NULL\n",
> +omap3_rom_rng_name);
> + return -EINVAL;
> + }
> +
> + setup_timer(&idle_timer, omap3_rom_idle_rng, 0);
> + rng_clk = clk_get_sys("omap_rng", "ick");
> + if (IS_ERR(rng_clk)) {
> + printk(KERN_ERR "%s: unable to get RNG clock\n",
> +omap3_rom_rng_name);
> + return IS_ERR(rng_clk);
> + }

You can use regular clk_get if you add the alias to
struct omap_clk omap3xxx_clks table.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options

[Tony Lindgren]

* Tomi Valkeinen  [130328 10:16]:
> On 2013-03-28 18:53, Tony Lindgren wrote:
> > 
> > Yes that's not nice from usability point of view. Can we still switch
> > between LCD and DVI during the runtime? I thought the issue was registering
> > multiple LCD panels where only one can exist at a time?
> 
> I guess I could've been more verbose in my descriptions. And I agree
> this is not a nice change.
> 
> No, we can't switch between the LCD and DVI. But that's not strictly DSS
> issue. The selection between LCD and DVI (or any other displays on the
> same bus) are board specific things, sometimes requiring board specific
> gpios or even things like i2c commands to muxes.
> 
> It works now because we have custom callbacks in the board files to do
> those things, but it'll break with DT.

Well people are already used to changing between LCD and DVI.. So we
need some way of doing it with DT also.

How do you plan to change between LCD and DVI with DT? By using some
custom driver modules?

There's the capebus coming that can be used for that too, but in most
cases all the hardware is permanently connected with LCD and DVI. So
sounds like capebus should only be needed for the add on boards.
 
> >> I bet there must be a much better solution for DT support.
> > 
> > Well the best legacy support option would be some fbdev/panel generic 
> > cmdline
> > option to specify which one to use. Maybe there is already something like
> > that available that the board-*.c files can parse and can be used also
> > later on with DT support to specify the preferred output?
> > 
> > What we don't want to do is add a board specific cmdline option as the
> > board-*.c files will be going away as soon as DT is usable for us and we
> > don't want to support a board specific cmdline after that. But if it's
> > a generic option then parsing it in the board-*.c file or the driver later
> > on can be supported.
> > 
> > Of course for some cases it might be possible to detect the configured
> > panel based on what's plugged in over i2c.
> 
> I could look at using omapdss's module parameter for this. It has
> default display parameter. Perhaps the board files could parse this, and
> use it to decide which display to register. Perhaps that'd cause less
> inconvenience.
> 
> It's still quite hacky, as you can only select one display. If there's a
> board with two video outputs, and, say, 2 displays connected to each.
> You can only select the display for one of the busses. Anyway, we don't
> have that kind of board in the mainline, so it's not an issue.

If we can use omapdss cmdline params for initializing the selected display,
that allows leaving out the kconfig selection, so that's much nicer for
distros etc.

--
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 5/6] ARM: OMAP3+: ABB: introduce ABB driver

[Mike Turquette]

Quoting Andrii Tseglytskyi (2013-03-28 10:16:07)
> From: "Andrii.Tseglytskyi" 
> 
> This patch introduces the Adaptive Body-Bias LDO driver,
> which handles LDOs voltage during OPP change routine.
> It follows general principles of ABB implementation
> in kernel 3.4.
> 
> Some new features are added:
> 
> 1) ABB driver uses clock notifier framework to scale LDO.
> To make this working it handles it's own OPP table.
> OPP table has the following format in device tree:
> 
> operating-points = <
>/* kHz   ABB (0 - Bypass, 1 - FBB, 2 - RBB) */
>499200   0
>1099800  1
>150  1
>1699200  1
> >;
> 
> Generic API is used for OPP table parsing - of_init_opp_table()
> 
> 2) ABB driver doesn't have any public interfaces. It follows
> Voltage/Frequency changes, using only notification mechanism.
> 
> 3) ABB driver uses PRM_IRQSTATUS register to check tranxdone status.
> This register is shared with VP.

Hi Andrii,

You should probably post this as an RFC.  It remains to be seen if using
the clk rate-change notifiers will be the mechanism for scaling voltage
in The Future.  This patch is helpful for the purposes of that
discussion but shouldn't be merged until there is more consensus.

Some comments below.



> +/*
> + * struct omap_abb_data - common data for each instance of ABB ldo
> + *
> + * @opp_sel_mask:  selects Fast/Nominal/Slow OPP for ABB
> + * @opp_change_mask:   selects OPP_CHANGE bit value
> + * @sr2_wtcnt_value_mask:  LDO settling time for active-mode OPP change
> + * @sr2en_mask:enables/disables ABB
> + * @fbb_sel_mask:  selects FBB mode
> + * @rbb_sel_mask:  selects RBB mode
> + * @settling_time: IRQ handle used to resolve IRQSTATUS offset & masks
> + * @clock_cycles:  value needed for LDO setting time calculation
> + * @setup_offs:PRM_LDO_ABB_XXX_SETUP register offset
> + * @control_offs:  PRM_LDO_ABB_IVA_CTRL register offset

Can you align all of these?

> + */
> +struct omap_abb_data {
> +   u32 opp_sel_mask;
> +   u32 opp_change_mask;
> +   u32 sr2_wtcnt_value_mask;
> +   u32 sr2en_mask;
> +   u32 fbb_sel_mask;
> +   u32 rbb_sel_mask;
> +   unsigned long settling_time;
> +   unsigned long clock_cycles;
> +   u8 setup_offs;
> +   u8 control_offs;
> +};
> +
> +/*
> + * struct omap_abb - ABB ldo instance
> + *
> + * @control:   memory mapped ABB registers
> + * @txdone:memory mapped IRQSTATUS register
> + * @dev:   device, for which ABB is created
> + * @txdone_mask:   ABB mode change done bit
> + * @opp_sel:   current ABB status - Fast/Nominal/Slow
> + * @notify_clk:clock, which rate changes are handled by ABB
> + * @data:  common data
> + * @abb_clk_nb:clock rate change notifier block
> + */
> +struct omap_abb {
> +   void __iomem*control;
> +   void __iomem*txdone;
> +   struct device   *dev;
> +   u32 txdone_mask;
> +   u32 opp_sel;
> +   struct clk  *notify_clk;
> +   struct omap_abb_datadata;
> +   struct notifier_block abb_clk_nb;
> +};
> +

Ditto.

> +static const struct omap_abb_data __initdata omap36xx_abb_data = {
> +   .opp_sel_mask   = (3 << 0), /* OMAP3630_OPP_SEL_MASK */
> +   .opp_change_mask= (1 << 2), /* OMAP3630_OPP_CHANGE_MASK */
> +   .sr2en_mask = (1 << 0), /* OMAP3630_SR2EN_MASK */
> +   .fbb_sel_mask   = (1 << 2), /* OMAP3630_ACTIVE_FBB_SEL_MASK */
> +   .sr2_wtcnt_value_mask = (0xff << 8), /* OMAP3630_SR2_WTCNT_VALUE_MASK 
> */
> +   .setup_offs = 0,
> +   .control_offs   = 0x4,
> +   .settling_time  = 30,
> +   .clock_cycles   = 8,
> +};
> +
> +static const struct omap_abb_data __initdata omap4_abb_data = {
> +   .opp_sel_mask   = (0x3 << 0), /* OMAP4430_OPP_SEL_MASK */
> +   .opp_change_mask= (1 << 2), /* OMAP4430_OPP_CHANGE_MASK */
> +   .sr2en_mask = (1 << 0), /* OMAP4430_SR2EN_MASK */
> +   .fbb_sel_mask   = (1 << 2), /* OMAP4430_ACTIVE_FBB_SEL_MASK */
> +   .rbb_sel_mask   = (1 << 1), /* OMAP4430_ACTIVE_RBB_SEL_MASK */
> +   .sr2_wtcnt_value_mask = (0xff << 8), /* OMAP4430_SR2_WTCNT_VALUE_MASK 
> */
> +   .setup_offs = 0,
> +   .control_offs   = 0x4,
> +   .settling_time  = 50,
> +   .clock_cycles   = 16,
> +};

Any reason to hard code those values and then put the TRM bitfield name
in a comment?  Probably better to #define these values using those
bitfield names.

Also please be consistent about "0x" in your numeric values.  Mixing it
in randomly (such as 0x3 and 0x4 above) is weird.

> +
> +static const struct omap_abb_data __initdata omap5_abb_data = {
> +   .opp_sel_mask  

Re: [PATCH v4 0/6] Generic PHY Framework

[David Miller]

You really need to CC: net...@vger.kernel.org rather than me explicitly
on this patch set.

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] OMAP3 ROM Random Number Generator support

[Pali Rohár]

On Wednesday 27 March 2013 23:25:24 Tony Lindgren wrote:
> * Pali Rohár  [130327 15:08]:
> > I will remove above code for checking omap type from hw rand
> > driver, because same code is in omap part which creating
> > platform_device for this driver. So soc.h is not needed.
> 
> OK thanks,
> 
> Tony

Here is new version of patch:

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5423456..37c4e09 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -82,7 +82,7 @@ obj-$(CONFIG_OMAP_PM_NOOP)+= omap-pm-noop.o
 ifeq ($(CONFIG_PM),y)
 obj-$(CONFIG_ARCH_OMAP2)   += pm24xx.o
 obj-$(CONFIG_ARCH_OMAP2)   += sleep24xx.o
-obj-$(CONFIG_ARCH_OMAP3)   += pm34xx.o sleep34xx.o
+obj-$(CONFIG_ARCH_OMAP3)   += pm34xx.o sleep34xx.o omap3-rom-rng.o
 obj-$(CONFIG_ARCH_OMAP4)   += pm44xx.o omap-mpuss-lowpower.o
 obj-$(CONFIG_SOC_OMAP5)+= omap-mpuss-lowpower.o
 obj-$(CONFIG_PM_DEBUG) += pm-debug.o
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 1ec7f05..0b6260a1 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -486,6 +486,23 @@ static void omap_init_mcspi(void)
 static inline void omap_init_mcspi(void) {}
 #endif
 
+extern u32 *omap3_rom_rng_call(u32 id, u32 proc, u32 flags, u32 va_ptr);
+
+static struct platform_device omap3_rom_rng_device = {
+   .name   = "omap3-rom-rng",
+   .id = -1,
+   .dev= {
+   .platform_data  = omap3_rom_rng_call,
+   },
+};
+
+static void omap_init_rom_rng(void)
+{
+   if (!cpu_is_omap34xx() || omap_type() == OMAP2_DEVICE_TYPE_GP)
+   return;
+   platform_device_register(&omap3_rom_rng_device);
+}
+
 /**
  * omap_init_rng - bind the RNG hwmod to the RNG omap_device
  *
@@ -767,6 +784,7 @@ static int __init omap2_init_devices(void)
}
omap_init_sti();
omap_init_rng();
+   omap_init_rom_rng();
omap_init_sham();
omap_init_aes();
omap_init_vout();
diff --git a/arch/arm/mach-omap2/omap3-rom-rng.S 
b/arch/arm/mach-omap2/omap3-rom-rng.S
new file mode 100644
index 000..5d7d886
--- /dev/null
+++ b/arch/arm/mach-omap2/omap3-rom-rng.S
@@ -0,0 +1,28 @@
+/*
+ * Copyright (C) 2009 Nokia Corporation
+ * Copyright (C) 2013 Pali Rohár 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+
+ENTRY(omap3_rom_rng_call)
+   .arch_extension sec
+   stmfd   sp!, {r4-r12, lr}
+   stmfd   sp!, {r0-r3}
+   bl  v7_flush_dcache_all
+   ldmfd   sp!, {r0-r3}
+   mov r6, #0xff
+   mov r12, r0
+   smc #1
+   mov r12, r0
+   bl  v7_flush_dcache_all
+   mov r0, #0
+   mcr p15, 0, r0, c7, c5, 0
+   mov r0, r12
+   ldmfd   sp!, {r4-r12, pc}
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index c5a0262..2d51db6 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -153,6 +153,19 @@ config HW_RANDOM_OMAP
 
  If unsure, say Y.
 
+config HW_RANDOM_OMAP3_ROM
+   tristate "OMAP3 ROM Random Number Generator support"
+   depends on HW_RANDOM && ARCH_OMAP3
+   default HW_RANDOM
+   ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on OMAP34xx processors.
+
+ To compile this driver as a module, choose M here: the
+ module will be called omap3-rom-rng.
+
+ If unsure, say Y.
+
 config HW_RANDOM_OCTEON
tristate "Octeon Random Number Generator support"
depends on HW_RANDOM && CPU_CAVIUM_OCTEON
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 1fd7eec..c53e018 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -15,6 +15,7 @@ n2-rng-y := n2-drv.o n2-asm.o
 obj-$(CONFIG_HW_RANDOM_VIA) += via-rng.o
 obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o
 obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o
+obj-$(CONFIG_HW_RANDOM_OMAP3_ROM) += omap3-rom-rng.o
 obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o
 obj-$(CONFIG_HW_RANDOM_VIRTIO) += virtio-rng.o
 obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o
diff --git a/drivers/char/hw_random/omap3-rom-rng.c 
b/drivers/char/hw_random/omap3-rom-rng.c
new file mode 100644
index 000..5343415
--- /dev/null
+++ b/drivers/char/hw_random/omap3-rom-rng.c
@@ -0,0 +1,165 @@
+/*
+ * omap3-rom-drv.c - RNG driver for TI OMAP3 CPU family
+ *
+ * Copyright (C) 2009 Nokia Corporation
+ * Author: Juha Yrjola 
+ *
+ * Copyright (C) 2013 Pali Rohár 
+ *
+ * This file is licensed under  the terms of the GNU General Public
+ * License version 2. This program is licensed "a

Re: [PATCH] OMAP3 ROM Random Number Generator support

[Pali Rohár]

On Thursday 28 March 2013 10:52:28 Russell King - ARM Linux 
wrote:
> On Wed, Mar 27, 2013 at 02:09:18PM -0700, Tony Lindgren wrote:
> > > + setup_timer(&idle_timer, omap3_rom_idle_rng, 0);
> > > + rng_clk = clk_get_sys("omap_rng", "ick");
> 
> Why is this using clk_get_sys when it should be using
> clk_get() with the platform device?

Funcion clk_get() needs struct device* instead clk device name. 
And I do not know how to get that pointer to device. With 
clk_get_sys driver working.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

[PATCH 6/6] ARM: OMAP3+: ABB: introduce debugfs entry

[Andrii Tseglytskyi]

From: "Andrii.Tseglytskyi" 

Patch adds debugfs entry for each ABB:
/sys/kernel/debug/

This entry is read-only. It prints current state of ABB.

Cc: Mike Turquette 
Cc: Tero Kristo 
Cc: Nishanth Menon 
Cc: "Benoît Cousson" 
Cc: linux-omap@vger.kernel.org

Signed-off-by: Andrii.Tseglytskyi 
---
 drivers/power/avs/abb.c |   64 +++
 1 file changed, 64 insertions(+)

diff --git a/drivers/power/avs/abb.c b/drivers/power/avs/abb.c
index f5bbb8d..ac43841 100644
--- a/drivers/power/avs/abb.c
+++ b/drivers/power/avs/abb.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* NOMINAL_OPP bypasses the ABB ldo, FAST_OPP sets it to Forward Body-Bias */
 #define OMAP_ABB_NOMINAL_OPP   0
@@ -410,6 +411,66 @@ static const struct of_device_id __initdata 
omap_abb_of_match[] = {
 MODULE_DEVICE_TABLE(of, omap_abb_of_match);
 #endif
 
+static int omap_abb_info_dump(struct seq_file *sf, void *unused)
+{
+   struct opp *opp;
+   struct omap_abb *abb = (struct omap_abb *)sf->private;
+   u32 abb_ctrl, abb_setup, rate;
+   unsigned long freq = 0;
+
+   if (!abb) {
+   seq_printf(sf, "No ABB defined\n");
+   goto out;
+   }
+
+   abb_ctrl =  omap_abb_readl(abb, abb->data.control_offs);
+   abb_setup = omap_abb_readl(abb, abb->data.setup_offs);
+   rate = clk_get_rate(abb->notify_clk);
+   seq_printf(sf, "Enabled\t->\t%d\n"
+  "opp_sel\t->\t%u\n"
+  "FBB mode\t->\t%u\n"
+  "RBB mode\t->\t%u\n"
+  "PRM_LDO_ABB_XXX_SETUP\t->\t0x%08x\n"
+  "PRM_LDO_ABB_XXX_CTRL\t->\t0x%08x\n"
+  "Notify clk\t->\t(%s) rate (%u)\n",
+  !!(abb_setup & abb->data.sr2en_mask),
+  abb->opp_sel,
+  !!(abb_setup & abb->data.fbb_sel_mask),
+  !!(abb_setup & abb->data.rbb_sel_mask),
+  abb_setup,
+  abb_ctrl,
+  __clk_get_name(abb->notify_clk), rate);
+
+   seq_printf(sf, "OPP table\n");
+   rcu_read_lock();
+   do {
+   opp = opp_find_freq_ceil(abb->dev, &freq);
+   if (IS_ERR(opp))
+   break;
+
+   seq_printf(sf, "Freq (%lu) ABB (%lu)\n", opp_get_freq(opp),
+  opp_get_voltage(opp));
+
+   freq++;
+   } while (1);
+   rcu_read_unlock();
+
+out:
+   return 0;
+}
+
+static int omap_abb_fops_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, omap_abb_info_dump, inode->i_private);
+}
+
+static const struct file_operations omap_abb_debug_fops = {
+   .open = omap_abb_fops_open,
+   .read = seq_read,
+   .llseek = seq_lseek,
+   .release = single_release,
+};
+
 /*
  * omap_abb_probe() - Initialize an ABB ldo instance
  * @pdev: ABB platform device
@@ -544,6 +605,9 @@ static int __init omap_abb_probe(struct platform_device 
*pdev)
omap_abb_rmw(abb, abb->data.sr2en_mask,
 abb->data.sr2en_mask, abb->data.setup_offs);
 
+   debugfs_create_file(dev_name(abb->dev), S_IRUGO, NULL,
+   abb, &omap_abb_debug_fops);
+
clk_put(sys_clk);
return 0;
 
-- 
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 5/6] ARM: OMAP3+: ABB: introduce ABB driver

[Andrii Tseglytskyi]

From: "Andrii.Tseglytskyi" 

This patch introduces the Adaptive Body-Bias LDO driver,
which handles LDOs voltage during OPP change routine.
It follows general principles of ABB implementation
in kernel 3.4.

Some new features are added:

1) ABB driver uses clock notifier framework to scale LDO.
To make this working it handles it's own OPP table.
OPP table has the following format in device tree:

operating-points = <
   /* kHz   ABB (0 - Bypass, 1 - FBB, 2 - RBB) */
   499200   0
   1099800  1
   150  1
   1699200  1
>;

Generic API is used for OPP table parsing - of_init_opp_table()

2) ABB driver doesn't have any public interfaces. It follows
Voltage/Frequency changes, using only notification mechanism.

3) ABB driver uses PRM_IRQSTATUS register to check tranxdone status.
This register is shared with VP.

Cc: Mike Turquette 
Cc: Tero Kristo 
Cc: Nishanth Menon 
Cc: "Benoît Cousson" 
Cc: linux-omap@vger.kernel.org

Signed-off-by: Andrii.Tseglytskyi 
Signed-off-by: Mike Turquette 
---
 drivers/power/avs/Makefile |2 +-
 drivers/power/avs/abb.c|  570 
 2 files changed, 571 insertions(+), 1 deletion(-)
 create mode 100644 drivers/power/avs/abb.c

diff --git a/drivers/power/avs/Makefile b/drivers/power/avs/Makefile
index 0843386..d5fc9c4 100644
--- a/drivers/power/avs/Makefile
+++ b/drivers/power/avs/Makefile
@@ -1 +1 @@
-obj-$(CONFIG_POWER_AVS_OMAP)   += smartreflex.o
+obj-$(CONFIG_POWER_AVS_OMAP)   += smartreflex.o abb.o
diff --git a/drivers/power/avs/abb.c b/drivers/power/avs/abb.c
new file mode 100644
index 000..f5bbb8d
--- /dev/null
+++ b/drivers/power/avs/abb.c
@@ -0,0 +1,570 @@
+/*
+ * OMAP Adaptive Body-Bias core
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Mike Turquette 
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ * Andrii Tseglytskyi 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* NOMINAL_OPP bypasses the ABB ldo, FAST_OPP sets it to Forward Body-Bias */
+#define OMAP_ABB_NOMINAL_OPP   0
+#define OMAP_ABB_FAST_OPP  1
+#define OMAP_ABB_SLOW_OPP  3
+#define OMAP_ABB_NO_LDO(~0)
+
+/* Time for the ABB ldo to settle after transition (in micro-seconds) */
+#define ABB_TRANXDONE_TIMEOUT  50
+
+/*
+ * struct omap_abb_data - common data for each instance of ABB ldo
+ *
+ * @opp_sel_mask:  selects Fast/Nominal/Slow OPP for ABB
+ * @opp_change_mask:   selects OPP_CHANGE bit value
+ * @sr2_wtcnt_value_mask:  LDO settling time for active-mode OPP change
+ * @sr2en_mask:enables/disables ABB
+ * @fbb_sel_mask:  selects FBB mode
+ * @rbb_sel_mask:  selects RBB mode
+ * @settling_time: IRQ handle used to resolve IRQSTATUS offset & masks
+ * @clock_cycles:  value needed for LDO setting time calculation
+ * @setup_offs:PRM_LDO_ABB_XXX_SETUP register offset
+ * @control_offs:  PRM_LDO_ABB_IVA_CTRL register offset
+ */
+struct omap_abb_data {
+   u32 opp_sel_mask;
+   u32 opp_change_mask;
+   u32 sr2_wtcnt_value_mask;
+   u32 sr2en_mask;
+   u32 fbb_sel_mask;
+   u32 rbb_sel_mask;
+   unsigned long settling_time;
+   unsigned long clock_cycles;
+   u8 setup_offs;
+   u8 control_offs;
+};
+
+/*
+ * struct omap_abb - ABB ldo instance
+ *
+ * @control:   memory mapped ABB registers
+ * @txdone:memory mapped IRQSTATUS register
+ * @dev:   device, for which ABB is created
+ * @txdone_mask:   ABB mode change done bit
+ * @opp_sel:   current ABB status - Fast/Nominal/Slow
+ * @notify_clk:clock, which rate changes are handled by ABB
+ * @data:  common data
+ * @abb_clk_nb:clock rate change notifier block
+ */
+struct omap_abb {
+   void __iomem*control;
+   void __iomem*txdone;
+   struct device   *dev;
+   u32 txdone_mask;
+   u32 opp_sel;
+   struct clk  *notify_clk;
+   struct omap_abb_datadata;
+   struct notifier_block abb_clk_nb;
+};
+
+static const struct omap_abb_data __initdata omap36xx_abb_data = {
+   .opp_sel_mask   = (3 << 0), /* OMAP3630_OPP_SEL_MASK */
+   .opp_change_mask= (1 << 2), /* OMAP3630_OPP_CHANGE_MASK */
+   .sr2en_mask = (1 << 0), /* OMAP3630_SR2EN_MASK */
+   .fbb_sel_mask   = (1 << 2), /* OMAP3630_ACTIVE_FBB_SEL_MASK */
+   .sr2_wtcnt_value_mask = (0xff << 8), /* OMAP3630_SR2_WTCNT_VALUE_MASK */
+   .setup_offs = 0,
+   .control_offs   = 0x4,
+   .settling_time  = 30,
+   .clock_cycles   = 8,
+};
+
+

[PATCH 4/6] ARM: OMAP3+: ABB: add aliases for clocks used in ABB driver

[Andrii Tseglytskyi]

From: "Andrii.Tseglytskyi" 

This patch introduces aliases for SYS clock, MPU clock
and IVA clock. These aliases will be used in ABB driver,
which will be introduced in the following patches.

Cc: Mike Turquette 
Cc: Tero Kristo 
Cc: Nishanth Menon 
Cc: "Benoît Cousson" 
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org

Signed-off-by: Andrii.Tseglytskyi 
---
 arch/arm/mach-omap2/cclock3xxx_data.c |2 ++
 arch/arm/mach-omap2/cclock44xx_data.c |4 
 arch/arm/mach-omap2/cclock54xx_data.c |4 
 3 files changed, 10 insertions(+)

diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c 
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 6ef8758..1d0f36d 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3494,6 +3494,8 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL,   "timer_32k_ck", &omap_32k_fck,  CK_3XXX),
CLK(NULL,   "timer_sys_ck", &sys_ck,CK_3XXX),
CLK(NULL,   "cpufreq_ck",   &dpll1_ck,  CK_3XXX),
+   CLK("483072f0.abb", "abb_notify_ck",&dpll1_ck,  
CK_36XX),
+   CLK("483072f0.abb", "abb_sys_ck",   &sys_ck,
CK_36XX),
 };
 
 static const char *enable_init_clks[] = {
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c 
b/arch/arm/mach-omap2/cclock44xx_data.c
index a2cc046..3eb3a7f 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -1978,6 +1978,10 @@ static struct omap_clk omap44xx_clks[] = {
CLK("4013c000.timer",   "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
CLK("4013e000.timer",   "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
CLK(NULL,   "cpufreq_ck",   &dpll_mpu_ck,   CK_443X),
+   CLK("4a307bd0.abb", "abb_notify_ck",&dpll_mpu_ck,   
CK_443X),
+   CLK("4a307bd8.abb", "abb_notify_ck",&dpll_iva_m5x2_ck,  
CK_443X),
+   CLK("4a307bd0.abb", "abb_sys_ck",   &sys_clkin_ck,  
CK_443X),
+   CLK("4a307bd8.abb", "abb_sys_ck",   &sys_clkin_ck,  
CK_443X),
 };
 
 static const char *enable_init_clks[] = {
diff --git a/arch/arm/mach-omap2/cclock54xx_data.c 
b/arch/arm/mach-omap2/cclock54xx_data.c
index a9ebed6..b440c9b 100644
--- a/arch/arm/mach-omap2/cclock54xx_data.c
+++ b/arch/arm/mach-omap2/cclock54xx_data.c
@@ -1383,6 +1383,10 @@ static struct omap_clk omap54xx_clks[] = {
CLK("4013a000.timer",   "timer_sys_ck", &dss_syc_gfclk_div, 
CK_54XX),
CLK("4013c000.timer",   "timer_sys_ck", &dss_syc_gfclk_div, 
CK_54XX),
CLK("4013e000.timer",   "timer_sys_ck", &dss_syc_gfclk_div, 
CK_54XX),
+   CLK("4ae07cdc.abb", "abb_notify_ck",&dpll_mpu_ck,   
CK_54XX),
+   CLK("4ae07ce4.abb", "abb_notify_ck",&dpll_iva_h12x2_ck, 
CK_54XX),
+   CLK("4ae07cdc.abb", "abb_sys_ck",   &sys_clkin, 
CK_54XX),
+   CLK("4ae07ce4.abb", "abb_sys_ck",   &sys_clkin, 
CK_54XX),
 };
 
 int __init omap5xxx_clk_init(void)
-- 
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 3/6] ARM: dts: OMAP5: add device tree for ABB

[Andrii Tseglytskyi]

From: "Andrii.Tseglytskyi" 

Add DT ABB data for OMAP543x family of devices.
This data is based on OMAP543x_ES2.0_NDA_TRM_vR.pdf
document.

Cc: Mike Turquette 
Cc: Tero Kristo 
Cc: Nishanth Menon 
Cc: "Benoît Cousson" 
Cc: linux-omap@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org

Signed-off-by: Andrii.Tseglytskyi 
---
 arch/arm/boot/dts/omap5.dtsi |   31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 150bff6..eb11bb7 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -74,6 +74,37 @@
};
};
 
+   abb@0x4ae07cdc {
+   compatible = "ti,omap5-abb";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x4ae07cdc 0x8>,
+ <0x4ae06014 0x4>; /* PRM_IRQSTATUS_MPU_2 */
+   operating-points = <
+   /* kHz   ABB */
+   499200  0
+   1099800 1
+   150 1
+   1699200 1
+   >;
+   ti,tranxdone_status_mask = <0x80>; /* (1 << 7) */
+   };
+
+   abb@0x4ae07ce4 {
+   compatible = "ti,omap5-abb";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x4ae07ce4 0x8>,
+ <0x4ae06010 0x4>; /* PRM_IRQSTATUS_MPU */
+   operating-points = <
+   /* kHz   ABB */
+   194100  0
+   388310  0
+   531200  0
+   >;
+   ti,tranxdone_status_mask = <0x8000>; /* (1 << 31) */
+   };
+
/*
 * XXX: Use a flat representation of the OMAP3 interconnect.
 * The real OMAP interconnect network is quite complex.
-- 
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 2/6] ARM: dts: OMAP4: add device tree for ABB

[Andrii Tseglytskyi]

From: "Andrii.Tseglytskyi" 

Add DT ABB data for OMAP44xx family of devices.
This data is based on OMAP4430_ES2.x_NDA_TRM_vAA.pdf
document.

Cc: Mike Turquette 
Cc: Tero Kristo 
Cc: Nishanth Menon 
Cc: "Benoît Cousson" 
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-omap@vger.kernel.org

Signed-off-by: Andrii.Tseglytskyi 
---
 arch/arm/boot/dts/omap4.dtsi|   18 ++
 arch/arm/boot/dts/omap443x.dtsi |   20 
 arch/arm/boot/dts/omap446x.dtsi |   36 
 3 files changed, 74 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap446x.dtsi

diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..0bc3ef1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -81,6 +81,24 @@
};
};
 
+   abb@0x4a307bd0 {
+   compatible = "ti,omap4-abb";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x4a307bd0 0x8>,
+ <0x4a306014 0x4>; /* PRM_IRQSTATUS_MPU_A9_2 */
+   ti,tranxdone_status_mask = <0x80>; /* (1 << 7) */
+   };
+
+   abb@0x4a307bd8 {
+   compatible = "ti,omap4-abb";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x4a307bd8 0x8>,
+ <0x4a306010 0x4>; /* PRM_IRQSTATUS_MPU_A9 */
+   ti,tranxdone_status_mask = <0x8000>; /* (1 << 31) */
+   };
+
/*
 * XXX: Use a flat representation of the OMAP4 interconnect.
 * The real OMAP interconnect network is quite complex.
diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi
index cccf39a..6c511c6 100644
--- a/arch/arm/boot/dts/omap443x.dtsi
+++ b/arch/arm/boot/dts/omap443x.dtsi
@@ -24,4 +24,24 @@
clock-latency = <30>; /* From legacy driver */
};
};
+
+   abb@0x4a307bd0 {
+   operating-points = <
+   /* kHz   ABB */
+   30  0
+   60  0
+   80  0
+   1008000 1
+   >;
+   };
+
+   abb@0x4a307bd8 {
+   operating-points = <
+   /* kHz   ABB */
+   133000  0
+   266100  0
+   332000  0
+   >;
+   };
+
 };
diff --git a/arch/arm/boot/dts/omap446x.dtsi b/arch/arm/boot/dts/omap446x.dtsi
new file mode 100644
index 000..b884c60
--- /dev/null
+++ b/arch/arm/boot/dts/omap446x.dtsi
@@ -0,0 +1,36 @@
+/*
+ * Device Tree Source for OMAP446x SoC
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2.  This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/include/ "omap4.dtsi"
+
+/ {
+   abb@0x4a307bd0 {
+   operating-points = <
+   /* kHz   ABB */
+   35  0
+   70  0
+   92  0
+   120 1
+   150 1
+   >;
+   };
+
+   abb@0x4a307bd8 {
+   operating-points = <
+   /* kHz   ABB */
+   133000  0
+   266100  0
+   332000  0
+   43  1
+   50  1
+   >;
+   };
+
+};
-- 
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/6] ARM: dts: OMAP36xx: add device tree for ABB

[Andrii Tseglytskyi]

From: "Andrii.Tseglytskyi" 

Add DT ABB data for OMAP36xx family of devices.
This data is based on OMAP36XX_ES1.x_NDA_TRM_vAB.pdf
document.

Cc: Mike Turquette 
Cc: Tero Kristo 
Cc: Nishanth Menon 
Cc: "Benoît Cousson" 
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-omap@vger.kernel.org

Signed-off-by: Andrii.Tseglytskyi 
---
 arch/arm/boot/dts/omap36xx.dtsi |   16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 96bf028..72d5135 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -15,6 +15,22 @@
serial3 = &uart4;
};
 
+   abb@0x483072f0 {
+   compatible = "ti,omap36xx-abb";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x483072f0 0x8>,
+ <0x48306818 0x4>; /* PRM_IRQSTATUS_MPU */
+   operating-points = <
+   /* kHz   ABB */
+   30  0
+   60  0
+   80  0
+   100 1
+   >;
+   ti,tranxdone_status_mask = <0x400>; /* (1 << 26) */
+   };
+
ocp {
uart4: serial@49042000 {
compatible = "ti,omap3-uart";
-- 
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

Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options

[Tomi Valkeinen]

On 2013-03-28 18:53, Tony Lindgren wrote:
> * Igor Grinberg  [130328 09:13]:
>> On 03/28/13 14:49, Tomi Valkeinen wrote:
>>> Boards with multiple display options for the same video bus have all the
>>> possible linux display devices present at the same time. Only one of
>>> those devices should be used at a time, as the video bus cannot be
>>> shared.
>>
>> Yes, only one can be used at a time, but you can switch at runtime...
>>
>>>
>>> This model is hacky, and will be changed in the forthcoming DSS patches
>>> to a model where only one display device can be present on a single
>>> video bus.
>>
>> What do you mean by "present"?
>> Is it active? or registered? or compiled in?
>>
>>>
>>> This patch creates Kconfig options to select which of the display
>>> devices is present on the board. While this model is also somewhat
>>> hacky, and prevents us from using a single kernel image for all the
>>> display options, it allows us to make the DSS driver changes for DT
>>> adaptation. And with DT, the information about display devices can be
>>> passed from the bootloader, solving the mess.
>>
>> Hmmm, the fact that we cannot use the same binary for multiple displays...
>> This does not sound right and good at all...
>> While we try to move to support multiple platforms in the same binary, we
>> cannot support multiple displays? I agree that the multiplatform stuff is
>> not really related, but you know what I mean...
> 
> Yes that's not nice from usability point of view. Can we still switch
> between LCD and DVI during the runtime? I thought the issue was registering
> multiple LCD panels where only one can exist at a time?

I guess I could've been more verbose in my descriptions. And I agree
this is not a nice change.

No, we can't switch between the LCD and DVI. But that's not strictly DSS
issue. The selection between LCD and DVI (or any other displays on the
same bus) are board specific things, sometimes requiring board specific
gpios or even things like i2c commands to muxes.

It works now because we have custom callbacks in the board files to do
those things, but it'll break with DT.

>> I bet there must be a much better solution for DT support.
> 
> Well the best legacy support option would be some fbdev/panel generic cmdline
> option to specify which one to use. Maybe there is already something like
> that available that the board-*.c files can parse and can be used also
> later on with DT support to specify the preferred output?
> 
> What we don't want to do is add a board specific cmdline option as the
> board-*.c files will be going away as soon as DT is usable for us and we
> don't want to support a board specific cmdline after that. But if it's
> a generic option then parsing it in the board-*.c file or the driver later
> on can be supported.
> 
> Of course for some cases it might be possible to detect the configured
> panel based on what's plugged in over i2c.

I could look at using omapdss's module parameter for this. It has
default display parameter. Perhaps the board files could parse this, and
use it to decide which display to register. Perhaps that'd cause less
inconvenience.

It's still quite hacky, as you can only select one display. If there's a
board with two video outputs, and, say, 2 displays connected to each.
You can only select the display for one of the busses. Anyway, we don't
have that kind of board in the mainline, so it's not an issue.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [GIT PULL] ARM: OMAP2+: Generic cleanups for 3.10

[Kevin Hilman]

Santosh Shilimkar  writes:

> On Thursday 28 March 2013 01:39 AM, Shilimkar, Santosh wrote:
>> Sorry for top posting ...
>> I will pick the ack and update commit log to prepare new pull request
>> for you. 
>> 
> I have updated the branch picking acks and updating changelogs and same
> is available below. No change in code.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git 
> for_3.10/omap_generic_cleanup_v2
>

Thanks for the changelog updates.  No more concerns from me.

Kevin
--
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 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options

[Tomi Valkeinen]

On 2013-03-28 18:09, Igor Grinberg wrote:
> On 03/28/13 14:49, Tomi Valkeinen wrote:
>> Boards with multiple display options for the same video bus have all the
>> possible linux display devices present at the same time. Only one of
>> those devices should be used at a time, as the video bus cannot be
>> shared.
> 
> Yes, only one can be used at a time, but you can switch at runtime...

Yep. But the panel drivers need to know about this, and they cannot do
more or less anything in the driver probe function, which I think should
be the place to reserve resources and do initialization. With the
current model that would lead to multiple drivers trying to acquire the
same resources.

>> This model is hacky, and will be changed in the forthcoming DSS patches
>> to a model where only one display device can be present on a single
>> video bus.
> 
> What do you mean by "present"?
> Is it active? or registered? or compiled in?

I mean that only one device can be registered. Well, nothing strictly
prevents having multiple devices registered, but if the devices have
matching drivers, the drivers would acquire the same resources. Possibly
the same gpios, but at least the same video bus.

>> This patch creates Kconfig options to select which of the display
>> devices is present on the board. While this model is also somewhat
>> hacky, and prevents us from using a single kernel image for all the
>> display options, it allows us to make the DSS driver changes for DT
>> adaptation. And with DT, the information about display devices can be
>> passed from the bootloader, solving the mess.
> 
> Hmmm, the fact that we cannot use the same binary for multiple displays...
> This does not sound right and good at all...
> While we try to move to support multiple platforms in the same binary, we
> cannot support multiple displays? I agree that the multiplatform stuff is
> not really related, but you know what I mean...

Yes, I quite agree that this sucks =). There are a few reasons I chose
to try this approach:

- The whole multi-display feature is hacky

- DT support for DSS has been in development too long time. We really
need it, preferably yesterday. This change helps getting DT support ready.

- Common Display Framework won't (most likely) support this kind of
feature, as the feature itself is rather hacky, so this would anyway
disappear.

- DT support should solve this (except for runtime switching), and the
board files are on the way out (as far as I understand). So in that
sense this is temporary.

- Keeping this feature functional consumes considerable amount of
man-hours, which are in short supply.

I still feel quite bad about this, though. Any ideas how to manage this
better are appreciated.

> I bet there must be a much better solution for DT support.

Yes, I think I covered that in the last email. DT will solve the issue,
except for runtime switching, which is still open. I'm not sure how
these board specific drivers would be implemented.

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH 00/28] OMAP: DSS related board file changes

[Tony Lindgren]

* Tomi Valkeinen  [130328 09:53]:
> On 2013-03-28 17:31, Igor Grinberg wrote:
> > On 03/28/13 14:48, Tomi Valkeinen wrote:
> > 
> > I've missed this discussion, can you please point to it?
> 
> Well, not so much discussion, but a few mails under "Display related
> board specific boot args" subject on l-o. I proposed a board specific
> kernel argument to select the displays present, Tony was less than
> enthusiastic about that.

If we can come up with a Linux generic command line option to select
the panel that can be supported also in the long run, I have no
objections to that naturally. What I'm against is a temporary
custom cmdline option until the board-*.c files go away as we
don't want to support it in the long run.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options

[Tony Lindgren]

* Igor Grinberg  [130328 09:13]:
> On 03/28/13 14:49, Tomi Valkeinen wrote:
> > Boards with multiple display options for the same video bus have all the
> > possible linux display devices present at the same time. Only one of
> > those devices should be used at a time, as the video bus cannot be
> > shared.
> 
> Yes, only one can be used at a time, but you can switch at runtime...
> 
> > 
> > This model is hacky, and will be changed in the forthcoming DSS patches
> > to a model where only one display device can be present on a single
> > video bus.
> 
> What do you mean by "present"?
> Is it active? or registered? or compiled in?
> 
> > 
> > This patch creates Kconfig options to select which of the display
> > devices is present on the board. While this model is also somewhat
> > hacky, and prevents us from using a single kernel image for all the
> > display options, it allows us to make the DSS driver changes for DT
> > adaptation. And with DT, the information about display devices can be
> > passed from the bootloader, solving the mess.
> 
> Hmmm, the fact that we cannot use the same binary for multiple displays...
> This does not sound right and good at all...
> While we try to move to support multiple platforms in the same binary, we
> cannot support multiple displays? I agree that the multiplatform stuff is
> not really related, but you know what I mean...

Yes that's not nice from usability point of view. Can we still switch
between LCD and DVI during the runtime? I thought the issue was registering
multiple LCD panels where only one can exist at a time?
 
> I bet there must be a much better solution for DT support.

Well the best legacy support option would be some fbdev/panel generic cmdline
option to specify which one to use. Maybe there is already something like
that available that the board-*.c files can parse and can be used also
later on with DT support to specify the preferred output?

What we don't want to do is add a board specific cmdline option as the
board-*.c files will be going away as soon as DT is usable for us and we
don't want to support a board specific cmdline after that. But if it's
a generic option then parsing it in the board-*.c file or the driver later
on can be supported.

Of course for some cases it might be possible to detect the configured
panel based on what's plugged in over i2c.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/28] OMAP: DSS related board file changes

[Tomi Valkeinen]

On 2013-03-28 17:31, Igor Grinberg wrote:
> On 03/28/13 14:48, Tomi Valkeinen wrote:
>> So here are the DSS related board file changes for 3.10.
>>
>> First there are a bunch of patches adding the Kconfig options so that only 
>> one
>> display device is created for a single video bus. Only Overo had more than 
>> two
>> displays on the same bus, but unfortunately there were multiple boards with a
>> setup that puts an LCD and DVI output on the same video bus.
> 
> Hmmm, so basically, if one could switch the display at runtime...
> This cannot be done anymore...
> This sounds like feature removal, no?
> I know several of our clients who used this feature
> (at least for evaluation purposes).

At some point in time it was possible to have multiple displays for the
same bus, and switch them at runtime.

Sometime later it was changed so that the board file adds all the
displays, but only one (per bus) is actually added to the list of
panels, but you could still set the default display in the kernel args,
and thus you could select which display gets added.

The reason why the multiple-displays-per-bus is problematic is that the
video bus cannot be shared, and if we have multiple devices on the same
bus, the drivers need extra trickery, delaying initializations, etc, to
handle this. And it still doesn't work right, as it's easy to get two
displays enabled at the same time, configuring the same video bus,
creating a mess.

Quite often the case is that the other displays are not even present
physically. But it is true that some boards have gpio switches that can
be used to change the display during runtime.

> Is there any strong pros you obtain while removing this feature?

For an user, only indirectly. The change will make things sane on the
display side, and will thus make it much easier to proceed towards DT
adaptation, and Common Display Framework. While I can't say it's a
strict must to remove this feature, I can say that it's been a constant
headache for me for, well, ever. And I presume CDF would not have this
feature anyway, as it's rather bad design.

>> So the ifdeffery is not very nice. But, as discussed, this is the best way
>> forward, and should be seen as a temporary solution until we get full DT
>> support.
> 
> I've missed this discussion, can you please point to it?

Well, not so much discussion, but a few mails under "Display related
board specific boot args" subject on l-o. I proposed a board specific
kernel argument to select the displays present, Tony was less than
enthusiastic about that.

> And what will change with full DT support?
> Will we be able to define several displays through DT and
> select and active one during runtime?

No, not as such. DT will let the bootloader pass the DT data, thus
telling which displays are present. So we can have single kernel binary,
which will work for all the cases.

Dynamic switching during runtime will still be missing. For that I think
we need board specific drivers. That driver should know about board
specific restrictions etc (which are rather missing currently), remove
the old display device, and create the new one.

Well, actually, if there was a way to add a device while somehow marking
it so that no driver will be bound to it... Then the user could use the
standard sysfs interface to bind a driver to the device. I wonder if
that could be done...

 Tomi




signature.asc
Description: OpenPGP digital signature

Re: [PATCH] arm/dts: OMAP3: fix pinctrl-single configuration

[Tony Lindgren]

* Christoph Fritz  [130328 01:12]:
> - Fix 'function-mask' referring to TRM Section 7.4.4:
>   "Pad Functional Multiplexing and Configuration".
> - Fix 'omap3_pmx_core' referring to TRM Table 7-4:
>   "Core Control Module Pad Configuration Register Fields"
> - Fix 'omap3_pmx_wkup' referring to TRM Table 7-6:
>   "Wake-Up Control Module Pad Configuration Register Fields".

Maybe mention which TRM this is so people will know.
 
> Signed-off-by: Christoph Fritz 
> ---
>  arch/arm/boot/dts/omap3.dtsi |   12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 1acc261..6ce3b5c 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -27,7 +27,7 @@
>   };
>  
>   /*
> -  * The soc node represents the soc top level view. It is uses for IPs
> +  * The soc node represents the soc top level view. It is used for IPs
>* that are not memory mapped in the MPU view or for the MPU itself.
>*/
>   soc {
> @@ -77,20 +77,20 @@
>  
>   omap3_pmx_core: pinmux@48002030 {
>   compatible = "ti,omap3-padconf", "pinctrl-single";
> - reg = <0x48002030 0x05cc>;
> + reg = <0x48002030 0x234>;
>   #address-cells = <1>;
>   #size-cells = <0>;
>   pinctrl-single,register-width = <16>;
> - pinctrl-single,function-mask = <0x7fff>;
> + pinctrl-single,function-mask = <0x7f1f>;
>   };

Changing the size from 0x5cc to 0x234 misses the range ending at
CONTROL_PADCONF_ETK_D14[31:16] 0x480025f8 that's listed at least in
the 3630 TRM. Which TRM are you looking at?

Ack for the function-mask change for omap3, looks like those bits are not
used.
  
> - omap3_pmx_wkup: pinmux@0x48002a58 {
> + omap3_pmx_wkup: pinmux@0x48002a00 {
>   compatible = "ti,omap3-padconf", "pinctrl-single";
> - reg = <0x48002a58 0x5c>;
> + reg = <0x48002a00 0x54>;
>   #address-cells = <1>;
>   #size-cells = <0>;
>   pinctrl-single,register-width = <16>;
> - pinctrl-single,function-mask = <0x7fff>;
> + pinctrl-single,function-mask = <0x7f1f>;
>   };

Hmm I think I converted these from the legacy mux framework, that seems
to be missing the wkup range between 0x2a00 - 0x2a58. So yes 0x2a00
is the right start as otherwise we're missing some wkup registers.

But the size should be 0x50 instead of 0x54 as the JTAG_TDO[31:16] is
already un-used in TRM?

Or it could be 0x60 if we want to map also the reserved GPIO128[31:16].

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP: dpll: enable bypass clock only when attempting dpll bypass

[Mike Turquette]

Quoting Rajendra Nayak (2013-03-28 03:59:41)
> omap3_noncore_dpll_set_rate() attempts an enable of bypass clk as well
> as ref clk for every .set_rate attempt on a noncore DPLL, regardless of
> whether the .set_rate results in the DPLL being locked or put in bypass.
> Early at boot, while some of these DPLLs are programmed and locked
> (using .set_rate for the DPLL), this causes an ordering issue.
> 
> For instance, on OMAP5, the USB DPLL derives its bypass clk from ABE DPLL.
> If a .set_rate of USB DPLL which programmes the M,N and locks it is called
> before the one for ABE, the enable of USB bypass clk (derived from ABE DPLL)
> then attempts to lock the ABE DPLL and fails as the M,N values for ABE
> are yet to be programmed.
> 
> To get rid of this ordering needs, enable bypass clk for a DPLL as part
> of its .set_rate only when its being put in bypass, and only enable the
> ref clk when its locked.
> 

Hi Rajendra,

Another way to solve this problem would be to model the DPLLs as mux
clocks with a list of possible parents (e.g. clk->parents[2]).  Then set
the CLK_SET_RATE_PARENT flag on the USB DPLL which will allow to
propagate the rate request up to the ABE DPLL.  This should set the MN
dividers appropriately.

> Reported-by: Roger Quadros 
> Signed-off-by: Rajendra Nayak 
> ---
>  arch/arm/mach-omap2/dpll3xxx.c |   19 +--
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
> index 3aed4b0..6e9873f 100644
> --- a/arch/arm/mach-omap2/dpll3xxx.c
> +++ b/arch/arm/mach-omap2/dpll3xxx.c
> @@ -480,20 +480,22 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, 
> unsigned long rate,
> if (!dd)
> return -EINVAL;
>  
> -   __clk_prepare(dd->clk_bypass);
> -   clk_enable(dd->clk_bypass);
> -   __clk_prepare(dd->clk_ref);
> -   clk_enable(dd->clk_ref);

Is this safe?  I always thought that the programming sequence in the TRM
was to enable both the ref and bypass clocks during DPLL reprogramming.
Maybe I am misremembering or assuming that the code strictly followed
the TRM.

Regards,
Mike

> -
> if (__clk_get_rate(dd->clk_bypass) == rate &&
> (dd->modes & (1 << DPLL_LOW_POWER_BYPASS))) {
> pr_debug("%s: %s: set rate: entering bypass.\n",
>  __func__, __clk_get_name(hw->clk));
>  
> +   __clk_prepare(dd->clk_bypass);
> +   clk_enable(dd->clk_bypass);
> ret = _omap3_noncore_dpll_bypass(clk);
> if (!ret)
> new_parent = dd->clk_bypass;
> +   clk_disable(dd->clk_bypass);
> +   __clk_unprepare(dd->clk_bypass);
> } else {
> +   __clk_prepare(dd->clk_ref);
> +   clk_enable(dd->clk_ref);
> +
> if (dd->last_rounded_rate != rate)
> rate = __clk_round_rate(hw->clk, rate);
>  
> @@ -514,6 +516,8 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, 
> unsigned long rate,
> ret = omap3_noncore_dpll_program(clk, freqsel);
> if (!ret)
> new_parent = dd->clk_ref;
> +   clk_disable(dd->clk_ref);
> +   __clk_unprepare(dd->clk_ref);
> }
> /*
> * FIXME - this is all wrong.  common code handles reparenting and
> @@ -525,11 +529,6 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, 
> unsigned long rate,
> if (!ret)
> __clk_reparent(hw->clk, new_parent);
>  
> -   clk_disable(dd->clk_ref);
> -   __clk_unprepare(dd->clk_ref);
> -   clk_disable(dd->clk_bypass);
> -   __clk_unprepare(dd->clk_bypass);
> -
> return 0;
>  }
>  
> -- 
> 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
--
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 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options

[Igor Grinberg]

On 03/28/13 14:49, Tomi Valkeinen wrote:
> Boards with multiple display options for the same video bus have all the
> possible linux display devices present at the same time. Only one of
> those devices should be used at a time, as the video bus cannot be
> shared.

Yes, only one can be used at a time, but you can switch at runtime...

> 
> This model is hacky, and will be changed in the forthcoming DSS patches
> to a model where only one display device can be present on a single
> video bus.

What do you mean by "present"?
Is it active? or registered? or compiled in?

> 
> This patch creates Kconfig options to select which of the display
> devices is present on the board. While this model is also somewhat
> hacky, and prevents us from using a single kernel image for all the
> display options, it allows us to make the DSS driver changes for DT
> adaptation. And with DT, the information about display devices can be
> passed from the bootloader, solving the mess.

Hmmm, the fact that we cannot use the same binary for multiple displays...
This does not sound right and good at all...
While we try to move to support multiple platforms in the same binary, we
cannot support multiple displays? I agree that the multiplatform stuff is
not really related, but you know what I mean...

I bet there must be a much better solution for DT support.


-- 
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

Re: [GIT PULL v2] ARM: omap2: twl-common update

[Tony Lindgren]

* Peter Ujfalusi  [130328 02:32]:
> Hi Tony,
> 
> On 03/27/2013 07:38 PM, Tony Lindgren wrote:
> > Sorry just noticed that this one adds:
> > 
> > Section mismatch in reference from the variable omap3_power_pdata to the 
> > (unknown reference) .init.data:(unknown)
> > The variable omap3_power_pdata references
> > the (unknown reference) __initdata (unknown)
> > If the reference is valid then annotate the
> > variable with __init* or __refdata (see linux/init.h) or name the variable:
> > *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
> > 
> > Is it safe to make it __initdata, or should also other power_pdata
> > have their __initdata flags removed if used by the drivers?
> 
> We could make the whole stack of struct for the omap3_power_pdata as
> __initdata since the driver (mfd/twl4030-power) is bool.

What if you rebind the driver via sysfs unbind/bind?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround

[Tony Lindgren]

* Ивайло Димитров  [130327 22:34]:
>  Tony,
> 
> Who do you expect to make that code merge? Do you expect us to mechanically 
> merge RX51 PPA API patch with the existing generic OMAP PPA API code putting 
> #ifdefs all over the place? Not that it is impossible, but the only real 
> piece of HW I have here is n900, so I just can't be sure the code will still 
> work on the other platforms besides RX51, once the code modified. Please, 
> advice on how to proceed.

Probably ifdefs won't work nice for other omapss. It seems that
your original patch is pretty close based on all that's been
discussed. Can you please repost with a proper patch description
also summarizing why we cannot have generci SMC API as discussed?

Thanks,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround

[Tony Lindgren]

* Santosh Shilimkar  [130328 03:10]:
> On Thursday 28 March 2013 03:20 PM, Russell King - ARM Linux wrote:
> > On Wed, Mar 27, 2013 at 01:56:07PM -0700, Tony Lindgren wrote:
> >> * Pali Rohár  [130324 07:31]:
> >>> it is possible to upstream errata 430973 workaround for RX-51?
> >>
> >> I think we should make the SMC handling a generic function for ARM.
> >>
> >> AFAIK just the SMC call numbering is different for various
> >> implementations. So the handler and passing of the parameters
> >> seems like it should be generic.
> > 
> > SMC calls vary greatly in how they are handled.  The only thing that's
> > generic is issuing the SMC call.  All the setup and what arguments are
> > required are completely different from SoC to SoC.
> > 
> > For example, some SoCs require arguments passed via memory.  Others like
> > OMAP its via registers.
> 
> Exactly. As somebody said on the list, that code looks identical but
> it is not. An SMC with barrier instruction is mostly common and nothing
> more than that.

Thanks all, case closed then. There's no way to come up with a generic
SMC function.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 0/8] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

[Benoit Cousson]

On 03/28/2013 02:43 PM, Nishanth Menon wrote:
> Hi Benoit,
> 
> On Thu, Mar 28, 2013 at 6:03 AM, Benoit Cousson  wrote:
>> The patches 1 to 6 looks good to me. Beside the pretty long Cc list,
>> that should not necessarily contain all the mailing list.
> Arrgh.. my bad. I will keep it in mind for the future.
> 
>>
>> Since you are changing / renaming some DTS files, and to avoid any merge
>> conflict I will apply only these 6 patches.
>> DTS and driver changes are in theory orthogonal enough to allow merging
>> them separately and in any order.
>>
>> I'll update my branch with these patches ASAP.
> Thanks. I will post a v3 of remaining patches later today.

Patches after changelog cleanup are available in the following branch:

git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
for_3.10/dts

Regards,
Benoit

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/6] drivers: phy: add generic PHY framework

[Stephen Warren]

On 03/27/2013 11:43 PM, Kishon Vijay Abraham I wrote:
> The PHY framework provides a set of APIs for the PHY drivers to
> create/destroy a PHY and APIs for the PHY users to obtain a reference to the

> diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt 
> b/Documentation/devicetree/bindings/phy/phy-bindings.txt

> +This document explains only the dt data binding. For general information 
> about
> +PHY subsystem refer Documentation/phy.txt
> +
> +PHY device node
> +===
> +
> +Optional Properties:
> +#phy-cells:  Number of cells in a PHY specifier;  The meaning of all those
> + cells is defined by the binding for the phy node. However
> + in-order to return the correct PHY, the PHY susbsystem
> + requires the first cell always refers to the port.

Why impose that restriction? Other DT bindings do not.

This is typically implemented by having each provider driver implement a
.of_xlate() operation, which parses all of the specifier cells, and
returns the ID of the object it represents. This allows bindings to use
whatever arbitrary representation they want.

For the common/simple cases where #phy-cells==0, or #phy-cells==1 and
directly represents the PHY ID, the PHY core can provide an
implementation of that common .of_xlate() function, which PHY provider
drivers can simply plug in as their .of_xlate() function.

> +This property is optional because it is needed only for the case where a
> +single IP implements multiple PHYs.

The property should always exist so that the DT-parsing code in the PHY
core can always validate exactly how many cells are present in the PHY
specifier.

> +
> +For example:
> +
> +phys: phy {
> +compatible = "xxx";
> +reg1 = <...>;
> +reg2 = <...>;
> +reg3 = <...>;

3 separate reg values should be 3 separate entries in a single reg
property, not 3 separate reg properties, with non-standard names.

> +.
> +.
> +#phy-cells = <1>;
> +.
> +.
> +};
> +
> +That node describes an IP block that implements 3 different PHYs. In order to
> +differentiate between these 3 PHYs, an additonal specifier should be given
> +while trying to get a reference to it. (The PHY subsystem assumes the
> +specifier is port id).

A single DT node would typically represent a single HW IP block, and
hence typically have a single reg property. If there are 3 separate HW
IP blocks, and their register aren't interleaved, and hence can be
represented by 3 separate reg values, then I'd typically expect to see 3
separate DT nodes, one for each independent register range.

The only case where I'd expect a single DT node to provide multipe PHYs,
is when a single HW IP block actually implements multiple PHYs /and/ the
registers for those 3 PHYs are interleaved (or share bits in the same
registers) such that each PHY can't be represented by a separate
non-overlapping reg property.

> +example1:
> +phys: phy {

How about:

Example 1:

usb1: usb@xxx {

> +};
> +This node represents a controller that uses two PHYs one for usb2 and one for

Blank line after }?

> +usb3. The controller driver can get the appropriate PHY either by using
> +devm_of_phy_get/of_phy_get by passing the correct index or by using
> +of_phy_get_byname/devm_of_phy_get_byname by passing the names given in
> +*phy-names*.

Discussions of Linux-specific driver APIs should be in the Linux API
documentation, not the DT binding documentation, which is supposed to be
OS-agnostic. Instead, perhaps say:

Individual bindings must specify the required set of entries the phys
property. Bindings must also specify either a required order for those
entries in the phys property, or specify required set of names that must
be present in the phy-names property, in which case the order is arbitrary.

> +example2:
> +phys: phy {

How about:

Example 2:

usb2: usb@yyy {

> +This node represents a controller that uses one of the PHYs which is defined
> +previously. Note that the phy handle has an additional specifier "1" to
> +differentiate between the three PHYs. For this case, the controller driver
> +should use of_phy_get_with_args/devm_of_phy_get_with_args.

I think tha last sentence should be removed, and perhaps the previous
sentence extended with:

, as required by #phy-cells = <1> in the PHY provider node.

> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c

> +subsys_initcall(phy_core_init);

Why not make that module_init(); device probe() ordering should be
handled using -EPROBE_DEFER these days, so the exact initcall used
doesn't really matter, and hence it'd be best to use the most common one
rather than something unusual.
--
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 00/28] OMAP: DSS related board file changes

[Igor Grinberg]

On 03/28/13 14:48, Tomi Valkeinen wrote:
> So here are the DSS related board file changes for 3.10.
> 
> First there are a bunch of patches adding the Kconfig options so that only one
> display device is created for a single video bus. Only Overo had more than two
> displays on the same bus, but unfortunately there were multiple boards with a
> setup that puts an LCD and DVI output on the same video bus.

Hmmm, so basically, if one could switch the display at runtime...
This cannot be done anymore...
This sounds like feature removal, no?
I know several of our clients who used this feature
(at least for evaluation purposes).
Is there any strong pros you obtain while removing this feature?

> 
> So the ifdeffery is not very nice. But, as discussed, this is the best way
> forward, and should be seen as a temporary solution until we get full DT
> support.

I've missed this discussion, can you please point to it?

And what will change with full DT support?
Will we be able to define several displays through DT and
select and active one during runtime?


-- 
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

Re: [PATCH 01/28] ARM: OMAP: Remove unnecessary platform callbacks for VENC devices

[Igor Grinberg]

On 03/28/13 14:48, Tomi Valkeinen wrote:
> From: Archit Taneja 
> 
> The omap_dss_device's platform_enable/disable callbacks don't do anything for
> any of the boards. The platform calls from the VENC driver will also be 
> removed
> in the future. Remove these calls from boards which have a VENC device.
> 
> Signed-off-by: Archit Taneja 
> Signed-off-by: Tomi Valkeinen 

This should have been done long long time ago...
Thanks!

Acked-by: Igor Grinberg 


-- 
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

Re: [PATCH RESEND v2 1/1] usb: musb: implement (un)map_urb_for_dma hooks

[Felipe Balbi]

On Thu, Mar 28, 2013 at 03:44:50PM +0200, Ruslan Bilovol wrote:
> Hi Felipe,
> 
> On Wed, Mar 27, 2013 at 3:17 PM, Felipe Balbi  wrote:
> > Hi,
> >
> > On Thu, Mar 14, 2013 at 08:12:09PM +0200, Ruslan Bilovol wrote:
> >> MUSB controller cannot work in DMA mode with misaligned buffers,
> >> switching in PIO mode.
> >>
> >> HCD core has hooks that allow to override the default DMA
> >> mapping and unmapping routines for host controllers that have
> >> special DMA requirements, such as alignment contraints.
> >>
> >> It is observed that work in PIO mode is slow and it's better
> >> to align buffers properly before passing them to MUSB
> >>
> >> This increased throughput 80->120 MBits/s over musb@omap4 with
> >> USB Gigabit ethernet adapter attached.
> >>
> >> Some ideas taken from ehci-tegra.c
> >>
> >> Signed-off-by: Ruslan Bilovol 
> >> ---
> >>  drivers/usb/musb/musb_core.c |   14 ++
> >>  drivers/usb/musb/musb_host.c |  102 
> >> +-
> >>  drivers/usb/musb/musb_host.h |2 +-
> >>  3 files changed, 116 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> >> index 60b41cc..91ac166 100644
> >> --- a/drivers/usb/musb/musb_core.c
> >> +++ b/drivers/usb/musb/musb_core.c
> >> @@ -1431,6 +1431,20 @@ static int musb_core_init(u16 musb_type, struct 
> >> musb *musb)
> >>
> >>   /* log release info */
> >>   musb->hwvers = musb_read_hwvers(mbase);
> >> +
> >> +#ifndef CONFIG_MUSB_PIO_ONLY
> >> + /*
> >> +  * The DMA engine in RTL1.8 and above cannot handle
> >> +  * DMA addresses that are not aligned to a 4 byte boundary.
> >> +  * For such engine implemented (un)map_urb_for_dma hooks.
> >> +  * Do not use these hooks for RTL<1.8
> >> +  */
> >> + if (musb->hwvers < MUSB_HWVERS_1800) {
> >
> > if you move this check to map/unmap and always return error if this is
> > true, you can avoid removing 'const' from our struct hc_driver. Would
> > that work ?
> 
> If we return an error in map/unmap callbacks, this will break urb 
> transferring,
> however I can call core function usb_hcd_(un)map_urb_for_dma() instead of
> returning the error (and that is default behavior if we do not have
> map/unmap callbacks
> set for the hc driver) so I can avoid removing 'const' from our struct
> hc_driver and this will work.
> The side effect will be only in small overhead for this path.
> 
> So, will be this OK for you? I will send v3 in this case.

should be alright. Thanks

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH RESEND v2 1/1] usb: musb: implement (un)map_urb_for_dma hooks

[Ruslan Bilovol]

Hi Felipe,

On Wed, Mar 27, 2013 at 3:17 PM, Felipe Balbi  wrote:
> Hi,
>
> On Thu, Mar 14, 2013 at 08:12:09PM +0200, Ruslan Bilovol wrote:
>> MUSB controller cannot work in DMA mode with misaligned buffers,
>> switching in PIO mode.
>>
>> HCD core has hooks that allow to override the default DMA
>> mapping and unmapping routines for host controllers that have
>> special DMA requirements, such as alignment contraints.
>>
>> It is observed that work in PIO mode is slow and it's better
>> to align buffers properly before passing them to MUSB
>>
>> This increased throughput 80->120 MBits/s over musb@omap4 with
>> USB Gigabit ethernet adapter attached.
>>
>> Some ideas taken from ehci-tegra.c
>>
>> Signed-off-by: Ruslan Bilovol 
>> ---
>>  drivers/usb/musb/musb_core.c |   14 ++
>>  drivers/usb/musb/musb_host.c |  102 
>> +-
>>  drivers/usb/musb/musb_host.h |2 +-
>>  3 files changed, 116 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
>> index 60b41cc..91ac166 100644
>> --- a/drivers/usb/musb/musb_core.c
>> +++ b/drivers/usb/musb/musb_core.c
>> @@ -1431,6 +1431,20 @@ static int musb_core_init(u16 musb_type, struct musb 
>> *musb)
>>
>>   /* log release info */
>>   musb->hwvers = musb_read_hwvers(mbase);
>> +
>> +#ifndef CONFIG_MUSB_PIO_ONLY
>> + /*
>> +  * The DMA engine in RTL1.8 and above cannot handle
>> +  * DMA addresses that are not aligned to a 4 byte boundary.
>> +  * For such engine implemented (un)map_urb_for_dma hooks.
>> +  * Do not use these hooks for RTL<1.8
>> +  */
>> + if (musb->hwvers < MUSB_HWVERS_1800) {
>
> if you move this check to map/unmap and always return error if this is
> true, you can avoid removing 'const' from our struct hc_driver. Would
> that work ?

If we return an error in map/unmap callbacks, this will break urb transferring,
however I can call core function usb_hcd_(un)map_urb_for_dma() instead of
returning the error (and that is default behavior if we do not have
map/unmap callbacks
set for the hc driver) so I can avoid removing 'const' from our struct
hc_driver and this will work.
The side effect will be only in small overhead for this path.

So, will be this OK for you? I will send v3 in this case.

-- 
Best regards,
Ruslan Bilvol

>
> --
> balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 0/8] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

[Nishanth Menon]

Hi Benoit,

On Thu, Mar 28, 2013 at 6:03 AM, Benoit Cousson  wrote:
> The patches 1 to 6 looks good to me. Beside the pretty long Cc list,
> that should not necessarily contain all the mailing list.
Arrgh.. my bad. I will keep it in mind for the future.

>
> Since you are changing / renaming some DTS files, and to avoid any merge
> conflict I will apply only these 6 patches.
> DTS and driver changes are in theory orthogonal enough to allow merging
> them separately and in any order.
>
> I'll update my branch with these patches ASAP.
Thanks. I will post a v3 of remaining patches later today.

Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 06/28] ARM: OMAP: DEVKIT8000: Kconfig option for the display options

[Tomi Valkeinen]

Boards with multiple display options for the same video bus have all the
possible linux display devices present at the same time. Only one of
those devices should be used at a time, as the video bus cannot be
shared.

This model is hacky, and will be changed in the forthcoming DSS patches
to a model where only one display device can be present on a single
video bus.

This patch creates Kconfig options to select which of the display
devices is present on the board. While this model is also somewhat
hacky, and prevents us from using a single kernel image for all the
display options, it allows us to make the DSS driver changes for DT
adaptation. And with DT, the information about display devices can be
passed from the bootloader, solving the mess.

Signed-off-by: Tomi Valkeinen 
Cc: Thomas Weber 
---
 arch/arm/mach-omap2/Kconfig|   13 +++
 arch/arm/mach-omap2/board-devkit8000.c |   58 +---
 2 files changed, 51 insertions(+), 20 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index fcbcd6c..940903e 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -206,6 +206,19 @@ config MACH_DEVKIT8000
default y
select OMAP_PACKAGE_CUS
 
+choice
+   depends on MACH_DEVKIT8000
+   default MACH_DEVKIT8000_EXPANSION_LCD
+   prompt "DEVKIT8000 video output"
+
+config MACH_DEVKIT8000_EXPANSION_LCD
+   bool "DEVKIT8000 with LCD"
+
+config MACH_DEVKIT8000_EXPANSION_DVI
+   bool "DEVKIT8000 with DVI"
+
+endchoice
+
 config MACH_OMAP_LDP
bool "OMAP3 LDP board"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
index 53056c3..e90808c 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -104,6 +104,24 @@ static struct omap2_hsmmc_info mmc[] = {
{}  /* Terminator */
 };
 
+static struct regulator_consumer_supply devkit8000_vmmc1_supply[] = {
+   REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0"),
+};
+
+/* ads7846 on SPI */
+static struct regulator_consumer_supply devkit8000_vio_supply[] = {
+   REGULATOR_SUPPLY("vcc", "spi2.0"),
+};
+
+static struct omap_dss_device devkit8000_tv_device = {
+   .name   = "tv",
+   .driver_name= "venc",
+   .type   = OMAP_DISPLAY_TYPE_VENC,
+   .phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+#if defined(CONFIG_MACH_DEVKIT8000_EXPANSION_LCD)
+
 static int devkit8000_panel_enable_lcd(struct omap_dss_device *dssdev)
 {
if (gpio_is_valid(dssdev->reset_gpio))
@@ -117,15 +135,6 @@ static void devkit8000_panel_disable_lcd(struct 
omap_dss_device *dssdev)
gpio_set_value_cansleep(dssdev->reset_gpio, 0);
 }
 
-static struct regulator_consumer_supply devkit8000_vmmc1_supply[] = {
-   REGULATOR_SUPPLY("vmmc", "omap_hsmmc.0"),
-};
-
-/* ads7846 on SPI */
-static struct regulator_consumer_supply devkit8000_vio_supply[] = {
-   REGULATOR_SUPPLY("vcc", "spi2.0"),
-};
-
 static struct panel_generic_dpi_data lcd_panel = {
.name   = "innolux_at070tn83",
.platform_enable= devkit8000_panel_enable_lcd,
@@ -140,6 +149,19 @@ static struct omap_dss_device devkit8000_lcd_device = {
.phy.dpi.data_lines = 24,
 };
 
+static struct omap_dss_device *devkit8000_dss_devices[] = {
+   &devkit8000_lcd_device,
+   &devkit8000_tv_device,
+};
+
+static struct omap_dss_board_info devkit8000_dss_data = {
+   .num_devices = ARRAY_SIZE(devkit8000_dss_devices),
+   .devices = devkit8000_dss_devices,
+   .default_display_name = "lcd",
+};
+
+#elif defined(CONFIG_MACH_DEVKIT8000_EXPANSION_DVI)
+
 static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
.i2c_bus_num= 1,
@@ -153,16 +175,7 @@ static struct omap_dss_device devkit8000_dvi_device = {
.phy.dpi.data_lines = 24,
 };
 
-static struct omap_dss_device devkit8000_tv_device = {
-   .name   = "tv",
-   .driver_name= "venc",
-   .type   = OMAP_DISPLAY_TYPE_VENC,
-   .phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
-};
-
-
 static struct omap_dss_device *devkit8000_dss_devices[] = {
-   &devkit8000_lcd_device,
&devkit8000_dvi_device,
&devkit8000_tv_device,
 };
@@ -170,8 +183,9 @@ static struct omap_dss_device *devkit8000_dss_devices[] = {
 static struct omap_dss_board_info devkit8000_dss_data = {
.num_devices = ARRAY_SIZE(devkit8000_dss_devices),
.devices = devkit8000_dss_devices,
-   .default_device = &devkit8000_lcd_device,
+   .default_display_name = "dvi",
 };
+#endif
 
 static uint32_t board_keymap[] = {
KEY(0, 0, KEY_1),
@@ -211,7 +225,9 @@ static struct gpio_led gpio_leds[];
 static int devkit8000_twl_gpio_setup(struct device *dev,
unsigned gpio, unsi

Re: [PATCH 13/28] ARM: OMAP: Beagle: use new TFP410 platform driver

[Peter Meerwald]

> -static struct omap_dss_device beagle_dvi_device = {
> - .type = OMAP_DISPLAY_TYPE_DPI,
> - .name = "dvi",
> - .driver_name = "tfp410",
> - .data = &dvi_panel,
> - .phy.dpi.data_lines = 24,
> +static struct platform_device omap4_panda_tfp410_device = {

omap4_panda? this is omap3_beagle!

-- 

Peter Meerwald
+43-664-218 (mobile)
--
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 17/28] ARM: OMAP: Devkit8000: use new TFP410 platform driver

[Tomi Valkeinen]

Use the new TFP410 platform driver instead of the old omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-devkit8000.c |   17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
index e90808c..d05f069 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -163,20 +163,20 @@ static struct omap_dss_board_info devkit8000_dss_data = {
 #elif defined(CONFIG_MACH_DEVKIT8000_EXPANSION_DVI)
 
 static struct tfp410_platform_data dvi_panel = {
+   .name   = "dvi",
+   .source = "dpi.0",
+   .data_lines = 24,
.power_down_gpio= -1,
.i2c_bus_num= 1,
 };
 
-static struct omap_dss_device devkit8000_dvi_device = {
-   .name   = "dvi",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "tfp410",
-   .data   = &dvi_panel,
-   .phy.dpi.data_lines = 24,
+static struct platform_device devkit8000_dvi_device = {
+   .name   = "tfp410",
+   .id = 0,
+   .dev.platform_data  = &dvi_panel,
 };
 
 static struct omap_dss_device *devkit8000_dss_devices[] = {
-   &devkit8000_dvi_device,
&devkit8000_tv_device,
 };
 
@@ -452,6 +452,9 @@ static struct platform_device *devkit8000_devices[] 
__initdata = {
&leds_gpio,
&keys_gpio,
&omap_dm9000_dev,
+#if defined(CONFIG_MACH_DEVKIT8000_EXPANSION_DVI)
+   &devkit8000_dvi_device,
+#endif
 };
 
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-- 
1.7.10.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

[PATCH 19/28] ARM: OMAP: AM3517EVM: use new TFP410 platform driver

[Tomi Valkeinen]

Use the new TFP410 platform driver instead of the old omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-am3517evm.c |   17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index 1d7d0d8..c545981 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -200,20 +200,20 @@ static void __init am3517_evm_display_init(void)
 }
 
 static struct tfp410_platform_data dvi_panel = {
+   .name   = "dvi",
+   .source = "dpi.0",
+   .data_lines = 24,
.power_down_gpio= -1,
.i2c_bus_num= -1,
 };
 
-static struct omap_dss_device am3517_evm_dvi_device = {
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .name   = "dvi",
-   .driver_name= "tfp410",
-   .data   = &dvi_panel,
-   .phy.dpi.data_lines = 24,
+static struct platform_device am3517_evm_dvi_device = {
+   .name   = "tfp410",
+   .id = 0,
+   .dev.platform_data  = &dvi_panel,
 };
 
 static struct omap_dss_device *am3517_evm_dss_devices[] = {
-   &am3517_evm_dvi_device,
&am3517_evm_tv_device,
 };
 
@@ -359,6 +359,9 @@ static void __init am3517_evm_init(void)
am3517_evm_hecc_init(&am3517_evm_hecc_pdata);
/* DSS */
am3517_evm_display_init();
+#if defined(CONFIG_MACH_OMAP3517EVM_EXPANSION_DVI)
+   platform_device_register(&am3517_evm_dvi_device);
+#endif
 
/* RTC - S35390A */
am3517_evm_rtc_init();
-- 
1.7.10.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

[PATCH 28/28] ARM: OMAP: 2430SDP: use new generic-dpi-panel platform driver

[Tomi Valkeinen]

Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-2430sdp.c |   24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/board-2430sdp.c 
b/arch/arm/mach-omap2/board-2430sdp.c
index a3e0aaa..4f94dec 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -100,10 +100,6 @@ static struct platform_device sdp2430_flash_device = {
.resource   = &sdp2430_flash_resource,
 };
 
-static struct platform_device *sdp2430_devices[] __initdata = {
-   &sdp2430_flash_device,
-};
-
 /* LCD */
 #define SDP2430_LCD_PANEL_BACKLIGHT_GPIO   91
 #define SDP2430_LCD_PANEL_ENABLE_GPIO  154
@@ -123,27 +119,27 @@ static void sdp2430_panel_disable_lcd(struct 
omap_dss_device *dssdev)
 }
 
 static struct panel_generic_dpi_data sdp2430_panel_data = {
+   .display_name   = "lcd",
+   .source = "dpi.0",
.name   = "nec_nl2432dr22-11b",
+   .data_lines = 16,
.platform_enable= sdp2430_panel_enable_lcd,
.platform_disable   = sdp2430_panel_disable_lcd,
 };
 
-static struct omap_dss_device sdp2430_lcd_device = {
-   .name   = "lcd",
-   .driver_name= "generic_dpi_panel",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .phy.dpi.data_lines = 16,
-   .data   = &sdp2430_panel_data,
+static struct platform_device sdp2430_lcd_device = {
+   .name   = "generic_dpi_panel",
+   .id = 0,
+   .dev.platform_data  = &sdp2430_panel_data,
 };
 
-static struct omap_dss_device *sdp2430_dss_devices[] = {
+static struct platform_device *sdp2430_devices[] __initdata = {
+   &sdp2430_flash_device,
&sdp2430_lcd_device,
 };
 
 static struct omap_dss_board_info sdp2430_dss_data = {
-   .num_devices= ARRAY_SIZE(sdp2430_dss_devices),
-   .devices= sdp2430_dss_devices,
-   .default_device = &sdp2430_lcd_device,
+   .default_display_name = "lcd",
 };
 
 static void __init sdp2430_display_init(void)
-- 
1.7.10.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

[PATCH 26/28] ARM: OMAP: CM-T35: use new generic-dpi-panel platform driver

[Tomi Valkeinen]

Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
Cc: Mike Rapoport 
Cc: Igor Grinberg 
---
 arch/arm/mach-omap2/board-cm-t35.c |   16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index 4f23be0..6b8aa87 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -214,21 +214,21 @@ static void cm_t35_panel_disable_lcd(struct 
omap_dss_device *dssdev)
 }
 
 static struct panel_generic_dpi_data lcd_panel = {
+   .display_name   = "lcd",
+   .source = "dpi.0",
.name   = "toppoly_tdo35s",
+   .data_lines = 18,
.platform_enable= cm_t35_panel_enable_lcd,
.platform_disable   = cm_t35_panel_disable_lcd,
 };
 
-static struct omap_dss_device cm_t35_lcd_device = {
-   .name   = "lcd",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "generic_dpi_panel",
-   .data   = &lcd_panel,
-   .phy.dpi.data_lines = 18,
+static struct platform_device cm_t35_lcd_device = {
+   .name   = "generic_dpi_panel",
+   .id = 0,
+   .dev.platform_data  = &lcd_panel,
 };
 
 static struct omap_dss_device *cm_t35_dss_devices[] = {
-   &cm_t35_lcd_device,
&cm_t35_tv_device,
 };
 
@@ -282,6 +282,8 @@ static void __init cm_t35_init_display(void)
msleep(50);
gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
 
+   platform_device_register(&cm_t35_lcd_device);
+
err = omap_display_init(&cm_t35_dss_data);
if (err) {
pr_err("CM-T35: failed to register DSS device\n");
-- 
1.7.10.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

[PATCH 27/28] ARM: OMAP: AM3517EVM: use new generic-dpi-panel platform driver

[Tomi Valkeinen]

Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-am3517evm.c |   17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index c545981..a7e728e 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -169,21 +169,21 @@ static void am3517_evm_panel_disable_lcd(struct 
omap_dss_device *dssdev)
 }
 
 static struct panel_generic_dpi_data lcd_panel = {
+   .display_name   = "lcd",
+   .source = "dpi.0",
.name   = "sharp_lq",
+   .data_lines = 16,
.platform_enable= am3517_evm_panel_enable_lcd,
.platform_disable   = am3517_evm_panel_disable_lcd,
 };
 
-static struct omap_dss_device am3517_evm_lcd_device = {
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .name   = "lcd",
-   .driver_name= "generic_dpi_panel",
-   .data   = &lcd_panel,
-   .phy.dpi.data_lines = 16,
+static struct platform_device am3517_evm_lcd_device = {
+   .name   = "generic_dpi_panel",
+   .id = 0,
+   .dev.platform_data  = &lcd_panel,
 };
 
 static struct omap_dss_device *am3517_evm_dss_devices[] = {
-   &am3517_evm_lcd_device,
&am3517_evm_tv_device,
 };
 
@@ -362,6 +362,9 @@ static void __init am3517_evm_init(void)
 #if defined(CONFIG_MACH_OMAP3517EVM_EXPANSION_DVI)
platform_device_register(&am3517_evm_dvi_device);
 #endif
+#if defined(CONFIG_MACH_OMAP3517EVM_EXPANSION_LCD)
+   platform_device_register(&am3517_evm_lcd_device);
+#endif
 
/* RTC - S35390A */
am3517_evm_rtc_init();
-- 
1.7.10.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

[PATCH 24/28] ARM: OMAP: H4: use new generic-dpi-panel platform driver

[Tomi Valkeinen]

Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-h4.c |   24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/board-h4.c b/arch/arm/mach-omap2/board-h4.c
index 812c829..bbcbc31 100644
--- a/arch/arm/mach-omap2/board-h4.c
+++ b/arch/arm/mach-omap2/board-h4.c
@@ -194,30 +194,26 @@ static struct platform_device h4_flash_device = {
.resource   = &h4_flash_resource,
 };
 
-static struct platform_device *h4_devices[] __initdata = {
-   &h4_flash_device,
-};
-
 static struct panel_generic_dpi_data h4_panel_data = {
+   .display_name   = "lcd",
+   .source = "dpi.0",
.name   = "h4",
+   .data_lines = 16,
 };
 
-static struct omap_dss_device h4_lcd_device = {
-   .name   = "lcd",
-   .driver_name= "generic_dpi_panel",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .phy.dpi.data_lines = 16,
-   .data   = &h4_panel_data,
+static struct platform_device h4_lcd_device = {
+   .name   = "generic_dpi_panel",
+   .id = 0,
+   .dev.platform_data  = &h4_panel_data,
 };
 
-static struct omap_dss_device *h4_dss_devices[] = {
+static struct platform_device *h4_devices[] __initdata = {
+   &h4_flash_device,
&h4_lcd_device,
 };
 
 static struct omap_dss_board_info h4_dss_data = {
-   .num_devices= ARRAY_SIZE(h4_dss_devices),
-   .devices= h4_dss_devices,
-   .default_device = &h4_lcd_device,
+   .default_display_name = "lcd",
 };
 
 /* 2420 Sysboot setup (2430 is different) */
-- 
1.7.10.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

[PATCH 25/28] ARM: OMAP: Devkit8000: use new generic-dpi-panel platform driver

[Tomi Valkeinen]

Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-devkit8000.c |   33 ++--
 1 file changed, 19 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/board-devkit8000.c 
b/arch/arm/mach-omap2/board-devkit8000.c
index d05f069..1e0343f 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -122,35 +122,37 @@ static struct omap_dss_device devkit8000_tv_device = {
 
 #if defined(CONFIG_MACH_DEVKIT8000_EXPANSION_LCD)
 
+static int lcd_reset_gpio;
+
 static int devkit8000_panel_enable_lcd(struct omap_dss_device *dssdev)
 {
-   if (gpio_is_valid(dssdev->reset_gpio))
-   gpio_set_value_cansleep(dssdev->reset_gpio, 1);
+   if (gpio_is_valid(lcd_reset_gpio))
+   gpio_set_value_cansleep(lcd_reset_gpio, 1);
return 0;
 }
 
 static void devkit8000_panel_disable_lcd(struct omap_dss_device *dssdev)
 {
-   if (gpio_is_valid(dssdev->reset_gpio))
-   gpio_set_value_cansleep(dssdev->reset_gpio, 0);
+   if (gpio_is_valid(lcd_reset_gpio))
+   gpio_set_value_cansleep(lcd_reset_gpio, 0);
 }
 
 static struct panel_generic_dpi_data lcd_panel = {
+   .display_name   = "lcd",
+   .source = "dpi.0",
.name   = "innolux_at070tn83",
+   .data_lines = 24,
.platform_enable= devkit8000_panel_enable_lcd,
.platform_disable   = devkit8000_panel_disable_lcd,
 };
 
-static struct omap_dss_device devkit8000_lcd_device = {
-   .name   = "lcd",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "generic_dpi_panel",
-   .data   = &lcd_panel,
-   .phy.dpi.data_lines = 24,
+static struct platform_device devkit8000_lcd_device = {
+   .name   = "generic_dpi_panel",
+   .id = 0,
+   .dev.platform_data  = &lcd_panel,
 };
 
 static struct omap_dss_device *devkit8000_dss_devices[] = {
-   &devkit8000_lcd_device,
&devkit8000_tv_device,
 };
 
@@ -238,11 +240,11 @@ static int devkit8000_twl_gpio_setup(struct device *dev,
 
 #if defined(CONFIG_MACH_DEVKIT8000_EXPANSION_LCD)
/* TWL4030_GPIO_MAX + 0 is "LCD_PWREN" (out, active high) */
-   devkit8000_lcd_device.reset_gpio = gpio + TWL4030_GPIO_MAX + 0;
-   ret = gpio_request_one(devkit8000_lcd_device.reset_gpio,
+   lcd_reset_gpio = gpio + TWL4030_GPIO_MAX + 0;
+   ret = gpio_request_one(lcd_reset_gpio,
   GPIOF_OUT_INIT_LOW, "LCD_PWREN");
if (ret < 0) {
-   devkit8000_lcd_device.reset_gpio = -EINVAL;
+   lcd_reset_gpio = -EINVAL;
printk(KERN_ERR "Failed to request GPIO for LCD_PWRN\n");
}
 #elif defined(CONFIG_MACH_DEVKIT8000_EXPANSION_DVI)
@@ -455,6 +457,9 @@ static struct platform_device *devkit8000_devices[] 
__initdata = {
 #if defined(CONFIG_MACH_DEVKIT8000_EXPANSION_DVI)
&devkit8000_dvi_device,
 #endif
+#if defined(CONFIG_MACH_DEVKIT8000_EXPANSION_LCD)
+   &devkit8000_lcd_device,
+#endif
 };
 
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-- 
1.7.10.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

[PATCH 23/28] ARM: OMAP: LDP: use new generic-dpi-panel platform driver

[Tomi Valkeinen]

Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-ldp.c |   22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index b12fe96..78e0470 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -206,27 +206,22 @@ static void ldp_panel_disable_lcd(struct omap_dss_device 
*dssdev)
 }
 
 static struct panel_generic_dpi_data ldp_panel_data = {
+   .display_name   = "lcd",
+   .source = "dpi.0",
.name   = "nec_nl2432dr22-11b",
+   .data_lines = 18,
.platform_enable= ldp_panel_enable_lcd,
.platform_disable   = ldp_panel_disable_lcd,
 };
 
-static struct omap_dss_device ldp_lcd_device = {
-   .name   = "lcd",
-   .driver_name= "generic_dpi_panel",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .phy.dpi.data_lines = 18,
-   .data   = &ldp_panel_data,
-};
-
-static struct omap_dss_device *ldp_dss_devices[] = {
-   &ldp_lcd_device,
+static struct platform_device ldp_lcd_device = {
+   .name   = "generic_dpi_panel",
+   .id = 0,
+   .dev.platform_data  = &ldp_panel_data,
 };
 
 static struct omap_dss_board_info ldp_dss_data = {
-   .num_devices= ARRAY_SIZE(ldp_dss_devices),
-   .devices= ldp_dss_devices,
-   .default_device = &ldp_lcd_device,
+   .default_display_name = "lcd",
 };
 
 static void __init ldp_display_init(void)
@@ -364,6 +359,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
 
 static struct platform_device *ldp_devices[] __initdata = {
&ldp_gpio_keys_device,
+   &ldp_lcd_device,
 };
 
 #ifdef CONFIG_OMAP_MUX
-- 
1.7.10.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

[PATCH 22/28] ARM: OMAP: Overo: use new generic-dpi-panel platform driver

[Tomi Valkeinen]

Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-overo.c |   23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/board-overo.c 
b/arch/arm/mach-omap2/board-overo.c
index 9cb29fc..03624c5 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -241,27 +241,22 @@ static void overo_panel_disable_lcd(struct 
omap_dss_device *dssdev)
gpio_set_value(OVERO_GPIO_LCD_BL, 0);
 }
 
-static struct panel_generic_dpi_data lcd43_panel = {
+static struct panel_generic_dpi_data overo_lcd43_data = {
+   .display_name   = "lcd43",
+   .source = "dpi.0",
.name   = "samsung_lte430wq_f0c",
.platform_enable= overo_panel_enable_lcd,
.platform_disable   = overo_panel_disable_lcd,
+   .data_lines = 24,
 };
 
-static struct omap_dss_device overo_lcd43_device = {
-   .name   = "lcd43",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "generic_dpi_panel",
-   .data   = &lcd43_panel,
-   .phy.dpi.data_lines = 24,
-};
-
-static struct omap_dss_device *overo_dss_devices[] = {
-   &overo_lcd43_device,
+static struct platform_device overo_lcd43_device = {
+   .name   = "generic_dpi_panel",
+   .id = 0,
+   .dev.platform_data  = &overo_lcd43_data,
 };
 
 static struct omap_dss_board_info overo_dss_data = {
-   .num_devices= ARRAY_SIZE(overo_dss_devices),
-   .devices= overo_dss_devices,
.default_display_name = "lcd43",
 };
 
@@ -279,6 +274,8 @@ static void __init overo_display_init(void)
 
gpio_export(OVERO_GPIO_LCD_EN, 0);
gpio_export(OVERO_GPIO_LCD_BL, 0);
+
+   platform_device_register(&overo_lcd43_device);
 }
 
 #endif
-- 
1.7.10.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

[PATCH 21/28] ARM: OMAP: Overo: use new TFP410 platform driver

[Tomi Valkeinen]

Use the new TFP410 platform driver instead of the old omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-overo.c |   20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/board-overo.c 
b/arch/arm/mach-omap2/board-overo.c
index 3253682..9cb29fc 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -148,30 +148,26 @@ static inline void __init overo_init_smsc911x(void) { 
return; }
 #if defined(CONFIG_MACH_OVERO_EXPANSION_SUMMIT)
 
 static struct tfp410_platform_data dvi_panel = {
+   .name   = "dvi",
+   .source = "dpi.0",
+   .data_lines = 24,
.i2c_bus_num= 3,
.power_down_gpio= -1,
 };
 
-static struct omap_dss_device overo_dvi_device = {
-   .name   = "dvi",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "tfp410",
-   .data   = &dvi_panel,
-   .phy.dpi.data_lines = 24,
-};
-
-static struct omap_dss_device *overo_dss_devices[] = {
-   &overo_dvi_device,
+static struct platform_device overo_dvi_device = {
+   .name   = "tfp410",
+   .id = 0,
+   .dev.platform_data  = &dvi_panel,
 };
 
 static struct omap_dss_board_info overo_dss_data = {
-   .num_devices= ARRAY_SIZE(overo_dss_devices),
-   .devices= overo_dss_devices,
.default_display_name = "dvi",
 };
 
 static void __init overo_display_init(void)
 {
+   platform_device_register(&overo_dvi_device);
 }
 
 #elif defined(CONFIG_MACH_OVERO_EXPANSION_PALO35)
-- 
1.7.10.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

[PATCH 18/28] ARM: OMAP: CM-T35: use new TFP410 platform driver

[Tomi Valkeinen]

Use the new TFP410 platform driver instead of the old omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
Cc: Mike Rapoport 
Cc: Igor Grinberg 
---
 arch/arm/mach-omap2/board-cm-t35.c |   16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index 1b34c96..4f23be0 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -294,20 +294,20 @@ static void __init cm_t35_init_display(void)
 #define CM_T35_DVI_EN_GPIO 54
 
 static struct tfp410_platform_data dvi_panel = {
+   .name   = "dvi",
+   .source = "dpi.0",
+   .data_lines = 24,
.power_down_gpio= CM_T35_DVI_EN_GPIO,
.i2c_bus_num= -1,
 };
 
-static struct omap_dss_device cm_t35_dvi_device = {
-   .name   = "dvi",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "tfp410",
-   .data   = &dvi_panel,
-   .phy.dpi.data_lines = 24,
+static struct platform_device cm_t35_dvi_device = {
+   .name   = "tfp410",
+   .id = 0,
+   .dev.platform_data  = &dvi_panel,
 };
 
 static struct omap_dss_device *cm_t35_dss_devices[] = {
-   &cm_t35_dvi_device,
&cm_t35_tv_device,
 };
 
@@ -321,6 +321,8 @@ static void __init cm_t35_init_display(void)
 {
int err;
 
+   platform_device_register(&cm_t35_dvi_device);
+
err = omap_display_init(&cm_t35_dss_data);
if (err)
pr_err("CM-T35: failed to register DSS device\n");
-- 
1.7.10.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

[PATCH 20/28] ARM: OMAP: 3430SDP: use new TFP410 platform driver

[Tomi Valkeinen]

Use the new TFP410 platform driver instead of the old omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-3430sdp.c |   19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 4acd4aa..2f9d4e0 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -119,27 +119,27 @@ static void __init sdp3430_display_init(void)
 }
 
 static struct tfp410_platform_data dvi_panel = {
+   .name   = "dvi",
+   .source = "dpi.0",
+   .data_lines = 24,
.power_down_gpio= -1,
.i2c_bus_num= -1,
 };
 
-static struct omap_dss_device sdp3430_dvi_device = {
-   .name   = "dvi",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "tfp410",
-   .data   = &dvi_panel,
-   .phy.dpi.data_lines = 24,
+static struct platform_device sdp3430_dvi_device = {
+   .name   = "tfp410",
+   .id = 0,
+   .dev.platform_data  = &dvi_panel,
 };
 
 static struct omap_dss_device *sdp3430_dss_devices[] = {
-   &sdp3430_dvi_device,
&sdp3430_tv_device,
 };
 
 static struct omap_dss_board_info sdp3430_dss_data = {
.num_devices= ARRAY_SIZE(sdp3430_dss_devices),
.devices= sdp3430_dss_devices,
-   .default_device = &sdp3430_dvi_device,
+   .default_display_name = "dvi",
 };
 
 #elif defined(CONFIG_MACH_OMAP_3430SDP_EXPANSION_LCD)
@@ -612,6 +612,9 @@ static void __init omap_3430sdp_init(void)
board_smc91x_init();
board_flash_init(sdp_flash_partitions, chip_sel_3430, 0);
sdp3430_display_init();
+#if defined(CONFIG_MACH_OMAP_3430SDP_EXPANSION_DVI)
+   platform_device_register(&sdp3430_dvi_device);
+#endif
enable_board_wakeup_source();
usbhs_init(&usbhs_bdata);
 }
-- 
1.7.10.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

[PATCH 16/28] ARM: OMAP: IGEP0020: use new TFP410 platform driver

[Tomi Valkeinen]

Use the new TFP410 platform driver instead of the old omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-igep0020.c |   22 +-
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c 
b/arch/arm/mach-omap2/board-igep0020.c
index bf92678..28d0b3e 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -430,30 +430,26 @@ static struct twl4030_gpio_platform_data 
igep_twl4030_gpio_pdata = {
 };
 
 static struct tfp410_platform_data dvi_panel = {
+   .name   = "dvi",
+   .source = "dpi.0",
+   .data_lines = 24,
.i2c_bus_num= 3,
.power_down_gpio= IGEP2_GPIO_DVI_PUP,
 };
 
-static struct omap_dss_device igep2_dvi_device = {
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .name   = "dvi",
-   .driver_name= "tfp410",
-   .data   = &dvi_panel,
-   .phy.dpi.data_lines = 24,
-};
-
-static struct omap_dss_device *igep2_dss_devices[] = {
-   &igep2_dvi_device
+static struct platform_device igep2_dvi_device = {
+   .name   = "tfp410",
+   .id = 0,
+   .dev.platform_data  = &dvi_panel,
 };
 
 static struct omap_dss_board_info igep2_dss_data = {
-   .num_devices= ARRAY_SIZE(igep2_dss_devices),
-   .devices= igep2_dss_devices,
-   .default_device = &igep2_dvi_device,
+   .default_display_name = "dvi",
 };
 
 static struct platform_device *igep_devices[] __initdata = {
&igep_vwlan_device,
+   &igep2_dvi_device,
 };
 
 static int igep2_keymap[] = {
-- 
1.7.10.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

[PATCH 15/28] ARM: OMAP: OMAP3EVM: use new TFP410 platform driver

[Tomi Valkeinen]

Use the new TFP410 platform driver instead of the old omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-omap3evm.c |   17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index 2050679..de92965 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -238,21 +238,21 @@ static void __init omap3_evm_display_init(void)
 }
 
 static struct tfp410_platform_data dvi_panel = {
+   .name   = "dvi",
+   .source = "dpi.0",
+   .data_lines = 24,
.power_down_gpio= OMAP3EVM_DVI_PANEL_EN_GPIO,
.i2c_bus_num= -1,
 };
 
-static struct omap_dss_device omap3_evm_dvi_device = {
-   .name   = "dvi",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "tfp410",
-   .data   = &dvi_panel,
-   .phy.dpi.data_lines = 24,
+static struct platform_device omap3_evm_dvi_device = {
+   .name   = "tfp410",
+   .id = 0,
+   .dev.platform_data  = &dvi_panel,
 };
 
 static struct omap_dss_device *omap3_evm_dss_devices[] = {
&omap3_evm_tv_device,
-   &omap3_evm_dvi_device,
 };
 
 static struct omap_dss_board_info omap3_evm_dss_data = {
@@ -705,6 +705,9 @@ static void __init omap3_evm_init(void)
 
omap3_evm_i2c_init();
 
+#if defined(CONFIG_MACH_OMAP3EVM_EXPANSION_DVI)
+   platform_device_register(&omap3_evm_dvi_device);
+#endif
omap_display_init(&omap3_evm_dss_data);
 
omap_serial_init();
-- 
1.7.10.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

[PATCH 13/28] ARM: OMAP: Beagle: use new TFP410 platform driver

[Tomi Valkeinen]

Use the new TFP410 platform driver instead of the old omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-omap3beagle.c |   25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index c3558f9..1b65e92 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -224,17 +224,18 @@ static struct mtd_partition omap3beagle_nand_partitions[] 
= {
 
 /* DSS */
 
-static struct tfp410_platform_data dvi_panel = {
-   .i2c_bus_num = 3,
-   .power_down_gpio = -1,
+static struct tfp410_platform_data omap4_tfp410_pdata = {
+   .name   = "dvi",
+   .source = "dpi.0",
+   .i2c_bus_num= 3,
+   .data_lines = 24,
+   .power_down_gpio= -1,
 };
 
-static struct omap_dss_device beagle_dvi_device = {
-   .type = OMAP_DISPLAY_TYPE_DPI,
-   .name = "dvi",
-   .driver_name = "tfp410",
-   .data = &dvi_panel,
-   .phy.dpi.data_lines = 24,
+static struct platform_device omap4_panda_tfp410_device = {
+   .name   = "tfp410",
+   .id = 0,
+   .dev.platform_data  = &omap4_tfp410_pdata,
 };
 
 static struct omap_dss_device beagle_tv_device = {
@@ -245,14 +246,13 @@ static struct omap_dss_device beagle_tv_device = {
 };
 
 static struct omap_dss_device *beagle_dss_devices[] = {
-   &beagle_dvi_device,
&beagle_tv_device,
 };
 
 static struct omap_dss_board_info beagle_dss_data = {
.num_devices = ARRAY_SIZE(beagle_dss_devices),
.devices = beagle_dss_devices,
-   .default_device = &beagle_dvi_device,
+   .default_display_name = "dvi",
 };
 
 #include "sdram-micron-mt46h32m32lf-6.h"
@@ -316,7 +316,7 @@ static int beagle_twl_gpio_setup(struct device *dev,
if (gpio_request_one(gpio + 1, GPIOF_IN, "EHCI_nOC"))
pr_err("%s: unable to configure EHCI_nOC\n", __func__);
}
-   dvi_panel.power_down_gpio = beagle_config.dvi_pd_gpio;
+   omap4_tfp410_pdata.power_down_gpio = beagle_config.dvi_pd_gpio;
 
gpio_request_one(gpio + TWL4030_GPIO_MAX, beagle_config.usb_pwr_level,
"nEN_USB_PWR");
@@ -450,6 +450,7 @@ static struct platform_device *omap3_beagle_devices[] 
__initdata = {
&keys_gpio,
&madc_hwmon,
&leds_pwm,
+   &omap4_panda_tfp410_device,
 };
 
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-- 
1.7.10.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

[PATCH 14/28] ARM: OMAP: Stalker: use new TFP410 platform driver

[Tomi Valkeinen]

Use the new TFP410 platform driver instead of the old omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-omap3stalker.c |   17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3stalker.c 
b/arch/arm/mach-omap2/board-omap3stalker.c
index d427240..3d10d7c 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -107,27 +107,27 @@ static struct omap_dss_device omap3_stalker_tv_device = {
 };
 
 static struct tfp410_platform_data dvi_panel = {
+   .name   = "dvi",
+   .source = "dpi.0",
+   .data_lines = 24,
.power_down_gpio= DSS_ENABLE_GPIO,
.i2c_bus_num= -1,
 };
 
-static struct omap_dss_device omap3_stalker_dvi_device = {
-   .name   = "dvi",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "tfp410",
-   .data   = &dvi_panel,
-   .phy.dpi.data_lines = 24,
+static struct platform_device omap3_stalker_dvi_device = {
+   .name   = "tfp410",
+   .id = 0,
+   .dev.platform_data  = &dvi_panel,
 };
 
 static struct omap_dss_device *omap3_stalker_dss_devices[] = {
&omap3_stalker_tv_device,
-   &omap3_stalker_dvi_device,
 };
 
 static struct omap_dss_board_info omap3_stalker_dss_data = {
.num_devices= ARRAY_SIZE(omap3_stalker_dss_devices),
.devices= omap3_stalker_dss_devices,
-   .default_device = &omap3_stalker_dvi_device,
+   .default_display_name = "dvi",
 };
 
 static struct regulator_consumer_supply omap3stalker_vmmc1_supply[] = {
@@ -349,6 +349,7 @@ static int __init omap3_stalker_i2c_init(void)
 
 static struct platform_device *omap3_stalker_devices[] __initdata = {
&keys_gpio,
+   &omap3_stalker_dvi_device,
 };
 
 static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
-- 
1.7.10.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

[PATCH 12/28] ARM: OMAP: 4430SDP: use new Taal driver

[Tomi Valkeinen]

Change 4430SDP to use the new Taal platform driver instead of the old
omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/dss-common.c |   47 +-
 1 file changed, 21 insertions(+), 26 deletions(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 1e2c5c0..0c0fc79 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -118,7 +118,8 @@ static struct platform_device sdp4430_hdmi_device = {
 #define DISPLAY_SEL_GPIO   59  /* LCD2/PicoDLP switch */
 
 static struct nokia_dsi_panel_data dsi1_panel = {
-   .name   = "taal",
+   .name   = "lcd",
+   .source = "dsi.0",
.reset_gpio = 102,
.use_ext_te = false,
.ext_te_gpio= 101,
@@ -129,15 +130,10 @@ static struct nokia_dsi_panel_data dsi1_panel = {
},
 };
 
-static struct omap_dss_device sdp4430_lcd_device = {
-   .name   = "lcd",
-   .driver_name= "taal",
-   .type   = OMAP_DISPLAY_TYPE_DSI,
-   .data   = &dsi1_panel,
-   .phy.dsi= {
-   .module = 0,
-   },
-   .channel= OMAP_DSS_CHANNEL_LCD,
+static struct platform_device sdp4430_lcd1_device = {
+   .name   = "taal",
+   .id = 0,
+   .dev.platform_data  = &dsi1_panel,
 };
 
 #if defined(CONFIG_MACH_OMAP_4430SDP_EXPANSION_LCD2)
@@ -145,7 +141,8 @@ static struct omap_dss_device sdp4430_lcd_device = {
 static void sdp4430_picodlp_init(void) { }
 
 static struct nokia_dsi_panel_data dsi2_panel = {
-   .name   = "taal",
+   .name   = "lcd2",
+   .source = "dsi.1",
.reset_gpio = 104,
.use_ext_te = false,
.ext_te_gpio= 103,
@@ -156,16 +153,10 @@ static struct nokia_dsi_panel_data dsi2_panel = {
},
 };
 
-static struct omap_dss_device sdp4430_lcd2_device = {
-   .name   = "lcd2",
-   .driver_name= "taal",
-   .type   = OMAP_DISPLAY_TYPE_DSI,
-   .data   = &dsi2_panel,
-   .phy.dsi= {
-
-   .module = 1,
-   },
-   .channel= OMAP_DSS_CHANNEL_LCD2,
+static struct platform_device sdp4430_lcd2_device = {
+   .name   = "taal",
+   .id = 1,
+   .dev.platform_data  = &dsi2_panel,
 };
 
 #elif defined(CONFIG_MACH_OMAP_4430SDP_EXPANSION_PICO)
@@ -223,10 +214,6 @@ static struct omap_dss_device sdp4430_picodlp_device = {
 #endif
 
 static struct omap_dss_device *sdp4430_dss_devices[] = {
-   &sdp4430_lcd_device,
-#ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_LCD2
-   &sdp4430_lcd2_device,
-#endif
 #ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_PICO
&sdp4430_picodlp_device,
 #endif
@@ -235,7 +222,7 @@ static struct omap_dss_device *sdp4430_dss_devices[] = {
 static struct omap_dss_board_info sdp4430_dss_data = {
.num_devices= ARRAY_SIZE(sdp4430_dss_devices),
.devices= sdp4430_dss_devices,
-   .default_device = &sdp4430_lcd_device,
+   .default_display_name = "lcd",
 };
 
 void __init omap_4430sdp_display_init(void)
@@ -251,6 +238,10 @@ void __init omap_4430sdp_display_init(void)
sdp4430_picodlp_init();
omap_display_init(&sdp4430_dss_data);
platform_device_register(&sdp4430_hdmi_device);
+   platform_device_register(&sdp4430_lcd1_device);
+#ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_LCD2
+   platform_device_register(&sdp4430_lcd2_device);
+#endif
/*
 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
 * later have external pull up on the HDMI I2C lines
@@ -278,4 +269,8 @@ void __init omap_4430sdp_display_init_of(void)
sdp4430_picodlp_init();
omap_display_init(&sdp4430_dss_data);
platform_device_register(&sdp4430_hdmi_device);
+   platform_device_register(&sdp4430_lcd1_device);
+#ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_LCD2
+   platform_device_register(&sdp4430_lcd2_device);
+#endif
 }
-- 
1.7.10.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

[PATCH 10/28] ARM: OMAP: Panda: use new TFP410 platform driver

[Tomi Valkeinen]

Use the new TFP410 platform driver instead of the old omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/dss-common.c |   23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 135fdd8..fac4b3e 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -25,6 +25,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -42,19 +43,18 @@
 /* Display DVI */
 #define PANDA_DVI_TFP410_POWER_DOWN_GPIO   0
 
-/* Using generic display panel */
-static struct tfp410_platform_data omap4_dvi_panel = {
+static struct tfp410_platform_data omap4_tfp410_pdata = {
+   .name   = "dvi",
+   .source = "dpi.0",
.i2c_bus_num= 3,
+   .data_lines = 24,
.power_down_gpio= PANDA_DVI_TFP410_POWER_DOWN_GPIO,
 };
 
-static struct omap_dss_device omap4_panda_dvi_device = {
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .name   = "dvi",
-   .driver_name= "tfp410",
-   .data   = &omap4_dvi_panel,
-   .phy.dpi.data_lines = 24,
-   .channel= OMAP_DSS_CHANNEL_LCD2,
+static struct platform_device omap4_panda_tfp410_device = {
+   .name   = "tfp410",
+   .id = 0,
+   .dev.platform_data  = &omap4_tfp410_pdata,
 };
 
 static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
@@ -72,19 +72,19 @@ static struct omap_dss_device  omap4_panda_hdmi_device = {
 };
 
 static struct omap_dss_device *omap4_panda_dss_devices[] = {
-   &omap4_panda_dvi_device,
&omap4_panda_hdmi_device,
 };
 
 static struct omap_dss_board_info omap4_panda_dss_data = {
.num_devices= ARRAY_SIZE(omap4_panda_dss_devices),
.devices= omap4_panda_dss_devices,
-   .default_device = &omap4_panda_dvi_device,
+   .default_display_name = "dvi",
 };
 
 void __init omap4_panda_display_init(void)
 {
omap_display_init(&omap4_panda_dss_data);
+   platform_device_register(&omap4_panda_tfp410_device);
 
/*
 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
@@ -103,6 +103,7 @@ void __init omap4_panda_display_init(void)
 void __init omap4_panda_display_init_of(void)
 {
omap_display_init(&omap4_panda_dss_data);
+   platform_device_register(&omap4_panda_tfp410_device);
 }
 
 
-- 
1.7.10.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

[PATCH 11/28] ARM: OMAP: Panda & SDP: use new HDMI driver

[Tomi Valkeinen]

Change Pandaboard and 4430SDP to use the new HDMI platform driver
instead of the old omap_dss_driver.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/dss-common.c |   31 ---
 1 file changed, 12 insertions(+), 19 deletions(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index fac4b3e..1e2c5c0 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -63,21 +63,13 @@ static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
.hpd_gpio = HDMI_GPIO_HPD,
 };
 
-static struct omap_dss_device  omap4_panda_hdmi_device = {
-   .name = "hdmi",
-   .driver_name = "hdmi_panel",
-   .type = OMAP_DISPLAY_TYPE_HDMI,
-   .channel = OMAP_DSS_CHANNEL_DIGIT,
-   .data = &omap4_panda_hdmi_data,
-};
-
-static struct omap_dss_device *omap4_panda_dss_devices[] = {
-   &omap4_panda_hdmi_device,
+static struct platform_device omap4_panda_hdmi_device = {
+   .name   = "hdmi_panel",
+   .id = 0,
+   .dev.platform_data  = &omap4_panda_hdmi_data,
 };
 
 static struct omap_dss_board_info omap4_panda_dss_data = {
-   .num_devices= ARRAY_SIZE(omap4_panda_dss_devices),
-   .devices= omap4_panda_dss_devices,
.default_display_name = "dvi",
 };
 
@@ -85,6 +77,7 @@ void __init omap4_panda_display_init(void)
 {
omap_display_init(&omap4_panda_dss_data);
platform_device_register(&omap4_panda_tfp410_device);
+   platform_device_register(&omap4_panda_hdmi_device);
 
/*
 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
@@ -104,6 +97,7 @@ void __init omap4_panda_display_init_of(void)
 {
omap_display_init(&omap4_panda_dss_data);
platform_device_register(&omap4_panda_tfp410_device);
+   platform_device_register(&omap4_panda_hdmi_device);
 }
 
 
@@ -115,12 +109,10 @@ static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
.hpd_gpio = HDMI_GPIO_HPD,
 };
 
-static struct omap_dss_device sdp4430_hdmi_device = {
-   .name = "hdmi",
-   .driver_name = "hdmi_panel",
-   .type = OMAP_DISPLAY_TYPE_HDMI,
-   .channel = OMAP_DSS_CHANNEL_DIGIT,
-   .data = &sdp4430_hdmi_data,
+static struct platform_device sdp4430_hdmi_device = {
+   .name   = "hdmi_panel",
+   .id = 0,
+   .dev.platform_data  = &sdp4430_hdmi_data,
 };
 
 #define DISPLAY_SEL_GPIO   59  /* LCD2/PicoDLP switch */
@@ -235,7 +227,6 @@ static struct omap_dss_device *sdp4430_dss_devices[] = {
 #ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_LCD2
&sdp4430_lcd2_device,
 #endif
-   &sdp4430_hdmi_device,
 #ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_PICO
&sdp4430_picodlp_device,
 #endif
@@ -259,6 +250,7 @@ void __init omap_4430sdp_display_init(void)
 
sdp4430_picodlp_init();
omap_display_init(&sdp4430_dss_data);
+   platform_device_register(&sdp4430_hdmi_device);
/*
 * OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
 * later have external pull up on the HDMI I2C lines
@@ -285,4 +277,5 @@ void __init omap_4430sdp_display_init_of(void)
 
sdp4430_picodlp_init();
omap_display_init(&sdp4430_dss_data);
+   platform_device_register(&sdp4430_hdmi_device);
 }
-- 
1.7.10.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

[PATCH 08/28] ARM: OMAP: CM-T35: Kconfig option for the display options

[Tomi Valkeinen]

Boards with multiple display options for the same video bus have all the
possible linux display devices present at the same time. Only one of
those devices should be used at a time, as the video bus cannot be
shared.

This model is hacky, and will be changed in the forthcoming DSS patches
to a model where only one display device can be present on a single
video bus.

This patch creates Kconfig options to select which of the display
devices is present on the board. While this model is also somewhat
hacky, and prevents us from using a single kernel image for all the
display options, it allows us to make the DSS driver changes for DT
adaptation. And with DT, the information about display devices can be
passed from the bootloader, solving the mess.

Signed-off-by: Tomi Valkeinen 
Cc: Mike Rapoport 
Cc: Igor Grinberg 
---
 arch/arm/mach-omap2/Kconfig|   13 ++
 arch/arm/mach-omap2/board-cm-t35.c |   84 +---
 2 files changed, 62 insertions(+), 35 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4108d07..6e73cb4 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -387,6 +387,19 @@ config MACH_CM_T35
select MACH_CM_T3730
select OMAP_PACKAGE_CUS
 
+choice
+   depends on MACH_CM_T35
+   default MACH_CM_T35_EXPANSION_LCD
+   prompt "CM-T35/CM-T3730 video output"
+
+config MACH_CM_T35_EXPANSION_LCD
+   bool "CM-T35/CM-T3730 with LCD"
+
+config MACH_CM_T35_EXPANSION_DVI
+   bool "CM-T35/CM-T3730 with DVI"
+
+endchoice
+
 config MACH_CM_T3517
bool "CompuLab CM-T3517 module"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index 9c1895a..1b34c96 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -187,32 +187,28 @@ static void __init cm_t35_init_nand(void)
 static inline void cm_t35_init_nand(void) {}
 #endif
 
+static struct omap_dss_device cm_t35_tv_device = {
+   .name   = "tv",
+   .driver_name= "venc",
+   .type   = OMAP_DISPLAY_TYPE_VENC,
+   .phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+#if defined(CONFIG_MACH_CM_T35_EXPANSION_LCD)
+
 #define CM_T35_LCD_EN_GPIO 157
 #define CM_T35_LCD_BL_GPIO 58
-#define CM_T35_DVI_EN_GPIO 54
-
-static int lcd_enabled;
-static int dvi_enabled;
 
 static int cm_t35_panel_enable_lcd(struct omap_dss_device *dssdev)
 {
-   if (dvi_enabled) {
-   printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
-   return -EINVAL;
-   }
-
gpio_set_value(CM_T35_LCD_EN_GPIO, 1);
gpio_set_value(CM_T35_LCD_BL_GPIO, 1);
 
-   lcd_enabled = 1;
-
return 0;
 }
 
 static void cm_t35_panel_disable_lcd(struct omap_dss_device *dssdev)
 {
-   lcd_enabled = 0;
-
gpio_set_value(CM_T35_LCD_BL_GPIO, 0);
gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
 }
@@ -231,36 +227,15 @@ static struct omap_dss_device cm_t35_lcd_device = {
.phy.dpi.data_lines = 18,
 };
 
-static struct tfp410_platform_data dvi_panel = {
-   .power_down_gpio= CM_T35_DVI_EN_GPIO,
-   .i2c_bus_num= -1,
-};
-
-static struct omap_dss_device cm_t35_dvi_device = {
-   .name   = "dvi",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "tfp410",
-   .data   = &dvi_panel,
-   .phy.dpi.data_lines = 24,
-};
-
-static struct omap_dss_device cm_t35_tv_device = {
-   .name   = "tv",
-   .driver_name= "venc",
-   .type   = OMAP_DISPLAY_TYPE_VENC,
-   .phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
-};
-
 static struct omap_dss_device *cm_t35_dss_devices[] = {
&cm_t35_lcd_device,
-   &cm_t35_dvi_device,
&cm_t35_tv_device,
 };
 
 static struct omap_dss_board_info cm_t35_dss_data = {
.num_devices= ARRAY_SIZE(cm_t35_dss_devices),
.devices= cm_t35_dss_devices,
-   .default_device = &cm_t35_dvi_device,
+   .default_display_name = "lcd",
 };
 
 static struct omap2_mcspi_device_config tdo24m_mcspi_config = {
@@ -314,6 +289,45 @@ static void __init cm_t35_init_display(void)
}
 }
 
+#elif defined(CONFIG_MACH_CM_T35_EXPANSION_DVI)
+
+#define CM_T35_DVI_EN_GPIO 54
+
+static struct tfp410_platform_data dvi_panel = {
+   .power_down_gpio= CM_T35_DVI_EN_GPIO,
+   .i2c_bus_num= -1,
+};
+
+static struct omap_dss_device cm_t35_dvi_device = {
+   .name   = "dvi",
+   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .driver_name= "tfp410",
+   .data   = &dvi_panel,
+   .phy.dpi.data_lines = 24,
+};
+
+static struct omap_dss_device *cm_t35_dss_devices[] = {
+   &cm_t35_dvi_device,
+   &cm_t35_tv_device,
+};
+
+static str

[PATCH 09/28] ARM: OMAP: AM3517EVM: Kconfig option for the display options

[Tomi Valkeinen]

Boards with multiple display options for the same video bus have all the
possible linux display devices present at the same time. Only one of
those devices should be used at a time, as the video bus cannot be
shared.

This model is hacky, and will be changed in the forthcoming DSS patches
to a model where only one display device can be present on a single
video bus.

This patch creates Kconfig options to select which of the display
devices is present on the board. While this model is also somewhat
hacky, and prevents us from using a single kernel image for all the
display options, it allows us to make the DSS driver changes for DT
adaptation. And with DT, the information about display devices can be
passed from the bootloader, solving the mess.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/Kconfig   |   13 +
 arch/arm/mach-omap2/board-am3517evm.c |   49 ++---
 2 files changed, 40 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 6e73cb4..57e1d37 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -298,6 +298,19 @@ config MACH_OMAP3517EVM
default y
select OMAP_PACKAGE_CBB
 
+choice
+   depends on MACH_OMAP3517EVM
+   default MACH_OMAP3517EVM_EXPANSION_LCD
+   prompt "OMAP3517/ AM3517 EVM video output"
+
+config MACH_OMAP3517EVM_EXPANSION_LCD
+   bool "OMAP3517/ AM3517 EVM with LCD"
+
+config MACH_OMAP3517EVM_EXPANSION_DVI
+   bool "OMAP3517/ AM3517 EVM with DVI"
+
+endchoice
+
 config MACH_CRANEBOARD
bool "AM3517/05 CRANE board"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index 25a0894..1d7d0d8 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -121,11 +121,15 @@ static int __init am3517_evm_i2c_init(void)
return 0;
 }
 
-static int lcd_enabled;
-static int dvi_enabled;
+static struct omap_dss_device am3517_evm_tv_device = {
+   .type   = OMAP_DISPLAY_TYPE_VENC,
+   .name   = "tv",
+   .driver_name= "venc",
+   .phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+#if defined(CONFIG_MACH_OMAP3517EVM_EXPANSION_LCD)
 
-#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
-   defined(CONFIG_PANEL_SHARP_LQ043T1DG01_MODULE)
 static struct gpio am3517_evm_dss_gpios[] __initdata = {
/* GPIO 182 = LCD Backlight Power */
{ LCD_PANEL_BKLIGHT_PWR, GPIOF_OUT_INIT_HIGH, "lcd_backlight_pwr" },
@@ -152,26 +156,16 @@ static void __init am3517_evm_display_init(void)
 
printk(KERN_INFO "Display initialized successfully\n");
 }
-#else
-static void __init am3517_evm_display_init(void) {}
-#endif
 
 static int am3517_evm_panel_enable_lcd(struct omap_dss_device *dssdev)
 {
-   if (dvi_enabled) {
-   printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
-   return -EINVAL;
-   }
gpio_set_value(LCD_PANEL_PWR, 1);
-   lcd_enabled = 1;
-
return 0;
 }
 
 static void am3517_evm_panel_disable_lcd(struct omap_dss_device *dssdev)
 {
gpio_set_value(LCD_PANEL_PWR, 0);
-   lcd_enabled = 0;
 }
 
 static struct panel_generic_dpi_data lcd_panel = {
@@ -188,13 +182,23 @@ static struct omap_dss_device am3517_evm_lcd_device = {
.phy.dpi.data_lines = 16,
 };
 
-static struct omap_dss_device am3517_evm_tv_device = {
-   .type   = OMAP_DISPLAY_TYPE_VENC,
-   .name   = "tv",
-   .driver_name= "venc",
-   .phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
+static struct omap_dss_device *am3517_evm_dss_devices[] = {
+   &am3517_evm_lcd_device,
+   &am3517_evm_tv_device,
+};
+
+static struct omap_dss_board_info am3517_evm_dss_data = {
+   .num_devices= ARRAY_SIZE(am3517_evm_dss_devices),
+   .devices= am3517_evm_dss_devices,
+   .default_display_name = "lcd",
 };
 
+#elif defined(CONFIG_MACH_OMAP3517EVM_EXPANSION_DVI)
+
+static void __init am3517_evm_display_init(void)
+{
+}
+
 static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
.i2c_bus_num= -1,
@@ -209,17 +213,18 @@ static struct omap_dss_device am3517_evm_dvi_device = {
 };
 
 static struct omap_dss_device *am3517_evm_dss_devices[] = {
-   &am3517_evm_lcd_device,
-   &am3517_evm_tv_device,
&am3517_evm_dvi_device,
+   &am3517_evm_tv_device,
 };
 
 static struct omap_dss_board_info am3517_evm_dss_data = {
.num_devices= ARRAY_SIZE(am3517_evm_dss_devices),
.devices= am3517_evm_dss_devices,
-   .default_device = &am3517_evm_lcd_device,
+   .default_display_name = "dvi",
 };
 
+#endif
+
 /*
  * Board initialization
  */
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a

[PATCH 07/28] ARM: OMAP: OMAP3EVM: Kconfig option for the display options

[Tomi Valkeinen]

Boards with multiple display options for the same video bus have all the
possible linux display devices present at the same time. Only one of
those devices should be used at a time, as the video bus cannot be
shared.

This model is hacky, and will be changed in the forthcoming DSS patches
to a model where only one display device can be present on a single
video bus.

This patch creates Kconfig options to select which of the display
devices is present on the board. While this model is also somewhat
hacky, and prevents us from using a single kernel image for all the
display options, it allows us to make the DSS driver changes for DT
adaptation. And with DT, the information about display devices can be
passed from the bootloader, solving the mess.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/Kconfig  |   13 ++
 arch/arm/mach-omap2/board-omap3evm.c |   46 +-
 2 files changed, 41 insertions(+), 18 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 940903e..4108d07 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -279,6 +279,19 @@ config MACH_OMAP3EVM
default y
select OMAP_PACKAGE_CBB
 
+choice
+   depends on MACH_OMAP3EVM
+   default MACH_OMAP3EVM_EXPANSION_LCD
+   prompt "OMAP 3530 EVM video output"
+
+config MACH_OMAP3EVM_EXPANSION_LCD
+   bool "OMAP 3530 EVM with LCD"
+
+config MACH_OMAP3EVM_EXPANSION_DVI
+   bool "OMAP 3530 EVM with DVI"
+
+endchoice
+
 config MACH_OMAP3517EVM
bool "OMAP3517/ AM3517 EVM board"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index e86eb41..2050679 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -149,6 +149,14 @@ static inline void __init omap3evm_init_smsc911x(void)
 static inline void __init omap3evm_init_smsc911x(void) { return; }
 #endif
 
+static struct omap_dss_device omap3_evm_tv_device = {
+   .name   = "tv",
+   .driver_name= "venc",
+   .type   = OMAP_DISPLAY_TYPE_VENC,
+   .phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+#if defined(CONFIG_MACH_OMAP3EVM_EXPANSION_LCD)
 /*
  * OMAP3EVM LCD Panel control signals
  */
@@ -159,7 +167,6 @@ static inline void __init omap3evm_init_smsc911x(void) { 
return; }
 #define OMAP3EVM_LCD_PANEL_QVGA154
 #define OMAP3EVM_LCD_PANEL_RESB155
 #define OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO210
-#define OMAP3EVM_DVI_PANEL_EN_GPIO 199
 
 static struct gpio omap3_evm_dss_gpios[] __initdata = {
{ OMAP3EVM_LCD_PANEL_RESB,  GPIOF_OUT_INIT_HIGH, "lcd_panel_resb"  },
@@ -170,9 +177,6 @@ static struct gpio omap3_evm_dss_gpios[] __initdata = {
{ OMAP3EVM_LCD_PANEL_ENVDD, GPIOF_OUT_INIT_LOW,  "lcd_panel_envdd" },
 };
 
-static int lcd_enabled;
-static int dvi_enabled;
-
 static void __init omap3_evm_display_init(void)
 {
int r;
@@ -185,10 +189,6 @@ static void __init omap3_evm_display_init(void)
 
 static int omap3_evm_enable_lcd(struct omap_dss_device *dssdev)
 {
-   if (dvi_enabled) {
-   printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
-   return -EINVAL;
-   }
gpio_set_value(OMAP3EVM_LCD_PANEL_ENVDD, 0);
 
if (get_omap3_evm_rev() >= OMAP3EVM_BOARD_GEN_2)
@@ -196,7 +196,6 @@ static int omap3_evm_enable_lcd(struct omap_dss_device 
*dssdev)
else
gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
 
-   lcd_enabled = 1;
return 0;
 }
 
@@ -208,8 +207,6 @@ static void omap3_evm_disable_lcd(struct omap_dss_device 
*dssdev)
gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
else
gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 0);
-
-   lcd_enabled = 0;
 }
 
 static struct omap_dss_device omap3_evm_lcd_device = {
@@ -221,13 +218,25 @@ static struct omap_dss_device omap3_evm_lcd_device = {
.platform_disable   = omap3_evm_disable_lcd,
 };
 
-static struct omap_dss_device omap3_evm_tv_device = {
-   .name   = "tv",
-   .driver_name= "venc",
-   .type   = OMAP_DISPLAY_TYPE_VENC,
-   .phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
+static struct omap_dss_device *omap3_evm_dss_devices[] = {
+   &omap3_evm_lcd_device,
+   &omap3_evm_tv_device,
 };
 
+static struct omap_dss_board_info omap3_evm_dss_data = {
+   .num_devices= ARRAY_SIZE(omap3_evm_dss_devices),
+   .devices= omap3_evm_dss_devices,
+   .default_display_name = "lcd",
+};
+
+#elif defined(CONFIG_MACH_OMAP3EVM_EXPANSION_DVI)
+
+#define OMAP3EVM_DVI_PANEL_EN_GPIO 199
+
+static void __init omap3_evm_display_init(void)
+{
+}
+
 static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= OMAP3

[PATCH 04/28] ARM: OMAP: 3430SDP: Kconfig option for the display options

[Tomi Valkeinen]

Boards with multiple display options for the same video bus have all the
possible linux display devices present at the same time. Only one of
those devices should be used at a time, as the video bus cannot be
shared.

This model is hacky, and will be changed in the forthcoming DSS patches
to a model where only one display device can be present on a single
video bus.

This patch creates Kconfig options to select which of the display
devices is present on the board. While this model is also somewhat
hacky, and prevents us from using a single kernel image for all the
display options, it allows us to make the DSS driver changes for DT
adaptation. And with DT, the information about display devices can be
passed from the bootloader, solving the mess.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/Kconfig |   13 
 arch/arm/mach-omap2/board-3430sdp.c |   63 +++
 2 files changed, 54 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f30aadb..17e02a3 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -296,6 +296,19 @@ config MACH_OMAP_3430SDP
default y
select OMAP_PACKAGE_CBB
 
+choice
+   depends on MACH_OMAP_3430SDP
+   default MACH_OMAP_3430SDP_EXPANSION_LCD
+   prompt "OMAP 3430 SDP video output"
+
+config MACH_OMAP_3430SDP_EXPANSION_LCD
+   bool "OMAP 3430 SDP with LCD"
+
+config MACH_OMAP_3430SDP_EXPANSION_DVI
+   bool "OMAP 3430 SDP with DVI"
+
+endchoice
+
 config MACH_NOKIA_N800
bool
 
diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index 5fdb382..4acd4aa 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -105,6 +105,45 @@ static struct twl4030_keypad_data sdp3430_kp_data = {
.rep= 1,
 };
 
+static struct omap_dss_device sdp3430_tv_device = {
+   .name   = "tv",
+   .driver_name= "venc",
+   .type   = OMAP_DISPLAY_TYPE_VENC,
+   .phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+#if defined(CONFIG_MACH_OMAP_3430SDP_EXPANSION_DVI)
+
+static void __init sdp3430_display_init(void)
+{
+}
+
+static struct tfp410_platform_data dvi_panel = {
+   .power_down_gpio= -1,
+   .i2c_bus_num= -1,
+};
+
+static struct omap_dss_device sdp3430_dvi_device = {
+   .name   = "dvi",
+   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .driver_name= "tfp410",
+   .data   = &dvi_panel,
+   .phy.dpi.data_lines = 24,
+};
+
+static struct omap_dss_device *sdp3430_dss_devices[] = {
+   &sdp3430_dvi_device,
+   &sdp3430_tv_device,
+};
+
+static struct omap_dss_board_info sdp3430_dss_data = {
+   .num_devices= ARRAY_SIZE(sdp3430_dss_devices),
+   .devices= sdp3430_dss_devices,
+   .default_device = &sdp3430_dvi_device,
+};
+
+#elif defined(CONFIG_MACH_OMAP_3430SDP_EXPANSION_LCD)
+
 #define SDP3430_LCD_PANEL_BACKLIGHT_GPIO   8
 #define SDP3430_LCD_PANEL_ENABLE_GPIO  5
 
@@ -147,30 +186,8 @@ static struct omap_dss_device sdp3430_lcd_device = {
.platform_disable   = sdp3430_panel_disable_lcd,
 };
 
-static struct tfp410_platform_data dvi_panel = {
-   .power_down_gpio= -1,
-   .i2c_bus_num= -1,
-};
-
-static struct omap_dss_device sdp3430_dvi_device = {
-   .name   = "dvi",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "tfp410",
-   .data   = &dvi_panel,
-   .phy.dpi.data_lines = 24,
-};
-
-static struct omap_dss_device sdp3430_tv_device = {
-   .name   = "tv",
-   .driver_name= "venc",
-   .type   = OMAP_DISPLAY_TYPE_VENC,
-   .phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
-};
-
-
 static struct omap_dss_device *sdp3430_dss_devices[] = {
&sdp3430_lcd_device,
-   &sdp3430_dvi_device,
&sdp3430_tv_device,
 };
 
@@ -180,6 +197,8 @@ static struct omap_dss_board_info sdp3430_dss_data = {
.default_device = &sdp3430_lcd_device,
 };
 
+#endif
+
 static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
-- 
1.7.10.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

[PATCH 05/28] ARM: OMAP: 4430SDP: Kconfig option for the display options

[Tomi Valkeinen]

Boards with multiple display options for the same video bus have all the
possible linux display devices present at the same time. Only one of
those devices should be used at a time, as the video bus cannot be
shared.

This model is hacky, and will be changed in the forthcoming DSS patches
to a model where only one display device can be present on a single
video bus.

This patch creates Kconfig options to select which of the display
devices is present on the board. While this model is also somewhat
hacky, and prevents us from using a single kernel image for all the
display options, it allows us to make the DSS driver changes for DT
adaptation. And with DT, the information about display devices can be
passed from the bootloader, solving the mess.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/Kconfig  |   13 +
 arch/arm/mach-omap2/dss-common.c |   39 +-
 2 files changed, 39 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 17e02a3..fcbcd6c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -413,6 +413,19 @@ config MACH_OMAP_4430SDP
select OMAP_PACKAGE_CBS
select REGULATOR_FIXED_VOLTAGE if REGULATOR
 
+choice
+   depends on MACH_OMAP_4430SDP
+   default MACH_OMAP_4430SDP_EXPANSION_LCD2
+   prompt "OMAP 4430 SDP video output"
+
+config MACH_OMAP_4430SDP_EXPANSION_LCD2
+   bool "OMAP 4430 SDP with second LCD panel"
+
+config MACH_OMAP_4430SDP_EXPANSION_PICO
+   bool "OMAP 4430 SDP with Pico DLP projector"
+
+endchoice
+
 config MACH_OMAP4_PANDA
bool "OMAP4 Panda Board"
default y
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 4228e57..135fdd8 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -108,8 +108,21 @@ void __init omap4_panda_display_init_of(void)
 
 /* OMAP4 Blaze display data */
 
+static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
+   .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
+   .ls_oe_gpio = HDMI_GPIO_LS_OE,
+   .hpd_gpio = HDMI_GPIO_HPD,
+};
+
+static struct omap_dss_device sdp4430_hdmi_device = {
+   .name = "hdmi",
+   .driver_name = "hdmi_panel",
+   .type = OMAP_DISPLAY_TYPE_HDMI,
+   .channel = OMAP_DSS_CHANNEL_DIGIT,
+   .data = &sdp4430_hdmi_data,
+};
+
 #define DISPLAY_SEL_GPIO   59  /* LCD2/PicoDLP switch */
-#define DLP_POWER_ON_GPIO  40
 
 static struct nokia_dsi_panel_data dsi1_panel = {
.name   = "taal",
@@ -134,6 +147,10 @@ static struct omap_dss_device sdp4430_lcd_device = {
.channel= OMAP_DSS_CHANNEL_LCD,
 };
 
+#if defined(CONFIG_MACH_OMAP_4430SDP_EXPANSION_LCD2)
+
+static void sdp4430_picodlp_init(void) { }
+
 static struct nokia_dsi_panel_data dsi2_panel = {
.name   = "taal",
.reset_gpio = 104,
@@ -158,19 +175,9 @@ static struct omap_dss_device sdp4430_lcd2_device = {
.channel= OMAP_DSS_CHANNEL_LCD2,
 };
 
-static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
-   .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
-   .ls_oe_gpio = HDMI_GPIO_LS_OE,
-   .hpd_gpio = HDMI_GPIO_HPD,
-};
+#elif defined(CONFIG_MACH_OMAP_4430SDP_EXPANSION_PICO)
 
-static struct omap_dss_device sdp4430_hdmi_device = {
-   .name = "hdmi",
-   .driver_name = "hdmi_panel",
-   .type = OMAP_DISPLAY_TYPE_HDMI,
-   .channel = OMAP_DSS_CHANNEL_DIGIT,
-   .data = &sdp4430_hdmi_data,
-};
+#define DLP_POWER_ON_GPIO  40
 
 static struct picodlp_panel_data sdp4430_picodlp_pdata = {
.picodlp_adapter_id = 2,
@@ -220,11 +227,17 @@ static struct omap_dss_device sdp4430_picodlp_device = {
.data   = &sdp4430_picodlp_pdata,
 };
 
+#endif
+
 static struct omap_dss_device *sdp4430_dss_devices[] = {
&sdp4430_lcd_device,
+#ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_LCD2
&sdp4430_lcd2_device,
+#endif
&sdp4430_hdmi_device,
+#ifdef CONFIG_MACH_OMAP_4430SDP_EXPANSION_PICO
&sdp4430_picodlp_device,
+#endif
 };
 
 static struct omap_dss_board_info sdp4430_dss_data = {
-- 
1.7.10.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

[PATCH 03/28] ARM: OMAP: Overo: Kconfig option for the display options

[Tomi Valkeinen]

Boards with multiple display options for the same video bus have all the
possible linux display devices present at the same time. Only one of
those devices should be used at a time, as the video bus cannot be
shared.

This model is hacky, and will be changed in the forthcoming DSS patches
to a model where only one display device can be present on a single
video bus.

This patch creates Kconfig options to select which of the display
devices is present on the board. While this model is also somewhat
hacky, and prevents us from using a single kernel image for all the
display options, it allows us to make the DSS driver changes for DT
adaptation. And with DT, the information about display devices can be
passed from the bootloader, solving the mess.

Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/Kconfig   |   22 ++
 arch/arm/mach-omap2/board-overo.c |  134 +++--
 2 files changed, 107 insertions(+), 49 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8111cd9..f30aadb 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -238,6 +238,28 @@ config MACH_OVERO
default y
select OMAP_PACKAGE_CBB
 
+choice
+   depends on MACH_OVERO
+   default MACH_OVERO_EXPANSION_PALO43
+   prompt "Overo Expansion Board"
+
+config MACH_OVERO_EXPANSION_PALO43
+   bool "Gumstix Overo Palo43 Expansion Board"
+   help
+ Palo43 Expansion board with Samsung 4.3" 480x272 LCD.
+
+config MACH_OVERO_EXPANSION_PALO35
+   bool "Gumstix Overo Palo35 Expansion Board"
+   help
+ Palo35 Expansion board with LG 3.5" 320x240 LCD.
+
+config MACH_OVERO_EXPANSION_SUMMIT
+   bool "Gumstix Overo Summit Expansion Board"
+   help
+ Summit expansion board with DVI output.
+
+endchoice
+
 config MACH_OMAP3EVM
bool "OMAP 3530 EVM board"
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/board-overo.c 
b/arch/arm/mach-omap2/board-overo.c
index 86bab51..3253682 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -145,13 +145,72 @@ static void __init overo_init_smsc911x(void)
 static inline void __init overo_init_smsc911x(void) { return; }
 #endif
 
-/* DSS */
-static int lcd_enabled;
-static int dvi_enabled;
+#if defined(CONFIG_MACH_OVERO_EXPANSION_SUMMIT)
+
+static struct tfp410_platform_data dvi_panel = {
+   .i2c_bus_num= 3,
+   .power_down_gpio= -1,
+};
+
+static struct omap_dss_device overo_dvi_device = {
+   .name   = "dvi",
+   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .driver_name= "tfp410",
+   .data   = &dvi_panel,
+   .phy.dpi.data_lines = 24,
+};
+
+static struct omap_dss_device *overo_dss_devices[] = {
+   &overo_dvi_device,
+};
+
+static struct omap_dss_board_info overo_dss_data = {
+   .num_devices= ARRAY_SIZE(overo_dss_devices),
+   .devices= overo_dss_devices,
+   .default_display_name = "dvi",
+};
+
+static void __init overo_display_init(void)
+{
+}
+
+#elif defined(CONFIG_MACH_OVERO_EXPANSION_PALO35)
 
 #define OVERO_GPIO_LCD_EN 144
 #define OVERO_GPIO_LCD_BL 145
 
+static int overo_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+   gpio_set_value(OVERO_GPIO_LCD_EN, 1);
+   gpio_set_value(OVERO_GPIO_LCD_BL, 1);
+   return 0;
+}
+
+static void overo_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+   gpio_set_value(OVERO_GPIO_LCD_EN, 0);
+   gpio_set_value(OVERO_GPIO_LCD_BL, 0);
+}
+
+static struct omap_dss_device overo_lcd35_device = {
+   .type   = OMAP_DISPLAY_TYPE_DPI,
+   .name   = "lcd35",
+   .driver_name= "lgphilips_lb035q02_panel",
+   .phy.dpi.data_lines = 24,
+   .platform_enable= overo_panel_enable_lcd,
+   .platform_disable   = overo_panel_disable_lcd,
+};
+
+static struct omap_dss_device *overo_dss_devices[] = {
+   &overo_lcd35_device,
+};
+
+static struct omap_dss_board_info overo_dss_data = {
+   .num_devices= ARRAY_SIZE(overo_dss_devices),
+   .devices= overo_dss_devices,
+   .default_display_name = "lcd35",
+};
+
 static struct gpio overo_dss_gpios[] __initdata = {
{ OVERO_GPIO_LCD_EN, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_EN" },
{ OVERO_GPIO_LCD_BL, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_BL" },
@@ -168,36 +227,15 @@ static void __init overo_display_init(void)
gpio_export(OVERO_GPIO_LCD_BL, 0);
 }
 
-static struct tfp410_platform_data dvi_panel = {
-   .i2c_bus_num= 3,
-   .power_down_gpio= -1,
-};
+#elif defined(CONFIG_MACH_OVERO_EXPANSION_PALO43)
 
-static struct omap_dss_device overo_dvi_device = {
-   .name   = "dvi",
-   .type   = OMAP_DISPLAY_TYPE_DPI,
-   .driver_name= "tfp410",
-   .data  

[PATCH 01/28] ARM: OMAP: Remove unnecessary platform callbacks for VENC devices

[Tomi Valkeinen]

From: Archit Taneja 

The omap_dss_device's platform_enable/disable callbacks don't do anything for
any of the boards. The platform calls from the VENC driver will also be removed
in the future. Remove these calls from boards which have a VENC device.

Signed-off-by: Archit Taneja 
Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/board-3430sdp.c  |   12 
 arch/arm/mach-omap2/board-am3517evm.c|   11 ---
 arch/arm/mach-omap2/board-cm-t35.c   |   11 ---
 arch/arm/mach-omap2/board-omap3evm.c |   11 ---
 arch/arm/mach-omap2/board-omap3stalker.c |   11 ---
 5 files changed, 56 deletions(-)

diff --git a/arch/arm/mach-omap2/board-3430sdp.c 
b/arch/arm/mach-omap2/board-3430sdp.c
index ce812de..5fdb382 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -138,16 +138,6 @@ static void sdp3430_panel_disable_lcd(struct 
omap_dss_device *dssdev)
gpio_direction_output(SDP3430_LCD_PANEL_BACKLIGHT_GPIO, 0);
 }
 
-static int sdp3430_panel_enable_tv(struct omap_dss_device *dssdev)
-{
-   return 0;
-}
-
-static void sdp3430_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
-
 static struct omap_dss_device sdp3430_lcd_device = {
.name   = "lcd",
.driver_name= "sharp_ls_panel",
@@ -175,8 +165,6 @@ static struct omap_dss_device sdp3430_tv_device = {
.driver_name= "venc",
.type   = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
-   .platform_enable= sdp3430_panel_enable_tv,
-   .platform_disable   = sdp3430_panel_disable_tv,
 };
 
 
diff --git a/arch/arm/mach-omap2/board-am3517evm.c 
b/arch/arm/mach-omap2/board-am3517evm.c
index 9fb8590..25a0894 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -188,22 +188,11 @@ static struct omap_dss_device am3517_evm_lcd_device = {
.phy.dpi.data_lines = 16,
 };
 
-static int am3517_evm_panel_enable_tv(struct omap_dss_device *dssdev)
-{
-   return 0;
-}
-
-static void am3517_evm_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
 static struct omap_dss_device am3517_evm_tv_device = {
.type   = OMAP_DISPLAY_TYPE_VENC,
.name   = "tv",
.driver_name= "venc",
.phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
-   .platform_enable= am3517_evm_panel_enable_tv,
-   .platform_disable   = am3517_evm_panel_disable_tv,
 };
 
 static struct tfp410_platform_data dvi_panel = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c 
b/arch/arm/mach-omap2/board-cm-t35.c
index af2bb21..9c1895a 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -217,15 +217,6 @@ static void cm_t35_panel_disable_lcd(struct 
omap_dss_device *dssdev)
gpio_set_value(CM_T35_LCD_EN_GPIO, 0);
 }
 
-static int cm_t35_panel_enable_tv(struct omap_dss_device *dssdev)
-{
-   return 0;
-}
-
-static void cm_t35_panel_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
 static struct panel_generic_dpi_data lcd_panel = {
.name   = "toppoly_tdo35s",
.platform_enable= cm_t35_panel_enable_lcd,
@@ -258,8 +249,6 @@ static struct omap_dss_device cm_t35_tv_device = {
.driver_name= "venc",
.type   = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
-   .platform_enable= cm_t35_panel_enable_tv,
-   .platform_disable   = cm_t35_panel_disable_tv,
 };
 
 static struct omap_dss_device *cm_t35_dss_devices[] = {
diff --git a/arch/arm/mach-omap2/board-omap3evm.c 
b/arch/arm/mach-omap2/board-omap3evm.c
index 48789e0..e86eb41 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -221,22 +221,11 @@ static struct omap_dss_device omap3_evm_lcd_device = {
.platform_disable   = omap3_evm_disable_lcd,
 };
 
-static int omap3_evm_enable_tv(struct omap_dss_device *dssdev)
-{
-   return 0;
-}
-
-static void omap3_evm_disable_tv(struct omap_dss_device *dssdev)
-{
-}
-
 static struct omap_dss_device omap3_evm_tv_device = {
.name   = "tv",
.driver_name= "venc",
.type   = OMAP_DISPLAY_TYPE_VENC,
.phy.venc.type  = OMAP_DSS_VENC_TYPE_SVIDEO,
-   .platform_enable= omap3_evm_enable_tv,
-   .platform_disable   = omap3_evm_disable_tv,
 };
 
 static struct tfp410_platform_data dvi_panel = {
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c 
b/arch/arm/mach-omap2/board-omap3stalker.c
index 95c10b3..d427240 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -95,15 +95,6 @@ static void __init omap3_stalker_display_init(void)
return;
 }
 
-static int

[PATCH 02/28] ARM: OMAP: don't use reset_gpio from omap4_panda_dvi_device

[Tomi Valkeinen]

From: Archit Taneja 

gpio reset info is passed to the tfp410 panel driver via the panel's platform
data struct 'tfp410_platform_data'. The tfp driver doesn't use the reset_gpio
field in the omap4_panda_dvi_device struct. Remove this field.

Signed-off-by: Archit Taneja 
Signed-off-by: Tomi Valkeinen 
---
 arch/arm/mach-omap2/dss-common.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 4be5cfc..4228e57 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -54,7 +54,6 @@ static struct omap_dss_device omap4_panda_dvi_device = {
.driver_name= "tfp410",
.data   = &omap4_dvi_panel,
.phy.dpi.data_lines = 24,
-   .reset_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
.channel= OMAP_DSS_CHANNEL_LCD2,
 };
 
-- 
1.7.10.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

[PATCH 00/28] OMAP: DSS related board file changes

[Tomi Valkeinen]

So here are the DSS related board file changes for 3.10.

First there are a bunch of patches adding the Kconfig options so that only one
display device is created for a single video bus. Only Overo had more than two
displays on the same bus, but unfortunately there were multiple boards with a
setup that puts an LCD and DVI output on the same video bus.

So the ifdeffery is not very nice. But, as discussed, this is the best way
forward, and should be seen as a temporary solution until we get full DT
support.

Then the rest are converting the old omap_dss_device style displays to platform
devices. Only TFP410, generic-dpi-panel, HDMI and Taal drivers have been
converted yet, but those seem to form the bulk of the display options used.

This series can be found from:
git://gitorious.org/linux-omap-dss2/linux.git 3.10-lo/1-arch-dss

These patches depend on a few dss header file changes. These header file
changes can be found from:
git://gitorious.org/linux-omap-dss2/linux.git 3.10/0-dss-headers

If this series is applied without the relevant omapdss changes, everything
compiles and the boards boot, but the converted displays do not work. The same
happens if only the omapdss changes are applied, but not this series.

The related omapdss changes can be found from:
git://gitorious.org/linux-omap-dss2/linux.git 3.10/3-dss-dev-model

 Tomi

Archit Taneja (2):
  ARM: OMAP: Remove unnecessary platform callbacks for VENC devices
  ARM: OMAP: don't use reset_gpio from omap4_panda_dvi_device

Tomi Valkeinen (26):
  ARM: OMAP: Overo: Kconfig option for the display options
  ARM: OMAP: 3430SDP: Kconfig option for the display options
  ARM: OMAP: 4430SDP: Kconfig option for the display options
  ARM: OMAP: DEVKIT8000: Kconfig option for the display options
  ARM: OMAP: OMAP3EVM: Kconfig option for the display options
  ARM: OMAP: CM-T35: Kconfig option for the display options
  ARM: OMAP: AM3517EVM: Kconfig option for the display options
  ARM: OMAP: Panda: use new TFP410 platform driver
  ARM: OMAP: Panda & SDP: use new HDMI driver
  ARM: OMAP: 4430SDP: use new Taal driver
  ARM: OMAP: Beagle: use new TFP410 platform driver
  ARM: OMAP: Stalker: use new TFP410 platform driver
  ARM: OMAP: OMAP3EVM: use new TFP410 platform driver
  ARM: OMAP: IGEP0020: use new TFP410 platform driver
  ARM: OMAP: Devkit8000: use new TFP410 platform driver
  ARM: OMAP: CM-T35: use new TFP410 platform driver
  ARM: OMAP: AM3517EVM: use new TFP410 platform driver
  ARM: OMAP: 3430SDP: use new TFP410 platform driver
  ARM: OMAP: Overo: use new TFP410 platform driver
  ARM: OMAP: Overo: use new generic-dpi-panel platform driver
  ARM: OMAP: LDP: use new generic-dpi-panel platform driver
  ARM: OMAP: H4: use new generic-dpi-panel platform driver
  ARM: OMAP: Devkit8000: use new generic-dpi-panel platform driver
  ARM: OMAP: CM-T35: use new generic-dpi-panel platform driver
  ARM: OMAP: AM3517EVM: use new generic-dpi-panel platform driver
  ARM: OMAP: 2430SDP: use new generic-dpi-panel platform driver

 arch/arm/mach-omap2/Kconfig  |  100 
 arch/arm/mach-omap2/board-2430sdp.c  |   24 ++---
 arch/arm/mach-omap2/board-3430sdp.c  |   78 +---
 arch/arm/mach-omap2/board-am3517evm.c|   86 -
 arch/arm/mach-omap2/board-cm-t35.c   |  113 +++---
 arch/arm/mach-omap2/board-devkit8000.c   |  106 +
 arch/arm/mach-omap2/board-h4.c   |   24 ++---
 arch/arm/mach-omap2/board-igep0020.c |   22 ++---
 arch/arm/mach-omap2/board-ldp.c  |   22 ++---
 arch/arm/mach-omap2/board-omap3beagle.c  |   25 ++---
 arch/arm/mach-omap2/board-omap3evm.c |   70 +++---
 arch/arm/mach-omap2/board-omap3stalker.c |   28 ++
 arch/arm/mach-omap2/board-overo.c|  149 ++
 arch/arm/mach-omap2/dss-common.c |  125 -
 14 files changed, 561 insertions(+), 411 deletions(-)

-- 
1.7.10.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: [PATCH-V2 0/6] ARM: dts: AM33XX: Cleanup and pinctrl binding support

[Benoit Cousson]

Hi Vaibhav,

The series looks good to me, but unfortunately does not apply cleanly on
top of the latest for_3.10/dts branch.

Could you rebase it?

Thanks,
Benoit

On 03/28/2013 07:42 AM, Vaibhav Hiremath wrote:
> This patch series fixes the numbering schema for I2C and GPIO
> module and adds the pin-control binding for I2C, UART, GPIO-LED across
> supported platforms (EVM, EVM-SK and Bone).
> 
> I have divided patches based on functionality and _not_
> into EVM/Board perspective.
> 
> Changes from V1: (no code change from last version, except uart)
>   - Added Acked-by from Matt Porter and Peter Korsgaard
> on couple of patches.
>   - Added new patch (PATCH 5/6) in the series for UART
> indexing fix
> 
> Vaibhav Hiremath (6):
>   ARM: dts: AM33XX: Fix the i2c numbering to match hardware/TRM
>   ARM: dts: AM33XX: Add default pinctrl binding for I2C device
>   ARM: dts: AM33XX: Fix gpio numbering to match hardware/TRM
>   ARM: dts: AM33XX: Add pinctrl binding to gpio-leds node
>   ARM: dts: AM33XX: Fix uart numbering to match hardware/TRM
>   ARM: dts: AM33XX: Add default pinctrl binding for UART0 device
> 
>  arch/arm/boot/dts/am335x-bone.dts  |   37 +-
>  arch/arm/boot/dts/am335x-evm.dts   |   50 ---
>  arch/arm/boot/dts/am335x-evmsk.dts |   45 
>  arch/arm/boot/dts/am33xx.dtsi  |   38 +-
>  4 files changed, 123 insertions(+), 47 deletions(-)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PULL] fbdev fixes for 3.9

[Tomi Valkeinen]

Hi Linus,

Since Florian is still away/inactive, I volunteered to collect fbdev fixes for
3.9 and changes for 3.10. I didn't receive any other fbdev fixes than OMAP yet,
but I didn't want to delay this further as there's a compilation fix for OMAP1.
So there could be still some fbdev fixes on the way a bit later.

 Tomi

The following changes since commit a937536b868b8369b98967929045f1df54234323:

  Linux 3.9-rc3 (2013-03-17 15:59:32 -0700)

are available in the git repository at:

  git://gitorious.org/linux-omap-dss2/linux.git tags/fbdev-fixes-3.9-rc4

for you to fetch changes up to ff588d83bf12fe05521a64e85dd4e2b848c0b20d:

  omapdss: features: fix supported outputs for OMAP4 (2013-03-22 10:14:32 +0200)


* Fix OMAP1 compilation
* OMAP display fixes


Aaro Koskinen (1):
  omapfb: fix broken build on OMAP1

Archit Taneja (1):
  omapdss: features: fix supported outputs for OMAP4

Grazvydas Ignotas (1):
  OMAPDSS: tpo-td043 panel: fix data passing between SPI/DSS parts

 drivers/video/omap/omapfb_main.c|2 ++
 drivers/video/omap2/displays/panel-tpo-td043mtea1.c |   13 +++--
 drivers/video/omap2/dss/dss_features.c  |6 ++
 3 files changed, 15 insertions(+), 6 deletions(-)



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] ARM: dts: AM33XX: Corrects typo in interrupt field in SPI node

[Benoit Cousson]

Hi Philip,

On 02/01/2013 06:37 AM, Philip Avinash wrote:
> DT field of "interrupts" was mentioned wrongly as "interrupt" in SPI
> node. This went unnoticed as spi-omap2 driver not making use of
> interrupt. Fixes the typo.
> 
> Signed-off-by: Philip Avinash 
> ---
>  arch/arm/boot/dts/am33xx.dtsi |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index fbcb90b..cece3ad 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -309,7 +309,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   reg = <0x4803 0x400>;
> - interrupt = <65>;
> + interrupts = <65>;
>   ti,spi-num-cs = <2>;
>   ti,hwmods = "spi0";
>   status = "disabled";
> @@ -320,7 +320,7 @@
>   #address-cells = <1>;
>   #size-cells = <0>;
>   reg = <0x481a 0x400>;
> - interrupt = <125>;
> + interrupts = <125>;
>   ti,spi-num-cs = <2>;
>   ti,hwmods = "spi1";
>   status = "disabled";
> 

Thanks for the fix. Applied with Peter Acked-by. It will be available in the 
following branch:

git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git 
for_3.10/dts

Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()

[Santosh Shilimkar]

On Thursday 28 March 2013 05:34 PM, Russell King - ARM Linux wrote:
> On Thu, Mar 28, 2013 at 03:28:12PM +0530, Santosh Shilimkar wrote:
>> On Thursday 28 March 2013 03:16 PM, Russell King - ARM Linux wrote:
>>> On Thu, Mar 28, 2013 at 12:34:50AM +0530, Santosh Shilimkar wrote:
 On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
> Santosh Shilimkar  writes:
>
>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 
>
> Why?
>
 Because that code belongs to smp_prepare_cpus(). As I said
 in earlier patches, it was remainder of the pen release code
 which was borrowed from ARM code initially.
>>>
>>> What about hotplug after the system is suspended?  Is this setup
>>> preserved by the secure ROM?
>>>
>>> If not, it really needs to be part of the CPU bringup, not the
>>> boot-time-only preparation code.
>>>
>> Its already the case. Hotplug CPU restarts just like CPU bring-up.
>> Initial code, hotplug cpu and last cpu(suspend) were taking identical
>> path for the suspend wakeup. Later you suggested after the discussion
>> that hotplug CPU state need not be saved and can be restarted just like
>> the CPU bring-up path.
>>
>> So the current code follows above.
> 
> smp_prepare_cpus() doesn't get run apart from at initial boot.
> 
> So, I repeat my question: what restores OMAP_AUX_CORE_BOOT_1 after
> context loss?
> 
Sorry I missed your point. OMAP_AUX_CORE_BOOT_* registers
are maintained across power transitions.

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 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()

[Russell King - ARM Linux]

On Thu, Mar 28, 2013 at 03:28:12PM +0530, Santosh Shilimkar wrote:
> On Thursday 28 March 2013 03:16 PM, Russell King - ARM Linux wrote:
> > On Thu, Mar 28, 2013 at 12:34:50AM +0530, Santosh Shilimkar wrote:
> >> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
> >>> Santosh Shilimkar  writes:
> >>>
>  Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 
> >>>
> >>> Why?
> >>>
> >> Because that code belongs to smp_prepare_cpus(). As I said
> >> in earlier patches, it was remainder of the pen release code
> >> which was borrowed from ARM code initially.
> > 
> > What about hotplug after the system is suspended?  Is this setup
> > preserved by the secure ROM?
> >
> > If not, it really needs to be part of the CPU bringup, not the
> > boot-time-only preparation code.
> >
> Its already the case. Hotplug CPU restarts just like CPU bring-up.
> Initial code, hotplug cpu and last cpu(suspend) were taking identical
> path for the suspend wakeup. Later you suggested after the discussion
> that hotplug CPU state need not be saved and can be restarted just like
> the CPU bring-up path.
> 
> So the current code follows above.

smp_prepare_cpus() doesn't get run apart from at initial boot.

So, I repeat my question: what restores OMAP_AUX_CORE_BOOT_1 after
context loss?
--
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: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'

[Dietmar Eggemann]

On 19/03/13 10:28, Will Deacon wrote:

On Tue, Mar 19, 2013 at 06:39:38AM +, Santosh Shilimkar wrote:

On Monday 18 March 2013 10:36 PM, Will Deacon wrote:

Any chance you could follow up with your firmware/hardware guys about this
please? I'd really like to understand how we end up in this state in case we
can do something in the architecture to stop it from happening in future.


I will check on this part and update you when I hear from them.


Ok, thanks.

Dietmar -- I seem to remember that you thought GDB did actually work with
hardware breakpoints on Pandaboard across low-power states. Can you
confirm/deny this please?


Sorry for the late response.

I did some testing on my Pandaboard trying to set hwbp from gdb.

System is a vanilla Linaro 13.02.
gdb is (GNU gdb (GDB) 7.5.1), build from tag gdb_7_5_1-2012-11-29-release

(gdb) hb *0x8440
Hardware assisted breakpoint 2 at 0x8440: file test.c, line 14.
(gdb) c
Continuing.
Unexpected error setting breakpoint address: No such device.

With additional kernel logs:

[] (unwind_backtrace+0x1/0x92) from []
(arch_validate_hwbkpt_settings+0x23/0x1d4)
[] (arch_validate_hwbkpt_settings+0x23/0x1d4) from
[] (register_perf_hw_breakpoint+0x19/0x30)
[] (register_perf_hw_breakpoint+0x19/0x30) from []
(hw_breakpoint_event_init+0x29/0x48)
[] (hw_breakpoint_event_init+0x29/0x48) from []
(perf_init_event+0x79/0xcc)
[] (perf_init_event+0x79/0xcc) from []
(perf_event_alloc+0x1c3/0x32c)
[] (perf_event_alloc+0x1c3/0x32c) from []
(perf_event_create_kernel_counter+0x19/0xc6)
[] (perf_event_create_kernel_counter+0x19/0xc6) from
[] (register_user_hw_breakpoint+0x2d/0x38)
[] (register_user_hw_breakpoint+0x2d/0x38) from []
(ptrace_hbp_create+0x53/0x5c)
[] (ptrace_hbp_create+0x53/0x5c) from []
(ptrace_sethbpregs+0x95/0x1a6)
[] (ptrace_sethbpregs+0x95/0x1a6) from []
(arch_ptrace+0x3bf/0x3ec)
[] (arch_ptrace+0x3bf/0x3ec) from []
(sys_ptrace+0x251/0x278)
[] (sys_ptrace+0x251/0x278) from []
(ret_fast_syscall+0x1/0x52)
perf_event_create_kernel_counter:6721 ret=-19
ptrace_sethbpregs:557 ret=-19

The call to monitor_mode_enabled() in arch_validate_hwbkpt_settings()
fails since DSCR.15 MDBGen is not set:

monitor_mode_enabled:239 dscr=0x1030002

I don't get the warning "Failed to enable monitor mode on CPU" during
system start-up though.

Doing the same on my TC2 gives me:

monitor_mode_enabled:239 dscr=0x2008002

So I guess that setting hwbp from self-hosted debugger on Pandaboard is
not possible at all.

There is no CPUidle enabled on Linaro 13.02 Pandaboard.

-- Dietmar





Well, we could just add the warn_once prints but that doesn't stop debug
from breaking after the first pm/suspend/hotplug operation.


Probably we should drop the $subject patch approach and use warn_once
at least for current rc. Ofcourse it doesn't help to get working
hw_breakpoint support. Patch end of the email with warn_once.


Yeah, I'll merge that, but it's a real shame that this breaks hardware debug
on one of the few platforms where it was reported to work.

Will



-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

--
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: regarding arm: update ARM_ERRATA_430973 Kconfig

[Tim Niemeyer]

Hi

Am Dienstag, den 26.03.2013, 12:57 +0100 schrieb Peter Meerwald:
> regarding your patch against arch/arm/Kconfig:
> 
> @@ -1215,7 +1215,7 @@  config ARM_ERRATA_430973
>   depends on CPU_V7
>   help
> This option enables the workaround for the 430973 Cortex-A8
> -   (r1p0..r1p2) erratum. If a code sequence containing an ARM/Thumb
> +   (r1p*) erratum. If a code sequence containing an ARM/Thumb
> interworking branch is replaced with another code sequence at the
> same virtual address, whether due to self-modifying code or virtual
> to physical address re-mapping, Cortex-A8 does not recover from the
> 
> 
> I am seeing strange segfault/illegal instructions fixed by enabling 
> ARM_ERRATA_430973 on a TI OMAP3 DM3730, r3p2 IMHO (see below) 
The only information i have is that it was fixed in r2p1. The statement
is from mru on:
http://www.beagleboard.org/irclogs/index.php?date=2013-02-18#T15:00:07

> ARM_ERRATA_430973 is relevant for which processors? have you checked the 
> errata list? I had no luck obtaining it yet
No, i don't have it either.

-- 
Tim Niemeyer

Corscience GmbH & Co. KG
Henkestr. 91
D-91052 Erlangen
Germany

e-mail: tim.nieme...@corscience.de
Internet: www.corscience.de

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 0/8] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot

[Benoit Cousson]

Hi Nishanth,

The patches 1 to 6 looks good to me. Beside the pretty long Cc list,
that should not necessarily contain all the mailing list.

Since you are changing / renaming some DTS files, and to avoid any merge
conflict I will apply only these 6 patches.
DTS and driver changes are in theory orthogonal enough to allow merging
them separately and in any order.

I'll update my branch with these patches ASAP.

Regards,
Benoit


On 03/19/2013 06:53 PM, Nishanth Menon wrote:
> Hi,
> The following version 2 of the series arose from trying to use BeagleBoard-XM
> (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This series enables the
> generic cpufreq-cpu0 driver to be used in device tree enabled boot while
> maintaining support of the legacy omap-cpufreq driver when used in non device
> tree enabled boot.
> 
> However, in order to enable complete SoC entitlement for OMAP platforms, with
> this series, key features are still pending on device tree adaptation for 
> OMAP:
> A) clock framework data transition to DT - this should happen soon, so this
> series hacks the clock node for the time being as suggested in review of
> original series[1].
> B) On processors that use voltage controller, voltage processor (VC/VP 
> hardware
> loop using I2C_SR path) - we have started work on transitioning them to
> regulator framework driven by DT.
> C) Adaptive Body Bias and SmartReflex AVS conversion to DT.
> 
> As a result of these pending features:
> - OMAP4 TWL6030 and TPS62361 which set voltage ONLY over I2C_SR have no
> regulators associated at the moment - fortunately, we boot at highest voltage,
> so things still work.
> - Missing ABB and AVS implies that for few of the SoCs (3630, OMAP4), I have
> not added those OPPs in DT yet - this also needs alignment with iMX, AM series
> pending work, where certain OPPs need enabling based on efuse programmed
> bit sequences - since it is an add-on work, it is not addressed here.
> 
> Note: At this point in time, we do not have DT entries for clock on OMAP
> platforms. Common Clock Framework(CCF) could also control regulators[2].
> Once these conversions are complete, there will be minimal cleanup work to
> switch to the new data structure changes.
> 
> Key benefit of the series is to allow all relevant TI platforms now to use a
> single cpufreq driver and equivalent frameworks in addition be part of the
> transition to device tree.
> NOTE: As a result of this series:
> 1. omap-cpufreq will be used only in non device tree boot scenario. we should
>delete this driver once the 100% DT conversion is complete.
> 2. Generic cpufreq-cpu0 will be used only in device tree boot scenario.
> boot systems.
> 
> Key changes in version 2:
>   - series now rebased on Device tree patches queued for OMAP 3.10
>   - cpufreq-cpu0 and omap_cpufreq will co-exist and used depending on
> usage of device tree.
>   - minor wording, cleanups for the same.
>   - omap3.dtsi and omap4.dtsi now become common dtsi which is used by
> omap34xx.dtsi, omap36xx.dtsi, omap443x.dtsi, omap4460.dtsi as needed.
> 
> version 1 of the series:
>   http://marc.info/?t=13632948545&r=1&w=2
>   available at:
>   
> https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1
> 
> [1] Original discussion thread which triggered this series:
>   http://marc.info/?l=linux-pm&m=136304313700602&w=2
>   https://patchwork.kernel.org/patch/2251841/
>   https://patchwork.kernel.org/patch/2251851/
> [2] CCF DVFS patches:
> https://patchwork.kernel.org/patch/2195431/
> https://patchwork.kernel.org/patch/2195421/
> https://patchwork.kernel.org/patch/2195451/
> https://patchwork.kernel.org/patch/2195441/
> https://patchwork.kernel.org/patch/2195461/
> 
> Version 2 is now based on for-3.10/dts branch from Benoit:
>   
> http://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.10/dts
>   44fab7a ARM: dts: omap3-devkit8000: Add NAND DT node
> 
> Version 2 is also available at:
>   
> https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v2
>   git link: git://github.com/nmenon/linux-2.6-playground.git
>   branch: cpufreq-cpu0-omap-all-v2
> 
> Test coverage:
>   test script: http://pastebin.com/zrr8ptge
> Platforms verified:
>   beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/PUx5h6Jy
>   beagleboard (rev C1D) - OMAP3430 compatible - 
> http://pastebin.com/SycCinFb (DT) http://pastebin.com/qwJHw9Ev (no DT)
>   omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/tVEXeVZC
>   Pandaboard -(OMAP4430 ES2.2) verified with omapconf - 
> http://pastebin.com/cAtytfW0
>   Pandaboard-ES -(OMAP4460 ES1.1) verified with omapconf - 
> http://pastebin.com/3EymNTMp
> 
> Nishanth Menon (8):
>   ARM: dts: OMAP34xx/35xx: Add CPU OPP table
>   ARM: dts: OMAP36xx: Add CPU OPP table
>   ARM: dts: OMAP3: use twl4030 vdd1 regulator for CPU
>   ARM: dts:

[PATCH] ARM: OMAP: dpll: enable bypass clock only when attempting dpll bypass

[Rajendra Nayak]

omap3_noncore_dpll_set_rate() attempts an enable of bypass clk as well
as ref clk for every .set_rate attempt on a noncore DPLL, regardless of
whether the .set_rate results in the DPLL being locked or put in bypass.
Early at boot, while some of these DPLLs are programmed and locked
(using .set_rate for the DPLL), this causes an ordering issue.

For instance, on OMAP5, the USB DPLL derives its bypass clk from ABE DPLL.
If a .set_rate of USB DPLL which programmes the M,N and locks it is called
before the one for ABE, the enable of USB bypass clk (derived from ABE DPLL)
then attempts to lock the ABE DPLL and fails as the M,N values for ABE
are yet to be programmed.

To get rid of this ordering needs, enable bypass clk for a DPLL as part
of its .set_rate only when its being put in bypass, and only enable the
ref clk when its locked.

Reported-by: Roger Quadros 
Signed-off-by: Rajendra Nayak 
---
 arch/arm/mach-omap2/dpll3xxx.c |   19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 3aed4b0..6e9873f 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -480,20 +480,22 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, 
unsigned long rate,
if (!dd)
return -EINVAL;
 
-   __clk_prepare(dd->clk_bypass);
-   clk_enable(dd->clk_bypass);
-   __clk_prepare(dd->clk_ref);
-   clk_enable(dd->clk_ref);
-
if (__clk_get_rate(dd->clk_bypass) == rate &&
(dd->modes & (1 << DPLL_LOW_POWER_BYPASS))) {
pr_debug("%s: %s: set rate: entering bypass.\n",
 __func__, __clk_get_name(hw->clk));
 
+   __clk_prepare(dd->clk_bypass);
+   clk_enable(dd->clk_bypass);
ret = _omap3_noncore_dpll_bypass(clk);
if (!ret)
new_parent = dd->clk_bypass;
+   clk_disable(dd->clk_bypass);
+   __clk_unprepare(dd->clk_bypass);
} else {
+   __clk_prepare(dd->clk_ref);
+   clk_enable(dd->clk_ref);
+
if (dd->last_rounded_rate != rate)
rate = __clk_round_rate(hw->clk, rate);
 
@@ -514,6 +516,8 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, unsigned 
long rate,
ret = omap3_noncore_dpll_program(clk, freqsel);
if (!ret)
new_parent = dd->clk_ref;
+   clk_disable(dd->clk_ref);
+   __clk_unprepare(dd->clk_ref);
}
/*
* FIXME - this is all wrong.  common code handles reparenting and
@@ -525,11 +529,6 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw, 
unsigned long rate,
if (!ret)
__clk_reparent(hw->clk, new_parent);
 
-   clk_disable(dd->clk_ref);
-   __clk_unprepare(dd->clk_ref);
-   clk_disable(dd->clk_bypass);
-   __clk_unprepare(dd->clk_bypass);
-
return 0;
 }
 
-- 
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

Re: [PATCH] arm: omap: RX-51: ARM errata 430973 workaround

[Santosh Shilimkar]

On Thursday 28 March 2013 03:20 PM, Russell King - ARM Linux wrote:
> On Wed, Mar 27, 2013 at 01:56:07PM -0700, Tony Lindgren wrote:
>> * Pali Rohár  [130324 07:31]:
>>> it is possible to upstream errata 430973 workaround for RX-51?
>>
>> I think we should make the SMC handling a generic function for ARM.
>>
>> AFAIK just the SMC call numbering is different for various
>> implementations. So the handler and passing of the parameters
>> seems like it should be generic.
> 
> SMC calls vary greatly in how they are handled.  The only thing that's
> generic is issuing the SMC call.  All the setup and what arguments are
> required are completely different from SoC to SoC.
> 
> For example, some SoCs require arguments passed via memory.  Others like
> OMAP its via registers.

Exactly. As somebody said on the list, that code looks identical but
it is not. An SMC with barrier instruction is mostly common and nothing
more than that.

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 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()

[Santosh Shilimkar]

On Thursday 28 March 2013 03:16 PM, Russell King - ARM Linux wrote:
> On Thu, Mar 28, 2013 at 12:34:50AM +0530, Santosh Shilimkar wrote:
>> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar  writes:
>>>
 Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 
>>>
>>> Why?
>>>
>> Because that code belongs to smp_prepare_cpus(). As I said
>> in earlier patches, it was remainder of the pen release code
>> which was borrowed from ARM code initially.
> 
> What about hotplug after the system is suspended?  Is this setup
> preserved by the secure ROM?
>
> If not, it really needs to be part of the CPU bringup, not the
> boot-time-only preparation code.
>
Its already the case. Hotplug CPU restarts just like CPU bring-up.
Initial code, hotplug cpu and last cpu(suspend) were taking identical
path for the suspend wakeup. Later you suggested after the discussion
that hotplug CPU state need not be saved and can be restarted just like
the CPU bring-up path.

So the current code follows above.

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] OMAP3 ROM Random Number Generator support

[Russell King - ARM Linux]

On Wed, Mar 27, 2013 at 02:09:18PM -0700, Tony Lindgren wrote:
> > +   setup_timer(&idle_timer, omap3_rom_idle_rng, 0);
> > +   rng_clk = clk_get_sys("omap_rng", "ick");

Why is this using clk_get_sys when it should be using clk_get() with the
platform device?
--
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: omap: RX-51: ARM errata 430973 workaround

[Russell King - ARM Linux]

On Wed, Mar 27, 2013 at 01:56:07PM -0700, Tony Lindgren wrote:
> * Pali Rohár  [130324 07:31]:
> > it is possible to upstream errata 430973 workaround for RX-51?
> 
> I think we should make the SMC handling a generic function for ARM.
> 
> AFAIK just the SMC call numbering is different for various
> implementations. So the handler and passing of the parameters
> seems like it should be generic.

SMC calls vary greatly in how they are handled.  The only thing that's
generic is issuing the SMC call.  All the setup and what arguments are
required are completely different from SoC to SoC.

For example, some SoCs require arguments passed via memory.  Others like
OMAP its via registers.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()

[Russell King - ARM Linux]

On Thu, Mar 28, 2013 at 12:34:50AM +0530, Santosh Shilimkar wrote:
> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
> > Santosh Shilimkar  writes:
> > 
> >> Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 
> > 
> > Why?
> > 
> Because that code belongs to smp_prepare_cpus(). As I said
> in earlier patches, it was remainder of the pen release code
> which was borrowed from ARM code initially.

What about hotplug after the system is suspended?  Is this setup
preserved by the secure ROM?

If not, it really needs to be part of the CPU bringup, not the
boot-time-only preparation code.
--
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] omap2: twl-common: Add default power configuration

[Peter Ujfalusi]

From: Matthias Brugger 

This patch adds a generic power script configuration.
When rebooting an OMAP3530 at 125 MHz, the reboot hangs.
With the generic power script, TWL4030 will be reset
when a warm reset occures. This way the OMAP3530 does not
hang on reboot.

Signed-off-by: Matthias Brugger 
Signed-off-by: Peter Ujfalusi 
---
Tony, Matthias,

I have marked the structs as __initdata to fix the section mismatch.

Regards,
Peter

 arch/arm/mach-omap2/twl-common.c | 38 ++
 arch/arm/mach-omap2/twl-common.h |  1 +
 2 files changed, 39 insertions(+)

diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 51e138c..7551bbc 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -121,6 +121,41 @@ static struct twl4030_audio_data omap3_audio_pdata = {
.codec = &omap3_codec,
 };
 
+static struct twl4030_ins wrst_seq[] __initdata = {
+   {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_OFF), 2},
+   {MSG_SINGULAR(DEV_GRP_P1, 0xf, RES_STATE_WRST), 15},
+   {MSG_SINGULAR(DEV_GRP_P1, 0x10, RES_STATE_WRST), 15},
+   {MSG_SINGULAR(DEV_GRP_P1, 0x7, RES_STATE_WRST), 0x60},
+   {MSG_SINGULAR(DEV_GRP_P1, 0x19, RES_STATE_ACTIVE), 2},
+   {MSG_SINGULAR(DEV_GRP_NULL, 0x1b, RES_STATE_ACTIVE), 2},
+};
+
+static struct twl4030_script wrst_script __initdata = {
+   .script = wrst_seq,
+   .size   = ARRAY_SIZE(wrst_seq),
+   .flags  = TWL4030_WRST_SCRIPT,
+};
+
+static struct twl4030_script *omap3_power_scripts[] __initdata = {
+   &wrst_script,
+};
+
+static struct twl4030_resconfig omap3_rconfig[] __initdata = {
+   { .resource = RES_HFCLKOUT, .devgroup = DEV_GRP_P3, .type = -1,
+   .type2 = -1 },
+   { .resource = RES_VDD1, .devgroup = DEV_GRP_P1, .type = -1,
+   .type2 = -1 },
+   { .resource = RES_VDD2, .devgroup = DEV_GRP_P1, .type = -1,
+   .type2 = -1 },
+   { 0, 0},
+};
+
+static struct twl4030_power_data omap3_power_pdata __initdata = {
+   .scripts= omap3_power_scripts,
+   .num= ARRAY_SIZE(omap3_power_scripts),
+   .resource_config = omap3_rconfig,
+};
+
 static struct regulator_consumer_supply omap3_vdda_dac_supplies[] = {
REGULATOR_SUPPLY("vdda_dac", "omapdss_venc"),
 };
@@ -225,6 +260,9 @@ void __init omap3_pmic_get_config(struct 
twl4030_platform_data *pmic_data,
if (pdata_flags & TWL_COMMON_PDATA_AUDIO && !pmic_data->audio)
pmic_data->audio = &omap3_audio_pdata;
 
+   if (pdata_flags & TWL_COMMON_PDATA_POWER && !pmic_data->power)
+   pmic_data->power = &omap3_power_pdata;
+
/* Common regulator configurations */
if (regulators_flags & TWL_COMMON_REGULATOR_VDAC && !pmic_data->vdac)
pmic_data->vdac = &omap3_vdac_idata;
diff --git a/arch/arm/mach-omap2/twl-common.h b/arch/arm/mach-omap2/twl-common.h
index 24b65d0..b64590b8 100644
--- a/arch/arm/mach-omap2/twl-common.h
+++ b/arch/arm/mach-omap2/twl-common.h
@@ -7,6 +7,7 @@
 #define TWL_COMMON_PDATA_BCI   (1 << 1)
 #define TWL_COMMON_PDATA_MADC  (1 << 2)
 #define TWL_COMMON_PDATA_AUDIO (1 << 3)
+#define TWL_COMMON_PDATA_POWER (1 << 4)
 
 /* Common LDO regulators for TWL4030/TWL6030 */
 #define TWL_COMMON_REGULATOR_VDAC  (1 << 0)
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL v2] ARM: omap2: twl-common update

[Peter Ujfalusi]

Hi Tony,

On 03/27/2013 07:38 PM, Tony Lindgren wrote:
> Sorry just noticed that this one adds:
> 
> Section mismatch in reference from the variable omap3_power_pdata to the 
> (unknown reference) .init.data:(unknown)
> The variable omap3_power_pdata references
> the (unknown reference) __initdata (unknown)
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
> 
> Is it safe to make it __initdata, or should also other power_pdata
> have their __initdata flags removed if used by the drivers?

We could make the whole stack of struct for the omap3_power_pdata as
__initdata since the driver (mfd/twl4030-power) is bool.

I resend the patch and update the branch (and rebase on -rc4) at the same time.

-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] arm/dts: OMAP3: fix pinctrl-single configuration

[Christoph Fritz]

- Fix 'function-mask' referring to TRM Section 7.4.4:
  "Pad Functional Multiplexing and Configuration".
- Fix 'omap3_pmx_core' referring to TRM Table 7-4:
  "Core Control Module Pad Configuration Register Fields"
- Fix 'omap3_pmx_wkup' referring to TRM Table 7-6:
  "Wake-Up Control Module Pad Configuration Register Fields".

Signed-off-by: Christoph Fritz 
---
 arch/arm/boot/dts/omap3.dtsi |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 1acc261..6ce3b5c 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -27,7 +27,7 @@
};
 
/*
-* The soc node represents the soc top level view. It is uses for IPs
+* The soc node represents the soc top level view. It is used for IPs
 * that are not memory mapped in the MPU view or for the MPU itself.
 */
soc {
@@ -77,20 +77,20 @@
 
omap3_pmx_core: pinmux@48002030 {
compatible = "ti,omap3-padconf", "pinctrl-single";
-   reg = <0x48002030 0x05cc>;
+   reg = <0x48002030 0x234>;
#address-cells = <1>;
#size-cells = <0>;
pinctrl-single,register-width = <16>;
-   pinctrl-single,function-mask = <0x7fff>;
+   pinctrl-single,function-mask = <0x7f1f>;
};
 
-   omap3_pmx_wkup: pinmux@0x48002a58 {
+   omap3_pmx_wkup: pinmux@0x48002a00 {
compatible = "ti,omap3-padconf", "pinctrl-single";
-   reg = <0x48002a58 0x5c>;
+   reg = <0x48002a00 0x54>;
#address-cells = <1>;
#size-cells = <0>;
pinctrl-single,register-width = <16>;
-   pinctrl-single,function-mask = <0x7fff>;
+   pinctrl-single,function-mask = <0x7f1f>;
};
 
gpio1: gpio@4831 {
-- 
1.7.10.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] ARM: OMAP2+: Generic cleanups for 3.10

[Santosh Shilimkar]

On Thursday 28 March 2013 01:39 AM, Shilimkar, Santosh wrote:
> Sorry for top posting ...
> I will pick the ack and update commit log to prepare new pull request
> for you. 
> 
I have updated the branch picking acks and updating changelogs and same
is available below. No change in code.

git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git 
for_3.10/omap_generic_cleanup_v2

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 3/9] ARM: OMAP2+: PM: Remove bogus fiq_[enable/disable] tuple

[Santosh Shilimkar]

On Thursday 28 March 2013 12:32 AM, Santosh Shilimkar wrote:
> On Thursday 28 March 2013 12:06 AM, Kevin Hilman wrote:
>> Santosh Shilimkar  writes:
>>
>>> On OMAP platform, FIQ is reserved for secure environment only. If at all
>>> the FIQ needs to be disabled, it involves going through security
>>> API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
>>>
>>> So just get rid of it.
>>
>> What about GP devices?
>>
> On GP devices as well FIQ isn't available for non-secure software since
> its marked secure only in ROM initialization. There has been heavy
> debate on this since some customers wanted to have it available
> for debug purpose but some other work-around was done rather
> than opening it for public.
> 

For record, patch with updated changelog for GP device is end of
the email.

Regards,
Santosh

>From 6b85638b83caac7bae9ffa202391882a9ad4388f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar 
Date: Mon, 11 Feb 2013 19:29:45 +0530
Subject: [PATCH v2 3/9] ARM: OMAP2+: PM: Remove bogus fiq_[enable/disable]
 tuple

On OMAP platform, FIQ is reserved for secure environment only. If at all
the FIQ needs to be disabled, it involves going through security
API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
On GP devices too, the fiq is disabled for non-secure software.

So just get rid of it.

Signed-off-by: Santosh Shilimkar 
---
 arch/arm/mach-omap2/cpuidle34xx.c |3 ---
 arch/arm/mach-omap2/cpuidle44xx.c |7 ---
 arch/arm/mach-omap2/pm24xx.c  |   11 +++
 arch/arm/mach-omap2/pm34xx.c  |9 +
 arch/arm/mach-omap2/pm44xx.c  |4 
 5 files changed, 4 insertions(+), 30 deletions(-)

diff --git a/arch/arm/mach-omap2/cpuidle34xx.c 
b/arch/arm/mach-omap2/cpuidle34xx.c
index 80392fc..06f567f 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -107,8 +107,6 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
 {
struct omap3_idle_statedata *cx = &omap3_idle_data[index];
 
-   local_fiq_disable();
-
if (omap_irq_pending() || need_resched())
goto return_sleep_time;
 
@@ -143,7 +141,6 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
clkdm_allow_idle(mpu_pd->pwrdm_clkdms[0]);
 
 return_sleep_time:
-   local_fiq_enable();
 
return index;
 }
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c 
b/arch/arm/mach-omap2/cpuidle44xx.c
index d639aef..944e64a 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -70,10 +70,7 @@ static int omap4_enter_idle_simple(struct cpuidle_device 
*dev,
struct cpuidle_driver *drv,
int index)
 {
-   local_fiq_disable();
omap_do_wfi();
-   local_fiq_enable();
-
return index;
 }
 
@@ -84,8 +81,6 @@ static int omap4_enter_idle_coupled(struct cpuidle_device 
*dev,
struct omap4_idle_statedata *cx = &omap4_idle_data[index];
int cpu_id = smp_processor_id();
 
-   local_fiq_disable();
-
/*
 * CPU0 has to wait and stay ON until CPU1 is OFF state.
 * This is necessary to honour hardware recommondation
@@ -158,8 +153,6 @@ fail:
cpuidle_coupled_parallel_barrier(dev, &abort_barrier);
cpu_done[dev->cpu] = false;
 
-   local_fiq_enable();
-
return index;
 }
 
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index b59d939..ce956b0 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -200,22 +200,17 @@ static int omap2_can_sleep(void)
 
 static void omap2_pm_idle(void)
 {
-   local_fiq_disable();
-
if (!omap2_can_sleep()) {
if (omap_irq_pending())
-   goto out;
+   return;
omap2_enter_mpu_retention();
-   goto out;
+   return;
}
 
if (omap_irq_pending())
-   goto out;
+   return;
 
omap2_enter_full_retention();
-
-out:
-   local_fiq_enable();
 }
 
 static void __init prcm_setup_regs(void)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2d93d8b..c018593 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -346,19 +346,14 @@ void omap_sram_idle(void)
 
 static void omap3_pm_idle(void)
 {
-   local_fiq_disable();
-
if (omap_irq_pending())
-   goto out;
+   return;
 
trace_cpu_idle(1, smp_processor_id());
 
omap_sram_idle();
 
trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
-
-out:
-   local_fiq_enable();
 }
 
 #ifdef CONFIG_SUSPEND
@@ -757,14 +752,12 @@ int __init omap3_pm_init(void)
pr_err("Memory allocation failed when allocating for 
secure sram context\n");
 
local_irq_disable();
-   local_fiq_disable();
 
omap_dma_global_con

Re: [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()

[Santosh Shilimkar]

On Thursday 28 March 2013 02:20 AM, Santosh Shilimkar wrote:
> On Thursday 28 March 2013 01:24 AM, Kevin Hilman wrote:
>> Santosh Shilimkar  writes:
>>
>>> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
 Santosh Shilimkar  writes:

> Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 

 Why?

>>> Because that code belongs to smp_prepare_cpus(). As I said
>>> in earlier patches, it was remainder of the pen release code
>>> which was borrowed from ARM code initially.
>>
>> Sure, but that should be in the changelog.
>>
> Yep. Will add above info in changelog.
> 
For record, patch with updated changelog end of email.

Regards,
Santosh

>From b699ddd19bf3542d43ffe293c6148161e160b1bc Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar 
Date: Sun, 10 Feb 2013 13:54:00 +0530
Subject: [PATCH v2 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under
 smp_prepare_cpus()

Move the secondary CPU wakeup prepare code under smp_prepare_cpus() where it
belongs. It was remainder of the pen release code which was borrowed from
ARM code initially.

While at it drop the un-necessary sev() and barrier which was under
prepare code.

Signed-off-by: Santosh Shilimkar 
---
 arch/arm/mach-omap2/omap-smp.c |   51 
 1 file changed, 20 insertions(+), 31 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 1e14899..0cbb677 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -164,36 +164,6 @@ static int __cpuinit omap4_boot_secondary(unsigned int 
cpu, struct task_struct *
return 0;
 }
 
-static void __init wakeup_secondary(void)
-{
-   void *startup_addr = omap_secondary_startup;
-   void __iomem *base = omap_get_wakeupgen_base();
-
-   if (cpu_is_omap446x()) {
-   startup_addr = omap_secondary_startup_4460;
-   pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
-   }
-
-   /*
-* Write the address of secondary startup routine into the
-* AuxCoreBoot1 where ROM code will jump and start executing
-* on secondary core once out of WFE
-* A barrier is added to ensure that write buffer is drained
-*/
-   if (omap_secure_apis_support())
-   omap_auxcoreboot_addr(virt_to_phys(startup_addr));
-   else
-   __raw_writel(virt_to_phys(omap5_secondary_startup),
-   base + OMAP_AUX_CORE_BOOT_1);
-
-   /*
-* Send a 'sev' to wake the secondary core from WFE.
-* Drain the outstanding writes to memory
-*/
-   dsb_sev();
-   mb();
-}
-
 /*
  * Initialise the CPU possible map early - this describes the CPUs
  * which may be present or become present in the system.
@@ -229,6 +199,8 @@ static void __init omap4_smp_init_cpus(void)
 
 static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
 {
+   void *startup_addr = omap_secondary_startup;
+   void __iomem *base = omap_get_wakeupgen_base();
 
/*
 * Initialise the SCU and wake up the secondary core using
@@ -236,7 +208,24 @@ static void __init omap4_smp_prepare_cpus(unsigned int 
max_cpus)
 */
if (scu_base)
scu_enable(scu_base);
-   wakeup_secondary();
+
+   if (cpu_is_omap446x()) {
+   startup_addr = omap_secondary_startup_4460;
+   pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
+   }
+
+   /*
+* Write the address of secondary startup routine into the
+* AuxCoreBoot1 where ROM code will jump and start executing
+* on secondary core once out of WFE
+* A barrier is added to ensure that write buffer is drained
+*/
+   if (omap_secure_apis_support())
+   omap_auxcoreboot_addr(virt_to_phys(startup_addr));
+   else
+   __raw_writel(virt_to_phys(omap5_secondary_startup),
+   base + OMAP_AUX_CORE_BOOT_1);
+
 }
 
 struct smp_operations omap4_smp_ops __initdata = {
-- 
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

Re: [PATCH 1/9] ARM: OMAP4+: Use common scratchpad SAR RAM offsets for all architectures

[Santosh Shilimkar]

On Thursday 28 March 2013 02:22 AM, Santosh Shilimkar wrote:
> On Thursday 28 March 2013 02:19 AM, Tony Lindgren wrote:
>> * Santosh Shilimkar  [130327 13:52]:
>>> On Thursday 28 March 2013 12:11 AM, Kevin Hilman wrote:
 Santosh Shilimkar  writes:

> From: Tero Kristo 
>
> Simplifies code and also allows the re-use as is on OMAP5 devices.

 nit: changelog here is rather weak.  It claims "simplifies code" but
 it's not obvious from the patch how changing a few #defines does that.

>>> I agree. Basically the offset are chosen such a way that they can
>>> work on OMAP4 and OMAP5 instead of having two separate sets.
>>> Will expand the changelog to make it clear.
>>
>> You might want to mention also that the offsets are only used by
>> the kernel to save and restore registers from so people don't
>> think those are hardare registers and that the patch might break
>> some things.
>>
> Yeah. Will mention that.
> 
For record, patch with updated changelog end of email.

Regards,
Santosh

>From f98d5fe8079cc4830e4ce22585055822119da5c8 Mon Sep 17 00:00:00 2001
From: Tero Kristo 
Date: Wed, 6 Feb 2013 18:39:20 +0530
Subject: [PATCH v2 1/9] ARM: OMAP4+: Use common scratchpad SAR RAM offsets
 for all architectures

Choose the common scratch pad offsets, so that same offsets can work for
OMAP4 and OMAP5 devices. It simplifies code and also allows the re-use as
is on OMAP5 devices. Note that these offsets are used by low power
code for various power state management. They are not hardware register
offsets.

Signed-off-by: Tero Kristo 
Signed-off-by: Santosh Shilimkar 
---
 arch/arm/mach-omap2/omap4-sar-layout.h |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h 
b/arch/arm/mach-omap2/omap4-sar-layout.h
index e170fe8..6822d0a 100644
--- a/arch/arm/mach-omap2/omap4-sar-layout.h
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -20,13 +20,13 @@
 #define SAR_BANK4_OFFSET   0x3000
 
 /* Scratch pad memory offsets from SAR_BANK1 */
-#define SCU_OFFSET00xd00
-#define SCU_OFFSET10xd04
-#define OMAP_TYPE_OFFSET   0xd10
-#define L2X0_SAVE_OFFSET0  0xd14
-#define L2X0_SAVE_OFFSET1  0xd18
-#define L2X0_AUXCTRL_OFFSET0xd1c
-#define L2X0_PREFETCH_CTRL_OFFSET  0xd20
+#define SCU_OFFSET00xfe4
+#define SCU_OFFSET10xfe8
+#define OMAP_TYPE_OFFSET   0xfec
+#define L2X0_SAVE_OFFSET0  0xff0
+#define L2X0_SAVE_OFFSET1  0xff4
+#define L2X0_AUXCTRL_OFFSET0xff8
+#define L2X0_PREFETCH_CTRL_OFFSET  0xffc
 
 /* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */
 #define CPU0_WAKEUP_NS_PA_ADDR_OFFSET  0xa04
-- 
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

Re: [PATCH 4/9] ARM: OMAP4+: Remove the un-necessary cache flush from hotplug code

[Santosh Shilimkar]

On Thursday 28 March 2013 02:17 AM, Santosh Shilimkar wrote:
> On Thursday 28 March 2013 12:13 AM, Kevin Hilman wrote:
>> Santosh Shilimkar  writes:
>>
>>> This was added with intial port where OMAP PM support wasn't existing
>>> and only simple WFI based hooks were used.
>>>
>>> This should have been cleaned up while adding the PM support but some
>>> how fall through cracks.
>>
>> Changelog describes a bit of history, but does not it's no longer
>> needed.
>>
> I thought "This should have been cleaned up while adding PM support"
> means its no longer needed. At least I meant that way.
> 
> Anyway I will just make it explicit.
> 
For record, patch with updated changelog end of email.

Regards,
Santosh


>From 4df9c29bf6eec23e99e83c9e1531603af69b4b42 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar 
Date: Sun, 10 Feb 2013 13:14:17 +0530
Subject: [PATCH v2 4/9] ARM: OMAP4+: Remove the un-necessary cache flush from
 hotplug code

This was added with intial port where OMAP PM support wasn't existing
and only simple WFI based hooks were used.

This should have been cleaned up while adding the PM support but some
how fall through cracks.

So remove the cache flush code which is no longer needed now.

Signed-off-by: Santosh Shilimkar 
---
 arch/arm/mach-omap2/omap-hotplug.c |6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap-hotplug.c 
b/arch/arm/mach-omap2/omap-hotplug.c
index e712d17..458f72f 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -19,11 +19,8 @@
 #include 
 #include 
 
-#include 
 #include "omap-wakeupgen.h"
-
 #include "common.h"
-
 #include "powerdomain.h"
 
 /*
@@ -35,9 +32,6 @@ void __ref omap4_cpu_die(unsigned int cpu)
unsigned int boot_cpu = 0;
void __iomem *base = omap_get_wakeupgen_base();
 
-   flush_cache_all();
-   dsb();
-
/*
 * we're ready for shutdown now, so do it
 */
-- 
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

Re: [PATCH-V2 5/6] ARM: dts: AM33XX: Fix uart numbering to match hardware/TRM

[Peter Korsgaard]

> "Vaibhav" == Vaibhav Hiremath  writes:

 Vaibhav> With DT support, where naming convention is based on base-addr
 Vaibhav> and not id, so we should follow TRM/Spec numbering label.

 Vaibhav> This patch changes UART numbering as per TRM, as uart0-5.

Acked-by: Peter Korsgaard 

-- 
Bye, Peter Korsgaard
--
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