On Thu, 2013-08-08 at 09:53 +0100, Mark Rutland wrote:
> On Wed, Aug 07, 2013 at 09:18:29PM +0100, Eduardo Valentin wrote:
> > Pawel, all,
> >
> > On 06-08-2013 07:14, Pawel Moll wrote:
> > > Apologies about the delay, I was "otherwise engaged" for a week...
> > >
> >
> > I do also excuse for
On Wed, Aug 07, 2013 at 09:18:29PM +0100, Eduardo Valentin wrote:
> Pawel, all,
>
> On 06-08-2013 07:14, Pawel Moll wrote:
> > Apologies about the delay, I was "otherwise engaged" for a week...
> >
>
> I do also excuse for my delay, as I was also "engaged" for a week or so.
>
> > I hope you
On Wed, Aug 07, 2013 at 09:18:29PM +0100, Eduardo Valentin wrote:
Pawel, all,
On 06-08-2013 07:14, Pawel Moll wrote:
Apologies about the delay, I was otherwise engaged for a week...
I do also excuse for my delay, as I was also engaged for a week or so.
I hope you haven't lost all
On Thu, 2013-08-08 at 09:53 +0100, Mark Rutland wrote:
On Wed, Aug 07, 2013 at 09:18:29PM +0100, Eduardo Valentin wrote:
Pawel, all,
On 06-08-2013 07:14, Pawel Moll wrote:
Apologies about the delay, I was otherwise engaged for a week...
I do also excuse for my delay, as I was
Pawel, all,
On 06-08-2013 07:14, Pawel Moll wrote:
> Apologies about the delay, I was "otherwise engaged" for a week...
>
I do also excuse for my delay, as I was also "engaged" for a week or so.
> I hope you haven't lost all motivation to work on this subject, as it's
> really worth the while!
Pawel, all,
On 06-08-2013 07:14, Pawel Moll wrote:
Apologies about the delay, I was otherwise engaged for a week...
I do also excuse for my delay, as I was also engaged for a week or so.
I hope you haven't lost all motivation to work on this subject, as it's
really worth the while!
Not
Apologies about the delay, I was "otherwise engaged" for a week...
I hope you haven't lost all motivation to work on this subject, as it's
really worth the while!
On Fri, 2013-07-26 at 20:55 +0100, Eduardo Valentin wrote:
> On 25-07-2013 13:33, Pawel Moll wrote:
> > On Thu, 2013-07-25 at 18:20
Apologies about the delay, I was otherwise engaged for a week...
I hope you haven't lost all motivation to work on this subject, as it's
really worth the while!
On Fri, 2013-07-26 at 20:55 +0100, Eduardo Valentin wrote:
On 25-07-2013 13:33, Pawel Moll wrote:
On Thu, 2013-07-25 at 18:20 +0100,
On 25-07-2013 13:33, Pawel Moll wrote:
> On Thu, 2013-07-25 at 18:20 +0100, Eduardo Valentin wrote:
thermal_zone {
type = "CPU";
>>>
>>> So what does this exactly mean? What is so special about CPU? What other
>>> types you've got there? (Am I just lazy not looking at the
On 25-07-2013 13:33, Pawel Moll wrote:
On Thu, 2013-07-25 at 18:20 +0100, Eduardo Valentin wrote:
thermal_zone {
type = CPU;
So what does this exactly mean? What is so special about CPU? What other
types you've got there? (Am I just lazy not looking at the numerous
links you
On Thu, 2013-07-25 at 18:20 +0100, Eduardo Valentin wrote:
> >>thermal_zone {
> >>type = "CPU";
> >
> > So what does this exactly mean? What is so special about CPU? What other
> > types you've got there? (Am I just lazy not looking at the numerous
> > links you provided? ;-)
>
>
On 25-07-2013 12:38, Pawel Moll wrote:
> On Thu, 2013-07-25 at 17:15 +0100, Pawel Moll wrote:
>>> Another way, as I mentioned in the original RFC, an option would be to
>>> have the thermal_zone node not embedded in any device node. But them, we
>>> would need to firmly link it to other device
On 25-07-2013 12:15, Pawel Moll wrote:
> On Wed, 2013-07-24 at 16:04 +0100, Eduardo Valentin wrote:
>>> 1. As you have pointed out, the thermal limits are related to the
>>> *device being monitored*, not the sensor itself.
>>>
>> Yeah, thinking of it now, this original proposal, it lacks a
On Thu, 2013-07-25 at 17:15 +0100, Pawel Moll wrote:
> > Another way, as I mentioned in the original RFC, an option would be to
> > have the thermal_zone node not embedded in any device node. But them, we
> > would need to firmly link it to other device nodes, to describe what is
> > monitored and
On Wed, 2013-07-24 at 16:04 +0100, Eduardo Valentin wrote:
> > 1. As you have pointed out, the thermal limits are related to the
> > *device being monitored*, not the sensor itself.
> >
> Yeah, thinking of it now, this original proposal, it lacks a stronger
> relationship mapping between
On Wed, 2013-07-24 at 16:04 +0100, Eduardo Valentin wrote:
1. As you have pointed out, the thermal limits are related to the
*device being monitored*, not the sensor itself.
Yeah, thinking of it now, this original proposal, it lacks a stronger
relationship mapping between monitored and
On Thu, 2013-07-25 at 17:15 +0100, Pawel Moll wrote:
Another way, as I mentioned in the original RFC, an option would be to
have the thermal_zone node not embedded in any device node. But them, we
would need to firmly link it to other device nodes, to describe what is
monitored and what is
On 25-07-2013 12:15, Pawel Moll wrote:
On Wed, 2013-07-24 at 16:04 +0100, Eduardo Valentin wrote:
1. As you have pointed out, the thermal limits are related to the
*device being monitored*, not the sensor itself.
Yeah, thinking of it now, this original proposal, it lacks a stronger
On 25-07-2013 12:38, Pawel Moll wrote:
On Thu, 2013-07-25 at 17:15 +0100, Pawel Moll wrote:
Another way, as I mentioned in the original RFC, an option would be to
have the thermal_zone node not embedded in any device node. But them, we
would need to firmly link it to other device nodes, to
On Thu, 2013-07-25 at 18:20 +0100, Eduardo Valentin wrote:
thermal_zone {
type = CPU;
So what does this exactly mean? What is so special about CPU? What other
types you've got there? (Am I just lazy not looking at the numerous
links you provided? ;-)
Hehehe. OK. Type
Pawel,
On 24-07-2013 07:19, Pawel Moll wrote:
> Greeting,
>
> Funnily enough I had this discussion couple a months ago and made my
> mind back then :-)
>
:-)
>> On 07/22/2013 07:25 AM, Eduardo Valentin wrote:
>>> representing in device tree would not
>>> infringe the original purpose of this
On 24-07-2013 06:45, Mark Rutland wrote:
> On Wed, Jul 24, 2013 at 02:44:38AM +0100, Stephen Warren wrote:
>> On 07/22/2013 07:25 AM, Eduardo Valentin wrote:
>>> Hello Grant and Rob,
>>>
>>> (Resending, as I got a message saying:
>>> : Recipient address rejected:
>>> User has moved to devicetree
On 23-07-2013 21:44, Stephen Warren wrote:
> On 07/22/2013 07:25 AM, Eduardo Valentin wrote:
>> Hello Grant and Rob,
>>
>> (Resending, as I got a message saying:
>> : Recipient address rejected:
>> User has moved to devicetree at vger.kernel.org)
>>
>> I am writing this email to you specifically
Greeting,
Funnily enough I had this discussion couple a months ago and made my
mind back then :-)
> On 07/22/2013 07:25 AM, Eduardo Valentin wrote:
> > representing in device tree would not
> > infringe the original purpose of this data structure ("The Device
> > Tree is a data structure for
On Wed, Jul 24, 2013 at 02:44:38AM +0100, Stephen Warren wrote:
> On 07/22/2013 07:25 AM, Eduardo Valentin wrote:
> > Hello Grant and Rob,
> >
> > (Resending, as I got a message saying:
> > : Recipient address rejected:
> > User has moved to devicetree at vger.kernel.org)
> >
> > I am writing
On Wed, Jul 24, 2013 at 02:44:38AM +0100, Stephen Warren wrote:
On 07/22/2013 07:25 AM, Eduardo Valentin wrote:
Hello Grant and Rob,
(Resending, as I got a message saying:
devicetree-disc...@lists.ozlabs.org: Recipient address rejected:
User has moved to devicetree at vger.kernel.org)
Greeting,
Funnily enough I had this discussion couple a months ago and made my
mind back then :-)
On 07/22/2013 07:25 AM, Eduardo Valentin wrote:
representing in device tree would not
infringe the original purpose of this data structure (The Device
Tree is a data structure for describing
On 23-07-2013 21:44, Stephen Warren wrote:
On 07/22/2013 07:25 AM, Eduardo Valentin wrote:
Hello Grant and Rob,
(Resending, as I got a message saying:
devicetree-disc...@lists.ozlabs.org: Recipient address rejected:
User has moved to devicetree at vger.kernel.org)
I am writing this email
On 24-07-2013 06:45, Mark Rutland wrote:
On Wed, Jul 24, 2013 at 02:44:38AM +0100, Stephen Warren wrote:
On 07/22/2013 07:25 AM, Eduardo Valentin wrote:
Hello Grant and Rob,
(Resending, as I got a message saying:
devicetree-disc...@lists.ozlabs.org: Recipient address rejected:
User has
Pawel,
On 24-07-2013 07:19, Pawel Moll wrote:
Greeting,
Funnily enough I had this discussion couple a months ago and made my
mind back then :-)
:-)
On 07/22/2013 07:25 AM, Eduardo Valentin wrote:
representing in device tree would not
infringe the original purpose of this data
On 07/22/2013 07:25 AM, Eduardo Valentin wrote:
> Hello Grant and Rob,
>
> (Resending, as I got a message saying:
> : Recipient address rejected:
> User has moved to devicetree at vger.kernel.org)
>
> I am writing this email to you specifically to ask your technical
> assessment with respect
On 07/22/2013 07:25 AM, Eduardo Valentin wrote:
Hello Grant and Rob,
(Resending, as I got a message saying:
devicetree-disc...@lists.ozlabs.org: Recipient address rejected:
User has moved to devicetree at vger.kernel.org)
I am writing this email to you specifically to ask your technical
Hello Grant and Rob,
I am writing this email to you specifically to ask your technical
assessment with respect to representing device thermal limits as device
tree nodes. I am proposing to introduce device tree nodes to describe
these limits as thermal zones, their composition and their relations
Hello Grant and Rob,
(Resending, as I got a message saying:
: Recipient address rejected: User
has moved to devicetree at vger.kernel.org)
I am writing this email to you specifically to ask your technical
assessment with respect to representing device thermal limits as device
tree nodes. I am
Hello Grant and Rob,
(Resending, as I got a message saying:
devicetree-disc...@lists.ozlabs.org: Recipient address rejected: User
has moved to devicetree at vger.kernel.org)
I am writing this email to you specifically to ask your technical
assessment with respect to representing device thermal
Hello Grant and Rob,
I am writing this email to you specifically to ask your technical
assessment with respect to representing device thermal limits as device
tree nodes. I am proposing to introduce device tree nodes to describe
these limits as thermal zones, their composition and their relations
36 matches
Mail list logo
