On 02/15/2011 10:22 PM, Hiroshi DOYU wrote:
> From: "ext Blanchard, Hollis"
> Subject: Re: [RFC] Inter-processor Mailboxes Drivers
> Date: Tue, 15 Feb 2011 15:38:25 -0800
>
>> On 02/15/2011 01:58 PM, Meador Inge wrote:
>>> On 02/14/2011 04:01 AM, Jamie Iles w
On 02/15/2011 01:58 PM, Meador Inge wrote:
> On 02/14/2011 04:01 AM, Jamie Iles wrote:
>> On Fri, Feb 11, 2011 at 03:19:51PM -0600, Meador Inge wrote:
>>> 1. Hardware specific bits somewhere under '.../arch/*'. Drivers
>>> for the MPIC message registers on Power and OMAP4 mailboxes,
On 02/13/2011 01:24 PM, Linus Walleij wrote:
>> > 3. Userspace interfaces for accessing the mailboxes. A
>> > '/dev/mailbox1', '/dev/mailbox2', etc... mapping, for example.
> What kind of business does userspace have with directly using
> mailboxes? Enlighten me so I get it... in our
On 01/07/2011 08:44 AM, Grant Likely wrote:
> On Fri, Jan 7, 2011 at 9:00 AM, Blanchard, Hollis
> wrote:
>> On 01/07/2011 07:48 AM, Grant Likely wrote:
>>> Actually, for a while now the kernel has been moving towards userspace
>>> being responsible for device identi
On 01/07/2011 07:48 AM, Grant Likely wrote:
> Actually, for a while now the kernel has been moving towards userspace
> being responsible for device identification. That's what udev is for.
> The kernel udev looks at the available information when a device is
> registered/bound, and it creates us
On 01/05/2011 03:07 PM, Scott Wood wrote:
> On Wed, 5 Jan 2011 14:49:40 -0800
> "Blanchard, Hollis" wrote:
>
>> On 01/05/2011 02:09 PM, Scott Wood wrote:
>>> On Wed, 5 Jan 2011 15:58:55 -0600
>>> Meador Inge wrote:
>>>
>>>> We ne
On 01/03/2011 03:01 PM, Grant Likely wrote:
> Device nodes with the property status="disabled" are not usable and so
> don't register them when parsing the device tree for devices.
>
This is great and all, but a fair amount of driver code explicitly
searches the tree, rather than registering a pro
On 01/05/2011 02:09 PM, Scott Wood wrote:
> On Wed, 5 Jan 2011 15:58:55 -0600
> Meador Inge wrote:
>
>> We need some sort of mapping between a message register and a message
>> register number so that the message registers can be referenced through
>> some sort of API (e.g. 'mpic_msgr_read(0)').
On 12/23/2010 01:49 PM, Meador Inge wrote:
>
> We can't just remove the IRQ of the _other_ OS from the 'interrupts'
> property in the message node because we need to know the IRQ in order
> to talk to the other OS. So, we use protected sources to tell the OS
> that an IRQ is not available for i