From: Felipe Balbi <balbi@ti.com> To: Pantelis Antoniou <panto@antoniou-consulting.com> Cc: <balbi@ti.com>, "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 15:16:09 +0200 [thread overview] Message-ID: <20121101131609.GC12489@arwen.pp.htv.fi> (raw) In-Reply-To: <A16B0ABF-AB9D-4F48-88BD-96F123FFEF2F@antoniou-consulting.com> [-- Attachment #1: Type: text/plain, Size: 5024 bytes --] Hi, On Thu, Nov 01, 2012 at 02:57:26PM +0200, Pantelis Antoniou wrote: > >>>>> 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? > > > > I never said it was supposed to be simpler, it just doesn't sound like > > something the kernel should care about. Kernel cares about the > > I just disagree here. The kernel should provide services that make the life > of users easier, not the lives of the kernel developers easier. and it's already doing that isn't it ? we have i2c framework for i2c clients. From a userland point of view, you have input layer, iio, hwmon, chardev and a whole bunch of other interfaces which standardize device accesses. Look at your sentence again: "kernel should make life of users easier, not that of kernel developers"; IMHO capebus is just making it easier for the kernel developers who have to maintain a bunch of drivers for different devices on different capes ;-) At the end of the day, capebus will just be creating devices which will be handled by the same I2C framework, iio, input, hwmon, and so on. So what was the great benefit from capebus other than decreasing the amount of changes to .dts files ? > >>> 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 > > > > how does linux communicate with those ? What they are matters very > > little ;-) All we need is an interface to load binaries to the FPGA. > > > > We can not know what people will come up with. It might have a few GPIOs > to load the bitfile to the FPGA, but after that, no-one can tell. > I might not interface to Linux at all; it might interface via I2C, or RS232. which means that whoever writes RTL for the FPGA needs to do so with bone's I/O choices in mind. Let's assume the use UART to send bitfile to FPGA and bitfile is a model of an I2C Sensor, they'll have to use /dev/ttyOn to pass bitfile to FPGA and later an i2c-client driver (possibly using iio, since it's a sensor) will be loaded. Right ? > Chances are, it won't fit in any kind of known drivers of linux. > Some guy is using an FPGA for SDR, another is making a radar cape. awesome. That means we need to take care of those :-) Even with capebus, they will still have to write those drivers won't they ? So instead of writing some capebus driver, why can't the guy write a driver for his radar instead ? That way, if he ever turns that into an ASIC and decides to sell it as a chip, he doesn't have to write another driver just to strip the capebus away. > These guys don't give a damn frankly about Linux. What they do care > about is having a cheap/easy to develop platform for their own little > widget. If you are going to ask from the to hunt down their own dts > and assemble from various dtsi's they'll just move to something else. I never asked that :-) What I'm claiming is that capebus doesn't sound like the best solution for the problem exposed. > Which is a shame, cause we do have a nice platform here. I agree with you, the bone is quite awesome ;-) > >> Some capes have their own MCUs. > >> A recent one has an 6502 communicating with uio_pruss. > >> https://github.com/ohporter/b6502 > > > > that uses remoteproc, so I assume it's using OMAP's mailbox ? > > > > Again I say that this is not a 'capebus', it's just another device > > which we use another interface to talk to. > > > > i2c devices will be children of the omap i2c controller, spi devices > > will be children of the omap mcspi, GPMC devices will need the GPMC > > controller and so on, but none of this looks like argument to introduce > > a fake bus into the kernel. > > > > I'll let the users of said bus to do the talking. You're just flat out > wrong IMO. fair enough, I feel the same way about your capebus ;-) -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@ti.com> To: Pantelis Antoniou <panto@antoniou-consulting.com> Cc: balbi@ti.com, "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 15:16:09 +0200 [thread overview] Message-ID: <20121101131609.GC12489@arwen.pp.htv.fi> (raw) In-Reply-To: <A16B0ABF-AB9D-4F48-88BD-96F123FFEF2F@antoniou-consulting.com> [-- Attachment #1: Type: text/plain, Size: 5024 bytes --] Hi, On Thu, Nov 01, 2012 at 02:57:26PM +0200, Pantelis Antoniou wrote: > >>>>> 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? > > > > I never said it was supposed to be simpler, it just doesn't sound like > > something the kernel should care about. Kernel cares about the > > I just disagree here. The kernel should provide services that make the life > of users easier, not the lives of the kernel developers easier. and it's already doing that isn't it ? we have i2c framework for i2c clients. From a userland point of view, you have input layer, iio, hwmon, chardev and a whole bunch of other interfaces which standardize device accesses. Look at your sentence again: "kernel should make life of users easier, not that of kernel developers"; IMHO capebus is just making it easier for the kernel developers who have to maintain a bunch of drivers for different devices on different capes ;-) At the end of the day, capebus will just be creating devices which will be handled by the same I2C framework, iio, input, hwmon, and so on. So what was the great benefit from capebus other than decreasing the amount of changes to .dts files ? > >>> 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 > > > > how does linux communicate with those ? What they are matters very > > little ;-) All we need is an interface to load binaries to the FPGA. > > > > We can not know what people will come up with. It might have a few GPIOs > to load the bitfile to the FPGA, but after that, no-one can tell. > I might not interface to Linux at all; it might interface via I2C, or RS232. which means that whoever writes RTL for the FPGA needs to do so with bone's I/O choices in mind. Let's assume the use UART to send bitfile to FPGA and bitfile is a model of an I2C Sensor, they'll have to use /dev/ttyOn to pass bitfile to FPGA and later an i2c-client driver (possibly using iio, since it's a sensor) will be loaded. Right ? > Chances are, it won't fit in any kind of known drivers of linux. > Some guy is using an FPGA for SDR, another is making a radar cape. awesome. That means we need to take care of those :-) Even with capebus, they will still have to write those drivers won't they ? So instead of writing some capebus driver, why can't the guy write a driver for his radar instead ? That way, if he ever turns that into an ASIC and decides to sell it as a chip, he doesn't have to write another driver just to strip the capebus away. > These guys don't give a damn frankly about Linux. What they do care > about is having a cheap/easy to develop platform for their own little > widget. If you are going to ask from the to hunt down their own dts > and assemble from various dtsi's they'll just move to something else. I never asked that :-) What I'm claiming is that capebus doesn't sound like the best solution for the problem exposed. > Which is a shame, cause we do have a nice platform here. I agree with you, the bone is quite awesome ;-) > >> Some capes have their own MCUs. > >> A recent one has an 6502 communicating with uio_pruss. > >> https://github.com/ohporter/b6502 > > > > that uses remoteproc, so I assume it's using OMAP's mailbox ? > > > > Again I say that this is not a 'capebus', it's just another device > > which we use another interface to talk to. > > > > i2c devices will be children of the omap i2c controller, spi devices > > will be children of the omap mcspi, GPMC devices will need the GPMC > > controller and so on, but none of this looks like argument to introduce > > a fake bus into the kernel. > > > > I'll let the users of said bus to do the talking. You're just flat out > wrong IMO. fair enough, I feel the same way about your capebus ;-) -- balbi [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-11-01 13:22 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 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 [this message] 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=20121101131609.GC12489@arwen.pp.htv.fi \ --to=balbi@ti.com \ --cc=Russ.Dill@ti.com \ --cc=b-cousson@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=panto@antoniou-consulting.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.