Message-ID: <20121101131609.GC12489@arwen.pp.htv.fi>
Date:	Thu, 1 Nov 2012 15:16:09 +0200
From:	Felipe Balbi <balbi@...com>
To:	Pantelis Antoniou <panto@...oniou-consulting.com>
CC:	<balbi@...com>, "Cousson, Benoit" <b-cousson@...com>,
	Tony Lindgren <tony@...mide.com>,
	<linux-kernel@...r.kernel.org>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Matt Porter <mporter@...com>, Russ Dill <Russ.Dill@...com>,
	<linux-omap@...r.kernel.org>, Kevin Hilman <khilman@...com>,
	Paul Walmsley <paul@...an.com>
Subject: Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2

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

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists