From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?QW5kcmVhcyBCaWXDn21hbm4=?= Date: Thu, 09 Jun 2011 11:46:08 +0200 Subject: [U-Boot] [PATCH 1/2] at91: move a/a/c/arm926ejs/at91/clock.c -> a/a/lib/at91 In-Reply-To: <4DF0949A.7030503@emk-elektronik.de> References: <1307489278-96804-1-git-send-email-andreas.devel@googlemail.com> <1307489278-96804-2-git-send-email-andreas.devel@googlemail.com> <4DF0949A.7030503@emk-elektronik.de> Message-ID: <4DF09660.2040903@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Reinhard Meyer, Am 09.06.2011 11:38, schrieb Reinhard Meyer: > Dear Andreas Bie?mann, >> The at91/clock.c is copied from linux kernel and has support for both >> arm920t and arm926ejs core devices. Therefore this patch moves this >> generic at91/clock.c to a new place at arch/arm/lib/at91 to be used from >> at91 family devices. >> >> We build a new libat91-common.o to provide the required symbols to both >> cpu types. >> >> Signed-off-by: Andreas Bie?mann >> --- >> Makefile | 3 + >> arch/arm/cpu/arm926ejs/at91/Makefile | 1 - >> arch/arm/cpu/arm926ejs/at91/clock.c | 215 ---------------------------------- >> arch/arm/lib/at91/Makefile | 45 +++++++ >> arch/arm/lib/at91/clock.c | 215 ++++++++++++++++++++++++++++++++++ >> 5 files changed, 263 insertions(+), 216 deletions(-) >> delete mode 100644 arch/arm/cpu/arm926ejs/at91/clock.c >> create mode 100644 arch/arm/lib/at91/Makefile >> create mode 100644 arch/arm/lib/at91/clock.c > > Please use the "git-mv" command to move the file "clock.c". I did it that way ... but I think there was another trick for git-format-patch ... will have a look for that > On any account, we should discuss about opening a subdir lib scheme first. > Currently arch/arm/lib does not have any subdirectories. Well as described in cover letter this was discussed before. See the other discussion on gmane: http://mid.gmane.org/BANLkTimn29vmAYGb5csMdCYS-xx6zD_6Zw at mail.gmail.com I think this solution was preferred by Albert too. But I'm open for another solution, so lets see what possibilities you have. > I _do_ see the problems of the current ARM directory structure which makes > the ARM core a more important criteria than SoC family especially in the > Atmel context where the SoCs have identical peripheral blocks but can have > different ARM cores. correct regards Andreas Bie?mann