Patchwork [v2,05/11] ARM: dt: tegra30: Add device node for APB MISC

login
register
mail settings
Submitter Prashant Gaikwad
Date Dec. 27, 2012, 2:47 p.m.
Message ID <1356619644-18565-6-git-send-email-pgaikwad@nvidia.com>
Download mbox | patch
Permalink /patch/208307/
State Superseded, archived
Headers show

Comments

Prashant Gaikwad - Dec. 27, 2012, 2:47 p.m.
APB misc contains multiple registers required by different modules
such as CAR.

Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
---
 arch/arm/boot/dts/tegra30.dtsi |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
Stephen Warren - Jan. 2, 2013, 10 p.m.
On 12/27/2012 07:47 AM, Prashant Gaikwad wrote:
> APB misc contains multiple registers required by different modules
> such as CAR.

I don't see a DT binding document that describes what
nvidia,tegra30-apbmisc means. Also, the register range for this new node
overlaps that for the pinmux node, so they can't both "request" their
register region. You may need multiple entries in the apbmisc reg
property to avoid this.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Prashant Gaikwad - Jan. 3, 2013, 6:11 a.m.
On Thursday 03 January 2013 03:30 AM, Stephen Warren wrote:
> On 12/27/2012 07:47 AM, Prashant Gaikwad wrote:
>> APB misc contains multiple registers required by different modules
>> such as CAR.
> I don't see a DT binding document that describes what
> nvidia,tegra30-apbmisc means. Also, the register range for this new node
> overlaps that for the pinmux node, so they can't both "request" their
> register region. You may need multiple entries in the apbmisc reg
> property to avoid this.

apbmisc reg for Tegra30 can be divided into following entries:

strap registers
jtag configuration registers
pull_up/pull_down control registers
vclk control registers
tvdac registers
chip id revision registers
pad control registers

This list is not same for Tegra20 and Tegra30.

OR

another way is to add chip id revision register region to CAR node as 
done for pinmux node and remove apb misc node.

What is preferred?
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Warren - Jan. 3, 2013, 4:11 p.m.
On 01/02/2013 11:11 PM, Prashant Gaikwad wrote:
> On Thursday 03 January 2013 03:30 AM, Stephen Warren wrote:
>> On 12/27/2012 07:47 AM, Prashant Gaikwad wrote:
>>> APB misc contains multiple registers required by different modules
>>> such as CAR.
>> I don't see a DT binding document that describes what
>> nvidia,tegra30-apbmisc means. Also, the register range for this new node
>> overlaps that for the pinmux node, so they can't both "request" their
>> register region. You may need multiple entries in the apbmisc reg
>> property to avoid this.
> 
> apbmisc reg for Tegra30 can be divided into following entries:
> 
> strap registers
> jtag configuration registers
> pull_up/pull_down control registers
> vclk control registers
> tvdac registers
> chip id revision registers
> pad control registers
> 
> This list is not same for Tegra20 and Tegra30.

OK. It sounds like we need a true APB MISC driver then, to abstract the
differences; the clock driver really shouldn't be touching the APB MISC
registers in all likelihood, unless a subset of the sections you mention
above are truly dedicated to clock functionality.

> OR
> 
> another way is to add chip id revision register region to CAR node as
> done for pinmux node and remove apb misc node.

The pinmux controller doesn't have a reg entry for the chip ID register.
I don't understand what you mean here.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Prashant Gaikwad - Jan. 4, 2013, 1:48 a.m.
On Thursday 03 January 2013 09:41 PM, Stephen Warren wrote:
> On 01/02/2013 11:11 PM, Prashant Gaikwad wrote:
>> On Thursday 03 January 2013 03:30 AM, Stephen Warren wrote:
>>> On 12/27/2012 07:47 AM, Prashant Gaikwad wrote:
>>>> APB misc contains multiple registers required by different modules
>>>> such as CAR.
>>> I don't see a DT binding document that describes what
>>> nvidia,tegra30-apbmisc means. Also, the register range for this new node
>>> overlaps that for the pinmux node, so they can't both "request" their
>>> register region. You may need multiple entries in the apbmisc reg
>>> property to avoid this.
>> apbmisc reg for Tegra30 can be divided into following entries:
>>
>> strap registers
>> jtag configuration registers
>> pull_up/pull_down control registers
>> vclk control registers
>> tvdac registers
>> chip id revision registers
>> pad control registers
>>
>> This list is not same for Tegra20 and Tegra30.
> OK. It sounds like we need a true APB MISC driver then, to abstract the
> differences; the clock driver really shouldn't be touching the APB MISC
> registers in all likelihood, unless a subset of the sections you mention
> above are truly dedicated to clock functionality.

I don't think it is a good idea to create a driver for APB MISC, all 
registers are used by different drivers.
Only chip id revision registers are used in clock driver.

>> OR
>>
>> another way is to add chip id revision register region to CAR node as
>> done for pinmux node and remove apb misc node.
> The pinmux controller doesn't have a reg entry for the chip ID register.
> I don't understand what you mean here.

I mean as we have separate entry for PAD control registers region in 
pinmux node we can have also have separate entry for chid id revision 
register region in CAR node.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Warren - Jan. 4, 2013, 3:05 a.m.
On 01/03/2013 06:48 PM, Prashant Gaikwad wrote:
> On Thursday 03 January 2013 09:41 PM, Stephen Warren wrote:
>> On 01/02/2013 11:11 PM, Prashant Gaikwad wrote:
>>> On Thursday 03 January 2013 03:30 AM, Stephen Warren wrote:
>>>> On 12/27/2012 07:47 AM, Prashant Gaikwad wrote:
>>>>> APB misc contains multiple registers required by different modules
>>>>> such as CAR.
>>>> I don't see a DT binding document that describes what
>>>> nvidia,tegra30-apbmisc means. Also, the register range for this new
>>>> node
>>>> overlaps that for the pinmux node, so they can't both "request" their
>>>> register region. You may need multiple entries in the apbmisc reg
>>>> property to avoid this.
>>> apbmisc reg for Tegra30 can be divided into following entries:
>>>
>>> strap registers
>>> jtag configuration registers
>>> pull_up/pull_down control registers
>>> vclk control registers
>>> tvdac registers
>>> chip id revision registers
>>> pad control registers
>>>
>>> This list is not same for Tegra20 and Tegra30.
>> OK. It sounds like we need a true APB MISC driver then, to abstract the
>> differences; the clock driver really shouldn't be touching the APB MISC
>> registers in all likelihood, unless a subset of the sections you mention
>> above are truly dedicated to clock functionality.
> 
> I don't think it is a good idea to create a driver for APB MISC, all
> registers are used by different drivers.

Well, it's even worse to have a bunch of other drivers randomly trample
on a set of registers they don't own.

> Only chip id revision registers are used in clock driver.

There are already global variables exposed by the Tegra fuse driver; can
you just read those?

>>> OR
>>>
>>> another way is to add chip id revision register region to CAR node as
>>> done for pinmux node and remove apb misc node.
>>
>> The pinmux controller doesn't have a reg entry for the chip ID register.
>> I don't understand what you mean here.
> 
> I mean as we have separate entry for PAD control registers region in
> pinmux node we can have also have separate entry for chid id revision
> register region in CAR node.

The pad control registers are part of the pinmux HW, so it makes perfect
sense for the pinmux driver to control them. The APB misc registers
aren't part of the clock register set, so it doesn't make sense to the
clock driver to touch them.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Prashant Gaikwad - Jan. 4, 2013, 3:23 a.m.
On Friday 04 January 2013 08:35 AM, Stephen Warren wrote:
> On 01/03/2013 06:48 PM, Prashant Gaikwad wrote:
>> On Thursday 03 January 2013 09:41 PM, Stephen Warren wrote:
>>> On 01/02/2013 11:11 PM, Prashant Gaikwad wrote:
>>>> On Thursday 03 January 2013 03:30 AM, Stephen Warren wrote:
>>>>> On 12/27/2012 07:47 AM, Prashant Gaikwad wrote:
>>>>>> APB misc contains multiple registers required by different modules
>>>>>> such as CAR.
>>>>> I don't see a DT binding document that describes what
>>>>> nvidia,tegra30-apbmisc means. Also, the register range for this new
>>>>> node
>>>>> overlaps that for the pinmux node, so they can't both "request" their
>>>>> register region. You may need multiple entries in the apbmisc reg
>>>>> property to avoid this.
>>>> apbmisc reg for Tegra30 can be divided into following entries:
>>>>
>>>> strap registers
>>>> jtag configuration registers
>>>> pull_up/pull_down control registers
>>>> vclk control registers
>>>> tvdac registers
>>>> chip id revision registers
>>>> pad control registers
>>>>
>>>> This list is not same for Tegra20 and Tegra30.
>>> OK. It sounds like we need a true APB MISC driver then, to abstract the
>>> differences; the clock driver really shouldn't be touching the APB MISC
>>> registers in all likelihood, unless a subset of the sections you mention
>>> above are truly dedicated to clock functionality.
>> I don't think it is a good idea to create a driver for APB MISC, all
>> registers are used by different drivers.
> Well, it's even worse to have a bunch of other drivers randomly trample
> on a set of registers they don't own.
>
>> Only chip id revision registers are used in clock driver.
> There are already global variables exposed by the Tegra fuse driver; can
> you just read those?

It is not about variables or some value, we have to read some apb 
register to flush the write operation in apb bus before we disable 
peripheral clock.
We are using chip id revision register for this purpose.

>>>> OR
>>>>
>>>> another way is to add chip id revision register region to CAR node as
>>>> done for pinmux node and remove apb misc node.
>>> The pinmux controller doesn't have a reg entry for the chip ID register.
>>> I don't understand what you mean here.
>> I mean as we have separate entry for PAD control registers region in
>> pinmux node we can have also have separate entry for chid id revision
>> register region in CAR node.
> The pad control registers are part of the pinmux HW, so it makes perfect
> sense for the pinmux driver to control them. The APB misc registers
> aren't part of the clock register set, so it doesn't make sense to the
> clock driver to touch them.

--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Warren - Jan. 4, 2013, 4 a.m.
On 01/03/2013 08:23 PM, Prashant Gaikwad wrote:
> On Friday 04 January 2013 08:35 AM, Stephen Warren wrote:
>> On 01/03/2013 06:48 PM, Prashant Gaikwad wrote:
>>> On Thursday 03 January 2013 09:41 PM, Stephen Warren wrote:
...
>>>> OK. It sounds like we need a true APB MISC driver then, to abstract the
>>>> differences; the clock driver really shouldn't be touching the APB MISC
>>>> registers in all likelihood, unless a subset of the sections you
>>>> mention
>>>> above are truly dedicated to clock functionality.
>>>
>>> I don't think it is a good idea to create a driver for APB MISC, all
>>> registers are used by different drivers.
>>
>> Well, it's even worse to have a bunch of other drivers randomly trample
>> on a set of registers they don't own.
>>
>>> Only chip id revision registers are used in clock driver.
>> There are already global variables exposed by the Tegra fuse driver; can
>> you just read those?
> 
> It is not about variables or some value, we have to read some apb
> register to flush the write operation in apb bus before we disable
> peripheral clock.
> We are using chip id revision register for this purpose.

Ah. That's definitely not something the clock driver should be doing
directly. It's probably OK to add a custom Tegra-specific function to
some file in arch/arm/mach-tegra to implement this. Even better would be
a full bus driver for the APB bus, but that's probably too much bloat
for now.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Prashant Gaikwad - Jan. 4, 2013, 4:26 a.m.
On Friday 04 January 2013 09:30 AM, Stephen Warren wrote:
> On 01/03/2013 08:23 PM, Prashant Gaikwad wrote:
>> On Friday 04 January 2013 08:35 AM, Stephen Warren wrote:
>>> On 01/03/2013 06:48 PM, Prashant Gaikwad wrote:
>>>> On Thursday 03 January 2013 09:41 PM, Stephen Warren wrote:
> ...
>>>>> OK. It sounds like we need a true APB MISC driver then, to abstract the
>>>>> differences; the clock driver really shouldn't be touching the APB MISC
>>>>> registers in all likelihood, unless a subset of the sections you
>>>>> mention
>>>>> above are truly dedicated to clock functionality.
>>>> I don't think it is a good idea to create a driver for APB MISC, all
>>>> registers are used by different drivers.
>>> Well, it's even worse to have a bunch of other drivers randomly trample
>>> on a set of registers they don't own.
>>>
>>>> Only chip id revision registers are used in clock driver.
>>> There are already global variables exposed by the Tegra fuse driver; can
>>> you just read those?
>> It is not about variables or some value, we have to read some apb
>> register to flush the write operation in apb bus before we disable
>> peripheral clock.
>> We are using chip id revision register for this purpose.
> Ah. That's definitely not something the clock driver should be doing
> directly. It's probably OK to add a custom Tegra-specific function to
> some file in arch/arm/mach-tegra to implement this. Even better would be
> a full bus driver for the APB bus, but that's probably too much bloat
> for now.

tegra_init_fuse in arch/arm/mach-tegra/fuse.c is already reading chip id 
revision register, so I can implement one function to read this register 
in fuse.c, which will be used by clock driver and tegra_init_fuse.
But then we need to add it to some header file in include/mach or 
include/linux, where? any suggestion?
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Warren - Jan. 4, 2013, 5:21 a.m.
On 01/03/2013 09:26 PM, Prashant Gaikwad wrote:
> On Friday 04 January 2013 09:30 AM, Stephen Warren wrote:
>> On 01/03/2013 08:23 PM, Prashant Gaikwad wrote:
>>> On Friday 04 January 2013 08:35 AM, Stephen Warren wrote:
>>>> On 01/03/2013 06:48 PM, Prashant Gaikwad wrote:
>>>>> On Thursday 03 January 2013 09:41 PM, Stephen Warren wrote:
>> ...
>>>>>> OK. It sounds like we need a true APB MISC driver then, to
>>>>>> abstract the
>>>>>> differences; the clock driver really shouldn't be touching the APB
>>>>>> MISC
>>>>>> registers in all likelihood, unless a subset of the sections you
>>>>>> mention
>>>>>> above are truly dedicated to clock functionality.
>>>>> I don't think it is a good idea to create a driver for APB MISC, all
>>>>> registers are used by different drivers.
>>>> Well, it's even worse to have a bunch of other drivers randomly trample
>>>> on a set of registers they don't own.
>>>>
>>>>> Only chip id revision registers are used in clock driver.
>>>> There are already global variables exposed by the Tegra fuse driver;
>>>> can
>>>> you just read those?
>>> It is not about variables or some value, we have to read some apb
>>> register to flush the write operation in apb bus before we disable
>>> peripheral clock.
>>> We are using chip id revision register for this purpose.
>> Ah. That's definitely not something the clock driver should be doing
>> directly. It's probably OK to add a custom Tegra-specific function to
>> some file in arch/arm/mach-tegra to implement this. Even better would be
>> a full bus driver for the APB bus, but that's probably too much bloat
>> for now.
> 
> tegra_init_fuse in arch/arm/mach-tegra/fuse.c is already reading chip id
> revision register, so I can implement one function to read this register
> in fuse.c, which will be used by clock driver and tegra_init_fuse.
> But then we need to add it to some header file in include/mach or
> include/linux, where? any suggestion?

Somewhere other than arch/arm/mach-tega/include/mach/ would be good, so
we don't have to move it later when we enable multi-platform zImage for
Tegra. Perhaps include/linux/tegra-soc.h? I guess we could move the
existing mach/powergate.h contents into that file later too.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Prashant Gaikwad - Jan. 4, 2013, 5:31 a.m.
On Friday 04 January 2013 10:51 AM, Stephen Warren wrote:
> On 01/03/2013 09:26 PM, Prashant Gaikwad wrote:
>> On Friday 04 January 2013 09:30 AM, Stephen Warren wrote:
>>> On 01/03/2013 08:23 PM, Prashant Gaikwad wrote:
>>>> On Friday 04 January 2013 08:35 AM, Stephen Warren wrote:
>>>>> On 01/03/2013 06:48 PM, Prashant Gaikwad wrote:
>>>>>> On Thursday 03 January 2013 09:41 PM, Stephen Warren wrote:
>>> ...
>>>>>>> OK. It sounds like we need a true APB MISC driver then, to
>>>>>>> abstract the
>>>>>>> differences; the clock driver really shouldn't be touching the APB
>>>>>>> MISC
>>>>>>> registers in all likelihood, unless a subset of the sections you
>>>>>>> mention
>>>>>>> above are truly dedicated to clock functionality.
>>>>>> I don't think it is a good idea to create a driver for APB MISC, all
>>>>>> registers are used by different drivers.
>>>>> Well, it's even worse to have a bunch of other drivers randomly trample
>>>>> on a set of registers they don't own.
>>>>>
>>>>>> Only chip id revision registers are used in clock driver.
>>>>> There are already global variables exposed by the Tegra fuse driver;
>>>>> can
>>>>> you just read those?
>>>> It is not about variables or some value, we have to read some apb
>>>> register to flush the write operation in apb bus before we disable
>>>> peripheral clock.
>>>> We are using chip id revision register for this purpose.
>>> Ah. That's definitely not something the clock driver should be doing
>>> directly. It's probably OK to add a custom Tegra-specific function to
>>> some file in arch/arm/mach-tegra to implement this. Even better would be
>>> a full bus driver for the APB bus, but that's probably too much bloat
>>> for now.
>> tegra_init_fuse in arch/arm/mach-tegra/fuse.c is already reading chip id
>> revision register, so I can implement one function to read this register
>> in fuse.c, which will be used by clock driver and tegra_init_fuse.
>> But then we need to add it to some header file in include/mach or
>> include/linux, where? any suggestion?
> Somewhere other than arch/arm/mach-tega/include/mach/ would be good, so
> we don't have to move it later when we enable multi-platform zImage for
> Tegra. Perhaps include/linux/tegra-soc.h? I guess we could move the
> existing mach/powergate.h contents into that file later too.

include/linux/tegra-soc.h seems fine, I will send updated patch series.


--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Laxman Dewangan - Jan. 4, 2013, 11:56 a.m.
On Friday 04 January 2013 09:30 AM, Stephen Warren wrote:
> On 01/03/2013 08:23 PM, Prashant Gaikwad wrote:
>> On Friday 04 January 2013 08:35 AM, Stephen Warren wrote:
>>> On 01/03/2013 06:48 PM, Prashant Gaikwad wrote:
>>>> On Thursday 03 January 2013 09:41 PM, Stephen Warren wrote:
> ...
>>>>> OK. It sounds like we need a true APB MISC driver then, to abstract the
>>>>> differences; the clock driver really shouldn't be touching the APB MISC
>>>>> registers in all likelihood, unless a subset of the sections you
>>>>> mention
>>>>> above are truly dedicated to clock functionality.
>>>> I don't think it is a good idea to create a driver for APB MISC, all
>>>> registers are used by different drivers.
>>> Well, it's even worse to have a bunch of other drivers randomly trample
>>> on a set of registers they don't own.
>>>
>>>> Only chip id revision registers are used in clock driver.
>>> There are already global variables exposed by the Tegra fuse driver; can
>>> you just read those?
>> It is not about variables or some value, we have to read some apb
>> register to flush the write operation in apb bus before we disable
>> peripheral clock.
>> We are using chip id revision register for this purpose.
> Ah. That's definitely not something the clock driver should be doing
> directly. It's probably OK to add a custom Tegra-specific function to
> some file in arch/arm/mach-tegra to implement this. Even better would be
> a full bus driver for the APB bus, but that's probably too much bloat
> for now.

I think individual driver should take care of flushing the write 
operation inplace of clock driver.
Atleast I moved flushing to i2c and spi for these drivers. Polluting 
clock driver here does not make sense here.

--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Warren - Jan. 4, 2013, 7:57 p.m.
On 01/04/2013 04:56 AM, Laxman Dewangan wrote:
> On Friday 04 January 2013 09:30 AM, Stephen Warren wrote:
>> On 01/03/2013 08:23 PM, Prashant Gaikwad wrote:
>>> On Friday 04 January 2013 08:35 AM, Stephen Warren wrote:
>>>> On 01/03/2013 06:48 PM, Prashant Gaikwad wrote:
>>>>> On Thursday 03 January 2013 09:41 PM, Stephen Warren wrote:
>> ...
>>>>>> OK. It sounds like we need a true APB MISC driver then, to
>>>>>> abstract the
>>>>>> differences; the clock driver really shouldn't be touching the APB
>>>>>> MISC
>>>>>> registers in all likelihood, unless a subset of the sections you
>>>>>> mention
>>>>>> above are truly dedicated to clock functionality.
>>>>> I don't think it is a good idea to create a driver for APB MISC, all
>>>>> registers are used by different drivers.
>>>> Well, it's even worse to have a bunch of other drivers randomly trample
>>>> on a set of registers they don't own.
>>>>
>>>>> Only chip id revision registers are used in clock driver.
>>>> There are already global variables exposed by the Tegra fuse driver;
>>>> can
>>>> you just read those?
>>> It is not about variables or some value, we have to read some apb
>>> register to flush the write operation in apb bus before we disable
>>> peripheral clock.
>>> We are using chip id revision register for this purpose.
>> Ah. That's definitely not something the clock driver should be doing
>> directly. It's probably OK to add a custom Tegra-specific function to
>> some file in arch/arm/mach-tegra to implement this. Even better would be
>> a full bus driver for the APB bus, but that's probably too much bloat
>> for now.
> 
> I think individual driver should take care of flushing the write
> operation inplace of clock driver.
> Atleast I moved flushing to i2c and spi for these drivers. Polluting
> clock driver here does not make sense here.

That does seem like a reasonable assertion.

Still, I believe the clock driver currently does this already today, so
removing it might be a regression. I think we want to:

a) Maintain this feature in the clock driver rework for now.
b) Audit and fix any device drivers.
c) Remove the feature from the clock driver.

Of course, if (b) is so easy to do that you don't need to do (a) or (c)
at all, that's fine too, but I believe Prashant is under time pressure
to get the common clock rework done before his vacation.
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 6765646..00e2d44 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -190,6 +190,11 @@ 
 		interrupt-controller;
 	};
 
+	apbmisc: apbmisc {
+		compatible = "nvidia,tegra30-apbmisc";
+		reg = <0x70000000 0x1000>;
+	};
+
 	pinmux: pinmux {
 		compatible = "nvidia,tegra30-pinmux";
 		reg = <0x70000868 0xd4    /* Pad control registers */