Hi,

On Thu, Nov 01, 2012 at 01:26:10PM +0200, Pantelis Antoniou wrote:

Hi 

On Nov 1, 2012, at 1:04 PM, Felipe Balbi wrote:

quoted

Hi,

On Thu, Nov 01, 2012 at 12:39:30PM +0200, Pantelis Antoniou wrote:

quoted

quoted

quoted

quoted

               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.

likewise:

the generic stuff can be handled by FDT easily, the more complex stuff
can be supported by dynamically changing FDT blob, no ?

quoted

quoted

quoted

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

quoted

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.

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.

-- 
balbi