* [Bug 17692] Intermittent failure to resume from suspend-to-ram in radeon_bo_get_surface_reg with RV515 and ColorTiling
From: bugzilla-daemon @ 2010-10-07 22:21 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-17692-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=17692
--- Comment #7 from Karl Tomlinson <bugs+kernel@karlt.net> 2010-10-07 22:21:46 ---
FWIW, I'm still seeing "I'm still seeing the same "stuck in loop for more than
5sec" messages, so that seems unrelated.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
--
^ permalink raw reply
* [Bug 17692] Intermittent failure to resume from suspend-to-ram in radeon_bo_get_surface_reg with RV515 and ColorTiling
From: bugzilla-daemon @ 2010-10-07 22:19 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-17692-2300@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=17692
Karl Tomlinson <bugs+kernel@karlt.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Intermittent failure to |Intermittent failure to
|resume from suspend-to-ram |resume from suspend-to-ram
|in |in
|radeon_bo_get_surface_reg |radeon_bo_get_surface_reg
|with RV515 |with RV515 and ColorTiling
--- Comment #6 from Karl Tomlinson <bugs+kernel@karlt.net> 2010-10-07 22:19:50 ---
Yes, seems that switching off ColorTiling works around the issue.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
--
^ permalink raw reply
* Re: Question about the ability of credit scheduler to handle I/O and CPU intensive VMs
From: Yuehai Xu @ 2010-10-07 22:18 UTC (permalink / raw)
To: George Dunlap; +Cc: xen-devel, yhxu
In-Reply-To: <AANLkTi=r2MzCwwNbNDopBkoCWvQSc=jkeWUy8hxKYD3_@mail.gmail.com>
> Your understanding of Xen is not correct. In Xen, the VM itself will
> initiate blocking if there is nothing for it to do. PV domains call
> SCHED_OP_block(), which will cause the VM to block until it is woken
> by an event channel; and HVM domains will execute the HLT instruction,
> which will cause the VM to block until it is woken by an interrupt.
>
> If you do a more complete trace (i.e., "xentrace -e all") and look at
> the results with xenalyze, you'll see dom2 making a sched_op
> hypercall, then transitioning from RUNSTATE_running to
> RUNSTATE_blocked.
>
I originally considered that when a Dom has an I/O event, its VCPU
would be waken up, in another word, csched_vcpu_wake(struct vcpu *vc)
should be invoked. However, I find I am definitely wrong. As long as
there is a CPU intensive program running in a Dom, this Dom should
never be in a state of "sleep"? In another word, it should never be
waken up?
In such case, suppose there is an I/O event for a VM, how can I insert
this VM schedule entity into the head of the link list and make
schedule() work immediately? I tried in the function of
csched_vcpu_wake, but since this VM also has CPU intensive program,
the throughput of I/O makes no difference.
I feel that in order to make VM that has I/O scheduled as soon as
possible(without considering CPU fairness), other files should be
modified besides csched_credit.c. But where it is?
I really appreciate your help.
Thanks,
Yuehai
^ permalink raw reply
* Re: [PATCH 1/2] drivers:bluetooth: TI_ST bluetooth driver
From: Greg KH @ 2010-10-07 22:17 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: Marcel Holtmann, pavan-savoy, linux-bluetooth, johan.hedberg,
linux-kernel, Pavan Savoy
In-Reply-To: <20101007190906.GE4893@vigoh>
On Thu, Oct 07, 2010 at 04:09:06PM -0300, Gustavo F. Padovan wrote:
> * Greg KH <greg@kroah.com> [2010-10-07 14:30:18 -0700]:
>
> > On Thu, Oct 07, 2010 at 02:51:48PM -0300, Gustavo F. Padovan wrote:
> > > Hi Greg,
> > >
> > > * Greg KH <greg@kroah.com> [2010-10-07 07:34:09 -0700]:
> > >
> > > > On Thu, Oct 07, 2010 at 12:05:48PM +0200, Marcel Holtmann wrote:
> > > > > Hi Pavan,
> > > > >
> > > > > > This is the bluetooth protocol driver for the TI WiLink7 chipsets.
> > > > > > Texas Instrument's WiLink chipsets combine wireless technologies
> > > > > > like BT, FM, GPS and WLAN onto a single chip.
> > > > > >
> > > > > > This Bluetooth driver works on top of the TI_ST shared transport
> > > > > > line discipline driver which also allows other drivers like
> > > > > > FM V4L2 and GPS character driver to make use of the same UART interface.
> > > > > >
> > > > > > Signed-off-by: Pavan Savoy <pavan_savoy@ti.com>
> > > > > > ---
> > > > > > drivers/bluetooth/bt_ti.c | 463 ++++++++++++++++++++++++++++++++++++
> > > > > > drivers/staging/ti-st/bt_drv.c | 509 ----------------------------------------
> > > > > > drivers/staging/ti-st/bt_drv.h | 61 -----
> > > > > > 3 files changed, 463 insertions(+), 570 deletions(-)
> > > > > > create mode 100644 drivers/bluetooth/bt_ti.c
> > > > > > delete mode 100644 drivers/staging/ti-st/bt_drv.c
> > > > > > delete mode 100644 drivers/staging/ti-st/bt_drv.h
> > > > >
> > > > > I don't care about staging at all. So you sort that out with Greg.
> > > > >
> > > > > Submit your driver for upstream inclusion. And once accepted you can pin
> > > > > Greg about removing it.
> > > >
> > > > The driver is already in staging, this is the request to move it out of
> > > > staging and into the "correct" place in the tree. The core of the ti-st
> > > > code is now in the drivers/misc/ directory in the linux-next tree, and
> > > > this patch is the request to move the bluetooth drive into the proper
> > > > drivers/bluetooth/ location.
> > >
> > > I'm wondering why this driver never touched linux-bluetooth before. It
> > > is on staging because it is not ready for a proper merge and while it is
> > > not ready it needs the comments from the bluetooth developers here to
> > > get it ready for merge in drivers/bluetooth. So why this never arrived
> > > here before?
> >
> > This is the exact reason _why_ it is being sent here now. To get the
> > review of the bluetooth developers for any changes that are needed to
> > get it merged into the proper place in the tree.
>
> Yes, but IMHO it took to long, from what I looked this drivers was merged
> in stage about May and the patches arrived in linux-bluetooth only in
> October. Is there a reason for such delay?
It took that long to get the "obvious" things fixed up.
> That's is something we need to fix for the next bluetooth drivers we
> want to merge, so the developers can get feedback earlier.
If you want to be notified of staging drivers that affect the bluetooth
stuff earlier, fine, I'll let you know. Otherwise, no other subsystem
has asked for such notification, preferring to let the stable stuff stay
alone in the directory until it at least achieves a basic "clean" level.
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH] power: introduce library for device-specific OPPs
From: Menon, Nishanth @ 2010-10-07 22:15 UTC (permalink / raw)
To: Kevin Hilman; +Cc: Rafael J. Wysocki, linux-pm, lkml, l-o, l-a, Paul
In-Reply-To: <87fwwh7isu.fsf@deeprootsystems.com>
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Thursday, October 07, 2010 5:14 PM
> To: Menon, Nishanth
> Cc: Rafael J. Wysocki; linux-pm; lkml; l-o; l-a; Paul
> Subject: Re: [PATCH] power: introduce library for device-specific OPPs
>
[...]
> >> > +static int opp_set_availability(struct device *dev, unsigned long
> freq,
> >> > + bool availability_req)
> >> > +{
> >> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
> >> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
> >> > + int r = 0;
> >> > +
> >> > + /* keep the node allocated */
> >> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
> >> > + if (!new_opp) {
> >> > + pr_warning("Unable to allocate opp\n");
> >>
> >> Please add an identification string to the messages, something like
> >> "OPP: Unable to allocat object\n" (and similarly in the other messages).
> >> That would help to find the source of a message in case there's any
> >> problem.
> >
> > pr_fmt has been reformatted for this. The actual message which will
> appear
> > is as follows:
> > opp_set_availability: Unable to allocate opp
> >
> > is'nt that good enough considering that all functions are opp_ prefixed?
> > I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But
> I
> > have no strong opinions on that and look forward to your recommendations.
>
> Even more informative would be to use dev_warn() and include the func.
> That way we'll even know which device has the problem.
Ack. Thanks. Yeah, this is better.. will do the change.
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] power: introduce library for device-specific OPPs
From: Menon, Nishanth @ 2010-10-07 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fwwh7isu.fsf@deeprootsystems.com>
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman at deeprootsystems.com]
> Sent: Thursday, October 07, 2010 5:14 PM
> To: Menon, Nishanth
> Cc: Rafael J. Wysocki; linux-pm; lkml; l-o; l-a; Paul
> Subject: Re: [PATCH] power: introduce library for device-specific OPPs
>
[...]
> >> > +static int opp_set_availability(struct device *dev, unsigned long
> freq,
> >> > + bool availability_req)
> >> > +{
> >> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
> >> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
> >> > + int r = 0;
> >> > +
> >> > + /* keep the node allocated */
> >> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
> >> > + if (!new_opp) {
> >> > + pr_warning("Unable to allocate opp\n");
> >>
> >> Please add an identification string to the messages, something like
> >> "OPP: Unable to allocat object\n" (and similarly in the other messages).
> >> That would help to find the source of a message in case there's any
> >> problem.
> >
> > pr_fmt has been reformatted for this. The actual message which will
> appear
> > is as follows:
> > opp_set_availability: Unable to allocate opp
> >
> > is'nt that good enough considering that all functions are opp_ prefixed?
> > I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But
> I
> > have no strong opinions on that and look forward to your recommendations.
>
> Even more informative would be to use dev_warn() and include the func.
> That way we'll even know which device has the problem.
Ack. Thanks. Yeah, this is better.. will do the change.
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH] power: introduce library for device-specific OPPs
From: Menon, Nishanth @ 2010-10-07 22:15 UTC (permalink / raw)
To: Kevin Hilman; +Cc: l-o, lkml, linux-pm, Paul, l-a
In-Reply-To: <87fwwh7isu.fsf@deeprootsystems.com>
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Thursday, October 07, 2010 5:14 PM
> To: Menon, Nishanth
> Cc: Rafael J. Wysocki; linux-pm; lkml; l-o; l-a; Paul
> Subject: Re: [PATCH] power: introduce library for device-specific OPPs
>
[...]
> >> > +static int opp_set_availability(struct device *dev, unsigned long
> freq,
> >> > + bool availability_req)
> >> > +{
> >> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
> >> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
> >> > + int r = 0;
> >> > +
> >> > + /* keep the node allocated */
> >> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
> >> > + if (!new_opp) {
> >> > + pr_warning("Unable to allocate opp\n");
> >>
> >> Please add an identification string to the messages, something like
> >> "OPP: Unable to allocat object\n" (and similarly in the other messages).
> >> That would help to find the source of a message in case there's any
> >> problem.
> >
> > pr_fmt has been reformatted for this. The actual message which will
> appear
> > is as follows:
> > opp_set_availability: Unable to allocate opp
> >
> > is'nt that good enough considering that all functions are opp_ prefixed?
> > I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But
> I
> > have no strong opinions on that and look forward to your recommendations.
>
> Even more informative would be to use dev_warn() and include the func.
> That way we'll even know which device has the problem.
Ack. Thanks. Yeah, this is better.. will do the change.
Regards,
Nishanth Menon
^ permalink raw reply
* RE: [PATCH] power: introduce library for device-specific OPPs
From: Menon, Nishanth @ 2010-10-07 22:15 UTC (permalink / raw)
To: Kevin Hilman; +Cc: l-o, lkml, Rafael J. Wysocki, linux-pm, Paul, l-a
In-Reply-To: <87fwwh7isu.fsf@deeprootsystems.com>
> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> Sent: Thursday, October 07, 2010 5:14 PM
> To: Menon, Nishanth
> Cc: Rafael J. Wysocki; linux-pm; lkml; l-o; l-a; Paul
> Subject: Re: [PATCH] power: introduce library for device-specific OPPs
>
[...]
> >> > +static int opp_set_availability(struct device *dev, unsigned long
> freq,
> >> > + bool availability_req)
> >> > +{
> >> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
> >> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
> >> > + int r = 0;
> >> > +
> >> > + /* keep the node allocated */
> >> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
> >> > + if (!new_opp) {
> >> > + pr_warning("Unable to allocate opp\n");
> >>
> >> Please add an identification string to the messages, something like
> >> "OPP: Unable to allocat object\n" (and similarly in the other messages).
> >> That would help to find the source of a message in case there's any
> >> problem.
> >
> > pr_fmt has been reformatted for this. The actual message which will
> appear
> > is as follows:
> > opp_set_availability: Unable to allocate opp
> >
> > is'nt that good enough considering that all functions are opp_ prefixed?
> > I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But
> I
> > have no strong opinions on that and look forward to your recommendations.
>
> Even more informative would be to use dev_warn() and include the func.
> That way we'll even know which device has the problem.
Ack. Thanks. Yeah, this is better.. will do the change.
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH] power: introduce library for device-specific OPPs
From: Kevin Hilman @ 2010-10-07 22:13 UTC (permalink / raw)
To: Menon, Nishanth; +Cc: Rafael J. Wysocki, linux-pm, lkml, l-o, l-a, Paul
In-Reply-To: <7A436F7769CA33409C6B44B358BFFF0C014F748B07@dlee02.ent.ti.com>
"Menon, Nishanth" <nm@ti.com> writes:
>> -----Original Message-----
>> From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
>> Sent: Thursday, October 07, 2010 4:55 PM
>
>
>>
>> Hi,
>>
>> On Wednesday, October 06, 2010, Nishanth Menon wrote:
>> > SoCs have a standard set of tuples consisting of frequency and
>> > voltage pairs that the device will support per voltage domain. These
>> > are called Operating Performance Points or OPPs. The actual
>> > definitions of OPP varies over silicon versions. For a specific domain,
>> > we can have a set of {frequency, voltage} pairs. As the kernel boots
>> > and more information is available, a default set of these are activated
>> > based on the precise nature of device. Further on operation, based on
>> > conditions prevailing in the system (such as temperature), some OPP
>> > availability may be temporarily controlled by the SoC frameworks.
>> >
>> > To implement an OPP, some sort of power management support is necessary
>> > hence this library depends on CONFIG_PM.
>>
>> The patch generally looks good to me, I only have a couple of cosmetic
> Thanks for the great reviews.. It did bump up the resultant patch.
>
>> remarks
>> (below).
>>
>> ...
>> > +static int opp_set_availability(struct device *dev, unsigned long freq,
>> > + bool availability_req)
>> > +{
>> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
>> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
>> > + int r = 0;
>> > +
>> > + /* keep the node allocated */
>> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
>> > + if (!new_opp) {
>> > + pr_warning("Unable to allocate opp\n");
>>
>> Please add an identification string to the messages, something like
>> "OPP: Unable to allocat object\n" (and similarly in the other messages).
>> That would help to find the source of a message in case there's any
>> problem.
>
> pr_fmt has been reformatted for this. The actual message which will appear
> is as follows:
> opp_set_availability: Unable to allocate opp
>
> is'nt that good enough considering that all functions are opp_ prefixed?
> I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But I
> have no strong opinions on that and look forward to your recommendations.
Even more informative would be to use dev_warn() and include the func.
That way we'll even know which device has the problem.
Kevin
^ permalink raw reply
* [PATCH] power: introduce library for device-specific OPPs
From: Kevin Hilman @ 2010-10-07 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7A436F7769CA33409C6B44B358BFFF0C014F748B07@dlee02.ent.ti.com>
"Menon, Nishanth" <nm@ti.com> writes:
>> -----Original Message-----
>> From: Rafael J. Wysocki [mailto:rjw at sisk.pl]
>> Sent: Thursday, October 07, 2010 4:55 PM
>
>
>>
>> Hi,
>>
>> On Wednesday, October 06, 2010, Nishanth Menon wrote:
>> > SoCs have a standard set of tuples consisting of frequency and
>> > voltage pairs that the device will support per voltage domain. These
>> > are called Operating Performance Points or OPPs. The actual
>> > definitions of OPP varies over silicon versions. For a specific domain,
>> > we can have a set of {frequency, voltage} pairs. As the kernel boots
>> > and more information is available, a default set of these are activated
>> > based on the precise nature of device. Further on operation, based on
>> > conditions prevailing in the system (such as temperature), some OPP
>> > availability may be temporarily controlled by the SoC frameworks.
>> >
>> > To implement an OPP, some sort of power management support is necessary
>> > hence this library depends on CONFIG_PM.
>>
>> The patch generally looks good to me, I only have a couple of cosmetic
> Thanks for the great reviews.. It did bump up the resultant patch.
>
>> remarks
>> (below).
>>
>> ...
>> > +static int opp_set_availability(struct device *dev, unsigned long freq,
>> > + bool availability_req)
>> > +{
>> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
>> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
>> > + int r = 0;
>> > +
>> > + /* keep the node allocated */
>> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
>> > + if (!new_opp) {
>> > + pr_warning("Unable to allocate opp\n");
>>
>> Please add an identification string to the messages, something like
>> "OPP: Unable to allocat object\n" (and similarly in the other messages).
>> That would help to find the source of a message in case there's any
>> problem.
>
> pr_fmt has been reformatted for this. The actual message which will appear
> is as follows:
> opp_set_availability: Unable to allocate opp
>
> is'nt that good enough considering that all functions are opp_ prefixed?
> I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But I
> have no strong opinions on that and look forward to your recommendations.
Even more informative would be to use dev_warn() and include the func.
That way we'll even know which device has the problem.
Kevin
^ permalink raw reply
* Re: [PATCH] power: introduce library for device-specific OPPs
From: Kevin Hilman @ 2010-10-07 22:13 UTC (permalink / raw)
To: Menon, Nishanth; +Cc: l-o, lkml, linux-pm, Paul, l-a
In-Reply-To: <7A436F7769CA33409C6B44B358BFFF0C014F748B07@dlee02.ent.ti.com>
"Menon, Nishanth" <nm@ti.com> writes:
>> -----Original Message-----
>> From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
>> Sent: Thursday, October 07, 2010 4:55 PM
>
>
>>
>> Hi,
>>
>> On Wednesday, October 06, 2010, Nishanth Menon wrote:
>> > SoCs have a standard set of tuples consisting of frequency and
>> > voltage pairs that the device will support per voltage domain. These
>> > are called Operating Performance Points or OPPs. The actual
>> > definitions of OPP varies over silicon versions. For a specific domain,
>> > we can have a set of {frequency, voltage} pairs. As the kernel boots
>> > and more information is available, a default set of these are activated
>> > based on the precise nature of device. Further on operation, based on
>> > conditions prevailing in the system (such as temperature), some OPP
>> > availability may be temporarily controlled by the SoC frameworks.
>> >
>> > To implement an OPP, some sort of power management support is necessary
>> > hence this library depends on CONFIG_PM.
>>
>> The patch generally looks good to me, I only have a couple of cosmetic
> Thanks for the great reviews.. It did bump up the resultant patch.
>
>> remarks
>> (below).
>>
>> ...
>> > +static int opp_set_availability(struct device *dev, unsigned long freq,
>> > + bool availability_req)
>> > +{
>> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
>> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
>> > + int r = 0;
>> > +
>> > + /* keep the node allocated */
>> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
>> > + if (!new_opp) {
>> > + pr_warning("Unable to allocate opp\n");
>>
>> Please add an identification string to the messages, something like
>> "OPP: Unable to allocat object\n" (and similarly in the other messages).
>> That would help to find the source of a message in case there's any
>> problem.
>
> pr_fmt has been reformatted for this. The actual message which will appear
> is as follows:
> opp_set_availability: Unable to allocate opp
>
> is'nt that good enough considering that all functions are opp_ prefixed?
> I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But I
> have no strong opinions on that and look forward to your recommendations.
Even more informative would be to use dev_warn() and include the func.
That way we'll even know which device has the problem.
Kevin
^ permalink raw reply
* Re: [PATCH] power: introduce library for device-specific OPPs
From: Kevin Hilman @ 2010-10-07 22:13 UTC (permalink / raw)
To: Menon, Nishanth; +Cc: Rafael J. Wysocki, linux-pm, lkml, l-o, l-a, Paul
In-Reply-To: <7A436F7769CA33409C6B44B358BFFF0C014F748B07@dlee02.ent.ti.com>
"Menon, Nishanth" <nm@ti.com> writes:
>> -----Original Message-----
>> From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
>> Sent: Thursday, October 07, 2010 4:55 PM
>
>
>>
>> Hi,
>>
>> On Wednesday, October 06, 2010, Nishanth Menon wrote:
>> > SoCs have a standard set of tuples consisting of frequency and
>> > voltage pairs that the device will support per voltage domain. These
>> > are called Operating Performance Points or OPPs. The actual
>> > definitions of OPP varies over silicon versions. For a specific domain,
>> > we can have a set of {frequency, voltage} pairs. As the kernel boots
>> > and more information is available, a default set of these are activated
>> > based on the precise nature of device. Further on operation, based on
>> > conditions prevailing in the system (such as temperature), some OPP
>> > availability may be temporarily controlled by the SoC frameworks.
>> >
>> > To implement an OPP, some sort of power management support is necessary
>> > hence this library depends on CONFIG_PM.
>>
>> The patch generally looks good to me, I only have a couple of cosmetic
> Thanks for the great reviews.. It did bump up the resultant patch.
>
>> remarks
>> (below).
>>
>> ...
>> > +static int opp_set_availability(struct device *dev, unsigned long freq,
>> > + bool availability_req)
>> > +{
>> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
>> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
>> > + int r = 0;
>> > +
>> > + /* keep the node allocated */
>> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
>> > + if (!new_opp) {
>> > + pr_warning("Unable to allocate opp\n");
>>
>> Please add an identification string to the messages, something like
>> "OPP: Unable to allocat object\n" (and similarly in the other messages).
>> That would help to find the source of a message in case there's any
>> problem.
>
> pr_fmt has been reformatted for this. The actual message which will appear
> is as follows:
> opp_set_availability: Unable to allocate opp
>
> is'nt that good enough considering that all functions are opp_ prefixed?
> I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But I
> have no strong opinions on that and look forward to your recommendations.
Even more informative would be to use dev_warn() and include the func.
That way we'll even know which device has the problem.
Kevin
^ permalink raw reply
* How to modify /etc/network/interfaces file in a OE recipe
From: Elvis Dowson @ 2010-10-07 21:11 UTC (permalink / raw)
To: OpenEmbedded Developer Mailing List
Hi,
Would someone be able to help me with modifying an omap3-console-image recipe, such that in the final image, the /etc/network/interfaces file gets edited as follows
#auto eth0 <- remove # sign ( auto eth0 )
#iface eth0 inet dhcp <- remove # sign ( iface eth0 inet dhcp )
#iface eth1 inet dhcp
I am using a Gumstix Overo + Chestnut43 expansion board, which has an inbuilt wired ethernet interface. I have to make this modification manually, to enable this interface each time. However, if I can modify the OE recipe somehow to do this it would be great. I know it can be done, but I don't know where to start and which file to modify.
Elvis Dowson
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Daniel Walker @ 2010-10-07 22:11 UTC (permalink / raw)
To: Greg KH
Cc: Alan Cox, linux-kernel, Hyok S. Choi, Tony Lindgren,
Jeff Ohlstein, Ben Dooks, Alan Cox, Kukjin Kim, Mike Frysinger,
Feng Tang, Tobias Klauser, Jason Wessel, Philippe Langlais
In-Reply-To: <20101007215221.GA11478@suse.de>
On Thu, 2010-10-07 at 14:52 -0700, Greg KH wrote:
> On Thu, Oct 07, 2010 at 02:47:18PM -0700, Daniel Walker wrote:
> > On Thu, 2010-10-07 at 14:15 -0700, Greg KH wrote:
> > > On Thu, Oct 07, 2010 at 01:51:18PM -0700, Daniel Walker wrote:
> > > > Your making too many assumptions .. You might be able to modify the
> > > > kernel, and not the userspace. So you couldn't tweak the device
> > > > creation .. It's much easier in the server world ..
> > >
> > > You're saying it's easier to replace an embedded kernel than a userspace
> > > file on an embedded system? Heh, that's funny.
> >
> > I'm saying it _can_ happen that it's easier to replace the kernel.. I'm
> > not saying it's always the case. We're talking about debugging
> > situations in an embedded environment which don't always follow a normal
> > path.
>
> Nothing is "normal", so stop trying to say it is easier in the "server"
> world please.
Ok ..
> > > > > We've said no over a period of about ten years to a lot of attempts to
> > > > > just borrow the ttyS0 range. If we'd said yes it would have been a
> > > > > complete mess by now.
> > > > >
> > > > > So the answer is no.
> > > >
> > > > Nothing can be unilateral, there's always room for exceptions. You
> > > > should say something more like "it's possible, but unlikely".
> > >
> > > Hm, how about this, as the TTY and serial driver[1] maintainer, I will
> > > not accept this kind of patch at all.
> > >
> > > Is that final enough for you?
> >
> > So you don't like it, that's fair enough .. <thinks>I wonder what other
> > maintainers I can send this too</thinks> ;)
> >
> > Can you be more specific about your objections
>
> See everything that Mike and Alan wrote, do I need to repeat it?
I'm not sure .. I would say "Yes" if I didn't get the feeling your
already to tear my head off.
I think the only disputed issue is the use of ttyS as options part of
the driver ..
Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Greg KH @ 2010-10-07 22:10 UTC (permalink / raw)
To: Feng Kan
Cc: linux-usb, David Daney, Rina Kagan, linuxppc-dev, Mark Miesfeld,
Ted Chan, Fushen Chen
In-Reply-To: <AANLkTinzG_g2--E5SwzEK6qK8NR+ewWJJU0UXsoWveP6@mail.gmail.com>
On Thu, Oct 07, 2010 at 03:01:33PM -0700, Feng Kan wrote:
> Hi Greg:
>
> We have obtained GPL 2 only header from Synopsis. We have also identified all
> parties that contributed to the code base and contacted them regarding
> license change.
> Any party that we could not reach, we will remove the patch from the submission.
> Let me know if this is sufficient for resubmission.
Yes, that sounds fine, thanks for doing that work.
greg k-h
^ permalink raw reply
* IPv4: sysctl table check failed [was: mmotm 2010-10-07-14-08 uploaded]
From: Jiri Slaby @ 2010-10-07 22:06 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, mm-commits, ML netdev, David S. Miller
In-Reply-To: <201010072140.o97Le69i025659@imap1.linux-foundation.org>
On 10/07/2010 11:08 PM, akpm@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2010-10-07-14-08 has been uploaded to
Hi, I got bunch of "sysctl table check failed" below. All seem to be
related to ipv4:
sysctl table check failed: /net/ipv4/tcp_mem No min
Pid: 1, comm: swapper Not tainted 2.6.36-rc7-mm1_64+ #1285
Call Trace:
[<ffffffff8108d444>] set_fail+0xa4/0xf0
[<ffffffff8108d736>] sysctl_check_table+0x2a6/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff81072204>] __register_sysctl_paths+0xf4/0x320
[<ffffffff815c1232>] ? printk+0x3c/0x42
[<ffffffff8115d3bc>] ? sysfs_add_file+0xc/0x10
[<ffffffff818b18bd>] ? sysctl_ipv4_init+0x0/0x87
[<ffffffff81072456>] register_sysctl_paths+0x26/0x30
[<ffffffff818b18fd>] sysctl_ipv4_init+0x40/0x87
[<ffffffff810002df>] do_one_initcall+0x3f/0x170
[<ffffffff81884d44>] kernel_init+0x158/0x1e2
[<ffffffff8102fb54>] kernel_thread_helper+0x4/0x10
[<ffffffff81884bec>] ? kernel_init+0x0/0x1e2
[<ffffffff8102fb50>] ? kernel_thread_helper+0x0/0x10
sysctl table check failed: /net/ipv4/tcp_mem No max
Pid: 1, comm: swapper Not tainted 2.6.36-rc7-mm1_64+ #1285
Call Trace:
[<ffffffff8108d444>] set_fail+0xa4/0xf0
[<ffffffff8108d4da>] sysctl_check_table+0x4a/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff81072204>] __register_sysctl_paths+0xf4/0x320
[<ffffffff815c1232>] ? printk+0x3c/0x42
[<ffffffff8115d3bc>] ? sysfs_add_file+0xc/0x10
[<ffffffff818b18bd>] ? sysctl_ipv4_init+0x0/0x87
[<ffffffff81072456>] register_sysctl_paths+0x26/0x30
[<ffffffff818b18fd>] sysctl_ipv4_init+0x40/0x87
[<ffffffff810002df>] do_one_initcall+0x3f/0x170
[<ffffffff81884d44>] kernel_init+0x158/0x1e2
[<ffffffff8102fb54>] kernel_thread_helper+0x4/0x10
[<ffffffff81884bec>] ? kernel_init+0x0/0x1e2
[<ffffffff8102fb50>] ? kernel_thread_helper+0x0/0x10
sysctl table check failed: /net/ipv4/udp_mem No min
Pid: 1, comm: swapper Not tainted 2.6.36-rc7-mm1_64+ #1285
Call Trace:
[<ffffffff8108d444>] set_fail+0xa4/0xf0
[<ffffffff8108d736>] sysctl_check_table+0x2a6/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff81072204>] __register_sysctl_paths+0xf4/0x320
[<ffffffff815c1232>] ? printk+0x3c/0x42
[<ffffffff8115d3bc>] ? sysfs_add_file+0xc/0x10
[<ffffffff818b18bd>] ? sysctl_ipv4_init+0x0/0x87
[<ffffffff81072456>] register_sysctl_paths+0x26/0x30
[<ffffffff818b18fd>] sysctl_ipv4_init+0x40/0x87
[<ffffffff810002df>] do_one_initcall+0x3f/0x170
[<ffffffff81884d44>] kernel_init+0x158/0x1e2
[<ffffffff8102fb54>] kernel_thread_helper+0x4/0x10
[<ffffffff81884bec>] ? kernel_init+0x0/0x1e2
[<ffffffff8102fb50>] ? kernel_thread_helper+0x0/0x10
sysctl table check failed: /net/ipv4/udp_mem No max
Pid: 1, comm: swapper Not tainted 2.6.36-rc7-mm1_64+ #1285
Call Trace:
[<ffffffff8108d444>] set_fail+0xa4/0xf0
[<ffffffff8108d4da>] sysctl_check_table+0x4a/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff8108d4eb>] sysctl_check_table+0x5b/0x310
[<ffffffff81072204>] __register_sysctl_paths+0xf4/0x320
[<ffffffff815c1232>] ? printk+0x3c/0x42
[<ffffffff8115d3bc>] ? sysfs_add_file+0xc/0x10
[<ffffffff818b18bd>] ? sysctl_ipv4_init+0x0/0x87
[<ffffffff81072456>] register_sysctl_paths+0x26/0x30
[<ffffffff818b18fd>] sysctl_ipv4_init+0x40/0x87
[<ffffffff810002df>] do_one_initcall+0x3f/0x170
[<ffffffff81884d44>] kernel_init+0x158/0x1e2
[<ffffffff8102fb54>] kernel_thread_helper+0x4/0x10
[<ffffffff81884bec>] ? kernel_init+0x0/0x1e2
[<ffffffff8102fb50>] ? kernel_thread_helper+0x0/0x10
regards,
--
js
^ permalink raw reply
* Re: mmotm 2010-10-07-14-08 uploaded
From: Valdis.Kletnieks @ 2010-10-07 22:09 UTC (permalink / raw)
To: linux-kernel; +Cc: mm-commits
In-Reply-To: <201010072140.o97Le69i025659@imap1.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2501 bytes --]
On Thu, 07 Oct 2010 14:08:45 PDT, akpm@linux-foundation.org said:
> The mm-of-the-moment snapshot 2010-10-07-14-08 has been uploaded to
>
> http://userweb.kernel.org/~akpm/mmotm/
'make oldconfig' splatted this at the very end:
NCP file system support (to mount NetWare volumes) (NCP_FS) [N/m/y/?] n
Coda file system support (advanced network fs) (CODA_FS) [N/m/y/?] n
Andrew File System support (AFS) (EXPERIMENTAL) (AFS_FS) [N/m/y/?] n
warning: (IEEE1394_PCILYNX && (PCI || BROKEN) && PCI && IEEE1394 && I2C || SFC && NETDEVICES && NETDEV_10000 && PCI && INET || I2C_VIA && I2C && PCI && EXPERIMENTAL || I2C_HYDRA && I2C && PCI && PPC_CHRP && EXPERIMENTAL || I2C_GPIO && I2C && GENERIC_GPIO || I2C_IXP2000 && I2C && ARCH_IXP2000 || I2C_SIMTEC && I2C || I2C_VERSATILE && I2C && (ARCH_VERSATILE || ARCH_REALVIEW || ARCH_VEXPRESS) || I2C_PARPORT && I2C && PARPORT || I2C_PARPORT_LIGHT && I2C || I2C_ACORN && I2C && ARCH_ACORN || SCx200_I2C && I2C && SCx200_GPIO || VIDEO_BT848 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_DEV && PCI && I2C && VIDEO_V4L2 && INPUT && VIDEO_IR || VIDEO_CX88 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && VIDEO_DEV && PCI && I2C && INPUT && VIDEO_IR || VIDEO_CX23885 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && IR_CORE || VIDEO_AU0828 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && I2C && INPUT && DVB_CORE && USB && V!
IDEO_V4L2 || VIDEO_IVTV && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && PCI && I2C && INPUT && VIDEO_IR || VIDEO_CX18 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && PCI && I2C && EXPERIMENTAL && INPUT && VIDEO_IR || VIDEO_SAA7164 && MEDIA_SUPPORT && VIDEO_CAPTURE_DRIVERS && VIDEO_V4L2 && DVB_CORE && PCI && I2C || DVB_PLUTO2 && MEDIA_SUPPORT && DVB_CAPTURE_DRIVERS && DVB_CORE && PCI && I2C || DRM && HAS_IOMEM && (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU || FB_DDC && HAS_IOMEM && FB || FB_VIA && HAS_IOMEM && FB && PCI && X86 || VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && BKL) selects I2C_ALGOBIT which has unmet direct dependencies (I2C && !I2C_HELPER_AUTO)
warning: (NETFILTER_XT_MATCH_REALM && NET && INET && NETFILTER && NETFILTER_XTABLES && NETFILTER_ADVANCED || NET_CLS_ROUTE4 && NET && NET_SCHED) selects NET_CLS_ROUTE which has unmet direct dependencies (NET && NET_SCHED)
#
# configuration written to .config
#
Haven't had a chance to research it yet.
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2 v1.03] Add support for DWC OTG HCD function.
From: Feng Kan @ 2010-10-07 22:01 UTC (permalink / raw)
To: Greg KH, Rina Kagan
Cc: linux-usb, David Daney, linuxppc-dev, Mark Miesfeld, Ted Chan,
Fushen Chen
In-Reply-To: <20100730033632.GB27275@suse.de>
Hi Greg:
We have obtained GPL 2 only header from Synopsis. We have also identified a=
ll
parties that contributed to the code base and contacted them regarding
license change.
Any party that we could not reach, we will remove the patch from the submis=
sion.
Let me know if this is sufficient for resubmission.
Thanks
Feng
On Thu, Jul 29, 2010 at 8:36 PM, Greg KH <gregkh@suse.de> wrote:
> On Thu, Jul 29, 2010 at 07:02:44PM -0700, Feng Kan wrote:
>> On Thu, Jul 29, 2010 at 6:26 PM, Greg KH <gregkh@suse.de> wrote:
>> > On Thu, Jul 29, 2010 at 06:19:25PM -0700, Feng Kan wrote:
>> >> Hi Greg:
>> >>
>> >> On Thu, Jul 29, 2010 at 5:50 PM, Greg KH <gregkh@suse.de> wrote:
>> >> > On Thu, Jul 29, 2010 at 05:14:59PM -0700, Feng Kan wrote:
>> >> >> Hi Greg:
>> >> >>
>> >> >> We will change to a BSD 3 clause license header. Our legal counsel=
is
>> >> >> talking to Synopsis to make this change.
>> >> >
>> >> > Why BSD? ??You do realize what that means when combined within the =
body
>> >> > of the kernel, right?
>> >> >
>> >>
>> >> FKAN: We will shoot for a dual BSD/GPL license such as the one in the=
HP
>> >> ?? ?? ?? ?? ?? ??Hil driver.
>> >
>> > What specific driver is this?
>>
>> FKAN: this is driver/input/serio/hil_mlc.c and quite a number of others.
>
> Ok, thanks.
>
> Are you _sure_ that you didn't take any existing GPL code and put it
> into this driver when making it? =C2=A0Did all contributors to the code
> release their contributions under both licenses?
>
>> > And are you sure that all of the contributors to the code agree with
>> > this licensing change? ??Are you going to require contributors to
>> > dual-license their changes?
>> >
>> > If so, why keep it BSD, what does that get you?
>>
>> FKAN: for one thing, to make it future proof on other submissions.
>
> What do you mean by this? =C2=A0What can you do with this code other than=
use
> it on a Linux system? =C2=A0You can't put it into any other operating sys=
tem
> with a different license, can you?
>
>> >> > Are you going to be expecting others to contribute back to the code
>> >> > under this license, or will you accept the fact that future
>> >> > contributions from the community will cause the license to change?
>> >
>> >
>> > You didn't answer this question, which is a very important one before =
I
>> > can accept this driver.
>>
>> FKAN: Yes, all of the above. Our legal is working on that. I thought by =
default
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0GPL defines the above statement=
.
>
> The GPL does, but as you are trying to dual-license the code, you have
> to be careful about how you accept changes, and under what license.
> It's a lot more work than I think you realize. =C2=A0What process do you =
have
> in place to handle this?
>
>> >> >> We will resubmit once this is in place. Please let me know if you =
have
>> >> >> any additional concerns.
>> >> >
>> >> > My main concern is that you, and everyone else involved in the driv=
er,
>> >> > never considered the license of the code in the first place and exp=
ected
>> >> > the kernel community to accept it as-is, placing the problem on us.
>> >>
>> >> FKAN: Please don't think this is the case, we gone through this exerc=
ise
>> >> ?? ?? ?? ?? ?? with Denx.
>> >
>> > What is "Denx"?
>>
>> FKAN: U-Boot Denx.de
>
> Ah, thanks.
>
>> >> We had legal looking into the header before submission
>> >> ?? ?? ?? ?? ?? to them and the kernel.
>> >
>> > Then what happened here? ??Just curious as to how the driver was publi=
c
>> > for so long before someone realized this.
>> >
>>
>> FKAN: =C2=A0this was few years back. At the time we had the header chang=
ed
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0so it was BSD like to be accept=
ed by Denx.
>>
>> >> > What will be done in the future to prevent this from happening agai=
n?
>> >>
>> >> FKAN: agreed, once bitten .... :)
>> >
>> > That didn't answer the question :)
>>
>> FKAN: we have a system of checks for every patch that goes out. I will s=
end
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0out a guideline to all reviewer=
to make sure the header
>> follow kernel precedence.
>
> But you took this code from a different vendor, are you able to properly
> identify the code contributions to this base and what license it is
> under and where they got it from?
>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Legal is quite aware of the iss=
ue now too.
>
> As they should be :)
>
> Please reconsider the dual licensing unless you really are ready to
> handle the implications of it.
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* opkg install gdbserver
From: Elvis Dowson @ 2010-10-07 21:04 UTC (permalink / raw)
To: OpenEmbedded Developer Mailing List
Hi,
I have a target board that is not connected to the internet.
What should I do to get gdbserver onto the target?
I have built gdb-cross. Is there another recipe I can add to omap3-console-image, to make sure that gdbserver gets pulled in?
Best regards,
Elvis Dowson
^ permalink raw reply
* Re: introduce dm-snap-mv
From: Daniel Phillips @ 2010-10-07 21:31 UTC (permalink / raw)
To: Cong Meng
Cc: linux-fsdevel, linux-kernel, dm-devel, Andrew Morton,
Alexander Viro, Christoph Hellwig, Nick Piggin
In-Reply-To: <20101006083150.GA15758@zhongling>
Hi Meng,
The patch looks sensible, however the question is: why do you want to
do this? Would it not be better to generalize your metadata format to
accomodate the device's native blocksize?
Regards,
Daniel
> a kernel patch
> --------------
> Now, dm-snap-mv highly depends on a kernel patch below, which make __getblk()
> can get a 4K buffer head while block size of the disk is NOT 4K.
>
> Signed-off-by: Cong Meng <mcpacino@gmail.com>
> ---
> fs/buffer.c | 7 ++-----
> 1 files changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 3e7dca2..f7f9d33 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -1051,10 +1051,7 @@ grow_buffers(struct block_device *bdev, sector_t block, int size)
> pgoff_t index;
> int sizebits;
>
> - sizebits = -1;
> - do {
> - sizebits++;
> - } while ((size << sizebits) < PAGE_SIZE);
> + sizebits = PAGE_CACHE_SHIFT - bdev->bd_inode->i_blkbits;
>
> index = block >> sizebits;
>
> @@ -2924,7 +2921,7 @@ int submit_bh(int rw, struct buffer_head * bh)
> */
> bio = bio_alloc(GFP_NOIO, 1);
>
> - bio->bi_sector = bh->b_blocknr * (bh->b_size >> 9);
> + bio->bi_sector = bh->b_blocknr << (bh->b_bdev->bd_inode->i_blkbits - 9);
> bio->bi_bdev = bh->b_bdev;
> bio->bi_io_vec[0].bv_page = bh->b_page;
> bio->bi_io_vec[0].bv_len = bh->b_size;
^ permalink raw reply
* RE: pvops Dom0 graphics doesnt work with Intel i915
From: Kay, Allen M @ 2010-10-07 22:05 UTC (permalink / raw)
To: sanjay kushwaha, Konrad Rzeszutek Wilk; +Cc: Jeremy Fitzhardinge, xen-devel
In-Reply-To: <AANLkTi=ofd6F4hN2pp=vmmJu5vfp6kDkVs4MBJw9PLvi@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 11403 bytes --]
Sanjay,
Have you tried the latest xen-unstable staging tree? It has a workaround for T410 VT-d graphics issue caused by Lenovo BIOS. This might be the workaround you need:
http://xenbits.xensource.com/staging/xen-unstable.hg?rev/4beee5779122
Allen
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of sanjay kushwaha
Sent: Thursday, October 07, 2010 12:13 PM
To: Konrad Rzeszutek Wilk
Cc: Jeremy Fitzhardinge; xen-devel
Subject: Re: [Xen-devel] pvops Dom0 graphics doesnt work with Intel i915
Hi Konrad,
Unfortunately T410 doesnt have a serial port and neither does the docking station. I havent had any success with USB-to-Serial port dongles in the past. is there any way to get the serial port output?
Thanks,
Sanjay
On Thu, Oct 7, 2010 at 11:05 AM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com<mailto:konrad.wilk@oracle.com>> wrote:
On Thu, Oct 07, 2010 at 10:36:34AM -0700, sanjay kushwaha wrote:
> Hi Konrad,
> I tried your tree. It created a 2.6.32.15 based pvops kernel but graphics
> with VT-d still doesn't work. when I give iommu=0 on xen kernel command line
> in grub menu, graphics works but with iommu=1 it doesnt work (The whole
> screen is garbage).
Are there any warnings/debug messages in the serial log? Please follow
the PVOPS Wiki on how to enable all the debug options.
>
>
> On Wed, Oct 6, 2010 at 6:07 PM, Konrad Rzeszutek Wilk <
> konrad.wilk@oracle.com<mailto:konrad.wilk@oracle.com>> wrote:
>
> > On Wed, Oct 06, 2010 at 04:02:51PM -0700, sanjay kushwaha wrote:
> > > Thanks Pasi.
> > >
> > > Hi Konrad,
> > > Could you please let me know how to get these backported drivers as
> > > indicated by Pasi? This is the tree that I have.
> >
> > Just follow the Wiki. Oh, I need to update it.
> >
> > Here do this:
> >
> > git remote add konrad git://
> > git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git<http://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git>
> >
> > git pull konrad
> > git checkout konrad/devel/next.drm
> >
> > make
> >
> > >
> > > [evans@vwifi0 linux-2.6.32.x]$ git show
> > > commit b297cdac0373625d3cd0e6f2b393570dcf2edba6
> > > Merge: c6cfd01 64392f6
> > > Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com<mailto:jeremy.fitzhardinge@citrix.com>>
> > > Date: Mon Sep 13 14:27:24 2010 -0700
> > >
> > > Merge branch 'xen/next' into xen/next-2.6.32
> > >
> > > * xen/next:
> > > xen/netfront: Fix another potential race condition
> > > Revert "xen/netfront: default smartpoll to on"
> > >
> > > [evans@vwifi0 linux-2.6.32.x]$
> > >
> > >
> > > Thanks,
> > > Sanjay
> > >
> > > On Wed, Oct 6, 2010 at 1:12 PM, Pasi Kärkkäinen <pasik@iki.fi<mailto:pasik@iki.fi>> wrote:
> > >
> > > > On Wed, Oct 06, 2010 at 10:50:57AM -0700, sanjay kushwaha wrote:
> > > > > Hi,
> > > > > I have run into more problems now. This time with VT-d.
> > > > > When I enable VT-d on this laptop, graphics again stops working in
> > > > dom0
> > > > > with pvops (linux 2.6.32.21). the screen starts showing garbage as
> > > > soon as
> > > > > it switches into graphics mode.this happens when I boot the pvops
> > > > kernel
> > > > > both as dom0 and native linux. However, when I try 2.6.33 based
> > pvops
> > > > > kernel (stable-2.6.33.x) graphics seems to work fine with VT-d
> > when
> > > > > running native but it doesnt work when running as Dom0.
> > > > >
> > > > > so now the problem is:
> > > > >
> > > > > with stable-2.6.32.x: graphics works in Dom0 without Vt-d but not
> > with
> > > > > VT-d (neither native nor Dom0).
> > > > > with stable-2.6.33.x: graphics works with VT-d when running native
> > but
> > > > > doesnt work when running as Dom0 (with or without VT-d).
> > > > >
> > > >
> > > > stable-2.6.33.x is not maintained, and you shouldn't use it.
> > > >
> > > > I think Konrad has a backport of the 2.6.34 drm/dri drivers
> > > > to stable-2.6.32.x somewhere.. that might help.
> > > >
> > > > http://wiki.xensource.com/xenwiki/XenPVOPSDRM
> > > >
> > > > -- Pasi
> > > >
> > > > > I am experiencing this problem both with Lenovo T410, and Dell
> > > > latitude
> > > > > E6410.
> > > > > Has anybody experienced this problem?
> > > > >
> > > > > Thanks,
> > > > > Sanjay
> > > > >
> > > > > On Fri, Oct 1, 2010 at 11:06 AM, sanjay kushwaha
> > > > > <[1]sanjay.kushwaha@gmail.com<mailto:sanjay.kushwaha@gmail.com>> wrote:
> > > > >
> > > > > havent tried stable-2.6.32.x on Radeon. It works with nomodeset
> > and
> > > > > nopat options with stable-2.6.33.x branch.
> > > > >
> > > > > On Fri, Oct 1, 2010 at 10:57 AM, Konrad Rzeszutek Wilk
> > > > > <[2]konrad.wilk@oracle.com<mailto:konrad.wilk@oracle.com>> wrote:
> > > > >
> > > > > On Fri, Oct 01, 2010 at 10:06:48AM -0700, sanjay kushwaha
> > wrote:
> > > > > > When I dont use nomodeset option, dom0 boots fine X runs
> > > > properly.
> > > > > So Fedora
> > > > > > 13 (X86_64) distro with stable-2.6.32.x pvops kernel and
> > > > > xen-unstable works
> > > > > > fine for i915 without nomodeset option.
> > > > >
> > > > > Good to hear it works for you.
> > > > >
> > > > > What about your radeon laptop?
> > > > > >
> > > > > > Thanks,
> > > > > > Sanjay
> > > > > >
> > > > > > On Wed, Sep 29, 2010 at 3:56 PM, sanjay kushwaha
> > > > > > <[3]sanjay.kushwaha@gmail.com<mailto:sanjay.kushwaha@gmail.com>>wrote:
> > > > > >
> > > > > > > Hi Jeremy,
> > > > > > > I switched to stable-2.6.32.x branch (which is 2.6.32.21
> > > > based)
> > > > > but I get
> > > > > > > the same problem. Attached is the Xorg.0.log file when I
> > > > booted
> > > > > with
> > > > > > > nomodeset option.
> > > > > > >
> > > > > > > interestingly I did not see any kernel or driver crash
> > > > messages in
> > > > > the
> > > > > > > dmesg output. I do see these messages multiple times in
> > > > > /var/log/messages
> > > > > > > *
> > > > > > > Sep 29 15:40:32 vwifi0 gdm-binary[2244]: WARNING:
> > GdmDisplay:
> > > > > display
> > > > > > > lasted 0.048984 seconds
> > > > > > > Sep 29 15:40:32 vwifi0 gdm-binary[2244]: WARNING:
> > > > > GdmLocalDisplayFactory:
> > > > > > > maximum number of X display failures reached: check X
> > server
> > > > log
> > > > > for errors
> > > > > > > *
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Sanjay
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Sep 29, 2010 at 11:57 AM, Jeremy Fitzhardinge
> > > > > <[4]jeremy@goop.org<mailto:jeremy@goop.org>>wrote:
> > > > > > >
> > > > > > >> On 09/29/2010 11:12 AM, sanjay kushwaha wrote:
> > > > > > >> > Hi Folks,
> > > > > > >> > I am trying to boot latest xen-unstable on my laptop
> > which
> > > > has
> > > > > Intel
> > > > > > >> > i915 graphics. PVOPS dom0 is 2.6.33.6 based (from
> > branch
> > > > > > >> > xen/stable-2.6.33.x)
> > > > > > >>
> > > > > > >> Don't use that branch; it isn't supported (in fact, I
> > deleted
> > > > it
> > > > > a while
> > > > > > >> ago). Use xen/stable-2.6.32.x for now.
> > > > > > >>
> > > > > > >> J
> > > > > > >>
> > > > > > >> > and the distro is fedora 13 64-bit. The graphics doesnt
> > > > come up
> > > > > and it
> > > > > > >> > seems that i915 driver is crashing multiple times. If I
> > > > boot in
> > > > > > >> > run-level 3 (without X) dom0 boots fine.
> > > > > > >> > I tried booting the dom0 kernel with nomodeset and
> > nopat
> > > > > options
> > > > > > >> > without any success. I searched on internet and found
> > that
> > > > > multiple
> > > > > > >> > people have reported similar problem but I could not
> > find
> > > > any
> > > > > solution.
> > > > > > >> >
> > > > > > >> > Has anybody found a solution or workaround to this
> > problem?
> > > > > > >> >
> > > > > > >> > Thanks,
> > > > > > >> > Sanjay
> > > > > > >> >
> > > > > > >> > PS: I have another laptop with same version of xen and
> > > > pvops
> > > > > dom0 but
> > > > > > >> > it has ATI radeon graphics card. This laptop boots dom0
> > > > with
> > > > > graphics
> > > > > > >> > when I give nomodeset and nopat options (but fails if I
> > > > dont
> > > > > give
> > > > > > >> > either of those two options).
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > _______________________________________________
> > > > > > >> > Xen-devel mailing list
> > > > > > >> > [5]Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
> > > > > > >> > [6]http://lists.xensource.com/xen-devel
> > > > > > >>
> > > > > > >>
> > > > > > >
> > > > >
> > > > > > _______________________________________________
> > > > > > Xen-devel mailing list
> > > > > > [7]Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
> > > > > > [8]http://lists.xensource.com/xen-devel
> > > > >
> > > > > --
> > > > > ----------------------
> > > > > Dr. Sanjay Kumar
> > > > > Research Scientist
> > > > > Intel Corporation
> > > > >
> > > > > --
> > > > > ----------------------
> > > > > Dr. Sanjay Kumar
> > > > > Research Scientist
> > > > > Intel Corporation
> > > > >
> > > > > References
> > > > >
> > > > > Visible links
> > > > > 1. mailto:sanjay.kushwaha@gmail.com<mailto:sanjay.kushwaha@gmail.com>
> > > > > 2. mailto:konrad.wilk@oracle.com<mailto:konrad.wilk@oracle.com>
> > > > > 3. mailto:sanjay.kushwaha@gmail.com<mailto:sanjay.kushwaha@gmail.com>
> > > > > 4. mailto:jeremy@goop.org<mailto:jeremy@goop.org>
> > > > > 5. mailto:Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
> > > > > 6. http://lists.xensource.com/xen-devel
> > > > > 7. mailto:Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
> > > > > 8. http://lists.xensource.com/xen-devel
> > > >
> > > > > _______________________________________________
> > > > > Xen-devel mailing list
> > > > > Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
> > > > > http://lists.xensource.com/xen-devel
> > > >
> > > >
> > >
> > >
> > > --
> > > ----------------------
> > > Dr. Sanjay Kumar
> > > Research Scientist
> > > Intel Corporation
> >
>
>
>
> --
> ----------------------
> Dr. Sanjay Kumar
> Research Scientist
> Intel Corporation
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
> http://lists.xensource.com/xen-devel
--
----------------------
Dr. Sanjay Kumar
Research Scientist
Intel Corporation
[-- Attachment #1.2: Type: text/html, Size: 23208 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: [PATCH 01/10] V4L/DVB: cx231xx: remove a printk warning at -avcore and at -417
From: Devin Heitmueller @ 2010-10-07 22:04 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Srinivasa.Deevi, Palash.Bandyopadhyay, Linux Media Mailing List
In-Reply-To: <4CAE4020.4000209@redhat.com>
On Thu, Oct 7, 2010 at 5:48 PM, Mauro Carvalho Chehab
<mchehab@redhat.com> wrote:
> Em 28-09-2010 15:46, Mauro Carvalho Chehab escreveu:
>> drivers/media/video/cx231xx/cx231xx-avcore.c:1608: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long unsigned int’
>> drivers/media/video/cx231xx/cx231xx-417.c:1047: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘size_t’
>>
>> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>
> OK, I just updated my tree with the patches that Mkrufky acked.
> It basically contains the same patches from my previous post, plus
> the patches that Palash sent, and Devin/Mkrufky patches from polaris4
> tree, rebased over the top of kernel v2.6.36-rc7 (this makes easier
> for me to test and to merge).
>
> The patches are at:
> http://git.linuxtv.org/mchehab/cx231xx.git
>
> Sri already sent his ack for the first series of the patches.
>
> The tree contains two extra patches:
>
> 1) a cx231xx large CodingStyle fix patch:
> http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=eacd1a7749ae45d1f2f5782c013b863ff480746d
>
> It basically solves the issues that checkpatch.pl complained on this series of patches;
>
> 2) a cx231xx-417 gcc warning fix:
> http://git.linuxtv.org/mchehab/cx231xx.git?a=commit;h=ca3a6a8c2a4819702e93b9612c4a6d90474ea9b5
>
> Devin,
>
> Would it be ok for you if I merge them on my main tree? They're needed for one
> board I'm working with (a Pixelview SBTVD Hybrid - that supports both analog
> and full-seg ISDB-T).
Yeah, I've got additional fixes which aren't on that tree yet, but I
don't see any reason why what's there cannot be merged.
It would be helpful if you could get Douglas to merge both sets of
patches (mine and yours) to the hg backport tree as well, so I can
continue development without requiring the bleeding edge kernel (all
the work going on is for an embedded target which is running a
relatively old kernel).
I've got another couple dozen patches and I'm willing to continue
pushing this stuff upstream, but you need to meet me halfway here by
not making the bleeding edge kernel a requirement for this work.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
^ permalink raw reply
* RE: [PATCH] power: introduce library for device-specific OPPs
From: Menon, Nishanth @ 2010-10-07 22:03 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-pm, lkml, l-o, l-a, Paul
In-Reply-To: <201010072354.57011.rjw@sisk.pl>
> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
> Sent: Thursday, October 07, 2010 4:55 PM
>
> Hi,
>
> On Wednesday, October 06, 2010, Nishanth Menon wrote:
> > SoCs have a standard set of tuples consisting of frequency and
> > voltage pairs that the device will support per voltage domain. These
> > are called Operating Performance Points or OPPs. The actual
> > definitions of OPP varies over silicon versions. For a specific domain,
> > we can have a set of {frequency, voltage} pairs. As the kernel boots
> > and more information is available, a default set of these are activated
> > based on the precise nature of device. Further on operation, based on
> > conditions prevailing in the system (such as temperature), some OPP
> > availability may be temporarily controlled by the SoC frameworks.
> >
> > To implement an OPP, some sort of power management support is necessary
> > hence this library depends on CONFIG_PM.
>
> The patch generally looks good to me, I only have a couple of cosmetic
Thanks for the great reviews.. It did bump up the resultant patch.
> remarks
> (below).
>
> ...
> > +static int opp_set_availability(struct device *dev, unsigned long freq,
> > + bool availability_req)
> > +{
> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
> > + int r = 0;
> > +
> > + /* keep the node allocated */
> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
> > + if (!new_opp) {
> > + pr_warning("Unable to allocate opp\n");
>
> Please add an identification string to the messages, something like
> "OPP: Unable to allocat object\n" (and similarly in the other messages).
> That would help to find the source of a message in case there's any
> problem.
pr_fmt has been reformatted for this. The actual message which will appear
is as follows:
opp_set_availability: Unable to allocate opp
is'nt that good enough considering that all functions are opp_ prefixed?
I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But I
have no strong opinions on that and look forward to your recommendations.
>
>
> > + return -ENOMEM;
> > + }
> > +
> > + mutex_lock(&dev_opp_list_lock);
> > +
> > + /* Find the device_opp */
> > + list_for_each_entry(tmp_dev_opp, &dev_opp_list, node) {
> > + if (dev == tmp_dev_opp->dev) {
> > + dev_opp = tmp_dev_opp;
> > + break;
> > + }
> > + }
> > + if (IS_ERR(dev_opp)) {
> > + r = PTR_ERR(dev_opp);
> > + pr_warning("Unable to find device\n");
> > + goto out1;
>
> I'd prefer this lable to be called "unlock". It will be a bit more
> informative.
Ack. Fixing in v6 if you are ok with the above.
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] power: introduce library for device-specific OPPs
From: Menon, Nishanth @ 2010-10-07 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201010072354.57011.rjw@sisk.pl>
> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw at sisk.pl]
> Sent: Thursday, October 07, 2010 4:55 PM
>
> Hi,
>
> On Wednesday, October 06, 2010, Nishanth Menon wrote:
> > SoCs have a standard set of tuples consisting of frequency and
> > voltage pairs that the device will support per voltage domain. These
> > are called Operating Performance Points or OPPs. The actual
> > definitions of OPP varies over silicon versions. For a specific domain,
> > we can have a set of {frequency, voltage} pairs. As the kernel boots
> > and more information is available, a default set of these are activated
> > based on the precise nature of device. Further on operation, based on
> > conditions prevailing in the system (such as temperature), some OPP
> > availability may be temporarily controlled by the SoC frameworks.
> >
> > To implement an OPP, some sort of power management support is necessary
> > hence this library depends on CONFIG_PM.
>
> The patch generally looks good to me, I only have a couple of cosmetic
Thanks for the great reviews.. It did bump up the resultant patch.
> remarks
> (below).
>
> ...
> > +static int opp_set_availability(struct device *dev, unsigned long freq,
> > + bool availability_req)
> > +{
> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
> > + int r = 0;
> > +
> > + /* keep the node allocated */
> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
> > + if (!new_opp) {
> > + pr_warning("Unable to allocate opp\n");
>
> Please add an identification string to the messages, something like
> "OPP: Unable to allocat object\n" (and similarly in the other messages).
> That would help to find the source of a message in case there's any
> problem.
pr_fmt has been reformatted for this. The actual message which will appear
is as follows:
opp_set_availability: Unable to allocate opp
is'nt that good enough considering that all functions are opp_ prefixed?
I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But I
have no strong opinions on that and look forward to your recommendations.
>
>
> > + return -ENOMEM;
> > + }
> > +
> > + mutex_lock(&dev_opp_list_lock);
> > +
> > + /* Find the device_opp */
> > + list_for_each_entry(tmp_dev_opp, &dev_opp_list, node) {
> > + if (dev == tmp_dev_opp->dev) {
> > + dev_opp = tmp_dev_opp;
> > + break;
> > + }
> > + }
> > + if (IS_ERR(dev_opp)) {
> > + r = PTR_ERR(dev_opp);
> > + pr_warning("Unable to find device\n");
> > + goto out1;
>
> I'd prefer this lable to be called "unlock". It will be a bit more
> informative.
Ack. Fixing in v6 if you are ok with the above.
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH] power: introduce library for device-specific OPPs
From: Menon, Nishanth @ 2010-10-07 22:03 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Paul, linux-pm, l-o, lkml, l-a
In-Reply-To: <201010072354.57011.rjw@sisk.pl>
> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@sisk.pl]
> Sent: Thursday, October 07, 2010 4:55 PM
>
> Hi,
>
> On Wednesday, October 06, 2010, Nishanth Menon wrote:
> > SoCs have a standard set of tuples consisting of frequency and
> > voltage pairs that the device will support per voltage domain. These
> > are called Operating Performance Points or OPPs. The actual
> > definitions of OPP varies over silicon versions. For a specific domain,
> > we can have a set of {frequency, voltage} pairs. As the kernel boots
> > and more information is available, a default set of these are activated
> > based on the precise nature of device. Further on operation, based on
> > conditions prevailing in the system (such as temperature), some OPP
> > availability may be temporarily controlled by the SoC frameworks.
> >
> > To implement an OPP, some sort of power management support is necessary
> > hence this library depends on CONFIG_PM.
>
> The patch generally looks good to me, I only have a couple of cosmetic
Thanks for the great reviews.. It did bump up the resultant patch.
> remarks
> (below).
>
> ...
> > +static int opp_set_availability(struct device *dev, unsigned long freq,
> > + bool availability_req)
> > +{
> > + struct device_opp *tmp_dev_opp, *dev_opp = NULL;
> > + struct opp *new_opp, *tmp_opp, *opp = ERR_PTR(-ENODEV);
> > + int r = 0;
> > +
> > + /* keep the node allocated */
> > + new_opp = kmalloc(sizeof(struct opp), GFP_KERNEL);
> > + if (!new_opp) {
> > + pr_warning("Unable to allocate opp\n");
>
> Please add an identification string to the messages, something like
> "OPP: Unable to allocat object\n" (and similarly in the other messages).
> That would help to find the source of a message in case there's any
> problem.
pr_fmt has been reformatted for this. The actual message which will appear
is as follows:
opp_set_availability: Unable to allocate opp
is'nt that good enough considering that all functions are opp_ prefixed?
I can modify pr_fmt to add "OPP:" but I kinda think it is redundant. But I
have no strong opinions on that and look forward to your recommendations.
>
>
> > + return -ENOMEM;
> > + }
> > +
> > + mutex_lock(&dev_opp_list_lock);
> > +
> > + /* Find the device_opp */
> > + list_for_each_entry(tmp_dev_opp, &dev_opp_list, node) {
> > + if (dev == tmp_dev_opp->dev) {
> > + dev_opp = tmp_dev_opp;
> > + break;
> > + }
> > + }
> > + if (IS_ERR(dev_opp)) {
> > + r = PTR_ERR(dev_opp);
> > + pr_warning("Unable to find device\n");
> > + goto out1;
>
> I'd prefer this lable to be called "unlock". It will be a bit more
> informative.
Ack. Fixing in v6 if you are ok with the above.
Regards,
Nishanth Menon
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.