Re: [PATCH v3 6/6] mmc: sdhci-s3c: Add device tree support

2012-04-09 Thread Chris Ball 
Hi Arnd,

On Fri, Mar 30 2012, Arnd Bergmann wrote:
> On Friday 30 March 2012, Viresh Kumar wrote:
>> On 3/27/2012 9:49 PM, Arnd Bergmann wrote:
>> > These bindings came up in a discussion IRC today. I think it's rather bad 
>> > that
>> > we can't agree on a common way to name the properties for mmc. We have
>> > bindings being proposed or already included from Anton, Stephen, Shawn,
>> > Rajendra, Viresh, Lee and Thomas. Almost all of them define GPIO pins
>> > for card detect and write protect, as well properties to define the bus
>> > width and high-speed modes, but we seem to have almost as many different
>> > definitions of these as we have drivers.
>> > 
>> > Can we please come up with a common binding for these?
>> 
>> Is there any progress on this? Sorry i wasn't following all mails.
>> How should i progress for sdhci-spear?
>
> No progress so far. I would suggest we apply the patch below to unify
> the bindings we have. I tried to minimize the impact by picking the most
> common version for each property, but if we know about devices that would
> get broken by this, we may have to be more careful.
>
> Signed-off-by: Arnd Bergmann 

Thanks very much for doing this -- I'll be happy to take the patch in
mmc-next once you get time to post a v2 covering Stephen Warren's review
comments (and adding "max-frequency" to the document, I guess).

- Chris.
-- 
Chris Ball  
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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/1] dmaengine/amba-pl08x: Add support for s3c64xx DMAC

2012-04-09 Thread Linus Walleij 
On Thu, Dec 8, 2011 at 2:03 AM, Alim Akhtar  wrote:

> Hello Linus,
> sorry for the delay in submitting V3 of the pl080 patches for s3c64xx.
> I am very busy with my current assignment.
> I will come back to my patch series incorporating yours and Viresh
> suggestions in v3.

Ping!

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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] thermal: exynos: Add kernel thermal support for exynos platform

2012-04-09 Thread Zhang Rui 
Hi, Amit,

On δΈ‰, 2012-04-04 at 10:02 +0530, Amit Kachhap wrote:
> Hi Len/Rui,
> 
> Any comment or feedback from your side about the status of this patch?
> Is it merge-able or major re-work is needed? I have fixed most of the
> comments in this patchset and currently working on some of the minor
> comments received and will submit them shortly.
> 
Sorry for the late response.

First of all, it makes sense to me to introduce the generic cpufrq
cooling implementation.
But I still have some questions.
I think the key reason why THERMAL_TRIP_STATE_INSTANCE is introduced is
that the MONIROR_ZONE and WARN_ZONE on exynos4 can not fit into the
current passive handling in the generic thermal layer well, right?
e.g. there is no tc1/tc2 on exynos4.

If yes, is it possible that we can enhance the passive cooling to
support the generic processor cooling?
say, introduce another way to throttle the processor in
thermal_zone_device_passive when tc1 and tc2 are not available?

thanks,
rui

> Regards,
> Amit Daniel
> 
> On 19 March 2012 11:47, Amit Daniel Kachhap  wrote:
> > Changes since V1:
> > *Moved the sensor driver to driver/thermal folder from driver/hwmon folder
> >  as suggested by Mark Brown and Guenter Roeck
> > *Added notifier support to notify the registered drivers of any cpu cooling
> >  action. The driver can modify the default cooling behaviour(eg set 
> > different
> >  max clip frequency).
> > *The percentage based frequency replaced with absolute clipped frequency.
> > *Some more conditional checks when setting max frequency.
> > *Renamed the new trip type THERMAL_TRIP_STATE_ACTIVE to
> >  THERMAL_TRIP_STATE_INSTANCE
> > *Many review comments from R, Durgadoss  and
> >  eduardo.valen...@ti.com implemented.
> > *Removed cooling stats through debugfs patch
> > *The V1 based can be found here,
> >  https://lkml.org/lkml/2012/2/22/123
> >  http://lkml.org/lkml/2012/3/3/32
> >
> > Changes since RFC:
> > *Changed the cpu cooling registration/unregistration API's to instance based
> > *Changed the STATE_ACTIVE trip type to pass correct instance id
> > *Adding support to restore back the policy->max_freq after doing frequency
> >  clipping.
> > *Moved the trip cooling stats from sysfs node to debugfs node as suggested
> >  by Greg KH g...@kroah.com
> > *Incorporated several review comments from eduardo.valen...@ti.com
> > *Moved the Temperature sensor driver from driver/hwmon/ to driver/mfd
> >  as discussed with Guenter Roeck  and
> >  Donggeun Kim  (https://lkml.org/lkml/2012/1/5/7)
> > *Some changes according to the changes in common cpu cooling APIs
> > *The RFC based patches can be found here,
> >  https://lkml.org/lkml/2011/12/13/186
> >  https://lkml.org/lkml/2011/12/21/169
> >
> >
> > Brief Description:
> >
> > 1) The generic cooling devices code is placed inside driver/thermal/* as
> > placing inside acpi folder will need un-necessary enabling of acpi code. 
> > This
> > codes is architecture independent.
> >
> > 2) This patchset adds a new trip type THERMAL_TRIP_STATE_INSTANCE which 
> > passes
> > cooling device instance number and may be helpful for cpufreq cooling 
> > devices
> > to take the correct cooling action. This trip type avoids the temperature
> > comparision check again inside the cooling handler.
> >
> > 3) This patchset adds generic cpu cooling low level implementation through
> > frequency clipping and cpu hotplug. In future, other cpu related cooling
> > devices may be added here. An ACPI version of this already exists
> > (drivers/acpi/processor_thermal.c). But this will be useful for platforms
> > like ARM using the generic thermal interface along with the generic cpu
> > cooling devices. The cooling device registration API's return cooling device
> > pointers which can be easily binded with the thermal zone trip points.
> > The important APIs exposed are,
> >   a)struct thermal_cooling_device *cpufreq_cooling_register(
> >struct freq_clip_table *tab_ptr, unsigned int tab_size,
> >const struct cpumask *mask_val)
> >   b)void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev)
> >
> > 4) Samsung exynos platform thermal implementation is done using the generic
> > cpu cooling APIs and the new trip type. The temperature sensor driver 
> > present
> > in the hwmon folder(registered as hwmon driver) is moved to thermal folder
> > and registered as a thermal driver.
> >
> > All this patchset is based on Kernel version 3.3-rc7
> >
> > A simple data/control flow diagrams is shown below,
> >
> > Core Linux thermal <->  Exynos thermal interface <- Temperature 
> > Sensor
> >  | |
> > \|/|
> >  Cpufreq cooling device <---
> >
> >
> > Amit Daniel Kachhap (6):
> >  thermal: Add a new trip type to use cooling device instance number
> >  thermal: Add generic cpufreq cooling implementation
> >  thermal: Add generic cpuhotplug cooling implementation
> >  hwmon: exynos4: Move therma