From: Pantelis Antoniou <panto@antoniou-consulting.com> To: <balbi@ti.com> Cc: "Cousson, Benoit" <b-cousson@ti.com>, Tony Lindgren <tony@atomide.com>, <linux-kernel@vger.kernel.org>, Koen Kooi <koen@dominion.thruhere.net>, Matt Porter <mporter@ti.com>, Russ Dill <Russ.Dill@ti.com>, <linux-omap@vger.kernel.org>, Kevin Hilman <khilman@ti.com>, Paul Walmsley <paul@pwsan.com> Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2 Date: Thu, 1 Nov 2012 13:26:10 +0200 [thread overview] Message-ID: <3AF5A6FC-61D9-40CA-85B3-81C2C788CB76@antoniou-consulting.com> (raw) In-Reply-To: <20121101110418.GF410@arwen.pp.htv.fi> Hi On Nov 1, 2012, at 1:04 PM, Felipe Balbi wrote: > Hi, > > On Thu, Nov 01, 2012 at 12:39:30PM +0200, Pantelis Antoniou wrote: >>>>> lcd@0 { >>>>> compatible = "adafruit,tft-lcd-1.8-red", "sitronix,st7735"; >>>>> spi-max-frequency = <8000000>; >>>>> reg = <0>; >>>>> spi-cpol; >>>>> spi-cpha; >>>>> pinctrl-names = "default"; >>>>> pinctrl-0 = <&lcd_pins>; >>>>> st7735-rst = <&gpio4 19 0>; >>>>> st7735-dc = <&gpio4 21 0>; >>>>> }; >>>>> >>>>> }; >>>>> }; >>>>> >>> >>> I guess there is no easy solution for that, but it looks to me that >>> what you have to do is to make the DT creation dynamic in your case. >>> Assuming you do not want to do that in the bootloader, you must do >>> that pretty early during the boot process to end up with a full >>> description of your DT tree before creating the devices. >>> >> >> Do it pretty early in the boot processes ended up with the am335xevm board file in the PSP tree. >> >> The whole set of possible cape designs cannot be controlled, nor do we want to. >> We want to empower users to come up with their own designs without having to do any kernel/boot loader >> hacking. > > that's impossible since you will have to provide the capebus driver > anyway. > The generic cape bus driver can handle the easy stuff. More complex stuff can be supported with per-cape drivers. >>> Each cape will have their own DTS and based on some board id you >>> will fix the DT dynamically. >>> >>> My point is that the issue you are facing is a real limitation of >>> DT, so you should fix the DT core and not workaround it by creating >>> artificial bindings / drivers. >>> >> >> You still haven't described any mechanism to deal with all the use >> cases I described. >> >> DT can't and will not deal with the complexity that we're facing right >> now. > > and DT-itself shouldn't. I agree with Benoit that this should be built > at bootloader level, perhaps. Whatever you're doing in capebus, you > could do at kernel space, build your DT bindings in runtime, and pass > that DT blob to kernel. We're just passing the buck someplace else. We're not fixing the problem. What makes you think that dealing with this in the bootloader is going to be simpler? > > One question though, what do you mean by "some capes are full blown > devices with their own drivers" ? Do you mean you have capes running > some other (RT)OS and communicating with linux somehow ? How does it > communicate to the bone ? Some have FPGAs. https://specialcomp.com/beaglebone/BeagleBone_FPGA.html Some capes have their own MCUs. A recent one has an 6502 communicating with uio_pruss. https://github.com/ohporter/b6502 What I'm saying is that there are simple capes, that are just DT devices which can be handled via cape-generic. The complex ones need their own drivers which need a place to live. Capebus handles both. > > cheers > > -- > balbi Regards -- Pantelis
WARNING: multiple messages have this Message-ID (diff)
From: Pantelis Antoniou <panto@antoniou-consulting.com> To: balbi@ti.com Cc: "Cousson, Benoit" <b-cousson@ti.com>, Tony Lindgren <tony@atomide.com>, linux-kernel@vger.kernel.org, Koen Kooi <koen@dominion.thruhere.net>, Matt Porter <mporter@ti.com>, Russ Dill <Russ.Dill@ti.com>, linux-omap@vger.kernel.org, Kevin Hilman <khilman@ti.com>, Paul Walmsley <paul@pwsan.com> Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2 Date: Thu, 1 Nov 2012 13:26:10 +0200 [thread overview] Message-ID: <3AF5A6FC-61D9-40CA-85B3-81C2C788CB76@antoniou-consulting.com> (raw) In-Reply-To: <20121101110418.GF410@arwen.pp.htv.fi> Hi On Nov 1, 2012, at 1:04 PM, Felipe Balbi wrote: > Hi, > > On Thu, Nov 01, 2012 at 12:39:30PM +0200, Pantelis Antoniou wrote: >>>>> lcd@0 { >>>>> compatible = "adafruit,tft-lcd-1.8-red", "sitronix,st7735"; >>>>> spi-max-frequency = <8000000>; >>>>> reg = <0>; >>>>> spi-cpol; >>>>> spi-cpha; >>>>> pinctrl-names = "default"; >>>>> pinctrl-0 = <&lcd_pins>; >>>>> st7735-rst = <&gpio4 19 0>; >>>>> st7735-dc = <&gpio4 21 0>; >>>>> }; >>>>> >>>>> }; >>>>> }; >>>>> >>> >>> I guess there is no easy solution for that, but it looks to me that >>> what you have to do is to make the DT creation dynamic in your case. >>> Assuming you do not want to do that in the bootloader, you must do >>> that pretty early during the boot process to end up with a full >>> description of your DT tree before creating the devices. >>> >> >> Do it pretty early in the boot processes ended up with the am335xevm board file in the PSP tree. >> >> The whole set of possible cape designs cannot be controlled, nor do we want to. >> We want to empower users to come up with their own designs without having to do any kernel/boot loader >> hacking. > > that's impossible since you will have to provide the capebus driver > anyway. > The generic cape bus driver can handle the easy stuff. More complex stuff can be supported with per-cape drivers. >>> Each cape will have their own DTS and based on some board id you >>> will fix the DT dynamically. >>> >>> My point is that the issue you are facing is a real limitation of >>> DT, so you should fix the DT core and not workaround it by creating >>> artificial bindings / drivers. >>> >> >> You still haven't described any mechanism to deal with all the use >> cases I described. >> >> DT can't and will not deal with the complexity that we're facing right >> now. > > and DT-itself shouldn't. I agree with Benoit that this should be built > at bootloader level, perhaps. Whatever you're doing in capebus, you > could do at kernel space, build your DT bindings in runtime, and pass > that DT blob to kernel. We're just passing the buck someplace else. We're not fixing the problem. What makes you think that dealing with this in the bootloader is going to be simpler? > > One question though, what do you mean by "some capes are full blown > devices with their own drivers" ? Do you mean you have capes running > some other (RT)OS and communicating with linux somehow ? How does it > communicate to the bone ? Some have FPGAs. https://specialcomp.com/beaglebone/BeagleBone_FPGA.html Some capes have their own MCUs. A recent one has an 6502 communicating with uio_pruss. https://github.com/ohporter/b6502 What I'm saying is that there are simple capes, that are just DT devices which can be handled via cape-generic. The complex ones need their own drivers which need a place to live. Capebus handles both. > > cheers > > -- > balbi Regards -- Pantelis
next prev parent reply other threads:[~2012-11-01 11:26 UTC|newest] Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-11-01 15:17 [PATCH 0/3] capebus moving omap_devices to mach-omap2 Pantelis Antoniou 2012-10-31 17:52 ` Tony Lindgren 2012-10-31 18:04 ` Pantelis Antoniou 2012-10-31 18:09 ` Tony Lindgren 2012-10-31 18:24 ` Pantelis Antoniou 2012-10-31 19:55 ` Benoit Cousson 2012-10-31 19:55 ` Benoit Cousson 2012-10-31 20:12 ` Pantelis Antoniou 2012-10-31 20:12 ` Pantelis Antoniou 2012-10-31 21:26 ` Tony Lindgren 2012-10-31 21:36 ` Pantelis Antoniou 2012-10-31 21:43 ` Tony Lindgren 2012-10-31 22:00 ` Pantelis Antoniou 2012-10-31 22:16 ` Tony Lindgren 2012-10-31 22:14 ` Felipe Balbi 2012-10-31 22:14 ` Felipe Balbi 2012-11-01 7:02 ` Pantelis Antoniou 2012-11-01 7:02 ` Pantelis Antoniou 2012-11-01 10:23 ` Cousson, Benoit 2012-11-01 10:23 ` Cousson, Benoit 2012-11-01 10:39 ` Pantelis Antoniou 2012-11-01 10:39 ` Pantelis Antoniou 2012-11-01 11:04 ` Felipe Balbi 2012-11-01 11:04 ` Felipe Balbi 2012-11-01 11:26 ` Pantelis Antoniou [this message] 2012-11-01 11:26 ` Pantelis Antoniou 2012-11-01 12:40 ` Felipe Balbi 2012-11-01 12:40 ` Felipe Balbi 2012-11-01 12:57 ` Pantelis Antoniou 2012-11-01 12:57 ` Pantelis Antoniou 2012-11-01 13:16 ` Felipe Balbi 2012-11-01 13:16 ` Felipe Balbi 2012-11-01 13:35 ` Pantelis Antoniou 2012-11-01 13:35 ` Pantelis Antoniou 2012-11-01 13:51 ` Alan Cox 2012-11-01 13:51 ` Alan Cox 2012-11-01 13:59 ` Pantelis Antoniou 2012-11-01 13:59 ` Pantelis Antoniou 2012-11-01 22:05 ` Felipe Balbi 2012-11-01 22:05 ` Felipe Balbi 2012-11-01 23:49 ` Russ Dill 2012-11-02 8:57 ` Felipe Balbi 2012-11-02 8:57 ` Felipe Balbi 2012-11-02 9:42 ` Russ Dill 2012-11-02 10:39 ` Koen Kooi 2012-11-02 10:39 ` Koen Kooi 2012-11-02 11:00 ` Felipe Balbi 2012-11-02 11:00 ` Felipe Balbi 2012-11-02 16:44 ` Russ Dill 2012-11-02 11:21 ` Alan Cox 2012-11-02 12:32 ` Pantelis Antoniou 2012-11-05 0:37 ` Grant Likely 2012-11-05 15:37 ` Pantelis Antoniou 2012-11-05 15:37 ` Pantelis Antoniou 2012-11-05 19:10 ` Grant Likely 2012-11-05 19:54 ` Pantelis Antoniou 2012-11-05 19:54 ` Pantelis Antoniou 2012-11-05 20:14 ` Grant Likely 2012-11-05 22:59 ` Joel A Fernandes 2012-11-05 23:58 ` Grant Likely 2012-11-05 23:58 ` Grant Likely 2012-11-06 3:06 ` Joel A Fernandes 2012-11-06 8:14 ` Pantelis Antoniou 2012-11-06 8:14 ` Pantelis Antoniou 2012-11-06 11:16 ` Grant Likely 2012-11-06 13:54 ` Pantelis Antoniou 2012-11-06 13:54 ` Pantelis Antoniou 2012-11-02 16:07 ` Jason Kridner 2012-11-02 16:07 ` Jason Kridner 2012-11-02 16:28 ` Alan Cox 2012-11-05 1:05 ` Grant Likely 2012-11-01 11:26 ` Cousson, Benoit 2012-11-01 11:26 ` Cousson, Benoit 2012-11-01 11:39 ` Pantelis Antoniou 2012-11-01 11:39 ` Pantelis Antoniou 2012-11-01 12:00 ` Koen Kooi 2012-11-01 12:00 ` Koen Kooi 2012-11-01 13:06 ` Felipe Balbi 2012-11-01 13:06 ` Felipe Balbi 2012-11-01 13:33 ` Koen Kooi 2012-11-01 13:33 ` Koen Kooi 2012-11-02 8:15 ` Cousson, Benoit 2012-11-02 8:15 ` Cousson, Benoit 2012-11-02 8:43 ` Pantelis Antoniou 2012-11-03 8:23 ` Kevin Hilman 2012-11-05 0:22 ` Grant Likely 2012-11-05 0:22 ` Grant Likely 2012-11-05 13:25 ` Pantelis Antoniou 2012-11-05 13:25 ` Pantelis Antoniou 2012-11-05 14:34 ` Grant Likely 2012-11-05 15:34 ` Tony Lindgren 2012-11-05 15:34 ` Tony Lindgren 2012-11-05 15:56 ` Rob Herring 2012-11-05 15:56 ` Rob Herring 2012-11-05 19:40 ` Grant Likely 2012-11-01 15:18 ` [PATCH 1/3] omap-device: Remove __init from omap_device_build family functions Pantelis Antoniou 2012-11-01 15:18 ` [PATCH 2/3] da8xx-dt: Create da8xx DT adapter device Pantelis Antoniou 2012-11-01 14:36 ` Tomi Valkeinen 2012-11-01 14:38 ` Pantelis Antoniou 2012-11-01 15:18 ` [PATCH 3/3] ti-tscadc-dt: Create ti-tscadc-dt " Pantelis Antoniou 2012-11-01 18:50 [PATCH 0/3] capebus moving omap_devices to mach-omap2 Jason Kridner 2012-11-01 19:07 ` Tony Lindgren 2012-11-02 9:26 ` Cousson, Benoit 2012-11-02 9:26 ` Cousson, Benoit 2012-11-02 10:19 ` Koen Kooi 2012-11-02 10:19 ` Koen Kooi 2012-11-05 0:32 ` Grant Likely
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=3AF5A6FC-61D9-40CA-85B3-81C2C788CB76@antoniou-consulting.com \ --to=panto@antoniou-consulting.com \ --cc=Russ.Dill@ti.com \ --cc=b-cousson@ti.com \ --cc=balbi@ti.com \ --cc=khilman@ti.com \ --cc=koen@dominion.thruhere.net \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=mporter@ti.com \ --cc=paul@pwsan.com \ --cc=tony@atomide.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.