Daisy-chainable communication

Maybe you can use a uC with two SPI-Ports.

The Master-Controller makes a big frame containig Data for all LEDs and 
starts sending the first byte to the first panel. The panel needs a kind 
of configuration (maybe DIP-switch) to know, if the reveiced data is 
addressed to that panel. If yes, it makes a copy of each Byte to it´s 
memory and sends the byte to the next panel via second SPI.

Master starts sending second byte.....

At the end of the cycle all data for all LEDs have been "seen" by every 
panel but because of the configuration each panel has a copy of the data 
slice addressed to it in it´s memory.

Alternatively you can choose a controller with ethernet-port.
Then you connect all panels to a switch and each panel receives a 
MAC-frame, containig all data for one panel.

Thanks for the input.
It could be doable, but I fear that SPI with overhead of receiving AND 
sending (plus crc maybe and addressing bytes) will be too slow. It may 
just work if the number of panels is limited to let's say 10 panels but 
if I later decide I want more it would not work.
For a small amount of panels I am thinking of using an NRF24 wireless 
connection and getting rid of the wiring work. Will do probably just 
that for first trials and software tests but later I want higher data 
rates.

Another approach I was thinking of was using 8 parallel data lines at 
lower speed (8MHz). That also is not feasible on a cortex M0, especially 
on the receiving side...

I think you cannot increase the amount of panels to infinitiy because 
the amount of data which has to be calculated is getting more and more 
an therefore the cycle time increases until you reach a point where the 
transmission time is far less then the time the master needs to update 
the data.

btw.
As I know, NRF is reduced to a datarate around something like 2 Mbit/s

10 panels x 256 Leds x 36 Bit/LED x 60cycles/s = appx. 5-6MBit/s  :-(

I already did some tests with the NRF24 and it is limited to about 
600-700kbps even at 2Mbit transfer rate because of crc and address 
overhead.
I do not want to use Ethernet because of cost and wiring effort (sockets 
are big, cables expensive and so on).
As mentioned in the initial post, a shift register would do the trick 
but cannot hold that amount of data.
I also thougt about using a Propeller uC but for it's 80MHz clock it is 
pretty slow because most instructions take 4 clocks and therefore does 
not support fast communication.
Think about a display input, that can be full HD with 60 updates per 
second no problem by using fast communication ICs.
A DSP with PPI interface would also be an option but that involves a lot 
of work in programming for such a "simple" task.
Is there a possibility to do something like the TLC5942 does for 16 
channels but for even more channels? I know I could just daisy chain all 
of these ICs of each panel but that makes it impossible to have each 
panel as a standalone unit and they all only work from one single input.
comments on that?

Well, it seems, that you exactly know what you are doing.
you want to update every 16ms more than 100kBit via serial connetction.
You like to have a solution with almost no cost (shift registers). But 
unfortunately there is no 100000 Bit ready to go shift register 
available on the market.
You think that a buidling a kind of "shift register" with daisy chained 
SPI-Controllers is too slow because they have overhead and CRC (it´s up 
to you to build a proper protocol for your application.. you can do it 
without a single bit of overhaed)
And you think that 1 Euro for Ethernet Cable and another Euro for the 
jack is too expensive.
But you like to do it via nRF which is way to slow and at the end surely 
more expensive..

If you want to make it with a shif register you can solder several dozen 
shift registers per panel on a pcb and put loads of components around it 
to handle emi and clock skews. Or you can impement your own 1000 bit 
shift register in an FPGA which needs minimum 2 different power supplies 
and at least a 4 layer micro via pcb.
fortunately you get all this for almost no money ;-)

exactly.
I do not want to use LAN cables because I want no star wiring. Imagine a 
wall with 10 panels and each one having a power connection to the next 
one AND a LAN cable to a hub. thats an awful lot of cables on something 
I want to look nice and tidy.
Oh well, maybe I will just go to something more expensive and load each 
panel with a WiFi module and a more powerful ARM. Is a huge overkill but 
at least it looks the way I want it to.

Star wiring with PoE.... only one cable per panel...
But I´m sure that you also don´t like this idea, because you LIKE to 
have it daisy chained ;-)