On Tuesday 14 January 2014 10:35:33 Feng Kan wrote:
> On Mon, Jan 13, 2014 at 10:06 PM, Arnd Bergmann wrote:
> > On Tuesday 14 January 2014, Feng Kan wrote:
> >>
> >> >
> >> > Is this related to the standard ARM SCU that manages multiprocessor
> >> > systems, or a different unit that uses the
On Mon, Jan 13, 2014 at 10:06 PM, Arnd Bergmann wrote:
> On Tuesday 14 January 2014, Feng Kan wrote:
>>
>> >
>> > Is this related to the standard ARM SCU that manages multiprocessor
>> > systems, or a different unit that uses the same name?
>>
>> FKAN: You mean the snoop control unit in ARM. This
On Mon, Jan 13, 2014 at 10:06 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 14 January 2014, Feng Kan wrote:
Is this related to the standard ARM SCU that manages multiprocessor
systems, or a different unit that uses the same name?
FKAN: You mean the snoop control unit in ARM. This is
On Tuesday 14 January 2014 10:35:33 Feng Kan wrote:
On Mon, Jan 13, 2014 at 10:06 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 14 January 2014, Feng Kan wrote:
Is this related to the standard ARM SCU that manages multiprocessor
systems, or a different unit that uses the same
On Tuesday 14 January 2014, Feng Kan wrote:
>
> >
> > Is this related to the standard ARM SCU that manages multiprocessor
> > systems, or a different unit that uses the same name?
>
> FKAN: You mean the snoop control unit in ARM. This is different from
> that, the main function of this unit is
>
> Is this related to the standard ARM SCU that manages multiprocessor
> systems, or a different unit that uses the same name?
FKAN: You mean the snoop control unit in ARM. This is different from
that, the main function of this unit is clk control.
>
> Since this is a global register range with
On Monday 13 January 2014, Feng Kan wrote:
> FKAN: I could remove this dts node and create another dts node that
> describe the range of registers on the SCU and use that node in this driver.
> I am not sure which subsystem I can use to handle this case, I do see a reset
> subsystem in the kernel
> That is not what I was asking about.
>
> The problem with your binding is that it doesn't seem to describe
> the hardware structure at all, but rather try to invent devices
> because of how it's convenient for how you write the Linux drivers.
>
> This is never a good idea and it will become a
On Thursday 09 January 2014, Feng Kan wrote:
> On Wed, Jan 8, 2014 at 2:08 AM, Arnd Bergmann wrote:
> > On Wednesday 08 January 2014 10:05:50 Mark Rutland wrote:
> >> > +
> >> > +Example:
> >> > +
> >> > + reboot@0 {
> >> > + compatible = "apm,xgene-reboot";
> >> > +
On Thursday 09 January 2014, Feng Kan wrote:
On Wed, Jan 8, 2014 at 2:08 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 08 January 2014 10:05:50 Mark Rutland wrote:
+
+Example:
+
+ reboot@0 {
+ compatible = apm,xgene-reboot;
+ reg = 0x0
That is not what I was asking about.
The problem with your binding is that it doesn't seem to describe
the hardware structure at all, but rather try to invent devices
because of how it's convenient for how you write the Linux drivers.
This is never a good idea and it will become a problem
On Monday 13 January 2014, Feng Kan wrote:
FKAN: I could remove this dts node and create another dts node that
describe the range of registers on the SCU and use that node in this driver.
I am not sure which subsystem I can use to handle this case, I do see a reset
subsystem in the kernel but
Is this related to the standard ARM SCU that manages multiprocessor
systems, or a different unit that uses the same name?
FKAN: You mean the snoop control unit in ARM. This is different from
that, the main function of this unit is clk control.
Since this is a global register range with a
On Tuesday 14 January 2014, Feng Kan wrote:
Is this related to the standard ARM SCU that manages multiprocessor
systems, or a different unit that uses the same name?
FKAN: You mean the snoop control unit in ARM. This is different from
that, the main function of this unit is clk
On Wed, Jan 8, 2014 at 2:05 AM, Mark Rutland wrote:
> On Tue, Jan 07, 2014 at 10:50:36PM +, Feng Kan wrote:
>> Add X-Gene reboot device tree node documentation.
>>
>> Signed-off-by: Feng Kan
>> ---
>> .../devicetree/bindings/arm64/xgene/reboot.txt | 10 ++
>> 1 files changed,
On Wed, Jan 8, 2014 at 2:05 AM, Mark Rutland mark.rutl...@arm.com wrote:
On Tue, Jan 07, 2014 at 10:50:36PM +, Feng Kan wrote:
Add X-Gene reboot device tree node documentation.
Signed-off-by: Feng Kan f...@apm.com
---
.../devicetree/bindings/arm64/xgene/reboot.txt | 10 ++
On Wed, Jan 8, 2014 at 2:08 AM, Arnd Bergmann wrote:
> On Wednesday 08 January 2014 10:05:50 Mark Rutland wrote:
>> > +
>> > +Example:
>> > +
>> > + reboot@0 {
>> > + compatible = "apm,xgene-reboot";
>> > + reg = <0x0 0x1714 0x0 0x4>;
>> > + };
>>
>> Given this
On Wed, Jan 8, 2014 at 2:08 AM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 08 January 2014 10:05:50 Mark Rutland wrote:
+
+Example:
+
+ reboot@0 {
+ compatible = apm,xgene-reboot;
+ reg = 0x0 0x1714 0x0 0x4;
+ };
Given this seems to be a
On Wednesday 08 January 2014 10:05:50 Mark Rutland wrote:
> > +
> > +Example:
> > +
> > + reboot@0 {
> > + compatible = "apm,xgene-reboot";
> > + reg = <0x0 0x1714 0x0 0x4>;
> > + };
>
> Given this seems to be a 64-bit address, the unit address should
>
On Tue, Jan 07, 2014 at 10:50:36PM +, Feng Kan wrote:
> Add X-Gene reboot device tree node documentation.
>
> Signed-off-by: Feng Kan
> ---
> .../devicetree/bindings/arm64/xgene/reboot.txt | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
> create mode 100644
On Tue, Jan 07, 2014 at 10:50:36PM +, Feng Kan wrote:
Add X-Gene reboot device tree node documentation.
Signed-off-by: Feng Kan f...@apm.com
---
.../devicetree/bindings/arm64/xgene/reboot.txt | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
create mode 100644
On Wednesday 08 January 2014 10:05:50 Mark Rutland wrote:
+
+Example:
+
+ reboot@0 {
+ compatible = apm,xgene-reboot;
+ reg = 0x0 0x1714 0x0 0x4;
+ };
Given this seems to be a 64-bit address, the unit address should
preferably be 0,1714
Add X-Gene reboot device tree node documentation.
Signed-off-by: Feng Kan
---
.../devicetree/bindings/arm64/xgene/reboot.txt | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm64/xgene/reboot.txt
diff --git
Add X-Gene reboot device tree node documentation.
Signed-off-by: Feng Kan f...@apm.com
---
.../devicetree/bindings/arm64/xgene/reboot.txt | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm64/xgene/reboot.txt
diff
24 matches
Mail list logo