On Fri, Feb 7, 2014 at 6:50 PM, Courtney Cavin <courtney.cavin@xxxxxxxxxxxxxx> wrote: > We don't remove the legacy methods here, but we mark them as deprecated > in the hopes that people with the ability to properly test modifications > can adapt its users. The DT for highbank is pretty much fixed at this point. So adopting this will need a way to register without DT. Unfortunately, I don't have access to h/w either ATM. I should note that this driver is very much highbank specific and not really a generic pl320 driver. The pl320 has up to 8 mailboxes and 8 interrupts. How it is used from there is a software decision. I've never seen any other user, but it could be done quite differently from how it is used in highbank. In the case of highbank, we assigned a tx and rx mailbox. While both the management core and linux side have all 8 interrupts wired up, we have assigned an interrupt to each side. I suppose you could have the interrupt tied to each mailbox, but really they are unrelated in the pl320 as each mailbox message could have multiple targets (interrupts). Probably splitting this between a pl320 lib and platform specific drivers would be the right split if there are ever other users. > - ipc_irq = adev->irq[0]; > - ret = request_irq(ipc_irq, ipc_handler, 0, dev_name(&adev->dev), NULL); > + pl->adapter.dev = &adev->dev; > + pl->adapter.ops = &pl320_mbox_ops; > + pl->adapter.nchannels = 1; Shouldn't this be 2? The 2 channels here are not a single bi-directional channel in any way. They are completely independent and have unrelated events. For example we originally defined having 3 mailboxes where we had 2 tx mailboxes for fast and slow messages, but we ultimately decided everything could be a single tx mailbox. Event completion is handled synchronously via the pl320's handshake mechanism. I'd imagine you could have a protocol where you have async completions via an rx mailbox instead. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
