--
I am Mr. Alain Nkontchou, banker contacting you based on my interests
to develop a mutual business relationship with someone in your
country. I decided to solicit for your assistance to execute this
transaction due to some circumstances beyond my control. In fact, the
deal will be made known
From: James Smart
[ Upstream commit 821bc882accaaaf1bbecf5c0ecef659443e3e8cb ]
When performing reset testing, the eq's list for related hwqs was getting
corrupted. In cases where there is not a 1:1 eq to hwq, the eq is
shared. The eq maintains a list of hwqs utilizing it in case of cpu
offlinin
Glad to write to you. I avail myself of this opportunity to approach you for an
establishment of a business relationship with you. I got your contact through
LinkedIn and would like to discuss more with you about this opportunity.
I would like to send a summary of this business for your review
From: James Smart
[ Upstream commit 821bc882accaaaf1bbecf5c0ecef659443e3e8cb ]
When performing reset testing, the eq's list for related hwqs was getting
corrupted. In cases where there is not a 1:1 eq to hwq, the eq is
shared. The eq maintains a list of hwqs utilizing it in case of cpu
offlinin
Am 2020-06-25 08:13, schrieb Lee Jones:
On Wed, 24 Jun 2020, Frank Rowand wrote:
On 2020-06-22 16:03, Michael Walle wrote:
> Am 2020-06-14 12:26, schrieb Michael Walle:
>> Hi Rob,
>>
>> Am 2020-06-10 00:03, schrieb Rob Herring:
>> [..]
>>> Yes, we should use 'reg' whenever possible. If we don't
On Wed, 24 Jun 2020, Frank Rowand wrote:
> On 2020-06-22 16:03, Michael Walle wrote:
> > Am 2020-06-14 12:26, schrieb Michael Walle:
> >> Hi Rob,
> >>
> >> Am 2020-06-10 00:03, schrieb Rob Herring:
> >> [..]
> >>> Yes, we should use 'reg' whenever possible. If we don't have 'reg',
> >>> then you sh
+Frank (me)
On 2020-06-22 16:03, Michael Walle wrote:
> Am 2020-06-14 12:26, schrieb Michael Walle:
>> Hi Rob,
>>
>> Am 2020-06-10 00:03, schrieb Rob Herring:
>> [..]
>>> Yes, we should use 'reg' whenever possible. If we don't have 'reg',
>>> then you shouldn't have a unit-address either and you c
Am 2020-06-14 12:26, schrieb Michael Walle:
Hi Rob,
Am 2020-06-10 00:03, schrieb Rob Herring:
[..]
Yes, we should use 'reg' whenever possible. If we don't have 'reg',
then you shouldn't have a unit-address either and you can simply match
on the node name (standard DT driver matching is with com
Hi Rob,
Am 2020-06-10 00:03, schrieb Rob Herring:
[..]
Yes, we should use 'reg' whenever possible. If we don't have 'reg',
then you shouldn't have a unit-address either and you can simply match
on the node name (standard DT driver matching is with compatible,
device_type, and node name (w/o unit
On Thu, 11 Jun 2020, Frank Rowand wrote:
> Please add me to the distribution list for future versions of this.
The solution patch is already on v2.
https://lore.kernel.org/lkml/20200611191002.2256570-1-lee.jo...@linaro.org/
I'll bounce it to you.
--
Lee Jones [李琼斯]
Senior Technical Lead - Dev
Hi Lee,
On 2020-06-09 06:01, Lee Jones wrote:
> Good morning,
>
> After a number of reports/queries surrounding a known long-term issue
> in the MFD core, including the submission of a couple of attempted
> solutions, I've decided to finally tackle this one myself.
>
> Currently, when a child pl
Hi Lee,
Please add me to the distribution list for future versions of this.
-Frank
On 2020-06-09 06:01, Lee Jones wrote:
> Good morning,
>
> After a number of reports/queries surrounding a known long-term issue
> in the MFD core, including the submission of a couple of attempted
> solutions, I'
On Tue, 09 Jun 2020, Rob Herring wrote:
Thanks for replying Rob.
> On Tue, Jun 9, 2020 at 5:01 AM Lee Jones wrote:
> >
> > Good morning,
> >
> > After a number of reports/queries surrounding a known long-term issue
> > in the MFD core, including the submission of a couple of attempted
> > soluti
On Tue, Jun 9, 2020 at 5:01 AM Lee Jones wrote:
>
> Good morning,
>
> After a number of reports/queries surrounding a known long-term issue
> in the MFD core, including the submission of a couple of attempted
> solutions, I've decided to finally tackle this one myself.
>
> Currently, when a child
On Tue, 09 Jun 2020, Andy Shevchenko wrote:
> On Tue, Jun 9, 2020 at 2:01 PM Lee Jones wrote:
> >
> > Good morning,
> >
> > After a number of reports/queries surrounding a known long-term issue
> > in the MFD core, including the submission of a couple of attempted
> > solutions, I've decided to f
On Tue, Jun 9, 2020 at 2:01 PM Lee Jones wrote:
>
> Good morning,
>
> After a number of reports/queries surrounding a known long-term issue
> in the MFD core, including the submission of a couple of attempted
> solutions, I've decided to finally tackle this one myself.
>
> Currently, when a child
Good morning,
After a number of reports/queries surrounding a known long-term issue
in the MFD core, including the submission of a couple of attempted
solutions, I've decided to finally tackle this one myself.
Currently, when a child platform device (sometimes referred to as a
sub-device) is regi
Hey Lu,
> On 20 Mar 2019, at 01:26, Lu Baolu wrote:
>
> Hi James,
>
> On 3/19/19 9:35 PM, James Sewart wrote:
>> Hey Lu,
>>> On 15 Mar 2019, at 03:13, Lu Baolu wrote:
>>>
>>> Hi James,
>>>
>>> On 3/14/19 7:56 PM, James Sewart wrote:
Patches 1 and 2 are the same as v1.
v1-v2:
Hi,
On 3/5/19 7:14 PM, James Sewart wrote:
Hey Lu,
The motivation for this is buggy domain <-> IOMMU group relationship when
using find_or_alloc_domain. From what I have read it should be the case
that an IOMMU domain is shared by all devices in the same group, thus the
same mappings. T
Hey Lu,
The motivation for this is buggy domain <-> IOMMU group relationship when
using find_or_alloc_domain. From what I have read it should be the case
that an IOMMU domain is shared by all devices in the same group, thus the
same mappings. This is because the IOMMU group is determi
Hi James,
Very glad to see this. Thank you!
On 3/4/19 11:41 PM, James Sewart wrote:
Hey,
This patchset moves IOMMU_DOMAIN_DMA iommu domain management to iommu.c.
This avoids the use of find_or_alloc_domain whose domain assignment is
inconsistent with the iommu grouping as determined by pci_dev
Hey,
This patchset moves IOMMU_DOMAIN_DMA iommu domain management to iommu.c.
This avoids the use of find_or_alloc_domain whose domain assignment is
inconsistent with the iommu grouping as determined by pci_device_group.
Patch 3 permits domain type IOMMU_DOMAIN_DMA to be allocated via the
iomm
Having two somewhat similar and largely overlapping APIs is confusing,
especially since the older one appears in the docs before the newer
and most featureful counterpart.
Clarify all of this in several ways:
- swap the two sections
- give a name to the two APIs in the section names
- add a not
Hi Hans,
thanks for the review.
On 13/05/2018 11:12, Hans Verkuil wrote:
> On 04/03/2018 11:15 PM, Luca Ceresoli wrote:
>> Having two somewhat similar and largely overlapping APIs is confusing,
>> especially since the older one appears in the docs before the newer
>> and most featureful counterpa
On 04/03/2018 11:15 PM, Luca Ceresoli wrote:
> Having two somewhat similar and largely overlapping APIs is confusing,
> especially since the older one appears in the docs before the newer
> and most featureful counterpart.
>
> Clarify all of this in several ways:
> - swap the two sections
> - gi
Having two somewhat similar and largely overlapping APIs is confusing,
especially since the older one appears in the docs before the newer
and most featureful counterpart.
Clarify all of this in several ways:
- swap the two sections
- give a name to the two APIs in the section names
- add a not
From: Chris Lapa
The max8903_charger.h file indicated that dcm and dok were not optional
when dc_valid is set.
It makes sense to have dok as a compulsory pin when dc_valid is given.
However dcm can be optionally wired to a fixed level especially when the
circuit is configured for dc power exclus
On 06/20/2016 12:27 AM, Chris Lapa wrote:
> From: Chris Lapa
>
> The max8903_charger.h file indicated that dcm and dok were not optional
> when dc_valid is set.
>
> It makes sense to have dok as a compulsory pin when dc_valid is given.
> However dcm can be optionally wired to a fixed level espec
From: Chris Lapa
The max8903_charger.h file indicated that dcm and dok were not optional
when dc_valid is set.
It makes sense to have dok as a compulsory pin when dc_valid is given.
However dcm can be optionally wired to a fixed level especially when the
circuit is configured for dc power exclus
On 17/06/2016 4:26 PM, Krzysztof Kozlowski wrote:
On 06/17/2016 07:00 AM, Chris Lapa wrote:
From: Chris Lapa
The max8903_charger.h file indicated that dcm and dok were not optional
when dc_valid is set.
It makes sense to have dok as a compulsory pin when dc_valid is given.
However dcm can be
On 06/17/2016 08:28 AM, Chris Lapa wrote:
> On 17/06/2016 4:26 PM, Krzysztof Kozlowski wrote:
>> On 06/17/2016 07:00 AM, Chris Lapa wrote:
>>> From: Chris Lapa
>>>
>>> The max8903_charger.h file indicated that dcm and dok were not optional
>>> when dc_valid is set.
>>>
>>> It makes sense to have d
On 17/06/2016 4:26 PM, Krzysztof Kozlowski wrote:
On 06/17/2016 07:00 AM, Chris Lapa wrote:
From: Chris Lapa
The max8903_charger.h file indicated that dcm and dok were not optional
when dc_valid is set.
It makes sense to have dok as a compulsory pin when dc_valid is given.
However dcm can be
On 06/17/2016 07:00 AM, Chris Lapa wrote:
> From: Chris Lapa
>
> The max8903_charger.h file indicated that dcm and dok were not optional
> when dc_valid is set.
>
> It makes sense to have dok as a compulsory pin when dc_valid is given.
> However dcm can be optionally wired to a fixed level espec
On 06/17/2016 07:00 AM, Chris Lapa wrote:
> From: Chris Lapa
>
> The max8903_charger.h file indicated that dcm and dok were not optional
> when dc_valid is set.
>
> It makes sense to have dok as a compulsory pin when dc_valid is given.
> However dcm can be optionally wired to a fixed level espec
From: Chris Lapa
The max8903_charger.h file indicated that dcm and dok were not optional
when dc_valid is set.
It makes sense to have dok as a compulsory pin when dc_valid is given.
However dcm can be optionally wired to a fixed level especially when the
circuit is configured for dc power exclus
From: Chris Lapa
The max8903_charger.h file indicated that dcm and dok were not optional
when dc_valid is set.
It makes sense to have dok as a compulsory pin when dc_valid is given.
However dcm can be optionally wired to a fixed level especially when the
circuit is configured for dc power exclus
From: Chris Lapa
The max8903_charger.h file indicated that dcm and dok were not optional
when dc_valid is set.
It makes sense to have dok as a compulsory pin when dc_valid is given.
However dcm can be optionally wired to a fixed level especially when the
circuit is configured for dc power exclus
On Wed, Apr 13, 2016 at 11:56:14PM -0400, Steven Rostedt wrote:
> On Tue, 12 Apr 2016 08:52:49 -0700
> "Paul E. McKenney" wrote:
>
> > The current documentation claims that the compiler ignores barrier(),
> > which is not the case. Instead, the compiler carefully pays attention
> > to barrier(),
On Tue, 12 Apr 2016 08:52:49 -0700
"Paul E. McKenney" wrote:
> The current documentation claims that the compiler ignores barrier(),
> which is not the case. Instead, the compiler carefully pays attention
> to barrier(), but in a creative way that still manages to destroy
> the control dependenc
: Clarify relationship of barrier() to control dependencies
The current documentation claims that the compiler ignores barrier(),
which is not the case. Instead, the compiler carefully pays attention
to barrier(), but in a creative way that still manages to destroy
the control dependency. This
The current documentation claims that the compiler ignores barrier(),
which is not the case. Instead, the compiler carefully pays attention
to barrier(), but in a creative way that still manages to destroy
the control dependency. This commit sets the story straight.
Reported-by: Mathieu Desnoyer
BUSINESS RELATIONSHIP
Dear Friend,
Please and Please contact me through this E_mail (drharunabello...@gmail.com)
Let me start by introducing myself,I am Dr Haruna Bello,
Manager of Bank Of Africa Burkina faso.
I am writting you this letter based on the latest development at my
Departmentwhich
BUSINESS RELATIONSHIP
Dear Friend,
Let me start by introducing myself,I am Dr Haruna Bello,
Manager of Bank Of Africa Burkina faso.
I am writting you this letter based on the latest development at my
Departmentwhich I will like to bring to your personal edification.(18.5 million
U.SDollars
: Clarify the relationship between tasks' deadlines and
absolute scheduling deadlines
Clarify what is the relationship between tasks' parameters and scheduling
parameters, explaining how to set the scheduling parameters so that all the
absolute deadlines of a task are respected.
Signed-of
Clarify what is the relationship between tasks' parameters and scheduling
parameters, explaining how to set the scheduling parameters so that all the
absolute deadlines of a task are respected.
Signed-off-by: Luca Abeni
---
Documentation/scheduler/sched-deadline.txt | 14 +++-
From: Rik van Riel
Document the subtly changed relationship between cpusets and isolcpus.
Turns out the old documentation did not match the code...
Signed-off-by: Rik van Riel
Suggested-by: Peter Zijlstra
---
Documentation/cgroups/cpusets.txt | 10 --
1 file changed, 8 insertions
From: Rik van Riel
Document the subtly changed relationship between cpusets and isolcpus.
Turns out the old documentation did not match the code...
Signed-off-by: Rik van Riel
Suggested-by: Peter Zijlstra
---
Documentation/cgroups/cpusets.txt | 10 --
1 file changed, 8 insertions
Hi numa guys,
Yasuaki Ishimatsu found a phenomenon that the numa mapping (cpu<->node
relationship)
changed when hot add/remove node.
And this change will cause allocation failure bug to workqueue sub-system:
...
SLUB: Unable to allocate memory on node 2 (gfp=0x80d0)
cache: kmall
On 2015/2/28 1:08, Rik van Riel wrote:
> Document the subtly changed relationship between cpusets and isolcpus.
> Turns out the old documentation did not quite match the code...
>
> Signed-off-by: Rik van Riel
> Suggested-by: Peter Zijlstra
Acked-by: Zefan Li
--
To unsubscribe
On Fri, 27 Feb 2015, Rik van Riel wrote:
> Document the subtly changed relationship between cpusets and isolcpus.
> Turns out the old documentation did not quite match the code...
>
> Signed-off-by: Rik van Riel
> Suggested-by: Peter Zijlstra
Acked-by: David Rientjes
--
To u
Document the subtly changed relationship between cpusets and isolcpus.
Turns out the old documentation did not quite match the code...
Signed-off-by: Rik van Riel
Suggested-by: Peter Zijlstra
---
Documentation/cgroups/cpusets.txt | 10 --
1 file changed, 8 insertions(+), 2 deletions
), Lai Jiangshan wrote:
On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
Although workqueue detects relationship between cpu<->node at boot,
it is finally determined in cpu_up().
This patch tries to update pool->node using online status of cpus.
1. When a node goes down, clear per-cpu po
;> (2014/12/15 11:12), Lai Jiangshan wrote:
>>>>>> On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
>>>>>>> Although workqueue detects relationship between cpu<->node at boot,
>>>>>>> it is finally determined in cpu_up().
>>>>>
detects relationship between cpu<->node at boot,
it is finally determined in cpu_up().
This patch tries to update pool->node using online status of cpus.
1. When a node goes down, clear per-cpu pool's node attr.
2. When a cpu comes up, update per-cpu pool's node attr.
3. When a c
On 12/15/2014 10:55 AM, Kamezawa Hiroyuki wrote:
> (2014/12/15 11:48), Lai Jiangshan wrote:
>> On 12/15/2014 10:20 AM, Kamezawa Hiroyuki wrote:
>>> (2014/12/15 11:12), Lai Jiangshan wrote:
>>>> On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
>>>>> Al
On 12/15/2014 10:55 AM, Kamezawa Hiroyuki wrote:
> (2014/12/15 11:48), Lai Jiangshan wrote:
>> On 12/15/2014 10:20 AM, Kamezawa Hiroyuki wrote:
>>> (2014/12/15 11:12), Lai Jiangshan wrote:
>>>> On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
>>>>> Al
(2014/12/15 11:48), Lai Jiangshan wrote:
On 12/15/2014 10:20 AM, Kamezawa Hiroyuki wrote:
(2014/12/15 11:12), Lai Jiangshan wrote:
On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
Although workqueue detects relationship between cpu<->node at boot,
it is finally determined in cpu_up()
On 12/15/2014 10:20 AM, Kamezawa Hiroyuki wrote:
> (2014/12/15 11:12), Lai Jiangshan wrote:
>> On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
>>> Although workqueue detects relationship between cpu<->node at boot,
>>> it is finally determined in cpu_up().
&g
(2014/12/15 11:12), Lai Jiangshan wrote:
On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
Although workqueue detects relationship between cpu<->node at boot,
it is finally determined in cpu_up().
This patch tries to update pool->node using online status of cpus.
1. When a node goes do
On 12/14/2014 12:38 AM, Kamezawa Hiroyuki wrote:
> Although workqueue detects relationship between cpu<->node at boot,
> it is finally determined in cpu_up().
> This patch tries to update pool->node using online status of cpus.
>
> 1. When a node goes down, clear per-c
Although workqueue detects relationship between cpu<->node at boot,
it is finally determined in cpu_up().
This patch tries to update pool->node using online status of cpus.
1. When a node goes down, clear per-cpu pool's node attr.
2. When a cpu comes up, update per-cpu pool's n
I'm simple, caring and understanding,I just need happiness. I'm interested and
would love to get to know more about you,but I'm aware that it takes some time
to know someone better so please write to me and tell me more about yourself..
--
To unsubscribe from this list: send the line "unsubscri
- Add clock lookups for APB devices.
- Update clock relationship to make it more exact and clear.
_
___| |
OSC ___/ | MUX |___ XXX CLK
\___ PLL ___ XXX DIV
Good Day,
I am writing this particular message to you to ascertain whether you could be
able to handle this matter effectively in your area or any place of your
choice. Be inform that i wish to enter into business relationship with you
which must be under your complete control and management
On Mon, Jul 07, 2014 at 03:24:19PM -0700, Paul E. McKenney wrote:
> From: "Paul E. McKenney"
>
> This commit adds an example demonstrating that if a wake_up() doesn't
> actually wake something up, no memory ordering is provided.
>
> Reported-by: Peter Zijlstra
> Signed-off-by: Paul E. McKenney
From: "Paul E. McKenney"
This commit adds an example demonstrating that if a wake_up() doesn't
actually wake something up, no memory ordering is provided.
Reported-by: Peter Zijlstra
Signed-off-by: Paul E. McKenney
---
Documentation/memory-barriers.txt | 15 +++
1 file changed, 15
On Fri, Nov 22, 2013 at 9:23 PM, Weijie Yang wrote:
> Hello Dan,
>
> On Sat, Nov 23, 2013 at 6:10 AM, Dan Streetman wrote:
>> Currently, zswap_entry_put removes the entry from its tree if
>> the resulting refcount is 0. Several places in code put an
>> entry's initial reference, but they also mu
Hello Dan,
On Sat, Nov 23, 2013 at 6:10 AM, Dan Streetman wrote:
> Currently, zswap_entry_put removes the entry from its tree if
> the resulting refcount is 0. Several places in code put an
> entry's initial reference, but they also must remove the entry
> from its tree first, which makes the tr
Currently, zswap_entry_put removes the entry from its tree if
the resulting refcount is 0. Several places in code put an
entry's initial reference, but they also must remove the entry
from its tree first, which makes the tree removal in zswap_entry_put
redundant.
I believe this has the refcount m
[+cc Rafael]
On Tue, Sep 25, 2012 at 8:29 AM, Jiang Liu wrote:
> From: Jiang Liu
>
> Currently pci_bind.c is used to maintain binding relationship between
> ACPI and PCI devices. But it's broken when handling PCI hotplug events.
>
> For the acpiphp driver, it's de
As part of PWM subsystem integration, PWM subsystem are sharing
resources like clock across submodules (ECAP, EQEP & EHRPWM). To handle
resource sharing & IP integration rework on parent child relation
between PWMSS and ECAP, EQEP & EHRPWM child devices to support runtime PM.
Signed-off-by: Phili
Hi, all
I want ask a question.
As we know, structure buffer_head has a member called b_state.
And this state could be defined by many flags.
The question is that, I want to know the relationship between BH_Uptodate
& BH_Dirty.
If a data is verified, the BH_Dirty will setup, and what a
As part of PWM subsystem integration, PWM subsystem are sharing
resources like clock across submodules (ECAP, EQEP & EHRPWM). To handle
resource sharing & IP integration rework on parent child relation
between PWMSS and ECAP, EQEP & EHRPWM child devices to support runtime PM.
Signed-off-by: Phili
ock gating
for individual PWMSS submodules, and submodule drivers has to enable
clock gating from their drivers.
As this is only supported during DT boot, the parent<->child relationship
is created and populated in DT execution flow. The only required change
is inside DTS file, making EHRPWM &
On Mon, Nov 26, 2012 at 16:37:36, Bedia, Vaibhav wrote:
> Hi Benoit,
>
> On Mon, Nov 26, 2012 at 14:32:59, Cousson, Benoit wrote:
> > Hi Vaibhav,
> >
> > On 11/26/2012 06:19 AM, Bedia, Vaibhav wrote:
> > > On Fri, Nov 23, 2012 at 16:36:06, Philip, Avinash wrote:
> > >> On Tue, Nov 20, 2012 at 10:
Hi Benoit,
On Mon, Nov 26, 2012 at 14:32:59, Cousson, Benoit wrote:
> Hi Vaibhav,
>
> On 11/26/2012 06:19 AM, Bedia, Vaibhav wrote:
> > On Fri, Nov 23, 2012 at 16:36:06, Philip, Avinash wrote:
> >> On Tue, Nov 20, 2012 at 10:33:44, Philip, Avinash wrote:
> >>> As part of PWM subsystem integration
Hi Vaibhav,
On 11/26/2012 06:19 AM, Bedia, Vaibhav wrote:
> On Fri, Nov 23, 2012 at 16:36:06, Philip, Avinash wrote:
>> On Tue, Nov 20, 2012 at 10:33:44, Philip, Avinash wrote:
>>> As part of PWM subsystem integration, PWM subsystem are sharing
>>> resources like clock across submodules (ECAP, EQE
On Fri, Nov 23, 2012 at 16:36:06, Philip, Avinash wrote:
> On Tue, Nov 20, 2012 at 10:33:44, Philip, Avinash wrote:
> > As part of PWM subsystem integration, PWM subsystem are sharing
> > resources like clock across submodules (ECAP, EQEP & EHRPWM).
> > To handle resource sharing & IP integration
>
On Tue, Nov 20, 2012 at 10:33:44, Philip, Avinash wrote:
> As part of PWM subsystem integration, PWM subsystem are sharing
> resources like clock across submodules (ECAP, EQEP & EHRPWM).
> To handle resource sharing & IP integration
> 1. Rework on parent child relation between PWMSS and
>ECAP,
On Fri, Nov 23, 2012 at 02:17:04, Thierry Reding wrote:
> On Wed, Nov 21, 2012 at 06:40:58PM +0530, Philip, Avinash wrote:
> [...]
> > +static const struct of_device_id pwmss_of_match[] = {
> > + {
> > + .compatible = "ti,am33xx-pwmss",
> > + },
>
> For consistency with other dri
On Wed, Nov 21, 2012 at 06:40:58PM +0530, Philip, Avinash wrote:
[...]
> +static const struct of_device_id pwmss_of_match[] = {
> + {
> + .compatible = "ti,am33xx-pwmss",
> + },
For consistency with other drivers this should be all on one line.
> +static const struct dev_p
As part of PWM subsystem integration, PWM subsystem are sharing
resources like clock across submodules (ECAP, EQEP & EHRPWM).
To handle resource sharing & IP integration
1. Rework on parent child relation between PWMSS and
ECAP, EQEP & EHRPWM child devices to support runtime PM.
2. Add support f
ock gating
for individual PWMSS submodules, and submodule drivers has to enable
clock gating from their drivers.
As this is only supported during DT boot, the parent<->child relationship
is created and populated in DT execution flow. The only required change
is inside DTS file, making EHRPWM &
ock gating
for individual PWMSS submodules, and submodule drivers has to enable
clock gating from their drivers.
As this is only supported during DT boot, the parent<->child relationship
is created and populated in DT execution flow. The only required change
is inside DTS file, making EHRPWM &
As part of PWM subsystem integration, PWM subsystem are sharing
resources like clock across submodules (ECAP, EQEP & EHRPWM).
To handle resource sharing & IP integration
1. Rework on parent child relation between PWMSS and
ECAP, EQEP & EHRPWM child devices to support runtime PM.
2. Add support f
On Fri, Nov 09, 2012 at 12:59:57, Thierry Reding wrote:
> On Thu, Nov 08, 2012 at 01:23:08PM +0530, Philip, Avinash wrote:
> > diff --git a/Documentation/devicetree/bindings/pwm/tipwmss.txt
> > b/Documentation/devicetree/bindings/pwm/tipwmss.txt
> > new file mode 100644
> > index 000..b6c2814
On Thu, Nov 08, 2012 at 01:23:08PM +0530, Philip, Avinash wrote:
> diff --git a/Documentation/devicetree/bindings/pwm/tipwmss.txt
> b/Documentation/devicetree/bindings/pwm/tipwmss.txt
> new file mode 100644
> index 000..b6c2814
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/tipw
As part of PWM subsystem integration, PWM subsystem are sharing
resources like clock across submodules (ECAP, EQEP & EHRPWM).
To handle resource sharing & IP integration
1. Rework on parent child relation between PWMSS and
ECAP, EQEP & EHRPWM child devices to support runtime PM.
2. Add support f
ock gating
for individual PWMSS submodules, and submodule drivers has to enable
clock gating from their drivers.
As this is only supported during DT boot, the parent<->child relationship
is created and populated in DT execution flow. The only required change
is inside DTS file, making EHRPWM &
On Tue, Nov 06, 2012 at 12:05:24, Bedia, Vaibhav wrote:
> On Mon, Nov 05, 2012 at 14:42:22, Philip, Avinash wrote:
> [...]
> > +pwmss0: pwmss@4830 {
> > + compatible = "ti,am33xx-pwmss";
> > + reg = <0x4830 0x10
> > + 0x48300100 0x80
> > + 0x48300180 0x80
> > +
.slave = &am33xx_ecap0_hwmod,
> > + .clk= "l4ls_gclk",
> > + .addr = am33xx_ecap0_addr_space,
> > + .user = OCP_USER_MPU,
> > +};
>
> Noticed this in another patch which is quite similar so commenting here
> agai
ot;l4ls_gclk",
> + .addr = am33xx_ecap0_addr_space,
> + .user = OCP_USER_MPU,
> +};
Noticed this in another patch which is quite similar so commenting here
again. Is the user field required if you are just creating a parent-child
relationship here?
Regards,
Vaibhav
--
To
On Mon, Nov 05, 2012 at 14:42:22, Philip, Avinash wrote:
[...]
> +pwmss0: pwmss@4830 {
> + compatible = "ti,am33xx-pwmss";
> + reg = <0x4830 0x10
> + 0x48300100 0x80
> + 0x48300180 0x80
> + 0x48300200 0x80>;
Do you really need the 4 address ranges
ock gating
for individual PWMSS submodules, and submodule drivers has to enable
clock gating from their drivers.
As this is only supported during DT boot, the parent<->child relationship
is created and populated in DT execution flow. The only required change
is inside DTS file, making EHRPWM &
As part of PWM subsystem integration, PWM subsystem are sharing
resources like clock across submodules (ECAP, EQEP & EHRPWM).
To handle resource sharing & IP integration
1. Rework on parent child relation between PWMSS and
ECAP, EQEP & EHRPWM child devices to support runtime PM.
2. Add support f
From: Jiang Liu
Currently pci_bind.c is used to maintain binding relationship between
ACPI and PCI devices. But it's broken when handling PCI hotplug events.
For the acpiphp driver, it's designed to update the binding relationship
when PCI hotplug event happens, but the impleme
From: Jiang Liu
Currently pci_bind.c is used to maintain binding relationship between
ACPI and PCI devices. But it's broken when handling PCI hotplug events.
For the acpiphp driver, it's designed to update the binding relationship
when PCI hotplug event happens, but the impleme
2012-07-25 (수), 17:39 +0200, Jiri Olsa:
> On Tue, Jul 24, 2012 at 06:01:27PM +0900, Namhyung Kim wrote:
> > In order to support the event group viewer, their group relationship
> > is needed. Since it's not recorded explicitly anywhere in the perf.data
> > we should par
On Tue, Jul 24, 2012 at 06:01:27PM +0900, Namhyung Kim wrote:
> In order to support the event group viewer, their group relationship
> is needed. Since it's not recorded explicitly anywhere in the perf.data
> we should parse saved cmdline and apply the result to the evlist. It is
In order to support the event group viewer, their group relationship
is needed. Since it's not recorded explicitly anywhere in the perf.data
we should parse saved cmdline and apply the result to the evlist. It is
assumed that parsed entries are in a same order with the originals.
I know
1 - 100 of 102 matches
Mail list logo
