Hi Kevin,
On Friday 18 November 2011 01:05 AM, Kevin Hilman wrote:
Rajendra Nayak writes:
A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hm
On Thu, Nov 17, 2011 at 8:22 PM, Amit Kachhap wrote:
> On 11 November 2011 13:03, MyungJoo Ham wrote:
>> On Sat, Nov 5, 2011 at 2:03 AM, wrote:
>>> From: Amit Daniel Kachhap
>>>
>>> This patch adds support for AFTR(ARM OFF TOP RUNNING) mode in
>>> cpuidle driver for EXYNOS4210. L2 cache keeps
Rajendra Nayak writes:
> A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
> enabled state by the hwmod framework post the initial setup.
> Once a real user of the device (a driver) tries to enable it
> at a later point, the hmwod framework throws a WARN() about
> the device being already
Hi,
I'm about to finish my work on libunwind [1] and I'd like to give you a
brief overview on the different Android branches. The good news is that
- if you don't need to unwind via DWARF debug frame information [2] -
there are no additional patches required for Android. You can just pull
the
On Thu, Nov 17, 2011 at 12:26 PM, Thomas Abraham
wrote:
> For now, the Samsung GPIO, Pinconfig and Pinmux information is
> represented in device tree as listed below.
Does this mean that the understanding of this format is merged into
the mainline kernel drivers or is it keps out-of-tree?
> i2c
On Thursday 17 November 2011 04:09 PM, Cousson, Benoit wrote:
+ Paul
On 11/17/2011 11:11 AM, Rajendra Nayak wrote:
A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
a
On 17 November 2011 13:38, Linus Walleij wrote:
>> Linus,
>> Is there a plan to move even the data that exists in the pinmux
>> drivers today (including the function/pin-groups definition)
>> eventually to DT? Or is it just the 'mapping' data to map
>> devices to functions (that today is done from
On 11 November 2011 13:03, MyungJoo Ham wrote:
> On Sat, Nov 5, 2011 at 2:03 AM, wrote:
>> From: Amit Daniel Kachhap
>>
>> This patch adds support for AFTR(ARM OFF TOP RUNNING) mode in
>> cpuidle driver for EXYNOS4210. L2 cache keeps their data in this mode.
>> This patch ports the code to the
On Thu, Nov 17, 2011 at 3:41 PM, Rajendra Nayak wrote:
> A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
> enabled state by the hwmod framework post the initial setup.
> Once a real user of the device (a driver) tries to enable it
> at a later point, the hmwod framework throws a WARN() ab
On Thursday 17 November 2011 01:50 PM, Linus Walleij wrote:
On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayak wrote:
(...)
+ * The OMAP control module has a device-control sub-module
+ * which handles all pin/padmuxing for OMAP. The sub-module
+ * is further split into a 'core' instance within t
+ Paul
On 11/17/2011 11:11 AM, Rajendra Nayak wrote:
A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hmwod framework throws a WARN() about
ty
[]...
Why do we have to idle -> enable? The module is already enabled, isn't
it?
The comment is not super clear for me :-)
Is the goal is to reset the IP?
Yes, now that I read it, it does sound confusing. I should have at-least
read it once before I picked it from serial.c
But anyway, here's
A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hmwod framework throws a WARN() about
the device being already in enabled state.
Fix this by intr
A hwmod with a 'HWMOD_INIT_NO_IDLE' flag set, is left in
enabled state by the hwmod framework post the initial setup.
Once a real user of the device (a driver) tries to enable it
at a later point, the hmwod framework throws a WARN() about
the device being already in enabled state.
Fix this by intr
Hi Rajendra,
On 11/17/2011 8:19 AM, Rajendra Nayak wrote:
[...]
+static int omap_console_hwmod_enable(struct omap_device *od)
+{
+ console_lock();
+ /*
+ * For early console we prevented hwmod reset and idle
A period is missing. Or maybe it should a comma with not capital letter.
+ * So bef
On Tue, Nov 15, 2011 at 6:36 AM, Rajendra Nayak wrote:
> Fix some minor typos in the pinctrl documentation.
(...)
> -the pins from 0 in the upper left corner to 63 in the lower right corner,
> +the pins from 0 in the lower left corner to 63 in the upper right corner,
It's the PINCTRL_PIN() defin
On Thursday 17 November 2011 06:34 AM, Rob Herring wrote:
On 11/16/2011 05:02 AM, Rajendra Nayak wrote:
Pass minimal data needed for console boot, from dt, for
OMAP4 panda/sdp and OMAP3 beagle boards, and get rid of the
static initialization from generic board file.
Signed-off-by: Rajendra Naya
On Wednesday 16 November 2011 08:29 PM, Rob Herring wrote:
On 11/16/2011 05:02 AM, Rajendra Nayak wrote:
Adapt the driver to device tree and pass minimal platform
data from device tree needed for console boot.
No power management features will be suppported for now
since it requires more tweaks
On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayak wrote:
> These are still early patches, but I wanted to get
> some feedback on if I am heading in the right direction.
> Hence sharing these in the current form.
The platform pieces look good! We need to discuss about
the driver and needed infrastr
On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayak wrote:
(...)
> + * The OMAP control module has a device-control sub-module
> + * which handles all pin/padmuxing for OMAP. The sub-module
> + * is further split into a 'core' instance within the CORE
> + * powerdomain and a 'wkup' instance within th
On Tue, Nov 15, 2011 at 5:33 AM, Rajendra Nayak wrote:
> On Monday 14 November 2011 10:53 PM, Tony Lindgren wrote:
>> * Rajendra Nayak [14 04:05]:
>>>
>>> > +static const struct pinctrl_pin_desc omap4_core_pads[] = {
>>> > + PINCTRL_PIN(0, "c12"),
>>> > + PINCTRL_PIN(1, "d12"),
>>> >
On Tue, Nov 15, 2011 at 7:40 AM, Rajendra Nayak wrote:
> Fix u300_pmx_endisable() to iterate over the list of 'bits' and
> 'mask' populated as part of u300_pmx_functions.mask[]
>
> Signed-off-by: Rajendra Nayak
> ---
> Linus W,
> I am not sure if this is a right fix. I just stumbled
> upon this
22 matches
Mail list logo
