Re: [PATCH V3] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
On 10/08/2013 12:58 PM, Tony Lindgren wrote:
> * Nishanth Menon [131008 05:08]:
>> On 10/07/2013 07:05 PM, Sebastian Reichel wrote:
>>> On Mon, Oct 07, 2013 at 03:43:49PM -0500, Nishanth Menon wrote:
>>>> diff --git a/arch/arm/mach-omap2/board-generic.c
>>>> b/arch/arm/mach-omap2/board-generic.c
>>>> index 39c7838..4fe5b9c 100644
>>>> --- a/arch/arm/mach-omap2/board-generic.c
>>>> +++ b/arch/arm/mach-omap2/board-generic.c
>>>> @@ -113,6 +113,7 @@ MACHINE_END
>>>> #ifdef CONFIG_ARCH_OMAP3
>>>> static const char *omap3_boards_compat[] __initdata = {
>>>>"ti,omap3",
>>>> + "ti,omap343x",
>>>
>>> You used omap36xx everywhere, so I guess this should be
>>> "ti,omap34xx"?
>>
>> 3630 has at least two variants:
>> http://www.ti.com/product/omap3621
>> http://www.ti.com/product/omap3630
>>
>> It got further spun off in 37xx family:
>> http://www.ti.com/product/dm3730 (DM3730 and DM3725)
>>
>> 3430 is no longer in production - but just had a single version (at
>> least what I can remember).
>>
>> 3530 variant of 3430 on the other hand has a few:
>> http://processors.wiki.ti.com/index.php/OMAP3_Overview
>>
>>
>> I am ok to change to ti,omap34xx if folks think that is the right
>> thing to do. Personally, I might prefer to handle 35xx family slightly
>> differently considering deltas.
>
> I've dropped that part as that's not needed for the fix AFAIK.
> Here's what I've applied and pushed out to omap-for-v3.12/fixes.
>
> Regards,
>
> Tony
>
> From: Nishanth Menon
> Date: Mon, 7 Oct 2013 15:43:49 -0500
> Subject: [PATCH] ARM: OMAP3: Fix hardware detection for omap3630 when booted
> with device tree
>
> SoC family definitions at the moment are reactive to board needs
> as a result, beagle-xm would matchup with ti,omap3 which invokes
> omap3430_init_early instead of omap3630_init_early. Obviously, this is
> the wrong behavior.
>
> With clock node dts conversion, we get the following warnings before
> system hangs as a result and 3630 based platforms fails to boot
> (uart4 clocks are only present in OMAP3630 and not present in
> OMAP3430):
>
> ...
> omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
> omap_hwmod: uart4: cannot _init_clocks
>
> WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
> _init+0x6c/0x80()
> omap_hwmod: uart4: couldn't init clocks
> ...
>
> WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
> _enable+0x254/0x280()
> omap_hwmod: timer12: enabled state can only be entered from
> initialized, idle, or disabled state
> ...
>
> WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
> _idle+0xd4/0xf8()
> omap_hwmod: timer12: idle state can only be entered from enabled state
>
> WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
> _enable+0x254/0x280()
> omap_hwmod: uart4: enabled state can only be entered from
> initialized, idle, or disabled state
>
> So, add specific compatiblity for 3630 to allow match for Beagle-XM
> platform.
>
> Signed-off-by: Nishanth Menon
> [t...@atomide.com: left out ti,omap343x, updated comments]
> Signed-off-by: Tony Lindgren
>
> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
> b/arch/arm/boot/dts/omap3-beagle-xm.dts
> index 0c514dc..2816bf6 100644
> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> @@ -11,7 +11,7 @@
>
> / {
> model = "TI OMAP3 BeagleBoard xM";
> - compatible = "ti,omap3-beagle-xm", "ti,omap3-beagle", "ti,omap3";
> + compatible = "ti,omap3-beagle-xm", "ti,omap36xx", "ti,omap3";
>
> cpus {
> cpu@0 {
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c
> index 39c7838..87162e1 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -129,6 +129,24 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened
> Device Tree)")
> .restart= omap3xxx_restart,
> MACHINE_END
>
> +static const char *omap36xx_boards_compat[] __initdata = {
> + "ti,omap36xx",
> + NULL,
> +};
> +
> +DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP36xx (Flattened Device Tree)")
> + .reserve= omap_reserve,
> + .map_io = omap3_map_io,
> + .init_early = omap3630_init_early,
> + .init_irq = omap_intc_of_init,
> + .h
Re: [PATCH V3] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
* Nishanth Menon [131008 05:08]:
> On 10/07/2013 07:05 PM, Sebastian Reichel wrote:
> > On Mon, Oct 07, 2013 at 03:43:49PM -0500, Nishanth Menon wrote:
> >> diff --git a/arch/arm/mach-omap2/board-generic.c
> >> b/arch/arm/mach-omap2/board-generic.c
> >> index 39c7838..4fe5b9c 100644
> >> --- a/arch/arm/mach-omap2/board-generic.c
> >> +++ b/arch/arm/mach-omap2/board-generic.c
> >> @@ -113,6 +113,7 @@ MACHINE_END
> >> #ifdef CONFIG_ARCH_OMAP3
> >> static const char *omap3_boards_compat[] __initdata = {
> >>"ti,omap3",
> >> + "ti,omap343x",
> >
> > You used omap36xx everywhere, so I guess this should be
> > "ti,omap34xx"?
>
> 3630 has at least two variants:
> http://www.ti.com/product/omap3621
> http://www.ti.com/product/omap3630
>
> It got further spun off in 37xx family:
> http://www.ti.com/product/dm3730 (DM3730 and DM3725)
>
> 3430 is no longer in production - but just had a single version (at
> least what I can remember).
>
> 3530 variant of 3430 on the other hand has a few:
> http://processors.wiki.ti.com/index.php/OMAP3_Overview
>
>
> I am ok to change to ti,omap34xx if folks think that is the right
> thing to do. Personally, I might prefer to handle 35xx family slightly
> differently considering deltas.
I've dropped that part as that's not needed for the fix AFAIK.
Here's what I've applied and pushed out to omap-for-v3.12/fixes.
Regards,
Tony
From: Nishanth Menon
Date: Mon, 7 Oct 2013 15:43:49 -0500
Subject: [PATCH] ARM: OMAP3: Fix hardware detection for omap3630 when booted
with device tree
SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.
With clock node dts conversion, we get the following warnings before
system hangs as a result and 3630 based platforms fails to boot
(uart4 clocks are only present in OMAP3630 and not present in
OMAP3430):
...
omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
omap_hwmod: uart4: cannot _init_clocks
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
_init+0x6c/0x80()
omap_hwmod: uart4: couldn't init clocks
...
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from
initialized, idle, or disabled state
...
WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled state
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from
initialized, idle, or disabled state
So, add specific compatiblity for 3630 to allow match for Beagle-XM
platform.
Signed-off-by: Nishanth Menon
[t...@atomide.com: left out ti,omap343x, updated comments]
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 0c514dc..2816bf6 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -11,7 +11,7 @@
/ {
model = "TI OMAP3 BeagleBoard xM";
- compatible = "ti,omap3-beagle-xm", "ti,omap3-beagle", "ti,omap3";
+ compatible = "ti,omap3-beagle-xm", "ti,omap36xx", "ti,omap3";
cpus {
cpu@0 {
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..87162e1 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -129,6 +129,24 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened
Device Tree)")
.restart= omap3xxx_restart,
MACHINE_END
+static const char *omap36xx_boards_compat[] __initdata = {
+ "ti,omap36xx",
+ NULL,
+};
+
+DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP36xx (Flattened Device Tree)")
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3630_init_early,
+ .init_irq = omap_intc_of_init,
+ .handle_irq = omap3_intc_handle_irq,
+ .init_machine = omap_generic_init,
+ .init_late = omap3_init_late,
+ .init_time = omap3_sync32k_timer_init,
+ .dt_compat = omap36xx_boards_compat,
+ .restart= omap3xxx_restart,
+MACHINE_END
+
static const char *omap3_gp_boards_compat[] __initdata = {
"ti,omap3-beagle",
"timll,omap3-devkit8000",
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
On 10/07/2013 07:05 PM, Sebastian Reichel wrote:
> On Mon, Oct 07, 2013 at 03:43:49PM -0500, Nishanth Menon wrote:
>> diff --git a/arch/arm/mach-omap2/board-generic.c
>> b/arch/arm/mach-omap2/board-generic.c
>> index 39c7838..4fe5b9c 100644
>> --- a/arch/arm/mach-omap2/board-generic.c
>> +++ b/arch/arm/mach-omap2/board-generic.c
>> @@ -113,6 +113,7 @@ MACHINE_END
>> #ifdef CONFIG_ARCH_OMAP3
>> static const char *omap3_boards_compat[] __initdata = {
>> "ti,omap3",
>> +"ti,omap343x",
>
> You used omap36xx everywhere, so I guess this should be
> "ti,omap34xx"?
3630 has at least two variants:
http://www.ti.com/product/omap3621
http://www.ti.com/product/omap3630
It got further spun off in 37xx family:
http://www.ti.com/product/dm3730 (DM3730 and DM3725)
3430 is no longer in production - but just had a single version (at
least what I can remember).
3530 variant of 3430 on the other hand has a few:
http://processors.wiki.ti.com/index.php/OMAP3_Overview
I am ok to change to ti,omap34xx if folks think that is the right
thing to do. Personally, I might prefer to handle 35xx family slightly
differently considering deltas.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
On 10/07/2013 07:05 PM, Sebastian Reichel wrote:
On Mon, Oct 07, 2013 at 03:43:49PM -0500, Nishanth Menon wrote:
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..4fe5b9c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -113,6 +113,7 @@ MACHINE_END
#ifdef CONFIG_ARCH_OMAP3
static const char *omap3_boards_compat[] __initdata = {
ti,omap3,
+ti,omap343x,
You used omap36xx everywhere, so I guess this should be
ti,omap34xx?
3630 has at least two variants:
http://www.ti.com/product/omap3621
http://www.ti.com/product/omap3630
It got further spun off in 37xx family:
http://www.ti.com/product/dm3730 (DM3730 and DM3725)
3430 is no longer in production - but just had a single version (at
least what I can remember).
3530 variant of 3430 on the other hand has a few:
http://processors.wiki.ti.com/index.php/OMAP3_Overview
I am ok to change to ti,omap34xx if folks think that is the right
thing to do. Personally, I might prefer to handle 35xx family slightly
differently considering deltas.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
* Nishanth Menon n...@ti.com [131008 05:08]:
On 10/07/2013 07:05 PM, Sebastian Reichel wrote:
On Mon, Oct 07, 2013 at 03:43:49PM -0500, Nishanth Menon wrote:
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..4fe5b9c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -113,6 +113,7 @@ MACHINE_END
#ifdef CONFIG_ARCH_OMAP3
static const char *omap3_boards_compat[] __initdata = {
ti,omap3,
+ ti,omap343x,
You used omap36xx everywhere, so I guess this should be
ti,omap34xx?
3630 has at least two variants:
http://www.ti.com/product/omap3621
http://www.ti.com/product/omap3630
It got further spun off in 37xx family:
http://www.ti.com/product/dm3730 (DM3730 and DM3725)
3430 is no longer in production - but just had a single version (at
least what I can remember).
3530 variant of 3430 on the other hand has a few:
http://processors.wiki.ti.com/index.php/OMAP3_Overview
I am ok to change to ti,omap34xx if folks think that is the right
thing to do. Personally, I might prefer to handle 35xx family slightly
differently considering deltas.
I've dropped that part as that's not needed for the fix AFAIK.
Here's what I've applied and pushed out to omap-for-v3.12/fixes.
Regards,
Tony
From: Nishanth Menon n...@ti.com
Date: Mon, 7 Oct 2013 15:43:49 -0500
Subject: [PATCH] ARM: OMAP3: Fix hardware detection for omap3630 when booted
with device tree
SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.
With clock node dts conversion, we get the following warnings before
system hangs as a result and 3630 based platforms fails to boot
(uart4 clocks are only present in OMAP3630 and not present in
OMAP3430):
...
omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
omap_hwmod: uart4: cannot _init_clocks
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
_init+0x6c/0x80()
omap_hwmod: uart4: couldn't init clocks
...
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from
initialized, idle, or disabled state
...
WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled state
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from
initialized, idle, or disabled state
So, add specific compatiblity for 3630 to allow match for Beagle-XM
platform.
Signed-off-by: Nishanth Menon n...@ti.com
[t...@atomide.com: left out ti,omap343x, updated comments]
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 0c514dc..2816bf6 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -11,7 +11,7 @@
/ {
model = TI OMAP3 BeagleBoard xM;
- compatible = ti,omap3-beagle-xm, ti,omap3-beagle, ti,omap3;
+ compatible = ti,omap3-beagle-xm, ti,omap36xx, ti,omap3;
cpus {
cpu@0 {
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..87162e1 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -129,6 +129,24 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened
Device Tree))
.restart= omap3xxx_restart,
MACHINE_END
+static const char *omap36xx_boards_compat[] __initdata = {
+ ti,omap36xx,
+ NULL,
+};
+
+DT_MACHINE_START(OMAP36XX_DT, Generic OMAP36xx (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3630_init_early,
+ .init_irq = omap_intc_of_init,
+ .handle_irq = omap3_intc_handle_irq,
+ .init_machine = omap_generic_init,
+ .init_late = omap3_init_late,
+ .init_time = omap3_sync32k_timer_init,
+ .dt_compat = omap36xx_boards_compat,
+ .restart= omap3xxx_restart,
+MACHINE_END
+
static const char *omap3_gp_boards_compat[] __initdata = {
ti,omap3-beagle,
timll,omap3-devkit8000,
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
On 10/08/2013 12:58 PM, Tony Lindgren wrote:
* Nishanth Menon n...@ti.com [131008 05:08]:
On 10/07/2013 07:05 PM, Sebastian Reichel wrote:
On Mon, Oct 07, 2013 at 03:43:49PM -0500, Nishanth Menon wrote:
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..4fe5b9c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -113,6 +113,7 @@ MACHINE_END
#ifdef CONFIG_ARCH_OMAP3
static const char *omap3_boards_compat[] __initdata = {
ti,omap3,
+ ti,omap343x,
You used omap36xx everywhere, so I guess this should be
ti,omap34xx?
3630 has at least two variants:
http://www.ti.com/product/omap3621
http://www.ti.com/product/omap3630
It got further spun off in 37xx family:
http://www.ti.com/product/dm3730 (DM3730 and DM3725)
3430 is no longer in production - but just had a single version (at
least what I can remember).
3530 variant of 3430 on the other hand has a few:
http://processors.wiki.ti.com/index.php/OMAP3_Overview
I am ok to change to ti,omap34xx if folks think that is the right
thing to do. Personally, I might prefer to handle 35xx family slightly
differently considering deltas.
I've dropped that part as that's not needed for the fix AFAIK.
Here's what I've applied and pushed out to omap-for-v3.12/fixes.
Regards,
Tony
From: Nishanth Menon n...@ti.com
Date: Mon, 7 Oct 2013 15:43:49 -0500
Subject: [PATCH] ARM: OMAP3: Fix hardware detection for omap3630 when booted
with device tree
SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.
With clock node dts conversion, we get the following warnings before
system hangs as a result and 3630 based platforms fails to boot
(uart4 clocks are only present in OMAP3630 and not present in
OMAP3430):
...
omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
omap_hwmod: uart4: cannot _init_clocks
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
_init+0x6c/0x80()
omap_hwmod: uart4: couldn't init clocks
...
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from
initialized, idle, or disabled state
...
WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled state
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from
initialized, idle, or disabled state
So, add specific compatiblity for 3630 to allow match for Beagle-XM
platform.
Signed-off-by: Nishanth Menon n...@ti.com
[t...@atomide.com: left out ti,omap343x, updated comments]
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 0c514dc..2816bf6 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -11,7 +11,7 @@
/ {
model = TI OMAP3 BeagleBoard xM;
- compatible = ti,omap3-beagle-xm, ti,omap3-beagle, ti,omap3;
+ compatible = ti,omap3-beagle-xm, ti,omap36xx, ti,omap3;
cpus {
cpu@0 {
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..87162e1 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -129,6 +129,24 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened
Device Tree))
.restart= omap3xxx_restart,
MACHINE_END
+static const char *omap36xx_boards_compat[] __initdata = {
+ ti,omap36xx,
+ NULL,
+};
+
+DT_MACHINE_START(OMAP36XX_DT, Generic OMAP36xx (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3630_init_early,
+ .init_irq = omap_intc_of_init,
+ .handle_irq = omap3_intc_handle_irq,
+ .init_machine = omap_generic_init,
+ .init_late = omap3_init_late,
+ .init_time = omap3_sync32k_timer_init,
+ .dt_compat = omap36xx_boards_compat,
+ .restart= omap3xxx_restart,
+MACHINE_END
+
static const char *omap3_gp_boards_compat[] __initdata = {
ti,omap3-beagle,
timll,omap3-devkit8000,
LGTM. Thanks for doing it.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
On Mon, Oct 07, 2013 at 03:43:49PM -0500, Nishanth Menon wrote:
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c
> index 39c7838..4fe5b9c 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -113,6 +113,7 @@ MACHINE_END
> #ifdef CONFIG_ARCH_OMAP3
> static const char *omap3_boards_compat[] __initdata = {
> "ti,omap3",
> + "ti,omap343x",
You used omap36xx everywhere, so I guess this should be
"ti,omap34xx"?
-- Sebastian
signature.asc
Description: Digital signature
[PATCH V3] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.
With clock node dts conversion, we get the following warnings as a
result and 3630 based platforms fails to boot (uart4 clocks are only
present in OMAP3630 and not present in OMAP3430):
...
omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
omap_hwmod: uart4: cannot _init_clocks
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
_init+0x6c/0x80()
omap_hwmod: uart4: couldn't init clocks
...
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from
initialized, idle, or disabled state
...
WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled state
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from
initialized, idle, or disabled state
So, add specific compatiblity for 3630 to allow match for Beagle-XM
platform.
Signed-off-by: Nishanth Menon
---
Changes in V3 (since v2):
- Fix typo in dts :(
V2: https://patchwork.kernel.org/patch/2999111/
- based on v3.12-rc4 tag
- Update based on Tony's review comments.
V1: http://marc.info/?l=linux-omap=138117342909375=2
RFC: https://patchwork.kernel.org/patch/2919661/
arch/arm/boot/dts/omap3-beagle-xm.dts |2 +-
arch/arm/mach-omap2/board-generic.c | 19 +++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 0c514dc..2816bf6 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -11,7 +11,7 @@
/ {
model = "TI OMAP3 BeagleBoard xM";
- compatible = "ti,omap3-beagle-xm", "ti,omap3-beagle", "ti,omap3";
+ compatible = "ti,omap3-beagle-xm", "ti,omap36xx", "ti,omap3";
cpus {
cpu@0 {
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..4fe5b9c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -113,6 +113,7 @@ MACHINE_END
#ifdef CONFIG_ARCH_OMAP3
static const char *omap3_boards_compat[] __initdata = {
"ti,omap3",
+ "ti,omap343x",
NULL,
};
@@ -129,6 +130,24 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened
Device Tree)")
.restart= omap3xxx_restart,
MACHINE_END
+static const char *omap36xx_boards_compat[] __initdata = {
+ "ti,omap36xx",
+ NULL,
+};
+
+DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP36xx (Flattened Device Tree)")
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3630_init_early,
+ .init_irq = omap_intc_of_init,
+ .handle_irq = omap3_intc_handle_irq,
+ .init_machine = omap_generic_init,
+ .init_late = omap3_init_late,
+ .init_time = omap3_sync32k_timer_init,
+ .dt_compat = omap36xx_boards_compat,
+ .restart= omap3xxx_restart,
+MACHINE_END
+
static const char *omap3_gp_boards_compat[] __initdata = {
"ti,omap3-beagle",
"timll,omap3-devkit8000",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
On 10/07/2013 03:30 PM, Nishanth Menon wrote:
[...]
> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
> b/arch/arm/boot/dts/omap3-beagle-xm.dts
> index 0c514dc..02dd4a9 100644
> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> @@ -11,7 +11,7 @@
>
> / {
> model = "TI OMAP3 BeagleBoard xM";
> - compatible = "ti,omap3-beagle-xm", "ti,omap3-beagle", "ti,omap3";
> + compatible = "ti,omap3-beagle-xm", "ti,omap363x", "ti,omap3";
^^^ yikes - should have been ti,omap36xx -> apologies, my fix was not
committed in local branch :( - will update and resend - grr..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.
With clock node dts conversion, we get the following warnings as a
result and 3630 based platforms fails to boot (uart4 clocks are only
present in OMAP3630 and not present in OMAP3430):
...
omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
omap_hwmod: uart4: cannot _init_clocks
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
_init+0x6c/0x80()
omap_hwmod: uart4: couldn't init clocks
...
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from
initialized, idle, or disabled state
...
WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled state
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from
initialized, idle, or disabled state
So, add specific compatiblity for 3630 to allow match for Beagle-XM
platform.
Signed-off-by: Nishanth Menon
---
Changes in V2 (since v1):
- based on v3.12-rc4 tag
- Update based on Tony's review comments.
V1: http://marc.info/?l=linux-omap=138117342909375=2
RFC: https://patchwork.kernel.org/patch/2919661/
arch/arm/boot/dts/omap3-beagle-xm.dts |2 +-
arch/arm/mach-omap2/board-generic.c | 19 +++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 0c514dc..02dd4a9 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -11,7 +11,7 @@
/ {
model = "TI OMAP3 BeagleBoard xM";
- compatible = "ti,omap3-beagle-xm", "ti,omap3-beagle", "ti,omap3";
+ compatible = "ti,omap3-beagle-xm", "ti,omap363x", "ti,omap3";
cpus {
cpu@0 {
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..4fe5b9c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -113,6 +113,7 @@ MACHINE_END
#ifdef CONFIG_ARCH_OMAP3
static const char *omap3_boards_compat[] __initdata = {
"ti,omap3",
+ "ti,omap343x",
NULL,
};
@@ -129,6 +130,24 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened
Device Tree)")
.restart= omap3xxx_restart,
MACHINE_END
+static const char *omap36xx_boards_compat[] __initdata = {
+ "ti,omap36xx",
+ NULL,
+};
+
+DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP363x (Flattened Device Tree)")
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3630_init_early,
+ .init_irq = omap_intc_of_init,
+ .handle_irq = omap3_intc_handle_irq,
+ .init_machine = omap_generic_init,
+ .init_late = omap3_init_late,
+ .init_time = omap3_sync32k_timer_init,
+ .dt_compat = omap36xx_boards_compat,
+ .restart= omap3xxx_restart,
+MACHINE_END
+
static const char *omap3_gp_boards_compat[] __initdata = {
"ti,omap3-beagle",
"timll,omap3-devkit8000",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.
With clock node dts conversion, we get the following warnings as a
result and 3630 based platforms fails to boot (uart4 clocks are only
present in OMAP3630 and not present in OMAP3430):
...
omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
omap_hwmod: uart4: cannot _init_clocks
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
_init+0x6c/0x80()
omap_hwmod: uart4: couldn't init clocks
...
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from
initialized, idle, or disabled state
...
WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled state
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from
initialized, idle, or disabled state
So, add specific compatiblity for 3630 to allow match for Beagle-XM
platform.
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in V2 (since v1):
- based on v3.12-rc4 tag
- Update based on Tony's review comments.
V1: http://marc.info/?l=linux-omapm=138117342909375w=2
RFC: https://patchwork.kernel.org/patch/2919661/
arch/arm/boot/dts/omap3-beagle-xm.dts |2 +-
arch/arm/mach-omap2/board-generic.c | 19 +++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 0c514dc..02dd4a9 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -11,7 +11,7 @@
/ {
model = TI OMAP3 BeagleBoard xM;
- compatible = ti,omap3-beagle-xm, ti,omap3-beagle, ti,omap3;
+ compatible = ti,omap3-beagle-xm, ti,omap363x, ti,omap3;
cpus {
cpu@0 {
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..4fe5b9c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -113,6 +113,7 @@ MACHINE_END
#ifdef CONFIG_ARCH_OMAP3
static const char *omap3_boards_compat[] __initdata = {
ti,omap3,
+ ti,omap343x,
NULL,
};
@@ -129,6 +130,24 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened
Device Tree))
.restart= omap3xxx_restart,
MACHINE_END
+static const char *omap36xx_boards_compat[] __initdata = {
+ ti,omap36xx,
+ NULL,
+};
+
+DT_MACHINE_START(OMAP36XX_DT, Generic OMAP363x (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3630_init_early,
+ .init_irq = omap_intc_of_init,
+ .handle_irq = omap3_intc_handle_irq,
+ .init_machine = omap_generic_init,
+ .init_late = omap3_init_late,
+ .init_time = omap3_sync32k_timer_init,
+ .dt_compat = omap36xx_boards_compat,
+ .restart= omap3xxx_restart,
+MACHINE_END
+
static const char *omap3_gp_boards_compat[] __initdata = {
ti,omap3-beagle,
timll,omap3-devkit8000,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
On 10/07/2013 03:30 PM, Nishanth Menon wrote:
[...]
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 0c514dc..02dd4a9 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -11,7 +11,7 @@
/ {
model = TI OMAP3 BeagleBoard xM;
- compatible = ti,omap3-beagle-xm, ti,omap3-beagle, ti,omap3;
+ compatible = ti,omap3-beagle-xm, ti,omap363x, ti,omap3;
^^^ yikes - should have been ti,omap36xx - apologies, my fix was not
committed in local branch :( - will update and resend - grr..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.
With clock node dts conversion, we get the following warnings as a
result and 3630 based platforms fails to boot (uart4 clocks are only
present in OMAP3630 and not present in OMAP3430):
...
omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
omap_hwmod: uart4: cannot _init_clocks
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
_init+0x6c/0x80()
omap_hwmod: uart4: couldn't init clocks
...
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from
initialized, idle, or disabled state
...
WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled state
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from
initialized, idle, or disabled state
So, add specific compatiblity for 3630 to allow match for Beagle-XM
platform.
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in V3 (since v2):
- Fix typo in dts :(
V2: https://patchwork.kernel.org/patch/2999111/
- based on v3.12-rc4 tag
- Update based on Tony's review comments.
V1: http://marc.info/?l=linux-omapm=138117342909375w=2
RFC: https://patchwork.kernel.org/patch/2919661/
arch/arm/boot/dts/omap3-beagle-xm.dts |2 +-
arch/arm/mach-omap2/board-generic.c | 19 +++
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 0c514dc..2816bf6 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -11,7 +11,7 @@
/ {
model = TI OMAP3 BeagleBoard xM;
- compatible = ti,omap3-beagle-xm, ti,omap3-beagle, ti,omap3;
+ compatible = ti,omap3-beagle-xm, ti,omap36xx, ti,omap3;
cpus {
cpu@0 {
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..4fe5b9c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -113,6 +113,7 @@ MACHINE_END
#ifdef CONFIG_ARCH_OMAP3
static const char *omap3_boards_compat[] __initdata = {
ti,omap3,
+ ti,omap343x,
NULL,
};
@@ -129,6 +130,24 @@ DT_MACHINE_START(OMAP3_DT, Generic OMAP3 (Flattened
Device Tree))
.restart= omap3xxx_restart,
MACHINE_END
+static const char *omap36xx_boards_compat[] __initdata = {
+ ti,omap36xx,
+ NULL,
+};
+
+DT_MACHINE_START(OMAP36XX_DT, Generic OMAP36xx (Flattened Device Tree))
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3630_init_early,
+ .init_irq = omap_intc_of_init,
+ .handle_irq = omap3_intc_handle_irq,
+ .init_machine = omap_generic_init,
+ .init_late = omap3_init_late,
+ .init_time = omap3_sync32k_timer_init,
+ .dt_compat = omap36xx_boards_compat,
+ .restart= omap3xxx_restart,
+MACHINE_END
+
static const char *omap3_gp_boards_compat[] __initdata = {
ti,omap3-beagle,
timll,omap3-devkit8000,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
On Mon, Oct 07, 2013 at 03:43:49PM -0500, Nishanth Menon wrote:
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..4fe5b9c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -113,6 +113,7 @@ MACHINE_END
#ifdef CONFIG_ARCH_OMAP3
static const char *omap3_boards_compat[] __initdata = {
ti,omap3,
+ ti,omap343x,
You used omap36xx everywhere, so I guess this should be
ti,omap34xx?
-- Sebastian
signature.asc
Description: Digital signature
[PATCH 3/38] KV: Make hardware detection an arch operation
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/kvm/kvm.h
===
--- linux-2.6.orig/drivers/kvm/kvm.h
+++ linux-2.6/drivers/kvm/kvm.h
@@ -236,6 +236,8 @@ struct kvm_stat {
};
struct kvm_arch_ops {
+ int (*cpu_has_kvm_support)(void); /* __init */
+ int (*disabled_by_bios)(void); /* __init */
};
extern struct kvm_stat kvm_stat;
Index: linux-2.6/drivers/kvm/kvm_main.c
===
--- linux-2.6.orig/drivers/kvm/kvm_main.c
+++ linux-2.6/drivers/kvm/kvm_main.c
@@ -527,12 +527,6 @@ static void free_vmcs(struct vmcs *vmcs)
free_pages((unsigned long)vmcs, vmcs_descriptor.order);
}
-static __init int cpu_has_kvm_support(void)
-{
- unsigned long ecx = cpuid_ecx(1);
- return test_bit(5, ); /* CPUID.1:ECX.VMX[bit 5] -> VT */
-}
-
static __exit void free_kvm_area(void)
{
int cpu;
@@ -559,14 +553,6 @@ static __init int alloc_kvm_area(void)
return 0;
}
-static __init int vmx_disabled_by_bios(void)
-{
- u64 msr;
-
- rdmsrl(MSR_IA32_FEATURE_CONTROL, msr);
- return (msr & 5) == 1; /* locked but not enabled */
-}
-
static __init void kvm_enable(void *garbage)
{
int cpu = raw_smp_processor_id();
@@ -3616,6 +3602,16 @@ int kvm_init_arch(struct kvm_arch_ops *o
int r;
kvm_arch_ops = ops;
+
+ if (!kvm_arch_ops->cpu_has_kvm_support()) {
+ printk(KERN_ERR "kvm: no hardware support\n");
+ return -EOPNOTSUPP;
+ }
+ if (kvm_arch_ops->disabled_by_bios()) {
+ printk(KERN_ERR "kvm: disabled by bios\n");
+ return -EOPNOTSUPP;
+ }
+
kvm_chardev_ops.owner = module;
r = misc_register(_dev);
@@ -3638,15 +3634,6 @@ static __init int kvm_init(void)
static struct page *bad_page;
int r = 0;
- if (!cpu_has_kvm_support()) {
- printk(KERN_ERR "kvm: no hardware support\n");
- return -EOPNOTSUPP;
- }
- if (vmx_disabled_by_bios()) {
- printk(KERN_ERR "kvm: disabled by bios\n");
- return -EOPNOTSUPP;
- }
-
kvm_init_debug();
setup_vmcs_descriptor();
Index: linux-2.6/drivers/kvm/vmx.c
===
--- linux-2.6.orig/drivers/kvm/vmx.c
+++ linux-2.6/drivers/kvm/vmx.c
@@ -18,10 +18,28 @@
#include "kvm.h"
#include
+#define MSR_IA32_FEATURE_CONTROL 0x03a
+
MODULE_AUTHOR("Qumranet");
MODULE_LICENSE("GPL");
+static __init int cpu_has_kvm_support(void)
+{
+ unsigned long ecx = cpuid_ecx(1);
+ return test_bit(5, ); /* CPUID.1:ECX.VMX[bit 5] -> VT */
+}
+
+static __init int vmx_disabled_by_bios(void)
+{
+ u64 msr;
+
+ rdmsrl(MSR_IA32_FEATURE_CONTROL, msr);
+ return (msr & 5) == 1; /* locked but not enabled */
+}
+
static struct kvm_arch_ops vmx_arch_ops = {
+ .cpu_has_kvm_support = cpu_has_kvm_support,
+ .disabled_by_bios = vmx_disabled_by_bios,
};
static int __init vmx_init(void)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/38] KV: Make hardware detection an arch operation
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
Index: linux-2.6/drivers/kvm/kvm.h
===
--- linux-2.6.orig/drivers/kvm/kvm.h
+++ linux-2.6/drivers/kvm/kvm.h
@@ -236,6 +236,8 @@ struct kvm_stat {
};
struct kvm_arch_ops {
+ int (*cpu_has_kvm_support)(void); /* __init */
+ int (*disabled_by_bios)(void); /* __init */
};
extern struct kvm_stat kvm_stat;
Index: linux-2.6/drivers/kvm/kvm_main.c
===
--- linux-2.6.orig/drivers/kvm/kvm_main.c
+++ linux-2.6/drivers/kvm/kvm_main.c
@@ -527,12 +527,6 @@ static void free_vmcs(struct vmcs *vmcs)
free_pages((unsigned long)vmcs, vmcs_descriptor.order);
}
-static __init int cpu_has_kvm_support(void)
-{
- unsigned long ecx = cpuid_ecx(1);
- return test_bit(5, ecx); /* CPUID.1:ECX.VMX[bit 5] - VT */
-}
-
static __exit void free_kvm_area(void)
{
int cpu;
@@ -559,14 +553,6 @@ static __init int alloc_kvm_area(void)
return 0;
}
-static __init int vmx_disabled_by_bios(void)
-{
- u64 msr;
-
- rdmsrl(MSR_IA32_FEATURE_CONTROL, msr);
- return (msr 5) == 1; /* locked but not enabled */
-}
-
static __init void kvm_enable(void *garbage)
{
int cpu = raw_smp_processor_id();
@@ -3616,6 +3602,16 @@ int kvm_init_arch(struct kvm_arch_ops *o
int r;
kvm_arch_ops = ops;
+
+ if (!kvm_arch_ops-cpu_has_kvm_support()) {
+ printk(KERN_ERR kvm: no hardware support\n);
+ return -EOPNOTSUPP;
+ }
+ if (kvm_arch_ops-disabled_by_bios()) {
+ printk(KERN_ERR kvm: disabled by bios\n);
+ return -EOPNOTSUPP;
+ }
+
kvm_chardev_ops.owner = module;
r = misc_register(kvm_dev);
@@ -3638,15 +3634,6 @@ static __init int kvm_init(void)
static struct page *bad_page;
int r = 0;
- if (!cpu_has_kvm_support()) {
- printk(KERN_ERR kvm: no hardware support\n);
- return -EOPNOTSUPP;
- }
- if (vmx_disabled_by_bios()) {
- printk(KERN_ERR kvm: disabled by bios\n);
- return -EOPNOTSUPP;
- }
-
kvm_init_debug();
setup_vmcs_descriptor();
Index: linux-2.6/drivers/kvm/vmx.c
===
--- linux-2.6.orig/drivers/kvm/vmx.c
+++ linux-2.6/drivers/kvm/vmx.c
@@ -18,10 +18,28 @@
#include kvm.h
#include linux/module.h
+#define MSR_IA32_FEATURE_CONTROL 0x03a
+
MODULE_AUTHOR(Qumranet);
MODULE_LICENSE(GPL);
+static __init int cpu_has_kvm_support(void)
+{
+ unsigned long ecx = cpuid_ecx(1);
+ return test_bit(5, ecx); /* CPUID.1:ECX.VMX[bit 5] - VT */
+}
+
+static __init int vmx_disabled_by_bios(void)
+{
+ u64 msr;
+
+ rdmsrl(MSR_IA32_FEATURE_CONTROL, msr);
+ return (msr 5) == 1; /* locked but not enabled */
+}
+
static struct kvm_arch_ops vmx_arch_ops = {
+ .cpu_has_kvm_support = cpu_has_kvm_support,
+ .disabled_by_bios = vmx_disabled_by_bios,
};
static int __init vmx_init(void)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Hardware-Detection
Ahmad Reza Cheraghi wrote: Where can i download it? --- Majid Ziaee <[EMAIL PROTECTED]> wrote: I think that utopia is working this way Ahmad Reza Cheraghi wrote: Is there any Hardware-Detection Program, that directly gets its Information from the I/O and not from /proc/ files?? as I know Robert Love was working on this project .. but I don´t know where you can download it maybe googling will help you - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hardware-Detection
I think that utopia is working this way Ahmad Reza Cheraghi wrote: Is there any Hardware-Detection Program, that directly gets its Information from the I/O and not from /proc/ files?? Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hardware-Detection
I think that utopia is working this way Ahmad Reza Cheraghi wrote: Is there any Hardware-Detection Program, that directly gets its Information from the I/O and not from /proc/ files?? Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hardware-Detection
Ahmad Reza Cheraghi wrote: Where can i download it? --- Majid Ziaee [EMAIL PROTECTED] wrote: I think that utopia is working this way Ahmad Reza Cheraghi wrote: Is there any Hardware-Detection Program, that directly gets its Information from the I/O and not from /proc/ files?? as I know Robert Love was working on this project .. but I don´t know where you can download it maybe googling will help you - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hardware-Detection
Is there any Hardware-Detection Program, that directly gets its Information from the I/O and not from /proc/ files?? Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hardware-Detection
Is there any Hardware-Detection Program, that directly gets its Information from the I/O and not from /proc/ files?? Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
