Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757409Ab1F1LhR (ORCPT ); Tue, 28 Jun 2011 07:37:17 -0400 Received: from smtp-out.google.com ([74.125.121.67]:5708 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755651Ab1F1Lgx (ORCPT ); Tue, 28 Jun 2011 07:36:53 -0400 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=NLfXP0ZiU3hJH4gXvNFOVA7gzypVtVqMQLN+OtPWStaN6ADsCxg4zPTEGIsrGgwRL M1bi8mx4JNewB+FJjwRpQ== MIME-Version: 1.0 In-Reply-To: References: <1308640714-17961-1-git-send-email-ohad@wizery.com> <4E04F0B0.4030408@codeaurora.org> Date: Tue, 28 Jun 2011 04:36:46 -0700 Message-ID: Subject: Re: [RFC 0/8] Introducing a generic AMP/IPC framework From: Brian Swetland To: Ohad Ben-Cohen Cc: "Grosen, Mark" , Stephen Boyd , davinci-linux-open-source , Arnd Bergmann , Rusty Russell , "linux-kernel@vger.kernel.org" , Grant Likely , "linux-arm-msm@vger.kernel.org" , "akpm@linux-foundation.org" , "linux-omap@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1553 Lines: 29 On Tue, Jun 28, 2011 at 4:26 AM, Ohad Ben-Cohen wrote: > On Tue, Jun 28, 2011 at 12:22 AM, Grosen, Mark wrote: >> 2. We added a special section (resource table) that is interpreted as part >> of the loading process. The tool that generates our simple format just >> recognizes a named section (".resource_table"), so perhaps that could be >> done with the PIL ELF loader. > > I hope that DT will completely replace that "resource table" section > eventually. We still need to try it out (as soon as DT materializes on > ARM/pandaboard) and see how it all fits together, but in general it > looks like DT could provide all the necessary static resource > configuration, and then we just need to expose it to the remote > processor. I'm not sure I see the benefit to pulling the resource information out of the firmware image. The resource information is a description of what resources the firmware requires to work properly (it needs certain amounts of working memory, timers, peripheral interfaces like i2c to control camera hw, etc), which will be specific to a given firmware build. Pulling that information out into another place adds new ways for things to break as the firmware and its resource requirements are now separate and could get out of sync, etc. Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/