[PATCH] leds-lp5521: additional platform data and attributes

[Kim, Milo]

* Changes of lp5521_platform_data
> 'update_config' is added
> 'name' is added
Value of CONFIG register(Addr 08h) and name of led channels are dependant on 
the project.
So these fields have been added in lp5521_platform_data.
> led pattern data
lp5521 has autonomous operation mode without external control.
This patch includes how to configure the led patterns and load them.

* Additional led class device attributes : delay_on, delay_off, blink
For supporting blink mode, 3 attributes have been updated.

* Additional i2c device attribute : led_pattern
Platform specific led pattern can be loaded via the user-space.

* Base kernel version : 3.0.9

Signed-off-by: Milo(Woogyom) Kim 
---
 Documentation/leds/leds-lp5521.txt |   60 ++
 drivers/leds/leds-lp5521.c |  222 +---
 include/linux/leds-lp5521.h|   25 
 3 files changed, 289 insertions(+), 18 deletions(-)

diff --git a/Documentation/leds/leds-lp5521.txt 
b/Documentation/leds/leds-lp5521.txt
index c4d8d15..b0d6abe 100644
--- a/Documentation/leds/leds-lp5521.txt
+++ b/Documentation/leds/leds-lp5521.txt
@@ -3,6 +3,7 @@ Kernel driver for lp5521

 * National Semiconductor LP5521 led driver chip
 * Datasheet: http://www.national.com/pf/LP/LP5521.html
+   or http://www.ti.com/product/lp5521

 Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo
 Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
@@ -43,17 +44,23 @@ Format: 10x mA i.e 10 means 1.0 mA
 example platform data:

 Note: chan_nr can have values between 0 and 2.
+Each channel can have own name.
+If name field is not defined, the default name will be set to ':channelN'
+( : pdata->label or i2c client name, N : channel number)

 static struct lp5521_led_config lp5521_led_config[] = {
 {
+   .name = "red",
 .chan_nr= 0,
 .led_current= 50,
.max_current= 130,
 }, {
+   .name = "green",
 .chan_nr= 1,
 .led_current= 0,
.max_current= 130,
 }, {
+   .name = "blue",
 .chan_nr= 2,
 .led_current= 0,
.max_current= 130,
@@ -86,3 +93,56 @@ static struct lp5521_platform_data lp5521_platform_data = {

 If the current is set to 0 in the platform data, that channel is
 disabled and it is not visible in the sysfs.
+
+update_config : CONFIG register (ADDR 08h)
+This value is platform-specific data. If NULL, the default value will be set.
+
+example)
+
+#define LP5521_CONFIGS (LP5521_PWM_HF | LP5521_PWRSAVE_EN | \
+   LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \
+   LP5521_CLK_INT)
+
+static struct lp5521_platform_data lp5521_pdata = {
+   .led_config = lp5521_led_config,
+   .num_channels = ARRAY_SIZE(lp5521_led_config),
+   .clock_mode = LP5521_CLOCK_INT,
+   .update_config = LP5521_CONFIGS,
+};
+
+LED patterns : LP5521 has autonomous operation without external control.
+Pattern data can be defined in the platform data.
+
+example)
+/* Pattern : RGB(50,5,0) 500ms on, 500ms off, infinite loop */
+static u8 pattern_red[] = {
+   0x40, 0x32, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00,
+   };
+
+static u8 pattern_green[] = {
+   0x40, 0x05, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00,
+   };
+
+static struct lp5521_led_pattern board_led_patterns[] = {
+   {
+   .r = pattern_r,
+   .g = pattern_g,
+   .size_r = ARRAY_SIZE(pattern_r),
+   .size_g = ARRAY_SIZE(pattern_g),
+   },
+};
+
+static struct lp5521_platform_data lp5521_platform_data = {
+.led_config = lp5521_led_config,
+.num_channels   = ARRAY_SIZE(lp5521_led_config),
+.clock_mode = LP5521_CLOCK_EXT,
+   .patterns = board_led_patterns,
+   .num_patterns = ARRAY_SIZE(board_led_patterns),
+};
+
+Then the predefined led pattern can be executed via the user-space.
+To start the pattern #1,
+# echo 1 > /sys/bus/i2c/devices//led_pattern
+( : i2c bus & slave address)
+To end the pattern,
+# echo 0 > /sys/bus/i2c/devices//led_pattern
diff --git a/drivers/leds/leds-lp5521.c b/drivers/leds/leds-lp5521.c
index cc1dc48..8239319 100644
--- a/drivers/leds/leds-lp5521.c
+++ b/drivers/leds/leds-lp5521.c
@@ -80,23 +80,23 @@
 /* Bits in ENABLE register */
 #define LP5521_MASTER_ENABLE   0x40/* Chip master enable */
 #define LP5521_LOGARITHMIC_PWM 0x80/* Logarithmic PWM adjustment */
+#define LP5521_EXEC_MASK   0xC0
 #define LP5521_EXEC_RUN0x2A
-
-/* Bits in CONFIG register */
-#define LP5521_PWM_HF  0x40/* PWM: 0 = 256Hz, 1 = 558Hz */
-#define LP5521_PWRSAVE_EN  0x20/* 1 = Power save mode */
-#define LP5521_CP_MODE_OFF 0   /* Charge pump (CP) off */
-#define LP5521_CP_MODE_B

Re: [U-Boot] [PATCH 4/6] EEYNOS: Add SMDK5250 board support

[Minkyu Kang]

Dear Chander Kashyap,

On 5 January 2012 19:31, Chander Kashyap  wrote:
> Hi Minkyu Kang,
>
> On 5 January 2012 12:13, Minkyu Kang  wrote:
>> Dear Chander Kashyap,
>>
>> On 27 December 2011 17:48, Chander Kashyap  
>> wrote:
> >  Torsten Koschorrek 
> >        scb9328         ARM920T (i.MXL)
> > diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
> > b/arch/arm/cpu/armv7/exynos/clock.c
> > index b101f96..88e2fc0 100644
> > --- a/arch/arm/cpu/armv7/exynos/clock.c
> > +++ b/arch/arm/cpu/armv7/exynos/clock.c
> > @@ -125,10 +125,14 @@ static unsigned long exynos_get_pwm_clk(void)
> >
> >        if (s5p_get_cpu_rev() == 0) {
> >                /*
> > -                * CLK_SRC_PERIL0
> > +                * CLK_SRC_{PERIL0 | PERIC0}
> >                 * PWM_SEL [27:24]
> >                 */
> > +#ifdef CONFIG_EXYNOS5
> > +               sel = readl(&clk->src_peric0);
> > +#else
> >                sel = readl(&clk->src_peril0);
> > +#endif
>
> NAK.
> We don't allow to using ifdef for separating SoCs.
> Please refer s5pc1xx case for solve it.
> This comment apply to this patch globally.
> Please remove '#ifdef CONFIG_EXYNOS5'.
>
 I have tried to reuse the code. It is possible to remove
 #ifdef CONFIG_EXYNOS5' in clock.c with cpu_is_s5pcXXX check.
 Is it a acceptable solution? Or is it necessary to write SoC specific 
 function
 in clock.c as done in case of s5pc1xx/clock.c.

 Please Advice
>>> Removing CONFIG_EXYNOS5 and following s5pc1xx case will not allow to
>>> reuse the code in clock.c.
>>> What is the technical hindrance of not using ifdefs?
>>
>> No need to reuse the code, if SoCs are different.
>> If need, please separate the functions.
>
> Yes, though SoC's are different, the functionality in clock.c is
> similar. The only difference is the clock name in the clock structure
> for Exynos4 and Exynos5 but the functionality is exactly same in
> clock.c. To accommodate this change in clock name #ifdef is used.
>
> Following is the function in clock .c which uses #ifdef to accommodate
> the different clock name in SoC's.
>
> static unsigned long exynos_get_pwm_clk(void)
> {
>        struct exynos_clock *clk =
>                (struct exynos_clock *)samsung_get_base_clock();
>        unsigned long pclk, sclk;
>        unsigned int sel;
>        unsigned int ratio;
>
>        if (s5p_get_cpu_rev() == 0) {
>                /*
>                 * CLK_SRC_{PERIL0 | PERIC0}
>                 * PWM_SEL [27:24]
>                 */
> #ifdef CONFIG_EXYNOS5
>                sel = readl(&clk->src_peric0);
> #else
>                sel = readl(&clk->src_peril0);
> #endif
>                sel = (sel >> 24) & 0xf;
>
>                if (sel == 0x6)
>                        sclk = get_pll_clk(MPLL);
>                else if (sel == 0x7)
>                        sclk = get_pll_clk(EPLL);
>                else if (sel == 0x8)
>                        sclk = get_pll_clk(VPLL);
>                else
>                        return 0;
>
>                /*
>                 * CLK_DIV_{PERIL3 | PERIC3}
>                 * PWM_RATIO [3:0]
>                 */
> #ifdef CONFIG_EXYNOS5
>                ratio = readl(&clk->div_peric3);
> #else
>                ratio = readl(&clk->div_peril3);
> #endif
>                ratio = ratio & 0xf;
>        } else if (s5p_get_cpu_rev() == 1) {
>                sclk = get_pll_clk(MPLL);
>                ratio = 8;
>        } else
>                return 0;
>
>        pclk = sclk / (ratio + 1);
>
>        return pclk;
> }
>
> As listed above, the exynos_get_pwm_clk(() function is fully reusable
> for both Exynos4 and Exynos5. The #ifdef was used to get around the
> different clock names of Exynos4 and Exynos5.
>
> Another option here could be, that the differing clock name
> (src_peril0 for Exynos4 and src_peric0 for Exynos5) is resolved by
> change the src_peric0 to src_peril0 for Exynos5, and clearly
> commenting the reason for the deviation from the user manual. Would
> this approach be acceptable ?
>

Using same clock's name is acceptable.

But exynos4 clock structure and exynos5 clock structure are different.
I requested removing all ifdefs in your patch.
So, I will not allow such cases.

+#ifdef CONFIG_EXYNOS4
+#include
+#elif defined CONFIG_EXYNOS5
+#include
 #endif

Then, we should do like this,

        struct exynos4_clock *clk =
                (struct exynos4_clock *)samsung_get_base_clock();

        struct exynos5_clock *clk =
                (struct exynos5_clock *)samsung_get_base_clock();

how solve it?

And you should consider variation by cpu revision.
If Exynos5 revision1 is different from Exynos4 revision1, then?

Thanks.
Minkyu Kang.
-- 
from. prom.
www.promsoft.net

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH V6 3/7] cpufreq: OMAP: remove loops_per_jiffy recalculate for smp

[Richard Zhao]

Hi Kevin,

Could you please look at and ack the patch if possible?
Sorry, I didn't cc you.

Thanks
Richard


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH V6 2/7] arm/imx: cpufreq: remove loops_per_jiffy recalculate for smp

[Richard Zhao]

Hi Sascha & Shawn,

Could you look and ack the patch?

Thanks
Richard 


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH V6 0/7] add a generic cpufreq driver

[Richard Zhao]

On Thu, Jan 05, 2012 at 06:16:54AM +0800, Richard Zhao wrote:
> hi Russell,
> 
> May I have your ACK, you merge it?
Russell, ping
> 
> Thanks
> Richard
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v4 2/6] Documentation: common clk API

[Turquette, Mike]

On Thu, Jan 5, 2012 at 6:31 AM, Amit Kucheria  wrote:
> Tiny, tiny typo...
>
> On 11 Dec 13, Mike Turquette wrote:
>
>> +clk_set_rate deserves a special mention because it is more complex than
>> +the other operations.  There are three key concepts to the common
>> +clk_set_rate implementation:
>> +
>> +1) recursively traversing up the clk tree and changing clk rates, one
>> +parent at a time, if each clk allows it
>> +2) failing to change rate if the clk is enabled and must only change
>> +rates while disabled
>> +3) using clk rate change notifiers to allow devices to handle dynamic
>> +rate changes for clks which do support changing rates while enabled
>> +
>> +For the simple, non-recursive case the call graph looks like:
>> +
>> +clk_set_rate(clk, rate);
>> +     __clk_set_rate(clk, rate);
>> +             clk->round_rate(clk, rate *parent_rate);
>                                      
>
> need a comma here? The next sentence kept me busy for 5 mins.

Thanks, will fix in next submission (along with general rework of
messy documentation).

Mike

>
>> +             clk->set_rate(clk, rate);
>> +
>> +You might be wondering what that third paramater in .round_rate is.  If
>> +a clk supports the CLK_PARENT_SET_RATE flag then that enables it's
>> +hardware-specific .round_rate function to provide a new rate that the
>> +parent should transition to.  For example, imagine a rate-adjustable clk
>> +A that is the parent of clk B, which has a fixed divider of 2.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Snowball bugs - New process announcement

[anmar.ou...@linaro.org]

Hello All:

Now that we have tightly integrated Linaro and Igloocommunity [1], it
is time for us to tweak our internal process to accommodate this
change. As of today, the following applies:

1. The igloocommunity [2] Launchpad project will replace the
linaro-landing-team-ste [3] one. This will apply to releases, bugs, etc.

2. The ST-Ericsson Landing Team will post their kernel releases on [2]
starting with the 2012.01 release onward.

3. All new snowball related bugs, should use [2]

4. Pre-existing bugs in [3] will be migrated to [2] in the next 24
hours.

5. Only private bugs will be left in [3]

6. Snowball PPA is now part of the igloocommunity-maintainers
Launchpad team [4]

[1] - http://www.igloocommunity.org
[2] - https://launchpad.net/igloocommunity
[3] - https://launchpad.net/linaro-landing-team-ste
[4] - https://launchpad.net/~igloocommunity-maintainers/+archive/snowball

Thanks

anmar

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: RFC: Ideas for Linaro

[Joey STANFORD]

Hi,

> I'm not sure adding one more service like brainstorm will help us enough
> to offset the added pain of further context-switching an already small
> team. Is there really that much demand that isn't finding its way to us?

We overlapped on emails.  That's were I was going with my trailer to
Loic's email.  I'm not sure the cost vs benefit is there but thought
it worthy enough to ask everyone to see if there are benefits/use
cases that I don't.

J

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: RFC: Ideas for Linaro

[Joey STANFORD]

Howdy,

>  will
>  we commit to implementing x things per cycle from brainstorm.linaro.org
>  if we start advertizing it?  The worst thing would be to give people a
>  place to suggest work and then ... ignore it.

Right on. We'll need to implement some sort of social contract for
this. I'd want to get the tech leads to weigh in on it as well if we
decide to do it.   Looking at Ubuntu there seem to be Chores, Tech
debt, new features, bugs, and some edge case stuff there. Each of
those would likely have a different priority within the Linaro working
groups (but not necessarily within the community developer area).

Your comments are really to my original point: if we roll something
like this out I'd want it to be useful to both the full time Linaro
Working Groups (and other areas inside Linaro) as well as to the
Linaro Community, including community developers. (Hence this
discussion on -dev).

J

--

For the non-Linaro folks on the list, our Working Groups commit to the
Linaro TSC to accomplish a number of items of our roadmap.
Consequently like any development shop they don't have a lot of free
time.  I'm hoping that an ideas system would provide a "wisdom of the
masses" affect and do a better job. It would also give us another pool
of opportunity items to look at ("Hey, we're in here working on X and
if I took another 2 hours I could accomplish this other great thing
that many people need and we'd be heroes.") .  You could do that with
bug reports though and good gardening techniques.  What I'm not sold
on yet is the cost vs benefit of doing this.  I would have to put
staff on this to manage it and get the ideas circulated within Linaro.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: RFC: Ideas for Linaro

[Christian Robottom Reis]

On Thu, Jan 05, 2012 at 09:51:01AM -0700, Joey Stanford wrote:
> > I like brainstorm, though on the Ubuntu side I know it's been a struggle
> > lately to maintain, keep moderators and idea reviewers.
> 
> I'm hoping that since we're a smaller group  that you and Michael can
> keep up with it (like ask.linaro.org).

I'm not sure adding one more service like brainstorm will help us enough
to offset the added pain of further context-switching an already small
team. Is there really that much demand that isn't finding its way to us?
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: RFC: Ideas for Linaro

[Joey STANFORD]

> I like brainstorm, though on the Ubuntu side I know it's been a struggle
> lately to maintain, keep moderators and idea reviewers.

I'm hoping that since we're a smaller group  that you and Michael can
keep up with it (like ask.linaro.org).


>  It's also my
> understanding that the code base is not being actively maintained though
> last month stgraber tracked down who maintains it (code base). Also we would
> need to insure that ideas are being reviewed by decision makers say at
> Linaro Connect and we either implement or close the ideas and let the
> submitter know we have acted on their idea and not let people think the
> ideas aren't being looked at.  This was one of the main complaints on the
> Ubuntu side that no-one in a decision making role was looking at the ideas.

Good comments. If we go this route (i.e. adding an ideas manager) I'll
have you and Michael (and maybe Andy?) evaluate the different tools
and see if we can get the technology and process to map up to make a
good implementation.

J


>
> Cheers,
> Amber
>>
>>
>> Joey
>
>
>
>
> --
>
> Amber Graner
>
> User Experience and Community Specialist
>
>
>
> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: Facebook | Twitter | Blog
>
>
> +1.828.582.9469 cell
> +1.828.395.1049 office
>
> irc: akgraner
> amber.gra...@linaro.org  (email and Google chat)
>
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: RFC: Ideas for Linaro

[Joey STANFORD]

Hi Patrik,

Yep, since Linaro has a Google Apps account we could indeed use Google
Moderator.   e.g.

https://www.google.com/moderator/#15/e=1c111&t=1c111.40&f=1c111.5df32a

I have large preference to the ideastorm code that brainstorm uses
(able to put a branding/theming on it, openid enabled so uses LP,
etc).

J

On Thu, Jan 5, 2012 at 2:20 AM, Patrik Ryd  wrote:
> We could just use https://www.google.com/moderator/#0.
>
>  /Patrik
>
> On 5 January 2012 00:18, Joey STANFORD  wrote:
>>
>> Hi Gang,
>>
>> During some roadmapping work today the discussion of capturing and
>> voting on ideas for Linaro came up.  The idea was to possibly recreate
>> a Linaro version of this
>>
>> http://brainstorm.ubuntu.com/
>>
>> for everyone to contribute to.  I'm looking for  +1 and -1  feedback
>> from folks about whether this would be useful (vs interesting).
>>
>> Joey
>>
>> ___
>> linaro-dev mailing list
>> linaro-dev@lists.linaro.org
>> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH v4 2/6] Documentation: common clk API

[Amit Kucheria]

Tiny, tiny typo...

On 11 Dec 13, Mike Turquette wrote:

> +clk_set_rate deserves a special mention because it is more complex than
> +the other operations.  There are three key concepts to the common
> +clk_set_rate implementation:
> +
> +1) recursively traversing up the clk tree and changing clk rates, one
> +parent at a time, if each clk allows it
> +2) failing to change rate if the clk is enabled and must only change
> +rates while disabled
> +3) using clk rate change notifiers to allow devices to handle dynamic
> +rate changes for clks which do support changing rates while enabled
> +
> +For the simple, non-recursive case the call graph looks like:
> +
> +clk_set_rate(clk, rate);
> + __clk_set_rate(clk, rate);
> + clk->round_rate(clk, rate *parent_rate);
  

need a comma here? The next sentence kept me busy for 5 mins.

> + clk->set_rate(clk, rate);
> +
> +You might be wondering what that third paramater in .round_rate is.  If
> +a clk supports the CLK_PARENT_SET_RATE flag then that enables it's
> +hardware-specific .round_rate function to provide a new rate that the
> +parent should transition to.  For example, imagine a rate-adjustable clk
> +A that is the parent of clk B, which has a fixed divider of 2.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ACTIVITY] Graphics WG weekly report - wk01.2012 (20120102 - 20120106)

[Ilias Biris]

Dashboard for the release and news are all in
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/WeeklyReport

Last meeting minutes:
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2012-01-04

Highlights:
Not much to highlight on - apart from working for the release 12.01
after coming back from the holidays. Check the link at the top for a
list of the blueprints aimed at 12.01 as of now.

- bug #907151 - glmark2 crash on ICS for Origen - the main issue has
been fixed, now looking at the secondary crash which may not be due to
glmark2

- Unity/nux/compiz: Picking up from Travis, Marc is now looking at  the
work involved in managing the pieces needed to be merged upstream. The
merge process is underway with Canonical DX and Graphics team is helping
to smooth out any possible issues

Other issues:
- Dashboard bugs: #881789 - "timeout in image deployment" and #904796 -
"provide staging/development lava server instances" are a risk for our
work with the dashboard
- Origen doesn't have h/w(Mali) accelerated Ubuntu and it takes a lot of
time to set up proper LAVA test environment

Best regards,

-- 
Ilias Biris ilias.bi...@linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [lm-sensors] [RFC PATCH 2/3] thermal: exynos4: Register the tmu sensor with the thermal interface layer

[Donggeun Kim]

Actually, the TMU driver is closely related to thermal layer.
I think it's okay to move it to the thermal.

Thanks.
-Donggeun

On 2012년 01월 04일 19:14, Amit Kachhap wrote:
> Hi Guenter,
> 
> The main idea of this work is to leave the current userspace based
> notification scheme and add the kernel based cooling scheme on top of
> it. Anyway, It is a good idea to move the file hwmon/exynos4_tmu.c as
> this creates 2 hwmon entries.
> Adding CC: Donggeun Kim to know his opinion.
> 
> Thanks,
> Amit Daniel
> 
> On 4 January 2012 03:55, Guenter Roeck  wrote:
>> On Wed, 2011-12-21 at 06:59 -0500, Amit Daniel Kachhap wrote:
>>> Export and register information from the hwmon tmu sensor to the samsung
>>> exynos kernel thermal framework where different cooling devices and thermal
>>> zone are binded. The exported information is based according to the data
>>> structure thermal_sensor_conf present in exynos_thermal.h. HWMON sysfs
>>> functions are currently left although all of them are present in generic
>>> linux thermal layer.
>>> Also the platform data structure is modified to pass frequency cooling
>>> in percentages for each thermal level.
>>>
>> Hi Amit,
>>
>> wouldn't it make more sense to merge the code as necessary from
>> hwmon/exynos4_tmu.c into the new thermal/exynos_thermal.c, and drop
>> hwmon/exynos4_tmu.c entirely ?
>>
>> With that, you should get the hwmon entries for free, and we would not
>> have to maintain two drivers with overlapping functionality.
>>
>> Thanks,
>> Guenter
>>
>>> Signed-off-by: Amit Daniel Kachhap 
>>> ---
>>>  drivers/hwmon/exynos4_tmu.c   |   34 
>>> ++--
>>>  include/linux/platform_data/exynos4_tmu.h |7 ++
>>>  2 files changed, 38 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/hwmon/exynos4_tmu.c b/drivers/hwmon/exynos4_tmu.c
>>> index f2359a0..6912a7f 100644
>>> --- a/drivers/hwmon/exynos4_tmu.c
>>> +++ b/drivers/hwmon/exynos4_tmu.c
>>> @@ -37,6 +37,9 @@
>>>  #include 
>>>
>>>  #include 
>>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>>> +#include 
>>> +#endif
>>>
>>>  #define EXYNOS4_TMU_REG_TRIMINFO 0x0
>>>  #define EXYNOS4_TMU_REG_CONTROL  0x20
>>> @@ -248,10 +251,13 @@ static void exynos4_tmu_work(struct work_struct *work)
>>>
>>>   kobject_uevent(&data->hwmon_dev->kobj, KOBJ_CHANGE);
>>>
>>> - enable_irq(data->irq);
>>>
>>>   clk_disable(data->clk);
>>>   mutex_unlock(&data->lock);
>>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>>> + exynos4_report_trigger();
>>> +#endif
>>> + enable_irq(data->irq);
>>>  }
>>>
>>>  static irqreturn_t exynos4_tmu_irq(int irq, void *id)
>>> @@ -345,6 +351,14 @@ static const struct attribute_group 
>>> exynos4_tmu_attr_group = {
>>>   .attrs = exynos4_tmu_attributes,
>>>  };
>>>
>>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>>> +static struct thermal_sensor_conf exynos4_sensor_conf = {
>>> + .name   = "exynos4-therm",
>>> + .read_temperature   = (int (*)(void *))exynos4_tmu_read,
>>> +};
>>> +#endif
>>> +/*CONFIG_SAMSUNG_THERMAL_INTERFACE*/
>>> +
>>>  static int __devinit exynos4_tmu_probe(struct platform_device *pdev)
>>>  {
>>>   struct exynos4_tmu_data *data;
>>> @@ -432,9 +446,20 @@ static int __devinit exynos4_tmu_probe(struct 
>>> platform_device *pdev)
>>>   }
>>>
>>>   exynos4_tmu_control(pdev, true);
>>> -
>>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>>> + (&exynos4_sensor_conf)->private_data = data;
>>> + (&exynos4_sensor_conf)->sensor_data = pdata;
>>> + ret = exynos4_register_thermal(&exynos4_sensor_conf);
>>> + if (ret) {
>>> + dev_err(&pdev->dev, "Failed to register thermal interface\n");
>>> + goto err_hwmon_device;
>>> + }
>>> +#endif
>>>   return 0;
>>> -
>>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>>> +err_hwmon_device:
>>> + hwmon_device_unregister(data->hwmon_dev);
>>> +#endif
>>>  err_create_group:
>>>   sysfs_remove_group(&pdev->dev.kobj, &exynos4_tmu_attr_group);
>>>  err_clk:
>>> @@ -458,6 +483,9 @@ static int __devexit exynos4_tmu_remove(struct 
>>> platform_device *pdev)
>>>
>>>   exynos4_tmu_control(pdev, false);
>>>
>>> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
>>> + exynos4_unregister_thermal();
>>> +#endif
>>>   hwmon_device_unregister(data->hwmon_dev);
>>>   sysfs_remove_group(&pdev->dev.kobj, &exynos4_tmu_attr_group);
>>>
>>> diff --git a/include/linux/platform_data/exynos4_tmu.h 
>>> b/include/linux/platform_data/exynos4_tmu.h
>>> index 39e038c..642c508 100644
>>> --- a/include/linux/platform_data/exynos4_tmu.h
>>> +++ b/include/linux/platform_data/exynos4_tmu.h
>>> @@ -21,6 +21,7 @@
>>>
>>>  #ifndef _LINUX_EXYNOS4_TMU_H
>>>  #define _LINUX_EXYNOS4_TMU_H
>>> +#include 
>>>
>>>  enum calibration_type {
>>>   TYPE_ONE_POINT_TRIMMING,
>>> @@ -64,6 +65,9 @@ enum calibration_type {
>>>   *   in the positive-TC generator block
>>>   *   0 <= reference_voltage <= 31
>>>   * @cal_type: calibration type for 

Re: RFC: Ideas for Linaro

[Loïc Minier]

On Wed, Jan 04, 2012, Joey STANFORD wrote:
> http://brainstorm.ubuntu.com/

 I love the concept and implementation of brainstorm -- +1 -- but will
 we commit to implementing x things per cycle from brainstorm.linaro.org
 if we start advertizing it?  The worst thing would be to give people a
 place to suggest work and then ... ignore it.

-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: RFC: Ideas for Linaro

[Amber Graner]

On 4 January 2012 18:18, Joey STANFORD  wrote:

> Hi Gang,
>
> During some roadmapping work today the discussion of capturing and
> voting on ideas for Linaro came up.  The idea was to possibly recreate
> a Linaro version of this
>
> http://brainstorm.ubuntu.com/
>
> for everyone to contribute to.  I'm looking for  +1 and -1  feedback
> from folks about whether this would be useful (vs interesting).
>

+1

I like brainstorm, though on the Ubuntu side I know it's been a struggle
lately to maintain, keep moderators and idea reviewers.  It's also my
understanding that the code base is not being actively maintained though
last month stgraber tracked down who maintains it (code base). Also we
would need to insure that ideas are being reviewed by decision makers say
at Linaro Connect and we either implement or close the ideas and let the
submitter know we have acted on their idea and not let people think the
ideas aren't being looked at.  This was one of the main complaints on the
Ubuntu side that no-one in a decision making role was looking at the ideas.

Cheers,
Amber

>
> Joey
>



-- 

Amber Graner

User Experience and Community Specialist



Linaro.org * **│ *Open source software for ARM SoCs*
***

Follow *Linaro: *Facebook  |
Twitter
 | Blog 


*+1.828.582.9469* cell
*+1.828.395.1049* office

irc: akgraner
amber.gra...@linaro.org  (email and Google chat)
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [U-Boot] [PATCH 4/6] EEYNOS: Add SMDK5250 board support

[Wolfgang Denk]

Dear Chander Kashyap,

In message  
you wrote:
>
> > No need to reuse the code, if SoCs are different.
> > If need, please separate the functions.
> 
> Yes, though SoC's are different, the functionality in clock.c is
> similar. The only difference is the clock name in the clock structure
> for Exynos4 and Exynos5 but the functionality is exactly same in
> clock.c. To accommodate this change in clock name #ifdef is used.

If this is the only difference, then I suggest just to rename the
field in thesta structure.  Although it makes sense to follow the names
in the documentation, it is sometimes better tochose a more suitable
name - a comment in the header file should be sufficient to explain
the rename (and to provide an anchor in case something greps for the
name as used in the docs).

Maybe we can avoid both #ifdef's and code duplication this way?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
What was sliced bread the greatest thing since?

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [U-Boot] [PATCH 4/6] EEYNOS: Add SMDK5250 board support

[Chander Kashyap]

Hi Minkyu Kang,

On 5 January 2012 12:13, Minkyu Kang  wrote:
> Dear Chander Kashyap,
>
> On 27 December 2011 17:48, Chander Kashyap  wrote:
 >  Torsten Koschorrek 
 >        scb9328         ARM920T (i.MXL)
 > diff --git a/arch/arm/cpu/armv7/exynos/clock.c 
 > b/arch/arm/cpu/armv7/exynos/clock.c
 > index b101f96..88e2fc0 100644
 > --- a/arch/arm/cpu/armv7/exynos/clock.c
 > +++ b/arch/arm/cpu/armv7/exynos/clock.c
 > @@ -125,10 +125,14 @@ static unsigned long exynos_get_pwm_clk(void)
 >
 >        if (s5p_get_cpu_rev() == 0) {
 >                /*
 > -                * CLK_SRC_PERIL0
 > +                * CLK_SRC_{PERIL0 | PERIC0}
 >                 * PWM_SEL [27:24]
 >                 */
 > +#ifdef CONFIG_EXYNOS5
 > +               sel = readl(&clk->src_peric0);
 > +#else
 >                sel = readl(&clk->src_peril0);
 > +#endif

 NAK.
 We don't allow to using ifdef for separating SoCs.
 Please refer s5pc1xx case for solve it.
 This comment apply to this patch globally.
 Please remove '#ifdef CONFIG_EXYNOS5'.

>>> I have tried to reuse the code. It is possible to remove
>>> #ifdef CONFIG_EXYNOS5' in clock.c with cpu_is_s5pcXXX check.
>>> Is it a acceptable solution? Or is it necessary to write SoC specific 
>>> function
>>> in clock.c as done in case of s5pc1xx/clock.c.
>>>
>>> Please Advice
>> Removing CONFIG_EXYNOS5 and following s5pc1xx case will not allow to
>> reuse the code in clock.c.
>> What is the technical hindrance of not using ifdefs?
>
> No need to reuse the code, if SoCs are different.
> If need, please separate the functions.

Yes, though SoC's are different, the functionality in clock.c is
similar. The only difference is the clock name in the clock structure
for Exynos4 and Exynos5 but the functionality is exactly same in
clock.c. To accommodate this change in clock name #ifdef is used.

Following is the function in clock .c which uses #ifdef to accommodate
the different clock name in SoC's.

static unsigned long exynos_get_pwm_clk(void)
{
struct exynos_clock *clk =
(struct exynos_clock *)samsung_get_base_clock();
unsigned long pclk, sclk;
unsigned int sel;
unsigned int ratio;

if (s5p_get_cpu_rev() == 0) {
/*
 * CLK_SRC_{PERIL0 | PERIC0}
 * PWM_SEL [27:24]
 */
#ifdef CONFIG_EXYNOS5
sel = readl(&clk->src_peric0);
#else
sel = readl(&clk->src_peril0);
#endif
sel = (sel >> 24) & 0xf;

if (sel == 0x6)
sclk = get_pll_clk(MPLL);
else if (sel == 0x7)
sclk = get_pll_clk(EPLL);
else if (sel == 0x8)
sclk = get_pll_clk(VPLL);
else
return 0;

/*
 * CLK_DIV_{PERIL3 | PERIC3}
 * PWM_RATIO [3:0]
 */
#ifdef CONFIG_EXYNOS5
ratio = readl(&clk->div_peric3);
#else
ratio = readl(&clk->div_peril3);
#endif
ratio = ratio & 0xf;
} else if (s5p_get_cpu_rev() == 1) {
sclk = get_pll_clk(MPLL);
ratio = 8;
} else
return 0;

pclk = sclk / (ratio + 1);

return pclk;
}

As listed above, the exynos_get_pwm_clk(() function is fully reusable
for both Exynos4 and Exynos5. The #ifdef was used to get around the
different clock names of Exynos4 and Exynos5.

Another option here could be, that the differing clock name
(src_peril0 for Exynos4 and src_peric0 for Exynos5) is resolved by
change the src_peric0 to src_peril0 for Exynos5, and clearly
commenting the reason for the deviation from the user manual. Would
this approach be acceptable ?

Thanks for your comments. Please let know your opinion about the
points listed in this email.


>
> like this,
>
> unsigned long get_arm_clk(void)
> {
>        if (cpu_is_s5pc110())
>                return s5pc110_get_arm_clk();
>        else
>                return s5pc100_get_arm_clk();
> }
>
> Thanks.
> Minkyu Kang
> --
> from. prom.
> www.promsoft.net



-- 
with warm regards,
Chander Kashyap

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: RFC: Ideas for Linaro

[Patrik Ryd]

We could just use https://www.google.com/moderator/#0.

 /Patrik

On 5 January 2012 00:18, Joey STANFORD  wrote:

> Hi Gang,
>
> During some roadmapping work today the discussion of capturing and
> voting on ideas for Linaro came up.  The idea was to possibly recreate
> a Linaro version of this
>
> http://brainstorm.ubuntu.com/
>
> for everyone to contribute to.  I'm looking for  +1 and -1  feedback
> from folks about whether this would be useful (vs interesting).
>
> Joey
>
> ___
> linaro-dev mailing list
> linaro-dev@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev