RE: [PATCH v5 0/2] ARM: dts: Add USB host support for Beagle-xm
Thanks Roger, I'll take them for 3.12. I was already late for my 3.11 pull request. Regards, Benoit > Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 12.654.784 -Original Message- >From: Quadros, Roger >Sent: Thursday, June 20, 2013 7:46 AM >To: Cousson, Benoit >Cc: t...@atomide.com; linux-o...@vger.kernel.org; devicetree- >disc...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; linux- >ker...@vger.kernel.org; Quadros, Roger >Subject: [PATCH v5 0/2] ARM: dts: Add USB host support for Beagle-xm > >Hi Benoit, > >Patch 1 adds USB host support for beagle-XM. >Patch 2 cleans up pin comments for USB host pins. > >Changes in v4: >- Rebased to todays for_3.11/dts branch >- added disclaimer about temporary usage of regulator framework for >GPIO RESET lines. > >cheers, >-roger > >Roger Quadros (2): > ARM: dts: omap3-beagle-xm: Add USB Host support > ARM: dts: omap3-beagle: Make USB host pin naming consistent > > arch/arm/boot/dts/omap3-beagle-xm.dts | 81 >+ > arch/arm/boot/dts/omap3-beagle.dts| 29 +++- > 2 files changed, 89 insertions(+), 21 deletions(-) > >-- >1.7.4.1 -- 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 v5 0/2] ARM: dts: Add USB host support for Beagle-xm
Thanks Roger, I'll take them for 3.12. I was already late for my 3.11 pull request. Regards, Benoit Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 12.654.784 -Original Message- From: Quadros, Roger Sent: Thursday, June 20, 2013 7:46 AM To: Cousson, Benoit Cc: t...@atomide.com; linux-o...@vger.kernel.org; devicetree- disc...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org; Quadros, Roger Subject: [PATCH v5 0/2] ARM: dts: Add USB host support for Beagle-xm Hi Benoit, Patch 1 adds USB host support for beagle-XM. Patch 2 cleans up pin comments for USB host pins. Changes in v4: - Rebased to todays for_3.11/dts branch - added disclaimer about temporary usage of regulator framework for GPIO RESET lines. cheers, -roger Roger Quadros (2): ARM: dts: omap3-beagle-xm: Add USB Host support ARM: dts: omap3-beagle: Make USB host pin naming consistent arch/arm/boot/dts/omap3-beagle-xm.dts | 81 + arch/arm/boot/dts/omap3-beagle.dts| 29 +++- 2 files changed, 89 insertions(+), 21 deletions(-) -- 1.7.4.1 -- 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: [PATCHv2 3/3] arm: dts: add bandgap entry for OMAP4460 devices
Hi Eduardo, On 5/29/2013 4:11 PM, Eduardo Valentin wrote: Salut Monsieur Benoit, On 16-05-2013 08:27, Eduardo Valentin wrote: On 16-05-2013 03:20, Benoit Cousson wrote: Hi Eduardo, We need to check. Yeah, I also dont think this will work, because we will reparent the interrupt, setting to a different controller. That will break the TALERT signal already defined at GIC (check original patch). I propose keeping the way I sent. Unless there is a way to set two different controllers to same device. Any idea on this patch? Shall we keep the way it is? Well since we cannot use directly interrupt, I think we need to use at least the proper gpio binding. Thanks, Benoit -- 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 v6] ARM:dts:omap4-panda: Update the LED support for the panda DTS
Hi Dan,
On 5/24/2013 8:56 PM, Dan Murphy wrote:
On 05/17/2013 11:17 AM, Dan Murphy wrote:
On 05/17/2013 11:15 AM, Nishanth Menon wrote:
On 11:02-20130517, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy
---
Changes in this version:
- review comments incorporated.
Previous version of this patch was discussed in:
https://patchwork.kernel.org/patch/2582771/
one minor nit,
$subject could do with space after the ':'
otherwise, it looks fine to me. Will suggest waiting for further
reviewers if they have an opinion prior to a new rev.
Thanks NM I will queue up this change locally and await further review prior to
sending v7.
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 28
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..5fd59b3 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = <0x8000 0x4000>; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ _wkgpio_pins
+ >;
+
heartbeat {
label = "pandaboard::status1";
gpios = < 7 0>;
@@ -137,6 +142,15 @@
};
};
+_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins = <
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+ };
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..c968a3b 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,31 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
>;
};
+
+_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins = <
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ >;
+ };
+};
+
+_wkgpio_pins {
+ pinctrl-single,pins = <
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ >;
+};
+
+ {
+ pinctrl-0 = <
+ _gpio_pins
+ _wkgpio_pins
+ >;
+
+ heartbeat {
+ gpios = < 14 0>;
+ };
+ mmc {
+ gpios = < 8 0>;
+ };
+};
Any additional comments besides the headline?
If not I will post v7
Sorry for the delay.
Go ahead and I'll take it in my dts branch for 3.11.
Thanks,
Benoit
--
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 v6] ARM:dts:omap4-panda: Update the LED support for the panda DTS
Hi Dan,
On 5/24/2013 8:56 PM, Dan Murphy wrote:
On 05/17/2013 11:17 AM, Dan Murphy wrote:
On 05/17/2013 11:15 AM, Nishanth Menon wrote:
On 11:02-20130517, Dan Murphy wrote:
The GPIO for LED D1 on the omap4-panda a1-a3 rev and the omap4-panda-es
are different.
A1-A3 = gpio_wk7
ES = gpio_110
There is no change to LED D2
Abstract away the pinmux and the LED definitions for the two boards into
the respective DTS files.
Signed-off-by: Dan Murphy dmur...@ti.com
---
Changes in this version:
- review comments incorporated.
Previous version of this patch was discussed in:
https://patchwork.kernel.org/patch/2582771/
one minor nit,
$subject could do with space after the ':'
otherwise, it looks fine to me. Will suggest waiting for further
reviewers if they have an opinion prior to a new rev.
Thanks NM I will queue up this change locally and await further review prior to
sending v7.
arch/arm/boot/dts/omap4-panda-common.dtsi | 16 +++-
arch/arm/boot/dts/omap4-panda-es.dts | 28
2 files changed, 43 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 03bd60d..5fd59b3 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -16,8 +16,13 @@
reg = 0x8000 0x4000; /* 1 GB */
};
- leds {
+ leds: leds {
compatible = gpio-leds;
+ pinctrl-names = default;
+ pinctrl-0 =
+ led_wkgpio_pins
+ ;
+
heartbeat {
label = pandaboard::status1;
gpios = gpio1 7 0;
@@ -137,6 +142,15 @@
};
};
+omap4_pmx_wkup {
+ led_wkgpio_pins: pinmux_leds_wkpins {
+ pinctrl-single,pins =
+ 0x1a 0x3/* gpio_wk7 OUTPUT | MODE 3 */
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
i2c1 {
pinctrl-names = default;
pinctrl-0 = i2c1_pins;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
index f1d8c21..c968a3b 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,3 +34,31 @@
0x5e 0x100 /* hdmi_sda.hdmi_sda INPUT | MODE 0 */
;
};
+
+omap4_pmx_core {
+ led_gpio_pins: gpio_led_pmx {
+ pinctrl-single,pins =
+ 0xb6 0x3/* gpio_110 OUTPUT | MODE 3 */
+ ;
+ };
+};
+
+led_wkgpio_pins {
+ pinctrl-single,pins =
+ 0x1c 0x3/* gpio_wk8 OUTPUT | MODE 3 */
+ ;
+};
+
+leds {
+ pinctrl-0 =
+ led_gpio_pins
+ led_wkgpio_pins
+ ;
+
+ heartbeat {
+ gpios = gpio4 14 0;
+ };
+ mmc {
+ gpios = gpio1 8 0;
+ };
+};
Any additional comments besides the headline?
If not I will post v7
Sorry for the delay.
Go ahead and I'll take it in my dts branch for 3.11.
Thanks,
Benoit
--
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: [PATCHv2 3/3] arm: dts: add bandgap entry for OMAP4460 devices
Hi Eduardo, On 5/29/2013 4:11 PM, Eduardo Valentin wrote: Salut Monsieur Benoit, On 16-05-2013 08:27, Eduardo Valentin wrote: On 16-05-2013 03:20, Benoit Cousson wrote: Hi Eduardo, cut We need to check. Yeah, I also dont think this will work, because we will reparent the interrupt, setting to a different controller. That will break the TALERT signal already defined at GIC (check original patch). I propose keeping the way I sent. Unless there is a way to set two different controllers to same device. Any idea on this patch? Shall we keep the way it is? Well since we cannot use directly interrupt, I think we need to use at least the proper gpio binding. Thanks, Benoit -- 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] arm: dts: Add uart1 and uart2 to igep boards.
Hi Matthias,
On 2/15/2013 10:35 AM, Matthias Brugger wrote:
2013/1/26 Javier Martinez Canillas :
On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger
wrote:
Hi Benoit,
2012/12/12 Benoit Cousson :
Hi Matthias,
On 12/12/2012 04:33 PM, Matthias Brugger wrote:
This patch is a follow-up patch for Javier Martinez effort adding
initial
device tree support to IGEP technology devices. [1]
It adds uart1 and uart2 bindings to the generic dtsi for the IGEP
boards.
[1] http://www.spinics.net/lists/linux-omap/msg83409.html
Signed-off-by: Matthias Brugger
---
arch/arm/boot/dts/omap3-igep.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index 125fe00..c02e3c0 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -27,6 +27,20 @@
};
_pmx_core {
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins = <
+ 0x152 0x100 /* uart1_rx.uart1_rx INPUT | MODE0
*/
+ 0x14c 0 /* uart1_tx.uart1_tx OUTPUT |
MODE0 */
+ >;
+ };
+
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins = <
+ 0x14a 0x100 /* uart2_rx.uart2_rx INPUT | MODE0
*/
+ 0x148 0 /* uart2_tx.uart2_tx OUTPUT |
MODE0 */
+ >;
+ };
+
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins = <
0x16e 0x100 /* uart3_rx.uart3_rx INPUT | MODE0
*/
@@ -77,6 +91,16 @@
status = "disabled";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins>;
That looks good to me. I'll apply it on top of javier's series for 3.9.
Can you pin-point me to the repository where this patches are in right
now? I tried to figure it out these days, but didn't found where to
clone the repository from.
Thanks,
Matthias
Hi Matthias,
OMAP DT tree is:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
Hi all,
unfortunately I can't find the patch in this tree.
Sorry about that. I've never pushed the latest branch, and was busy the
past month. I'll refresh the branch with all the pending patches.
Regards,
Benoit
--
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] arm: dts: Add uart1 and uart2 to igep boards.
Hi Matthias,
On 2/15/2013 10:35 AM, Matthias Brugger wrote:
2013/1/26 Javier Martinez Canillas martinez.jav...@gmail.com:
On Sat, Jan 26, 2013 at 4:16 PM, Matthias Brugger matthias@gmail.com
wrote:
Hi Benoit,
2012/12/12 Benoit Cousson b-cous...@ti.com:
Hi Matthias,
On 12/12/2012 04:33 PM, Matthias Brugger wrote:
This patch is a follow-up patch for Javier Martinez effort adding
initial
device tree support to IGEP technology devices. [1]
It adds uart1 and uart2 bindings to the generic dtsi for the IGEP
boards.
[1] http://www.spinics.net/lists/linux-omap/msg83409.html
Signed-off-by: Matthias Brugger matthias@gmail.com
---
arch/arm/boot/dts/omap3-igep.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-igep.dtsi
b/arch/arm/boot/dts/omap3-igep.dtsi
index 125fe00..c02e3c0 100644
--- a/arch/arm/boot/dts/omap3-igep.dtsi
+++ b/arch/arm/boot/dts/omap3-igep.dtsi
@@ -27,6 +27,20 @@
};
omap3_pmx_core {
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins =
+ 0x152 0x100 /* uart1_rx.uart1_rx INPUT | MODE0
*/
+ 0x14c 0 /* uart1_tx.uart1_tx OUTPUT |
MODE0 */
+ ;
+ };
+
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins =
+ 0x14a 0x100 /* uart2_rx.uart2_rx INPUT | MODE0
*/
+ 0x148 0 /* uart2_tx.uart2_tx OUTPUT |
MODE0 */
+ ;
+ };
+
uart3_pins: pinmux_uart3_pins {
pinctrl-single,pins =
0x16e 0x100 /* uart3_rx.uart3_rx INPUT | MODE0
*/
@@ -77,6 +91,16 @@
status = disabled;
};
+uart1 {
+ pinctrl-names = default;
+ pinctrl-0 = uart1_pins;
+};
+
+uart2 {
+ pinctrl-names = default;
+ pinctrl-0 = uart2_pins;
+};
+
uart3 {
pinctrl-names = default;
pinctrl-0 = uart3_pins;
That looks good to me. I'll apply it on top of javier's series for 3.9.
Can you pin-point me to the repository where this patches are in right
now? I tried to figure it out these days, but didn't found where to
clone the repository from.
Thanks,
Matthias
Hi Matthias,
OMAP DT tree is:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
Hi all,
unfortunately I can't find the patch in this tree.
Sorry about that. I've never pushed the latest branch, and was busy the
past month. I'll refresh the branch with all the pending patches.
Regards,
Benoit
--
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: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
+ Peter
Hi Stephen,
On 11/7/2012 6:25 PM, Stephen Warren wrote:
On 11/07/2012 03:19 AM, Benoit Cousson wrote:
Hi Panto,
On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
Hi Grant
On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
wrote:
[ snip ]
g.
Since we've started talking about longer term goals, and the versioning
provision seems to stand, I hope we address how much the fragment versioning
thing is similar to the way board revisions progress.
If a versioning syntax is available then one could create a single DT
file for a bunch of 'almost' similar board and board revisions.
I even think that the version issue is probably much more important for the
short term than the overlay aspect. Well at least as important. We start having
as well a bunch a panda board version with different HW setup.
Having a single board-XXX.dts that will support all these versions is probably
the best approach to avoid choosing that from the bootloader.
We need to figure out a format + mechanism compatible with the current
non-versioned format to allow filtering the nodes at runtime to keep only the
relevant one.
Something that can find the driver that will provide the proper board version
or subsystem version or whatever like that:
compatible-version = "ti,panda-version", "panda";
Then at runtime we should create only the node with the correct match between
the driver version and the string version.
/* regular panda audio routing */
sound: sound {
compatible = "ti,abe-twl6040";
ti,model = "PandaBoard";
compatible-version = "ti,panda-version", "panda";
/* Audio routing */
ti,audio-routing =
"Headset Stereophone", "HSOL",
"Headset Stereophone", "HSOR",
"Ext Spk", "HFL",
"Ext Spk", "HFR",
"Line Out", "AUXL",
"Line Out", "AUXR",
"HSMIC", "Headset Mic",
"Headset Mic", "Headset Mic Bias",
"AFML", "Line In",
"AFMR", "Line In";
};
/* Audio routing is different between PandaBoard4430 and PandaBoardES */
{
ti,model = "PandaBoardES";
compatible-version = "ti,panda-version", "panda-es";
/* Audio routing */
ti,audio-routing =
"Headset Stereophone", "HSOL",
"Headset Stereophone", "HSOR",
"Ext Spk", "HFL",
"Ext Spk", "HFR",
"Line Out", "AUXL",
"Line Out", "AUXR",
"AFML", "Line In",
"AFMR", "Line In";
};
Maybe some extra version match table can just be passed during the board
machine_init
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL,
panda_version_match_table);
Is the only difference here the content of the ti,audio-routing
property? If so, then I don't think there's any need for infra-structure
for this; the driver code already reads that property and adjusts its
behaviour based upon it.
That was just an example, and maybe not the best one. It could be any
kind of HW differences, like a different GPIO line, a different I2C
peripheral, an extra DCDC...
The point was just that you might have several version of the same node
with different attributes depending of the board revision.
Regards,
Benoit
--
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: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
+ Peter
Hi Stephen,
On 11/7/2012 6:25 PM, Stephen Warren wrote:
On 11/07/2012 03:19 AM, Benoit Cousson wrote:
Hi Panto,
On 11/07/2012 09:13 AM, Pantelis Antoniou wrote:
Hi Grant
On Nov 6, 2012, at 9:45 PM, Grant Likely wrote:
On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou
pa...@antoniou-consulting.com wrote:
[ snip ]
g.
Since we've started talking about longer term goals, and the versioning
provision seems to stand, I hope we address how much the fragment versioning
thing is similar to the way board revisions progress.
If a versioning syntax is available then one could create a single DT
file for a bunch of 'almost' similar board and board revisions.
I even think that the version issue is probably much more important for the
short term than the overlay aspect. Well at least as important. We start having
as well a bunch a panda board version with different HW setup.
Having a single board-XXX.dts that will support all these versions is probably
the best approach to avoid choosing that from the bootloader.
We need to figure out a format + mechanism compatible with the current
non-versioned format to allow filtering the nodes at runtime to keep only the
relevant one.
Something that can find the driver that will provide the proper board version
or subsystem version or whatever like that:
compatible-version = ti,panda-version, panda;
Then at runtime we should create only the node with the correct match between
the driver version and the string version.
/* regular panda audio routing */
sound: sound {
compatible = ti,abe-twl6040;
ti,model = PandaBoard;
compatible-version = ti,panda-version, panda;
/* Audio routing */
ti,audio-routing =
Headset Stereophone, HSOL,
Headset Stereophone, HSOR,
Ext Spk, HFL,
Ext Spk, HFR,
Line Out, AUXL,
Line Out, AUXR,
HSMIC, Headset Mic,
Headset Mic, Headset Mic Bias,
AFML, Line In,
AFMR, Line In;
};
/* Audio routing is different between PandaBoard4430 and PandaBoardES */
sound {
ti,model = PandaBoardES;
compatible-version = ti,panda-version, panda-es;
/* Audio routing */
ti,audio-routing =
Headset Stereophone, HSOL,
Headset Stereophone, HSOR,
Ext Spk, HFL,
Ext Spk, HFR,
Line Out, AUXL,
Line Out, AUXR,
AFML, Line In,
AFMR, Line In;
};
Maybe some extra version match table can just be passed during the board
machine_init
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL,
panda_version_match_table);
Is the only difference here the content of the ti,audio-routing
property? If so, then I don't think there's any need for infra-structure
for this; the driver code already reads that property and adjusts its
behaviour based upon it.
That was just an example, and maybe not the best one. It could be any
kind of HW differences, like a different GPIO line, a different I2C
peripheral, an extra DCDC...
The point was just that you might have several version of the same node
with different attributes depending of the board revision.
Regards,
Benoit
--
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 0/3] capebus moving omap_devices to mach-omap2
Hi Jason, On 11/1/2012 7:50 PM, Jason Kridner wrote: My apologies for starting a new thread, but I don't have this thread in my Inbox. http://www.spinics.net/lists/linux-omap/msg81034.html Tony Lindgren wrote: * Pantelis Antoniou [121031 15:02]: So when device's node is 'disabled' of_platform_device_create_pdata() will not create the device. Now, of course it is possible to re-trigger the platform's probe method to be called, and in fact I do so in the capebus patches. You should fix this in generic way then rather than working around it in capebus. The same problem exists changing between different functionality for the shared pins, let's say between USB pins and UART pins if you want a serial debug console on some phone. The current capebus solution goes a long way to fixing a huge issue for BeagleBone users and I don't understand what seems to be a push-back on principle. On BeagleBone capes, these conflicts cannot be resolved early. I don't think there is any push-back on the principle. It is a very valid problem that does not have any solution today. The comments are more on the implementation. Do you have suggestions on some more generic method? It seems to me the proposed capebus approach strikes a good balance. Well, yeah, that's a generic DT issue, not a beagle-cape issue. We should not necessarily handle it by introducing some fake bus and some new binding like spi-dt / i2c-dt that does not mean anything in term of HW. DT is about pure HW representation. Introducing some fake hierarchy to make SW life easier is not necessarily the good approach. Adding the version information in the nodes is potentially a good idea, but should clearly be well thought and part of the DT core. Regards, Benoit -- 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 0/3] capebus moving omap_devices to mach-omap2
On 11/1/2012 1:00 PM, Koen Kooi wrote: tl;dr: please suggest an actual solution that allows plug when plugging in multiple capes and applying power after that. Preferably one that doesn't pass the buck to u-boot. Op 1 nov. 2012, om 12:26 heeft "Cousson, Benoit" het volgende geschreven: Hi Panto, On 11/1/2012 11:39 AM, Pantelis Antoniou wrote: Hi Benoit, On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote: On 11/1/2012 8:02 AM, Pantelis Antoniou wrote: Hi Felibe, On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: Hi, On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: * Pantelis Antoniou [121031 13:14]: On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? The problem is that capes are not external boards in the normal sense as a PCI board is. In the PCI case the hardware that implements the desired functionality is on the PCI board, while in the cape case the hardware module is in the SoC. The cape most of the times is quite simple and contains passive components, leds or some kind of I2C/SPI devices. Ah now I see, you're talking about the beaglebone extension boards :) The way to deal with those properly is to just edit the board .dts entry to include omap-beaglebone-cape-xyz.dtsi whatever. That is what is being done... This is the fallout. You can't instantiate the omap_device early in the boot process like it was done up to now in the board file. You can only do that later in the boot process (for built-in cape drivers), or even after user-space has booted and the matching cape driver module has been loaded. Yes you can, just edit the .dts file for the extension board you have connected. This stuff should be DT only for sure, let's not even start adding platform_data entries for that. The omap_device entries for the omap internal devices will be created automatically during startup based on the .dts. Note that you can set status = "disabled" for the omap internal devices in the .dts file, the devices are there in the hardware. If you are sure the extension boards are safely hot pluggable, then all you need is some interface to enable and disable devices after booting. But that should be done in Linux generic way. So we should not export any omap_hwmod or omap_device things, and want to keep it __init only, and local to arch/arm/mach-omap2. I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. when you have an actual bus, that'd be correct. What do you think capebus is? It is an actual bus that allows you to do so. We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. why this requirement of instantiating them only after reading EEPROMs ? It's unnecessary to add that requirement, just do what Tony said (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices should be created automatically. The thing is that there is no such thing as a cape-device. The cape is just a collection of I2C, 1-wire and SPI devices anyway. What we should instantiate is bmp085, tls2550, sht21, instead of instantiating beagle-bone-weather-cape. What's the problem in just instantiating all of those from bone.dts ? Expose the EEPROMs to userland so whatever SW you guys have running on the bone can figure out what features to expose to the SDK which the user sees, but the kernel doesn't need to know that there is a weather-cape attached to the bone. The I2C/SPI devices are not a problem at all. Let me try to explain what the problem is, and why it all this is needed. First of all, capes may be relatively simple boards, which may function as a generic device - like the generic capes. They might not necessarily be simple. Some capes, for example the geiger cape have a number of components that perform a specific task; in this instance the driving circuit of the geiger tube and the event detector input. Other capes that are being designed now are even more complex, i.e. there's a radar cape, an fpga cape and so on. So for these kind of boards you will need a specific driver. That driver will probably use some generic-cape bits (like gpios,
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On 11/1/2012 1:00 PM, Koen Kooi wrote: tl;dr: please suggest an actual solution that allows plugplay when plugging in multiple capes and applying power after that. Preferably one that doesn't pass the buck to u-boot. Op 1 nov. 2012, om 12:26 heeft Cousson, Benoit b-cous...@ti.com het volgende geschreven: Hi Panto, On 11/1/2012 11:39 AM, Pantelis Antoniou wrote: Hi Benoit, On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote: On 11/1/2012 8:02 AM, Pantelis Antoniou wrote: Hi Felibe, On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: Hi, On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [121031 13:14]: On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? The problem is that capes are not external boards in the normal sense as a PCI board is. In the PCI case the hardware that implements the desired functionality is on the PCI board, while in the cape case the hardware module is in the SoC. The cape most of the times is quite simple and contains passive components, leds or some kind of I2C/SPI devices. Ah now I see, you're talking about the beaglebone extension boards :) The way to deal with those properly is to just edit the board .dts entry to include omap-beaglebone-cape-xyz.dtsi whatever. That is what is being done... This is the fallout. You can't instantiate the omap_device early in the boot process like it was done up to now in the board file. You can only do that later in the boot process (for built-in cape drivers), or even after user-space has booted and the matching cape driver module has been loaded. Yes you can, just edit the .dts file for the extension board you have connected. This stuff should be DT only for sure, let's not even start adding platform_data entries for that. The omap_device entries for the omap internal devices will be created automatically during startup based on the .dts. Note that you can set status = disabled for the omap internal devices in the .dts file, the devices are there in the hardware. If you are sure the extension boards are safely hot pluggable, then all you need is some interface to enable and disable devices after booting. But that should be done in Linux generic way. So we should not export any omap_hwmod or omap_device things, and want to keep it __init only, and local to arch/arm/mach-omap2. I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. when you have an actual bus, that'd be correct. What do you think capebus is? It is an actual bus that allows you to do so. We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. why this requirement of instantiating them only after reading EEPROMs ? It's unnecessary to add that requirement, just do what Tony said (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices should be created automatically. The thing is that there is no such thing as a cape-device. The cape is just a collection of I2C, 1-wire and SPI devices anyway. What we should instantiate is bmp085, tls2550, sht21, instead of instantiating beagle-bone-weather-cape. What's the problem in just instantiating all of those from bone.dts ? Expose the EEPROMs to userland so whatever SW you guys have running on the bone can figure out what features to expose to the SDK which the user sees, but the kernel doesn't need to know that there is a weather-cape attached to the bone. The I2C/SPI devices are not a problem at all. Let me try to explain what the problem is, and why it all this is needed. First of all, capes may be relatively simple boards, which may function as a generic device - like the generic capes. They might not necessarily be simple. Some capes, for example the geiger cape have a number of components that perform a specific task; in this instance the driving circuit of the geiger tube and the event detector input. Other capes that are being designed now are even more complex, i.e. there's a radar cape, an fpga cape and so on. So for these kind of boards you will need a specific driver. That driver will probably use some generic
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi Jason, On 11/1/2012 7:50 PM, Jason Kridner wrote: My apologies for starting a new thread, but I don't have this thread in my Inbox. http://www.spinics.net/lists/linux-omap/msg81034.html Tony Lindgren wrote: * Pantelis Antoniou panto@xxx [121031 15:02]: So when device's node is 'disabled' of_platform_device_create_pdata() will not create the device. Now, of course it is possible to re-trigger the platform's probe method to be called, and in fact I do so in the capebus patches. You should fix this in generic way then rather than working around it in capebus. The same problem exists changing between different functionality for the shared pins, let's say between USB pins and UART pins if you want a serial debug console on some phone. The current capebus solution goes a long way to fixing a huge issue for BeagleBone users and I don't understand what seems to be a push-back on principle. On BeagleBone capes, these conflicts cannot be resolved early. I don't think there is any push-back on the principle. It is a very valid problem that does not have any solution today. The comments are more on the implementation. Do you have suggestions on some more generic method? It seems to me the proposed capebus approach strikes a good balance. Well, yeah, that's a generic DT issue, not a beagle-cape issue. We should not necessarily handle it by introducing some fake bus and some new binding like spi-dt / i2c-dt that does not mean anything in term of HW. DT is about pure HW representation. Introducing some fake hierarchy to make SW life easier is not necessarily the good approach. Adding the version information in the nodes is potentially a good idea, but should clearly be well thought and part of the DT core. Regards, Benoit -- 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 0/3] capebus moving omap_devices to mach-omap2
Hi Panto, On 11/1/2012 11:39 AM, Pantelis Antoniou wrote: Hi Benoit, On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote: On 11/1/2012 8:02 AM, Pantelis Antoniou wrote: Hi Felibe, On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: Hi, On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: * Pantelis Antoniou [121031 13:14]: On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? The problem is that capes are not external boards in the normal sense as a PCI board is. In the PCI case the hardware that implements the desired functionality is on the PCI board, while in the cape case the hardware module is in the SoC. The cape most of the times is quite simple and contains passive components, leds or some kind of I2C/SPI devices. Ah now I see, you're talking about the beaglebone extension boards :) The way to deal with those properly is to just edit the board .dts entry to include omap-beaglebone-cape-xyz.dtsi whatever. That is what is being done... This is the fallout. You can't instantiate the omap_device early in the boot process like it was done up to now in the board file. You can only do that later in the boot process (for built-in cape drivers), or even after user-space has booted and the matching cape driver module has been loaded. Yes you can, just edit the .dts file for the extension board you have connected. This stuff should be DT only for sure, let's not even start adding platform_data entries for that. The omap_device entries for the omap internal devices will be created automatically during startup based on the .dts. Note that you can set status = "disabled" for the omap internal devices in the .dts file, the devices are there in the hardware. If you are sure the extension boards are safely hot pluggable, then all you need is some interface to enable and disable devices after booting. But that should be done in Linux generic way. So we should not export any omap_hwmod or omap_device things, and want to keep it __init only, and local to arch/arm/mach-omap2. I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. when you have an actual bus, that'd be correct. What do you think capebus is? It is an actual bus that allows you to do so. We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. why this requirement of instantiating them only after reading EEPROMs ? It's unnecessary to add that requirement, just do what Tony said (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices should be created automatically. The thing is that there is no such thing as a cape-device. The cape is just a collection of I2C, 1-wire and SPI devices anyway. What we should instantiate is bmp085, tls2550, sht21, instead of instantiating beagle-bone-weather-cape. What's the problem in just instantiating all of those from bone.dts ? Expose the EEPROMs to userland so whatever SW you guys have running on the bone can figure out what features to expose to the SDK which the user sees, but the kernel doesn't need to know that there is a weather-cape attached to the bone. The I2C/SPI devices are not a problem at all. Let me try to explain what the problem is, and why it all this is needed. First of all, capes may be relatively simple boards, which may function as a generic device - like the generic capes. They might not necessarily be simple. Some capes, for example the geiger cape have a number of components that perform a specific task; in this instance the driving circuit of the geiger tube and the event detector input. Other capes that are being designed now are even more complex, i.e. there's a radar cape, an fpga cape and so on. So for these kind of boards you will need a specific driver. That driver will probably use some generic-cape bits (like gpios, pwms, keys what-ever). But it will put them to use in the custom in-kernel driver in it's own way. You can't put that task to user-space, if it's ever slightly complex. So for really simple capes, after considerable pain you might, just might, dump the problem to user-space and try to make it work. People
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On 11/1/2012 8:02 AM, Pantelis Antoniou wrote: Hi Felibe, On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: Hi, On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: * Pantelis Antoniou [121031 13:14]: On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? The problem is that capes are not external boards in the normal sense as a PCI board is. In the PCI case the hardware that implements the desired functionality is on the PCI board, while in the cape case the hardware module is in the SoC. The cape most of the times is quite simple and contains passive components, leds or some kind of I2C/SPI devices. Ah now I see, you're talking about the beaglebone extension boards :) The way to deal with those properly is to just edit the board .dts entry to include omap-beaglebone-cape-xyz.dtsi whatever. That is what is being done... This is the fallout. You can't instantiate the omap_device early in the boot process like it was done up to now in the board file. You can only do that later in the boot process (for built-in cape drivers), or even after user-space has booted and the matching cape driver module has been loaded. Yes you can, just edit the .dts file for the extension board you have connected. This stuff should be DT only for sure, let's not even start adding platform_data entries for that. The omap_device entries for the omap internal devices will be created automatically during startup based on the .dts. Note that you can set status = "disabled" for the omap internal devices in the .dts file, the devices are there in the hardware. If you are sure the extension boards are safely hot pluggable, then all you need is some interface to enable and disable devices after booting. But that should be done in Linux generic way. So we should not export any omap_hwmod or omap_device things, and want to keep it __init only, and local to arch/arm/mach-omap2. I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. when you have an actual bus, that'd be correct. What do you think capebus is? It is an actual bus that allows you to do so. We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. why this requirement of instantiating them only after reading EEPROMs ? It's unnecessary to add that requirement, just do what Tony said (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices should be created automatically. The thing is that there is no such thing as a cape-device. The cape is just a collection of I2C, 1-wire and SPI devices anyway. What we should instantiate is bmp085, tls2550, sht21, instead of instantiating beagle-bone-weather-cape. What's the problem in just instantiating all of those from bone.dts ? Expose the EEPROMs to userland so whatever SW you guys have running on the bone can figure out what features to expose to the SDK which the user sees, but the kernel doesn't need to know that there is a weather-cape attached to the bone. The I2C/SPI devices are not a problem at all. Let me try to explain what the problem is, and why it all this is needed. First of all, capes may be relatively simple boards, which may function as a generic device - like the generic capes. They might not necessarily be simple. Some capes, for example the geiger cape have a number of components that perform a specific task; in this instance the driving circuit of the geiger tube and the event detector input. Other capes that are being designed now are even more complex, i.e. there's a radar cape, an fpga cape and so on. So for these kind of boards you will need a specific driver. That driver will probably use some generic-cape bits (like gpios, pwms, keys what-ever). But it will put them to use in the custom in-kernel driver in it's own way. You can't put that task to user-space, if it's ever slightly complex. So for really simple capes, after considerable pain you might, just might, dump the problem to user-space and try to make it work. People have tried that and it's a total pain. There is no way that this will work with anything more complex than a generic cape. Then there's
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On 11/1/2012 8:02 AM, Pantelis Antoniou wrote: Hi Felibe, On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: Hi, On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [121031 13:14]: On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? The problem is that capes are not external boards in the normal sense as a PCI board is. In the PCI case the hardware that implements the desired functionality is on the PCI board, while in the cape case the hardware module is in the SoC. The cape most of the times is quite simple and contains passive components, leds or some kind of I2C/SPI devices. Ah now I see, you're talking about the beaglebone extension boards :) The way to deal with those properly is to just edit the board .dts entry to include omap-beaglebone-cape-xyz.dtsi whatever. That is what is being done... This is the fallout. You can't instantiate the omap_device early in the boot process like it was done up to now in the board file. You can only do that later in the boot process (for built-in cape drivers), or even after user-space has booted and the matching cape driver module has been loaded. Yes you can, just edit the .dts file for the extension board you have connected. This stuff should be DT only for sure, let's not even start adding platform_data entries for that. The omap_device entries for the omap internal devices will be created automatically during startup based on the .dts. Note that you can set status = disabled for the omap internal devices in the .dts file, the devices are there in the hardware. If you are sure the extension boards are safely hot pluggable, then all you need is some interface to enable and disable devices after booting. But that should be done in Linux generic way. So we should not export any omap_hwmod or omap_device things, and want to keep it __init only, and local to arch/arm/mach-omap2. I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. when you have an actual bus, that'd be correct. What do you think capebus is? It is an actual bus that allows you to do so. We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. why this requirement of instantiating them only after reading EEPROMs ? It's unnecessary to add that requirement, just do what Tony said (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices should be created automatically. The thing is that there is no such thing as a cape-device. The cape is just a collection of I2C, 1-wire and SPI devices anyway. What we should instantiate is bmp085, tls2550, sht21, instead of instantiating beagle-bone-weather-cape. What's the problem in just instantiating all of those from bone.dts ? Expose the EEPROMs to userland so whatever SW you guys have running on the bone can figure out what features to expose to the SDK which the user sees, but the kernel doesn't need to know that there is a weather-cape attached to the bone. The I2C/SPI devices are not a problem at all. Let me try to explain what the problem is, and why it all this is needed. First of all, capes may be relatively simple boards, which may function as a generic device - like the generic capes. They might not necessarily be simple. Some capes, for example the geiger cape have a number of components that perform a specific task; in this instance the driving circuit of the geiger tube and the event detector input. Other capes that are being designed now are even more complex, i.e. there's a radar cape, an fpga cape and so on. So for these kind of boards you will need a specific driver. That driver will probably use some generic-cape bits (like gpios, pwms, keys what-ever). But it will put them to use in the custom in-kernel driver in it's own way. You can't put that task to user-space, if it's ever slightly complex. So for really simple capes, after considerable pain you might, just might, dump the problem to user-space and try to make it work. People have tried that and it's a total pain. There is no way that this will work with anything more complex than a
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi Panto, On 11/1/2012 11:39 AM, Pantelis Antoniou wrote: Hi Benoit, On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote: On 11/1/2012 8:02 AM, Pantelis Antoniou wrote: Hi Felibe, On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: Hi, On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [121031 13:14]: On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? The problem is that capes are not external boards in the normal sense as a PCI board is. In the PCI case the hardware that implements the desired functionality is on the PCI board, while in the cape case the hardware module is in the SoC. The cape most of the times is quite simple and contains passive components, leds or some kind of I2C/SPI devices. Ah now I see, you're talking about the beaglebone extension boards :) The way to deal with those properly is to just edit the board .dts entry to include omap-beaglebone-cape-xyz.dtsi whatever. That is what is being done... This is the fallout. You can't instantiate the omap_device early in the boot process like it was done up to now in the board file. You can only do that later in the boot process (for built-in cape drivers), or even after user-space has booted and the matching cape driver module has been loaded. Yes you can, just edit the .dts file for the extension board you have connected. This stuff should be DT only for sure, let's not even start adding platform_data entries for that. The omap_device entries for the omap internal devices will be created automatically during startup based on the .dts. Note that you can set status = disabled for the omap internal devices in the .dts file, the devices are there in the hardware. If you are sure the extension boards are safely hot pluggable, then all you need is some interface to enable and disable devices after booting. But that should be done in Linux generic way. So we should not export any omap_hwmod or omap_device things, and want to keep it __init only, and local to arch/arm/mach-omap2. I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. when you have an actual bus, that'd be correct. What do you think capebus is? It is an actual bus that allows you to do so. We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. why this requirement of instantiating them only after reading EEPROMs ? It's unnecessary to add that requirement, just do what Tony said (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices should be created automatically. The thing is that there is no such thing as a cape-device. The cape is just a collection of I2C, 1-wire and SPI devices anyway. What we should instantiate is bmp085, tls2550, sht21, instead of instantiating beagle-bone-weather-cape. What's the problem in just instantiating all of those from bone.dts ? Expose the EEPROMs to userland so whatever SW you guys have running on the bone can figure out what features to expose to the SDK which the user sees, but the kernel doesn't need to know that there is a weather-cape attached to the bone. The I2C/SPI devices are not a problem at all. Let me try to explain what the problem is, and why it all this is needed. First of all, capes may be relatively simple boards, which may function as a generic device - like the generic capes. They might not necessarily be simple. Some capes, for example the geiger cape have a number of components that perform a specific task; in this instance the driving circuit of the geiger tube and the event detector input. Other capes that are being designed now are even more complex, i.e. there's a radar cape, an fpga cape and so on. So for these kind of boards you will need a specific driver. That driver will probably use some generic-cape bits (like gpios, pwms, keys what-ever). But it will put them to use in the custom in-kernel driver in it's own way. You can't put that task to user-space, if it's ever slightly complex. So for really simple capes, after considerable pain you might, just might, dump the problem to user-space and try to make
Re: [RESEND/PATCHv3] arm: dts: omap5-evm: Add keypad support
Hi Sourav,
On 10/30/2012 6:26 AM, Sourav wrote:
Hi Benoit,
On Monday 29 October 2012 10:14 PM, Benoit Cousson wrote:
Hi Sourav,
On 10/29/2012 11:40 AM, Sourav Poddar wrote:
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different series.
Tested on omap5430 evm with 3.7-rc1 kernel.
Cc: Felipe Balbi
Cc: Santosh Shilimkar
Tested on omap5430 sdp with 3.7-rc1 kernel.
Signed-off-by: Sourav Poddar
---
arch/arm/boot/dts/omap5-evm.dts | 95
+++
1 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts
b/arch/arm/boot/dts/omap5-evm.dts
index c663eba..b812d6d 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -140,3 +140,98 @@
{
status = "disabled";
};
+
+ {
+clock-frequency = <40>;
+
+smsc@38 {
+compatible = "smscece1099";
+reg = <0x38>;
+clock = <0x13>;
What does that "clock" mean?
This chip supports a clock control register which is used to enable the
interface used by the chip to communicate. Here, the interface which you
can are
SMBUS interface or BC-LINK interface.
OK, so you should use a less generic name than "clock" and potentially
prefix it with "smsc," since it is not a generic attribute at all.
BTW, cannot we use the CCF in order to control that clock? I guess it is
just a clock mux?
Well, anyway we need CCF for OMAP to be merged first :-)
But it might worth highlighting this is a temporary solution.
I cannot find that in the binding documentation. BTW, did you add that
documentation in the driver patch?
Nope, I missed out on the dt binding documentation for the driver. :(
Will send a seperate patch for the bindings.
Thanks,
Benoit
--
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: [RESEND/PATCHv3] arm: dts: omap5-evm: Add keypad support
Hi Sourav,
On 10/30/2012 6:26 AM, Sourav wrote:
Hi Benoit,
On Monday 29 October 2012 10:14 PM, Benoit Cousson wrote:
Hi Sourav,
On 10/29/2012 11:40 AM, Sourav Poddar wrote:
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different series.
Tested on omap5430 evm with 3.7-rc1 kernel.
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Tested on omap5430 sdp with 3.7-rc1 kernel.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 95
+++
1 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts
b/arch/arm/boot/dts/omap5-evm.dts
index c663eba..b812d6d 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -140,3 +140,98 @@
mcbsp3 {
status = disabled;
};
+
+i2c5 {
+clock-frequency = 40;
+
+smsc@38 {
+compatible = smscece1099;
+reg = 0x38;
+clock = 0x13;
What does that clock mean?
This chip supports a clock control register which is used to enable the
interface used by the chip to communicate. Here, the interface which you
can are
SMBUS interface or BC-LINK interface.
OK, so you should use a less generic name than clock and potentially
prefix it with smsc, since it is not a generic attribute at all.
BTW, cannot we use the CCF in order to control that clock? I guess it is
just a clock mux?
Well, anyway we need CCF for OMAP to be merged first :-)
But it might worth highlighting this is a temporary solution.
I cannot find that in the binding documentation. BTW, did you add that
documentation in the driver patch?
Nope, I missed out on the dt binding documentation for the driver. :(
Will send a seperate patch for the bindings.
Thanks,
Benoit
--
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 1/5] drivers: usb: phy: add a new driver for omap usb2 phy
On 9/28/2012 3:07 AM, ABRAHAM, KISHON VIJAY wrote: Hi, On Fri, Sep 28, 2012 at 4:18 AM, Cousson, Benoit wrote: On 9/27/2012 7:24 AM, Rob Herring wrote: On 09/25/2012 05:06 AM, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring wrote: On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote: All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi Signed-off-by: Kishon Vijay Abraham I --- Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++ drivers/usb/phy/Kconfig |9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 271 + include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 6 files changed, 378 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt new file mode 100644 index 000..80d4148 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt This is a very generic name... @@ -0,0 +1,17 @@ +USB PHY + +OMAP USB2 PHY + +Required properties: + - compatible: Should be "ti,omap-usb2" ...for a specific phy. However, I do think a generic binding to describe host ctrlr to phy connections is needed. + - reg : Address and length of the register set for the device. Also +add the address of control module dev conf register until a driver for +control module is added The dts should describe the h/w, not what you need for the current driver. The 2nd reg field does not belong here. Indeed. This was discussed and agreed upon as a interim solution till we have a control module driver in place to write to the control module register. Discussed where and agreed by who? I for one do not agree. Yeah, what was tolerated was the addition of that address inside hwmod data, but I do agree that it should not go into DTS. So how can we handle reg writes to control module until we have a control module driver. usb2 phy does not have a hwmod data for itself. Do you think we should add a new hwmod data for usb2 phy and use this in the usb2phy data node in the dts file? Now, I'm confused... didn't you already do that? What was the hwmod you added? Maybe it is time to write your own control module driver now. Talking with Tony on that, there is no need for a common control driver, it is up to each individual control driver to handle their own register space. It means that you should probably just add a simple driver to access these region. Regards, Benoit -- 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 1/5] drivers: usb: phy: add a new driver for omap usb2 phy
On 9/28/2012 3:07 AM, ABRAHAM, KISHON VIJAY wrote: Hi, On Fri, Sep 28, 2012 at 4:18 AM, Cousson, Benoit b-cous...@ti.com wrote: On 9/27/2012 7:24 AM, Rob Herring wrote: On 09/25/2012 05:06 AM, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring robherri...@gmail.com wrote: On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote: All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++ drivers/usb/phy/Kconfig |9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 271 + include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 6 files changed, 378 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt new file mode 100644 index 000..80d4148 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt This is a very generic name... @@ -0,0 +1,17 @@ +USB PHY + +OMAP USB2 PHY + +Required properties: + - compatible: Should be ti,omap-usb2 ...for a specific phy. However, I do think a generic binding to describe host ctrlr to phy connections is needed. + - reg : Address and length of the register set for the device. Also +add the address of control module dev conf register until a driver for +control module is added The dts should describe the h/w, not what you need for the current driver. The 2nd reg field does not belong here. Indeed. This was discussed and agreed upon as a interim solution till we have a control module driver in place to write to the control module register. Discussed where and agreed by who? I for one do not agree. Yeah, what was tolerated was the addition of that address inside hwmod data, but I do agree that it should not go into DTS. So how can we handle reg writes to control module until we have a control module driver. usb2 phy does not have a hwmod data for itself. Do you think we should add a new hwmod data for usb2 phy and use this in the usb2phy data node in the dts file? Now, I'm confused... didn't you already do that? What was the hwmod you added? Maybe it is time to write your own control module driver now. Talking with Tony on that, there is no need for a common control driver, it is up to each individual control driver to handle their own register space. It means that you should probably just add a simple driver to access these region. Regards, Benoit -- 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 1/5] drivers: usb: phy: add a new driver for omap usb2 phy
On 9/27/2012 7:24 AM, Rob Herring wrote: On 09/25/2012 05:06 AM, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring wrote: On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote: All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi Signed-off-by: Kishon Vijay Abraham I --- Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++ drivers/usb/phy/Kconfig |9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 271 + include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 6 files changed, 378 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt new file mode 100644 index 000..80d4148 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt This is a very generic name... @@ -0,0 +1,17 @@ +USB PHY + +OMAP USB2 PHY + +Required properties: + - compatible: Should be "ti,omap-usb2" ...for a specific phy. However, I do think a generic binding to describe host ctrlr to phy connections is needed. + - reg : Address and length of the register set for the device. Also +add the address of control module dev conf register until a driver for +control module is added The dts should describe the h/w, not what you need for the current driver. The 2nd reg field does not belong here. Indeed. This was discussed and agreed upon as a interim solution till we have a control module driver in place to write to the control module register. Discussed where and agreed by who? I for one do not agree. Yeah, what was tolerated was the addition of that address inside hwmod data, but I do agree that it should not go into DTS. Regards, Benoit -- 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 1/5] drivers: usb: phy: add a new driver for omap usb2 phy
On 9/27/2012 7:24 AM, Rob Herring wrote: On 09/25/2012 05:06 AM, ABRAHAM, KISHON VIJAY wrote: Hi, On Mon, Sep 24, 2012 at 6:45 PM, Rob Herring robherri...@gmail.com wrote: On 09/06/2012 09:57 AM, Kishon Vijay Abraham I wrote: All phy related programming like enabling/disabling the clocks, powering on/off the phy is taken care of by this driver. It is also used for OTG related functionality like srp. This also includes device tree support for usb2 phy driver and the documentation with device tree binding information is updated. Currently writing to control module register is taken care in this driver which will be removed once the control module driver is in place. Cc: Felipe Balbi ba...@ti.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/usb/usb-phy.txt | 17 ++ drivers/usb/phy/Kconfig |9 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/omap-usb2.c | 271 + include/linux/usb/omap_usb.h | 46 include/linux/usb/phy_companion.h | 34 +++ 6 files changed, 378 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/usb-phy.txt create mode 100644 drivers/usb/phy/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt new file mode 100644 index 000..80d4148 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt This is a very generic name... @@ -0,0 +1,17 @@ +USB PHY + +OMAP USB2 PHY + +Required properties: + - compatible: Should be ti,omap-usb2 ...for a specific phy. However, I do think a generic binding to describe host ctrlr to phy connections is needed. + - reg : Address and length of the register set for the device. Also +add the address of control module dev conf register until a driver for +control module is added The dts should describe the h/w, not what you need for the current driver. The 2nd reg field does not belong here. Indeed. This was discussed and agreed upon as a interim solution till we have a control module driver in place to write to the control module register. Discussed where and agreed by who? I for one do not agree. Yeah, what was tolerated was the addition of that address inside hwmod data, but I do agree that it should not go into DTS. Regards, Benoit -- 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 0/2] OMAP: mailbox initial device tree support
Hi Omar, On 9/26/2012 3:21 PM, Omar Ramirez Luna wrote: Hi Benoit, On 12 September 2012 19:08, Omar Ramirez Luna wrote: To allow mailbox driver to function with device tree. Tested in OMAP4 and OMAP3. OMAP2 untested. Patch: arm/dts: OMAP2+: Add mailbox nodes, was Acked by Benoit however it seems it wasn't picked up, so resend. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69121.html Patch: OMAP: mailbox: add device tree support, there wasn't an opposition other than to cleanup the driver too, however I got quite some patches to send before continuing the cleanup. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69338.html Omar Ramirez Luna (2): OMAP: mailbox: add device tree support arm/dts: OMAP2+: Add mailbox nodes .../devicetree/bindings/arm/omap/mailbox.txt |9 + arch/arm/boot/dts/omap2.dtsi |5 + arch/arm/boot/dts/omap3.dtsi |5 + arch/arm/boot/dts/omap4.dtsi |5 + arch/arm/mach-omap2/devices.c |3 +++ arch/arm/mach-omap2/mailbox.c | 12 6 files changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt Ping. I'm in the understanding that these go through your tree, am I right? Since it is too late for 3.7, you should probably do two more things: - move the mailbox driver outside mach-omap2 - move the nr_mbox information in the driver as well instead of the hwmod for the DT boot. Regards, Benoit -- 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 0/2] OMAP: mailbox initial device tree support
Hi Omar, On 9/26/2012 3:21 PM, Omar Ramirez Luna wrote: Hi Benoit, On 12 September 2012 19:08, Omar Ramirez Luna omar.l...@linaro.org wrote: To allow mailbox driver to function with device tree. Tested in OMAP4 and OMAP3. OMAP2 untested. Patch: arm/dts: OMAP2+: Add mailbox nodes, was Acked by Benoit however it seems it wasn't picked up, so resend. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69121.html Patch: OMAP: mailbox: add device tree support, there wasn't an opposition other than to cleanup the driver too, however I got quite some patches to send before continuing the cleanup. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg69338.html Omar Ramirez Luna (2): OMAP: mailbox: add device tree support arm/dts: OMAP2+: Add mailbox nodes .../devicetree/bindings/arm/omap/mailbox.txt |9 + arch/arm/boot/dts/omap2.dtsi |5 + arch/arm/boot/dts/omap3.dtsi |5 + arch/arm/boot/dts/omap4.dtsi |5 + arch/arm/mach-omap2/devices.c |3 +++ arch/arm/mach-omap2/mailbox.c | 12 6 files changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt Ping. I'm in the understanding that these go through your tree, am I right? Since it is too late for 3.7, you should probably do two more things: - move the mailbox driver outside mach-omap2 - move the nr_mbox information in the driver as well instead of the hwmod for the DT boot. Regards, Benoit -- 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 3/9] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
+ Paul
On 9/12/2012 2:45 PM, Omar Ramirez Luna wrote:
Add mmu hwmod data for ipu and dsp.
Cc: Benoit Cousson
Signed-off-by: Omar Ramirez Luna
Acked-by: Benoit Cousson
Thanks Paul for taking care of that patch.
Regards,
Benoit
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 136 +++-
1 file changed, 134 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..c2cf25a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "omap_hwmod_common_data.h"
#include "cm1_44xx.h"
@@ -612,7 +613,6 @@ static struct omap_hwmod_irq_info omap44xx_dsp_irqs[] = {
static struct omap_hwmod_rst_info omap44xx_dsp_resets[] = {
{ .name = "dsp", .rst_shift = 0 },
- { .name = "mmu_cache", .rst_shift = 1 },
};
static struct omap_hwmod omap44xx_dsp_hwmod = {
@@ -1632,7 +1632,6 @@ static struct omap_hwmod_irq_info omap44xx_ipu_irqs[] = {
static struct omap_hwmod_rst_info omap44xx_ipu_resets[] = {
{ .name = "cpu0", .rst_shift = 0 },
{ .name = "cpu1", .rst_shift = 1 },
- { .name = "mmu_cache", .rst_shift = 2 },
};
static struct omap_hwmod omap44xx_ipu_hwmod = {
@@ -2439,6 +2438,137 @@ static struct omap_hwmod omap44xx_mmc5_hwmod = {
};
/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig mmu_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= _hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_mmu_hwmod_class = {
+ .name = "mmu",
+ .sysc = _sysc,
+};
+
+/* mmu ipu */
+
+static struct omap_mmu_dev_attr mmu_ipu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_mmu_ipu_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mmu_ipu_irqs[] = {
+ { .irq = 100 + OMAP44XX_IRQ_GIC_START, },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_mmu_ipu_resets[] = {
+ { .name = "mmu_cache", .rst_shift = 2 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mmu_ipu_addrs[] = {
+ {
+ .pa_start = 0x55082000,
+ .pa_end = 0x550820ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l3_main_2 -> mmu_ipu */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_2__mmu_ipu = {
+ .master = _l3_main_2_hwmod,
+ .slave = _mmu_ipu_hwmod,
+ .clk= "l3_div_ck",
+ .addr = omap44xx_mmu_ipu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap44xx_mmu_ipu_hwmod = {
+ .name = "mmu_ipu",
+ .class = _mmu_hwmod_class,
+ .clkdm_name = "ducati_clkdm",
+ .mpu_irqs = omap44xx_mmu_ipu_irqs,
+ .rst_lines = omap44xx_mmu_ipu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_mmu_ipu_resets),
+ .main_clk = "ducati_clk_mux_ck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .dev_attr = _ipu_dev_attr,
+};
+
+/* mmu dsp */
+
+static struct omap_mmu_dev_attr mmu_dsp_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_mmu_dsp_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mmu_dsp_irqs[] = {
+ { .irq = 28 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_mmu_dsp_resets[] = {
+ { .name = "mmu_cache", .rst_shift = 1 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mmu_dsp_addrs[] = {
+ {
+ .pa_start = 0x4a066000,
+ .pa_end = 0x4a0660ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l4_cfg -> dsp */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__mmu_dsp = {
+ .master = _l4_cfg_hwmod,
+ .slave = _mmu_dsp_hwmod,
+ .clk= "l4_div_ck",
+ .addr = omap44xx_mmu_dsp_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct
Re: [PATCH v2 3/9] ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dsp
+ Paul
On 9/12/2012 2:45 PM, Omar Ramirez Luna wrote:
Add mmu hwmod data for ipu and dsp.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
Acked-by: Benoit Cousson b-cous...@ti.com
Thanks Paul for taking care of that patch.
Regards,
Benoit
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 136 +++-
1 file changed, 134 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 242aee4..c2cf25a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -31,6 +31,7 @@
#include plat/mmc.h
#include plat/dmtimer.h
#include plat/common.h
+#include plat/iommu.h
#include omap_hwmod_common_data.h
#include cm1_44xx.h
@@ -612,7 +613,6 @@ static struct omap_hwmod_irq_info omap44xx_dsp_irqs[] = {
static struct omap_hwmod_rst_info omap44xx_dsp_resets[] = {
{ .name = dsp, .rst_shift = 0 },
- { .name = mmu_cache, .rst_shift = 1 },
};
static struct omap_hwmod omap44xx_dsp_hwmod = {
@@ -1632,7 +1632,6 @@ static struct omap_hwmod_irq_info omap44xx_ipu_irqs[] = {
static struct omap_hwmod_rst_info omap44xx_ipu_resets[] = {
{ .name = cpu0, .rst_shift = 0 },
{ .name = cpu1, .rst_shift = 1 },
- { .name = mmu_cache, .rst_shift = 2 },
};
static struct omap_hwmod omap44xx_ipu_hwmod = {
@@ -2439,6 +2438,137 @@ static struct omap_hwmod omap44xx_mmc5_hwmod = {
};
/*
+ * 'mmu' class
+ * The memory management unit performs virtual to physical address translation
+ * for its requestors.
+ */
+
+static struct omap_hwmod_class_sysconfig mmu_sysc = {
+ .rev_offs = 0x000,
+ .sysc_offs = 0x010,
+ .syss_offs = 0x014,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSC_HAS_AUTOIDLE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap44xx_mmu_hwmod_class = {
+ .name = mmu,
+ .sysc = mmu_sysc,
+};
+
+/* mmu ipu */
+
+static struct omap_mmu_dev_attr mmu_ipu_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_mmu_ipu_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mmu_ipu_irqs[] = {
+ { .irq = 100 + OMAP44XX_IRQ_GIC_START, },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_mmu_ipu_resets[] = {
+ { .name = mmu_cache, .rst_shift = 2 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mmu_ipu_addrs[] = {
+ {
+ .pa_start = 0x55082000,
+ .pa_end = 0x550820ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l3_main_2 - mmu_ipu */
+static struct omap_hwmod_ocp_if omap44xx_l3_main_2__mmu_ipu = {
+ .master = omap44xx_l3_main_2_hwmod,
+ .slave = omap44xx_mmu_ipu_hwmod,
+ .clk= l3_div_ck,
+ .addr = omap44xx_mmu_ipu_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod omap44xx_mmu_ipu_hwmod = {
+ .name = mmu_ipu,
+ .class = omap44xx_mmu_hwmod_class,
+ .clkdm_name = ducati_clkdm,
+ .mpu_irqs = omap44xx_mmu_ipu_irqs,
+ .rst_lines = omap44xx_mmu_ipu_resets,
+ .rst_lines_cnt = ARRAY_SIZE(omap44xx_mmu_ipu_resets),
+ .main_clk = ducati_clk_mux_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_DUCATI_DUCATI_CLKCTRL_OFFSET,
+ .rstctrl_offs = OMAP4_RM_DUCATI_RSTCTRL_OFFSET,
+ .context_offs = OMAP4_RM_DUCATI_DUCATI_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+ .dev_attr = mmu_ipu_dev_attr,
+};
+
+/* mmu dsp */
+
+static struct omap_mmu_dev_attr mmu_dsp_dev_attr = {
+ .da_start = 0x0,
+ .da_end = 0xf000,
+ .nr_tlb_entries = 32,
+};
+
+static struct omap_hwmod omap44xx_mmu_dsp_hwmod;
+static struct omap_hwmod_irq_info omap44xx_mmu_dsp_irqs[] = {
+ { .irq = 28 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_rst_info omap44xx_mmu_dsp_resets[] = {
+ { .name = mmu_cache, .rst_shift = 1 },
+};
+
+static struct omap_hwmod_addr_space omap44xx_mmu_dsp_addrs[] = {
+ {
+ .pa_start = 0x4a066000,
+ .pa_end = 0x4a0660ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ { }
+};
+
+/* l4_cfg - dsp */
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__mmu_dsp = {
+ .master = omap44xx_l4_cfg_hwmod,
+ .slave = omap44xx_mmu_dsp_hwmod,
+ .clk= l4_div_ck,
+ .addr
