| Message ID | 1369845494-30231-1-git-send-email-santosh.shilimkar@ti.com |
|---|---|
| State | New |
| Headers | show |
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130529 09:44]: > Tony, Paul, > > Here is another attempt to send the SOC data files for OMAP5 based devices. > As aligned on list, I have dropped clock data from the series. > That means for the boot, one clock data patch needs to be applied. > It is available on my git tree in 'out_of_tree/omap5_clk_data' branch. > > With OMAP5 and AM33XX support is DT only, respective hwmod files are cleaned > up to remove iospace information and un-used hwmod. For 3.11 since OMAP4 > is also targeted as DT only, its hwmod data files is also cleaned up. > Diffstat looks something like below. > > 27 files changed, 9013 insertions(+), 2764 deletions(-) > > One can easily notice that the OMAP5 SOC data has significantly come down > becasue of iospace and rest of the hwmod clean-up. Yes that's great. I'd like to take the last three patches into my yet to be posted omap-for-v3.11/cleanup branch with the omap4 legacy boot files now that -rc3 is out and the GPIO fix dependency has cleared. Paul, care to ack those three? Then you probably want to review queue the rest I presume. Regards, Tony
* Tony Lindgren <tony@atomide.com> [130529 17:19]: > * Santosh Shilimkar <santosh.shilimkar@ti.com> [130529 09:44]: > > Tony, Paul, > > > > Here is another attempt to send the SOC data files for OMAP5 based devices. > > As aligned on list, I have dropped clock data from the series. > > That means for the boot, one clock data patch needs to be applied. > > It is available on my git tree in 'out_of_tree/omap5_clk_data' branch. > > > > With OMAP5 and AM33XX support is DT only, respective hwmod files are cleaned > > up to remove iospace information and un-used hwmod. For 3.11 since OMAP4 > > is also targeted as DT only, its hwmod data files is also cleaned up. > > Diffstat looks something like below. > > > > 27 files changed, 9013 insertions(+), 2764 deletions(-) > > > > One can easily notice that the OMAP5 SOC data has significantly come down > > becasue of iospace and rest of the hwmod clean-up. > > Yes that's great. I'd like to take the last three patches into my yet to > be posted omap-for-v3.11/cleanup branch with the omap4 legacy boot files > now that -rc3 is out and the GPIO fix dependency has cleared. > > Paul, care to ack those three? Then you probably want to review queue > the rest I presume. Correction: The last two patches I mean. Regards, Tony
On Wed, 29 May 2013, Santosh Shilimkar wrote: > From: Vaibhav Hiremath <hvaibhav@ti.com> > > AM33XX only supports DT boot mode and with addition of > extracting module resources like, irq, dma and address space > from DT block, so now we can remove duplicate information from > hwmod data file. OK, guess I'll take your word for it that it all works. The BeagleBone-white with appended DTB hasn't booted here since v3.7. And the BeagleBone-black with discrete DTB doesn't boot at all with current mainline, only with the TI vendor kernel & DTB... Acked-by: Paul Walmsley <paul@pwsan.com> - Paul
On Wed, 29 May 2013, Santosh Shilimkar wrote: > From: Sricharan R <r.sricharan@ti.com> > > - The IO resource information like dma request lines, irq number and > ocp address space can be populated via dt blob. So such data is stripped > from OMAP4 SOC hwmod data file. > > - The devices which are still missing the device tree bindings, > address space entries are not removed yet. When such devices add > the dt bindings, respective address space data can be deleted. > > - Also other unnessecary hwmods like firewalls are removed as a part of this. > > The above update, results in reduction of about ~1650 lines of code. > > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> > Signed-off-by: Sricharan R <r.sricharan@ti.com> I assume that you're not autogenerating this data any more, based on your change list above. If that's correct, please also remove the paragraph at the top of the file: * This file is automatically generated from the OMAP hardware databases. * We respectfully ask that any modifications to this file be coordinated * with the public linux-omap@vger.kernel.org mailing list and the * authors above to ensure that the autogeneration scripts are kept * up-to-date with the file contents. - Paul
On Thursday 06 June 2013 01:57 PM, Paul Walmsley wrote: > On Wed, 29 May 2013, Santosh Shilimkar wrote: > >> From: Sricharan R <r.sricharan@ti.com> >> >> - The IO resource information like dma request lines, irq number and >> ocp address space can be populated via dt blob. So such data is stripped >> from OMAP4 SOC hwmod data file. >> >> - The devices which are still missing the device tree bindings, >> address space entries are not removed yet. When such devices add >> the dt bindings, respective address space data can be deleted. >> >> - Also other unnessecary hwmods like firewalls are removed as a part of this. >> >> The above update, results in reduction of about ~1650 lines of code. >> >> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> >> Signed-off-by: Sricharan R <r.sricharan@ti.com> > > I assume that you're not autogenerating this data any more, based on > your change list above. If that's correct, please also remove > the paragraph at the top of the file: > The data is auto-generated. I let Sricharan comment if it is otherwise in the final version of the patch. Sricharan ? Regards, Santosh
Paul Walmsley <paul@pwsan.com> writes: > On Wed, 29 May 2013, Santosh Shilimkar wrote: > >> From: Vaibhav Hiremath <hvaibhav@ti.com> >> >> AM33XX only supports DT boot mode and with addition of >> extracting module resources like, irq, dma and address space >> from DT block, so now we can remove duplicate information from >> hwmod data file. > > OK, guess I'll take your word for it that it all works. The > BeagleBone-white with appended DTB hasn't booted here since v3.7. > And the BeagleBone-black with discrete DTB doesn't boot at all with > current mainline, only with the TI vendor kernel & DTB... Anyone care to shed light on what's missing for BeagleBone boot with mainline currently? I've also not been able to boot a mainline kernel on the BeagleBone for some time. Kevin
On Friday 07 June 2013 12:00 AM, Santosh Shilimkar wrote: > On Thursday 06 June 2013 01:57 PM, Paul Walmsley wrote: >> On Wed, 29 May 2013, Santosh Shilimkar wrote: >> >>> From: Sricharan R <r.sricharan@ti.com> >>> >>> - The IO resource information like dma request lines, irq number and >>> ocp address space can be populated via dt blob. So such data is stripped >>> from OMAP4 SOC hwmod data file. >>> >>> - The devices which are still missing the device tree bindings, >>> address space entries are not removed yet. When such devices add >>> the dt bindings, respective address space data can be deleted. >>> >>> - Also other unnessecary hwmods like firewalls are removed as a part of this. >>> >>> The above update, results in reduction of about ~1650 lines of code. >>> >>> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> >>> Signed-off-by: Sricharan R <r.sricharan@ti.com> >> I assume that you're not autogenerating this data any more, based on >> your change list above. If that's correct, please also remove >> the paragraph at the top of the file: >> > The data is auto-generated. I let Sricharan comment if it is otherwise > in the final version of the patch. > > Sricharan ? I used autogen to remove the data, but some of the data were not in sync with the mainline .(like abe, dss, aess, context register offsets etc..). So i have to sync them manually. Regards, Sricharan
cc Benoît On Fri, 7 Jun 2013, Sricharan R wrote: > I used autogen to remove the data, but some of the data were not in sync > with the mainline .(like abe, dss, aess, context register offsets etc..). > So i have to sync them manually. OK. Are you going to fix the differences up soon? - Paul
On Friday 07 June 2013 01:22 PM, Paul Walmsley wrote: > cc Benoît > > On Fri, 7 Jun 2013, Sricharan R wrote: > >> I used autogen to remove the data, but some of the data were not in sync >> with the mainline .(like abe, dss, aess, context register offsets etc..). >> So i have to sync them manually. > OK. Are you going to fix the differences up soon? > > - Paul + Ambresh and Tero for autogen. Regards, Sricharan
On Fri, 2013-06-07 at 14:31 +0530, Sricharan R wrote: > On Friday 07 June 2013 01:22 PM, Paul Walmsley wrote: > > cc Benoît > > > > On Fri, 7 Jun 2013, Sricharan R wrote: > > > >> I used autogen to remove the data, but some of the data were not in sync > >> with the mainline .(like abe, dss, aess, context register offsets etc..). > >> So i have to sync them manually. > > OK. Are you going to fix the differences up soon? > > > > - Paul > + Ambresh and Tero for autogen. This is not going to happen soon, if ever. We might consider doing this if a complete overhaul for the hwmod data is going to be done at some point so that re-generating the new format is easier. -Tero
On Fri, 7 Jun 2013, Tero Kristo wrote: > On Fri, 2013-06-07 at 14:31 +0530, Sricharan R wrote: > > On Friday 07 June 2013 01:22 PM, Paul Walmsley wrote: > > > cc Benoît > > > > > > On Fri, 7 Jun 2013, Sricharan R wrote: > > > > > >> I used autogen to remove the data, but some of the data were not in sync > > >> with the mainline .(like abe, dss, aess, context register offsets etc..). > > >> So i have to sync them manually. > > > OK. Are you going to fix the differences up soon? > > > > > > - Paul > > + Ambresh and Tero for autogen. > > This is not going to happen soon, if ever. We might consider doing this > if a complete overhaul for the hwmod data is going to be done at some > point so that re-generating the new format is easier. OK. Sricharan, how about reposting the OMAP4 hwmod data patch and drop the comment regarding autogeneration? That will be more accurate and will save some more lines. - Paul
On Friday 07 June 2013 03:20 PM, Paul Walmsley wrote: > On Fri, 7 Jun 2013, Tero Kristo wrote: > >> On Fri, 2013-06-07 at 14:31 +0530, Sricharan R wrote: >>> On Friday 07 June 2013 01:22 PM, Paul Walmsley wrote: >>>> cc Benoît >>>> >>>> On Fri, 7 Jun 2013, Sricharan R wrote: >>>> >>>>> I used autogen to remove the data, but some of the data were not in sync >>>>> with the mainline .(like abe, dss, aess, context register offsets etc..). >>>>> So i have to sync them manually. >>>> OK. Are you going to fix the differences up soon? >>>> >>>> - Paul >>> + Ambresh and Tero for autogen. >> This is not going to happen soon, if ever. We might consider doing this >> if a complete overhaul for the hwmod data is going to be done at some >> point so that re-generating the new format is easier. > OK. Sricharan, how about reposting the OMAP4 hwmod data patch and drop > the comment regarding autogeneration? That will be more accurate and will > save some more lines. > > > - Paul ok, sure, i will repost by dropping that comment. Regards, Sricharan
* Paul Walmsley <paul@pwsan.com> [130605 21:06]: > On Wed, 29 May 2013, Santosh Shilimkar wrote: > > > From: Vaibhav Hiremath <hvaibhav@ti.com> > > > > AM33XX only supports DT boot mode and with addition of > > extracting module resources like, irq, dma and address space > > from DT block, so now we can remove duplicate information from > > hwmod data file. > > OK, guess I'll take your word for it that it all works. The > BeagleBone-white with appended DTB hasn't booted here since v3.7. > And the BeagleBone-black with discrete DTB doesn't boot at all with > current mainline, only with the TI vendor kernel & DTB... > > Acked-by: Paul Walmsley <paul@pwsan.com> Thanks applying into omap-for-v3.11/cleanup. Regards, Tony
On Thursday 06 June 2013 06:27 PM, Kevin Hilman wrote: > Paul Walmsley <paul@pwsan.com> writes: > >> On Wed, 29 May 2013, Santosh Shilimkar wrote: >> >>> From: Vaibhav Hiremath <hvaibhav@ti.com> >>> >>> AM33XX only supports DT boot mode and with addition of >>> extracting module resources like, irq, dma and address space >>> from DT block, so now we can remove duplicate information from >>> hwmod data file. >> >> OK, guess I'll take your word for it that it all works. The >> BeagleBone-white with appended DTB hasn't booted here since v3.7. >> And the BeagleBone-black with discrete DTB doesn't boot at all with >> current mainline, only with the TI vendor kernel & DTB... > > Anyone care to shed light on what's missing for BeagleBone boot with > mainline currently? > > I've also not been able to boot a mainline kernel on the BeagleBone for > some time. > Looping Rajendra. Regards, Santosh
On Wed, 29 May 2013, Santosh Shilimkar wrote: > OMAP5 reuses OMAP4 CM IP block which lets us re-use CM1/CM2 functions. > So move the function prototypes from cm1_44xx.h, cm2_44xx.h to > cm_prm44xx_54xx.h header. The suggestion came from Paul Walmsley > as part of the OMAP5 data file review. > > This is preparatory patch to add OMAP5 CM data file. > > Cc: Paul Walmsley <paul@pwsan.com> ... > new file mode 100644 > index 0000000..4154f86 > --- /dev/null > +++ b/arch/arm/mach-omap2/cm_44xx_54xx.h > @@ -0,0 +1,36 @@ > +/* > + * OMAP44xx and OMAP54xx CM1/CM2 function prototypes > + * > + * Copyright (C) 2009-201333 Texas Instruments, Inc. Heh, looks like someone's a vi user ;-) Fixed in the local copy here. - Paul
On Wed, 29 May 2013, Santosh Shilimkar wrote: > From: Benoit Cousson <b-cousson@ti.com> > > Add the new defines for OMAP54XX cm registers. > > Cc: Paul Walmsley <paul@pwsan.com> > > Signed-off-by: Rajendra Nayak <rnayak@ti.com> > Signed-off-by: Benoit Cousson <b-cousson@ti.com> > [santosh.shilimkar@ti.com: Generated es2.0 data] > Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> ... > diff --git a/arch/arm/mach-omap2/cm1_54xx.h b/arch/arm/mach-omap2/cm1_54xx.h > new file mode 100644 > index 0000000..7b1f3b6 > --- /dev/null > +++ b/arch/arm/mach-omap2/cm1_54xx.h ... > + > +/* Function prototypes */ > +extern u32 omap4_cm1_read_inst_reg(s16 inst, u16 idx); > +extern void omap4_cm1_write_inst_reg(u32 val, s16 inst, u16 idx); > +extern u32 omap4_cm1_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); No need for these since they're already prototyped in a common file in your earlier patch set. > diff --git a/arch/arm/mach-omap2/cm2_54xx.h b/arch/arm/mach-omap2/cm2_54xx.h > new file mode 100644 > index 0000000..bab76bd > --- /dev/null > +++ b/arch/arm/mach-omap2/cm2_54xx.h > @@ -0,0 +1,394 @@ ... > +/* Function prototypes */ > +extern u32 omap4_cm2_read_inst_reg(s16 inst, u16 idx); > +extern void omap4_cm2_write_inst_reg(u32 val, s16 inst, u16 idx); > +extern u32 omap4_cm2_rmw_inst_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); No need for these since they're already prototyped in a common file in your earlier patch set. Fixed in the local copy here. - Paul
Hi Kevin, On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote: > Paul Walmsley <paul@pwsan.com> writes: > >> On Wed, 29 May 2013, Santosh Shilimkar wrote: >> >>> From: Vaibhav Hiremath <hvaibhav@ti.com> >>> >>> AM33XX only supports DT boot mode and with addition of >>> extracting module resources like, irq, dma and address space >>> from DT block, so now we can remove duplicate information from >>> hwmod data file. >> >> OK, guess I'll take your word for it that it all works. The >> BeagleBone-white with appended DTB hasn't booted here since v3.7. >> And the BeagleBone-black with discrete DTB doesn't boot at all with >> current mainline, only with the TI vendor kernel & DTB... > > Anyone care to shed light on what's missing for BeagleBone boot with > mainline currently? I have tested BeagleBone boot with today's mainline bootloader and kernel. It boots perfectly fine. Thanks and regards, Lokesh > > I've also not been able to boot a mainline kernel on the BeagleBone for > some time. > > Kevin > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
Hi Paul, On Monday 10 June 2013 02:05 PM, Lokesh Vutla wrote: > Hi Kevin, > > On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote: >> Paul Walmsley <paul@pwsan.com> writes: >> >>> On Wed, 29 May 2013, Santosh Shilimkar wrote: >>> >>>> From: Vaibhav Hiremath <hvaibhav@ti.com> >>>> >>>> AM33XX only supports DT boot mode and with addition of >>>> extracting module resources like, irq, dma and address space >>>> from DT block, so now we can remove duplicate information from >>>> hwmod data file. >>> >>> OK, guess I'll take your word for it that it all works. The >>> BeagleBone-white with appended DTB hasn't booted here since v3.7. >>> And the BeagleBone-black with discrete DTB doesn't boot at all with >>> current mainline, only with the TI vendor kernel & DTB... >> >> Anyone care to shed light on what's missing for BeagleBone boot with >> mainline currently? > I have tested BeagleBone boot with today's mainline bootloader and > kernel. It boots perfectly fine. I have taken the boot log for BeagleBone from the folllowing site: http://www.pwsan.com/omap/testlogs/test_v3.10-rc5/20130609031534/boot/am335xbone/ I have reset to your U-Boot commit id and took latest mainline kernel. It boots fine in my setup. You can find the logs here: http://pastebin.com/ggVYs3RG Thanks and regards, Lokesh > > Thanks and regards, > Lokesh >> >> I've also not been able to boot a mainline kernel on the BeagleBone for >> some time. >> >> Kevin >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-omap" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Lokesh, Lokesh Vutla <lokeshvutla@ti.com> writes: > Hi Kevin, > > On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote: >> Paul Walmsley <paul@pwsan.com> writes: >> >>> On Wed, 29 May 2013, Santosh Shilimkar wrote: >>> >>>> From: Vaibhav Hiremath <hvaibhav@ti.com> >>>> >>>> AM33XX only supports DT boot mode and with addition of >>>> extracting module resources like, irq, dma and address space >>>> from DT block, so now we can remove duplicate information from >>>> hwmod data file. >>> >>> OK, guess I'll take your word for it that it all works. The >>> BeagleBone-white with appended DTB hasn't booted here since v3.7. >>> And the BeagleBone-black with discrete DTB doesn't boot at all with >>> current mainline, only with the TI vendor kernel & DTB... >> >> Anyone care to shed light on what's missing for BeagleBone boot with >> mainline currently? > I have tested BeagleBone boot with today's mainline bootloader and > kernel. It boots perfectly fine. Can you post git trees + branch names (and/or commit IDs) and also kernel config please? Thanks, Kevin
Hi Kevin, On Monday 10 June 2013 10:33 PM, Kevin Hilman wrote: > Hi Lokesh, > > Lokesh Vutla <lokeshvutla@ti.com> writes: > >> Hi Kevin, >> >> On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote: >>> Paul Walmsley <paul@pwsan.com> writes: >>> >>>> On Wed, 29 May 2013, Santosh Shilimkar wrote: >>>> >>>>> From: Vaibhav Hiremath <hvaibhav@ti.com> >>>>> >>>>> AM33XX only supports DT boot mode and with addition of >>>>> extracting module resources like, irq, dma and address space >>>>> from DT block, so now we can remove duplicate information from >>>>> hwmod data file. >>>> >>>> OK, guess I'll take your word for it that it all works. The >>>> BeagleBone-white with appended DTB hasn't booted here since v3.7. >>>> And the BeagleBone-black with discrete DTB doesn't boot at all with >>>> current mainline, only with the TI vendor kernel & DTB... >>> >>> Anyone care to shed light on what's missing for BeagleBone boot with >>> mainline currently? >> I have tested BeagleBone boot with today's mainline bootloader and >> kernel. It boots perfectly fine. > > Can you post git trees + branch names (and/or commit IDs) and also > kernel config please? Following are the details: U-Boot: url: git://git.denx.de/u-boot.git branch : master config: am335x_evm Top commit: "842033e pci: introduce CONFIG_PCI_INDIRECT_BRIDGE option" Kernel: url: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git branch: master config: omap2plus_defocnfig dtb file: am335x-bone.dtb Top commit: "317ddd2 Linux 3.10-rc5" (On top of this I have a local patch for appending dtb) You can find the logs here: http://pastebin.com/vcBr0UhM Thanks and regards, Lokesh > > Thanks, > > Kevin >
> -----Original Message----- > From: Vutla, Lokesh > Sent: Tuesday, June 11, 2013 9:45 AM > To: Kevin Hilman > Cc: Paul Walmsley; Shilimkar, Santosh; tony@atomide.com; linux-arm- > kernel@lists.infradead.org; linux-omap@vger.kernel.org; Hiremath, > Vaibhav; R, Sricharan; Nayak, Rajendra > Subject: Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr > info clean up > > Hi Kevin, > On Monday 10 June 2013 10:33 PM, Kevin Hilman wrote: > > Hi Lokesh, > > > > Lokesh Vutla <lokeshvutla@ti.com> writes: > > > >> Hi Kevin, > >> > >> On Friday 07 June 2013 03:57 AM, Kevin Hilman wrote: > >>> Paul Walmsley <paul@pwsan.com> writes: > >>> > >>>> On Wed, 29 May 2013, Santosh Shilimkar wrote: > >>>> > >>>>> From: Vaibhav Hiremath <hvaibhav@ti.com> > >>>>> > >>>>> AM33XX only supports DT boot mode and with addition of > >>>>> extracting module resources like, irq, dma and address space > >>>>> from DT block, so now we can remove duplicate information from > >>>>> hwmod data file. > >>>> > >>>> OK, guess I'll take your word for it that it all works. The > >>>> BeagleBone-white with appended DTB hasn't booted here since v3.7. > >>>> And the BeagleBone-black with discrete DTB doesn't boot at all > with > >>>> current mainline, only with the TI vendor kernel & DTB... > >>> > >>> Anyone care to shed light on what's missing for BeagleBone boot > with > >>> mainline currently? > >> I have tested BeagleBone boot with today's mainline bootloader and > >> kernel. It boots perfectly fine. > > > > Can you post git trees + branch names (and/or commit IDs) and also > > kernel config please? > Following are the details: > U-Boot: > url: git://git.denx.de/u-boot.git > branch : master > config: am335x_evm > Top commit: "842033e pci: introduce CONFIG_PCI_INDIRECT_BRIDGE > option" > > Kernel: > url: > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux- > 2.6.git > branch: master > config: omap2plus_defocnfig > dtb file: am335x-bone.dtb > Top commit: "317ddd2 Linux 3.10-rc5" (On top of this I have a local > patch for appending dtb) > You can find the logs here: http://pastebin.com/vcBr0UhM > Paul/Kevin/Santosh, AM335x is booting up from Mainline, starting from v3.7, that’s where HWMOD data got merged to Mainline. We have discussed on this in the past as well, let me explain the issue here in detail again for everybody - In case of Am335x we have only two possible options, as AM335x only boots up With DTB (Tested in BBB) - 1. Mainline u-boot + mainline Kernel: ===================================== 1.a. Appended DTB method ------------------------ Here you __must__ enabled below config options in order to get kernel booting, CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y And, I have used below command to append DTB to kernel image # cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > zImage-append && mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d zImage-append uImage-append I have attached complete log here with this mail for reference http://pastebin.com/82duFh78 1.b. Discrete DTB and uImage method: ------------------------------------ Here you don’t need to enable any extra config options. Plain omap2plus_defconfig Should work without any issues. I have attached complete log here with this mail for reference http://pastebin.com/Nqr0PiwW 2. Older U-Boot (without DTB) + Mainline Kernel: ================================================ This is same as #OPTION-1.a above. Thanks, Vaibhav
> -----Original Message----- > From: Kevin Hilman [mailto:khilman@linaro.org] > Sent: Friday, June 07, 2013 3:57 AM > To: Paul Walmsley > Cc: Shilimkar, Santosh; tony@atomide.com; linux-arm- > kernel@lists.infradead.org; linux-omap@vger.kernel.org; Hiremath, > Vaibhav; R, Sricharan > Subject: Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr > info clean up > > Paul Walmsley <paul@pwsan.com> writes: > > > On Wed, 29 May 2013, Santosh Shilimkar wrote: > > > >> From: Vaibhav Hiremath <hvaibhav@ti.com> > >> > >> AM33XX only supports DT boot mode and with addition of > >> extracting module resources like, irq, dma and address space > >> from DT block, so now we can remove duplicate information from > >> hwmod data file. > > > > OK, guess I'll take your word for it that it all works. The > > BeagleBone-white with appended DTB hasn't booted here since v3.7. > > And the BeagleBone-black with discrete DTB doesn't boot at all with > > current mainline, only with the TI vendor kernel & DTB... > > Anyone care to shed light on what's missing for BeagleBone boot with > mainline currently? > > I've also not been able to boot a mainline kernel on the BeagleBone for > some time. > Sorry for delayed response, as I was on vacation for almost for a week. I have just responded to this thread on complete analysis of the issue. http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90309.html Thanks, Vaibhav
> -----Original Message----- > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap- > owner@vger.kernel.org] On Behalf Of Hiremath, Vaibhav > Sent: Wednesday, June 12, 2013 11:34 AM > To: Kevin Hilman; Paul Walmsley > Cc: Shilimkar, Santosh; tony@atomide.com; linux-arm- > kernel@lists.infradead.org; linux-omap@vger.kernel.org; R, Sricharan > Subject: RE: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr > info clean up > > > > -----Original Message----- > > From: Kevin Hilman [mailto:khilman@linaro.org] > > Sent: Friday, June 07, 2013 3:57 AM > > To: Paul Walmsley > > Cc: Shilimkar, Santosh; tony@atomide.com; linux-arm- > > kernel@lists.infradead.org; linux-omap@vger.kernel.org; Hiremath, > > Vaibhav; R, Sricharan > > Subject: Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr > > info clean up > > > > Paul Walmsley <paul@pwsan.com> writes: > > > > > On Wed, 29 May 2013, Santosh Shilimkar wrote: > > > > > >> From: Vaibhav Hiremath <hvaibhav@ti.com> > > >> > > >> AM33XX only supports DT boot mode and with addition of > > >> extracting module resources like, irq, dma and address space > > >> from DT block, so now we can remove duplicate information from > > >> hwmod data file. > > > > > > OK, guess I'll take your word for it that it all works. The > > > BeagleBone-white with appended DTB hasn't booted here since v3.7. > > > And the BeagleBone-black with discrete DTB doesn't boot at all with > > > current mainline, only with the TI vendor kernel & DTB... > > > > Anyone care to shed light on what's missing for BeagleBone boot with > > mainline currently? > > > > I've also not been able to boot a mainline kernel on the BeagleBone > for > > some time. > > > > Sorry for delayed response, as I was on vacation for almost for a week. > > I have just responded to this thread on complete analysis of the issue. > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90309.html > I have also pushed the branch to github, https://github.com/hvaibhav/am335x-linux.git linus-master OR https://github.com/hvaibhav/am335x-linux/tree/linus-master NOTE: Tested on BeagleBone-Black platform. Thanks, Vaibhav
Hi Vaibhav, "Hiremath, Vaibhav" <hvaibhav@ti.com> writes: [...] > Paul/Kevin/Santosh, > > AM335x is booting up from Mainline, starting from v3.7, that’s where HWMOD data got merged to > Mainline. > > We have discussed on this in the past as well, let me explain the issue here in detail > again for everybody - Thanks for the detail. In my case, after more debug, it appears that where I was putting the DTB in memory from u-boot was not working. Using the addresses you used gets things working again. Thanks. u-boot mainline (v2013.04) for BeagleBone has defaults that don't work appear together: U-Boot# printenv loadaddr loadaddr=0x80200000 U-Boot# printenv fdtaddr fdtaddr=0x80F80000 Changing fdtaddr around got things working again. It's probably a good idea to change the u-boot defaults to values that work, since that's a likely starting point for people. I'm now back to mainline booting well on both my original BeagleBone and my BeagleBone black. Thanks, Kevin > In case of Am335x we have only two possible options, as AM335x only boots up > With DTB (Tested in BBB) - > > 1. Mainline u-boot + mainline Kernel: > ===================================== > > 1.a. Appended DTB method > ------------------------ > > Here you __must__ enabled below config options in order to get kernel booting, > > CONFIG_ARM_APPENDED_DTB=y > CONFIG_ARM_ATAG_DTB_COMPAT=y > CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y > > And, I have used below command to append DTB to kernel image > > # cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > > zImage-append && mkimage -A arm -O linux -T kernel -C none -a > 0x80008000 -e 0x80008000 -n "Linux" -d zImage-append uImage-append > > > I have attached complete log here with this mail for reference > http://pastebin.com/82duFh78 > > > 1.b. Discrete DTB and uImage method: > ------------------------------------ > > Here you don’t need to enable any extra config options. Plain omap2plus_defconfig > Should work without any issues. > > I have attached complete log here with this mail for reference > http://pastebin.com/Nqr0PiwW > > > 2. Older U-Boot (without DTB) + Mainline Kernel: > ================================================ > > This is same as #OPTION-1.a above. > > > Thanks, > Vaibhav
> -----Original Message----- > From: Kevin Hilman [mailto:khilman@linaro.org] > Sent: Thursday, June 13, 2013 4:09 AM > To: Hiremath, Vaibhav > Cc: Vutla, Lokesh; Paul Walmsley; Shilimkar, Santosh; tony@atomide.com; > linux-arm-kernel@lists.infradead.org; linux-omap@vger.kernel.org; R, > Sricharan; Nayak, Rajendra > Subject: Re: [PATCH 13/14] ARM: AM33XX: hwmod data: irq, dma and addr > info clean up > > Hi Vaibhav, > > "Hiremath, Vaibhav" <hvaibhav@ti.com> writes: > > [...] > > > Paul/Kevin/Santosh, > > > > AM335x is booting up from Mainline, starting from v3.7, that’s where > HWMOD data got merged to > > Mainline. > > > > We have discussed on this in the past as well, let me explain the > issue here in detail > > again for everybody - > > Thanks for the detail. > > In my case, after more debug, it appears that where I was putting the > DTB in memory from u-boot was not working. Using the addresses you > used gets things working again. Thanks. > > u-boot mainline (v2013.04) for BeagleBone has defaults that don't work > appear together: > > U-Boot# printenv loadaddr > loadaddr=0x80200000 > U-Boot# printenv fdtaddr > fdtaddr=0x80F80000 > I tried above address and it is booting up for me, below is the log for your reference - Boot LOG: ========================================= U-Boot SPL 2013.04-00274-ga71d45d (Jun 12 2013 - 10:54:45) musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2013.04-00274-ga71d45d (Jun 12 2013 - 10:54:45) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: <ethaddr> not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 U-Boot# U-Boot# U-Boot# U-Boot# U-Boot# U-Boot# U-Boot# mmc rescan U-Boot# fatload mmc 0 0x80F80000 am335x-bone.dtb reading am335x-bone.dtb 8865 bytes read in 6 ms (1.4 MiB/s) U-Boot# fatload mmc 0 0x80200000 uImage reading uImage 4044224 bytes read in 464 ms (8.3 MiB/s) U-Boot# fatload mmc 0 82000000 ramdisk-pm.gz reading ramdisk-pm.gz 2022580 bytes read in 235 ms (8.2 MiB/s) U-Boot# setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x82000000,32MB ramdisk_size=65536 earlyprintk=serial omap_wdt.nowayout=60 U-Boot# bootm 0x80200000 - 0x80F80000 ## Booting kernel from Legacy Image at 80200000 ... Image Name: Linux-3.10.0-rc5-00054-g75da4e1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4044160 Bytes = 3.9 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 80f80000 Booting using the fdt blob at 0x80f80000 Loading Kernel Image ... OK OK Using Device Tree in place at 80f80000, end 80f852a0 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 3.10.0-rc5-00054-g75da4e1 (a0393758@psplinux064) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Wed Jun 12 10:51:03 IST 2013 [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [ 0.000000] cma: CMA: reserved 16 MiB at 8e800000 [ 0.000000] Memory policy: ECC disabled, Data cache writeback [ 0.000000] CPU: All CPU(s) started in SVC mode. [ 0.000000] AM335X ES2.0 (neon ) [ 0.000000] PERCPU: Embedded 9 pages/cpu @c0f83000 s13632 r8192 d15040 u36864 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64768 [ 0.000000] Kernel command line: console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x82000000,32MB ramdisk_size=65536 earlyprintk=serial omap_wdt.nowayout=60 [ 0.000000] Booting kernel: `60' invalid for parameter `omap_wdt.nowayout' [ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes) [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Memory: 255MB = 255MB total [ 0.000000] Memory: 195812k/195812k available, 66332k reserved, 0K highmem [ 0.000000] Virtual kernel memory layout: [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB) [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) [ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB) [ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB) [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB) [ 0.000000] .text : 0xc0008000 - 0xc0717e40 (7232 kB) [ 0.000000] .init : 0xc0718000 - 0xc077a540 ( 394 kB) [ 0.000000] .data : 0xc077c000 - 0xc0812748 ( 602 kB) [ 0.000000] .bss : 0xc0812748 - 0xc0d76b98 (5522 kB) [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [ 0.000000] NR_IRQS:16 nr_irqs:16 16 [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts [ 0.000000] Total of 128 interrupts on 1 active controller [ 0.000000] OMAP clockevent source: timer2 at 24000000 Hz [ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms [ 0.000000] OMAP clocksource: timer1 at 24000000 Hz [ 0.000000] Console: colour dummy device 80x30 [ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8 [ 0.000000] ... MAX_LOCK_DEPTH: 48 [ 0.000000] ... MAX_LOCKDEP_KEYS: 8191 [ 0.000000] ... CLASSHASH_SIZE: 4096 [ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384 [ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768 [ 0.000000] ... CHAINHASH_SIZE: 16384 [ 0.000000] memory used by lock dependency info: 3695 kB [ 0.000000] per task-struct memory footprint: 1152 bytes [ 0.001358] Calibrating delay loop... 363.72 BogoMIPS (lpj=1818624) [ 0.119593] pid_max: default: 32768 minimum: 301 [ 0.120264] Security Framework initialized [ 0.120460] Mount-cache hash table entries: 512 [ 0.134531] CPU: Testing write buffer coherency: ok [ 0.136519] CPU0: thread -1, cpu 0, socket -1, mpidr 0 [ 0.136607] Setting up static identity map for 0xc0504ff8 - 0xc0505068 [ 0.140793] Brought up 1 CPUs [ 0.140823] SMP: Total of 1 processors activated (363.72 BogoMIPS). [ 0.140838] CPU: All CPU(s) started in SVC mode. [ 0.145003] devtmpfs: initialized [ 0.166693] omap_hwmod: debugss: _wait_target_disable failed [ 0.230142] pinctrl core: initialized pinctrl subsystem [ 0.236351] regulator-dummy: no parameters [ 0.241091] NET: Registered protocol family 16 [ 0.251936] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.282410] OMAP GPIO hardware version 0.1 [ 0.312014] No ATAGs? [ 0.312046] hw-breakpoint: debug architecture 0x4 unsupported. [ 0.398189] bio: create slab <bio-0> at 0 [ 0.412467] SCSI subsystem initialized [ 0.415411] usbcore: registered new interface driver usbfs [ 0.416049] usbcore: registered new interface driver hub [ 0.417035] usbcore: registered new device driver usb [ 0.419839] omap_i2c 44e0b000.i2c: could not find pctldev for node /pinmux@44e10800/pinmux_i2c0_pins, deferring probe [ 0.419903] platform 44e0b000.i2c: Driver omap_i2c requests probe deferral [ 0.430813] Switching to clocksource timer1 [ 0.619592] NET: Registered protocol family 2 [ 0.622548] TCP established hash table entries: 2048 (order: 2, 16384 bytes) [ 0.622830] TCP bind hash table entries: 2048 (order: 4, 73728 bytes) [ 0.624078] TCP: Hash tables configured (established 2048 bind 2048) [ 0.624356] TCP: reno registered [ 0.624402] UDP hash table entries: 256 (order: 2, 20480 bytes) [ 0.624748] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes) [ 0.626623] NET: Registered protocol family 1 [ 0.629144] RPC: Registered named UNIX socket transport module. [ 0.629176] RPC: Registered udp transport module. [ 0.629192] RPC: Registered tcp transport module. [ 0.629209] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.630501] Trying to unpack rootfs image as initramfs... [ 0.633407] rootfs image is not initramfs (no cpio magic); looks like an initrd [ 0.929698] Freeing initrd memory: 32768K (c2000000 - c4000000) [ 0.929929] NetWinder Floating Point Emulator V0.97 (double precision) [ 1.191112] VFS: Disk quotas dquot_6.5.2 [ 1.191622] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.195187] NFS: Registering the id_resolver key type [ 1.195835] Key type id_resolver registered [ 1.195867] Key type id_legacy registered [ 1.196055] jffs2: version 2.2. (NAND) (SUMMARY) © 2001-2006 Red Hat, Inc. [ 1.196790] msgmni has been set to 478 [ 1.201528] io scheduler noop registered [ 1.201559] io scheduler deadline registered [ 1.201659] io scheduler cfq registered (default) [ 1.203470] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568 [ 1.209102] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 1.219674] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0 [ 1.834393] console [ttyO0] enabled [ 1.882450] brd: module loaded [ 1.910319] loop: module loaded [ 1.921131] mtdoops: mtd device (mtddev=name/number) must be supplied [ 1.939745] usbcore: registered new interface driver asix [ 1.946692] usbcore: registered new interface driver ax88179_178a [ 1.954307] usbcore: registered new interface driver cdc_ether [ 1.961165] usbcore: registered new interface driver smsc95xx [ 1.967981] usbcore: registered new interface driver net1080 [ 1.974853] usbcore: registered new interface driver cdc_subset [ 1.981820] usbcore: registered new interface driver zaurus [ 1.988373] usbcore: registered new interface driver cdc_ncm [ 1.997216] usbcore: registered new interface driver cdc_wdm [ 2.004100] usbcore: registered new interface driver usb-storage [ 2.011102] usbcore: registered new interface driver usbtest [ 2.020244] mousedev: PS/2 mouse device common for all mice [ 2.034865] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0 [ 2.043174] 44e3e000.rtc: already running [ 2.049525] i2c /dev entries driver [ 2.054310] Driver for 1-wire Dallas network protocol. [ 2.065743] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec [ 2.085316] ledtrig-cpu: registered to indicate activity on CPUs [ 2.094003] usbcore: registered new interface driver usbhid [ 2.099879] usbhid: USB HID core driver [ 2.106188] oprofile: no performance counters [ 2.114316] oprofile: using timer interrupt. [ 2.119754] TCP: cubic registered [ 2.123467] Initializing XFRM netlink socket [ 2.128168] NET: Registered protocol family 17 [ 2.133042] NET: Registered protocol family 15 [ 2.138255] Key type dns_resolver registered [ 2.143036] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3 [ 2.151220] ThumbEE CPU extension supported. [ 2.168166] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz [ 2.183328] DCDC1: at 1500 mV [ 2.189549] vdd_mpu: 925 <--> 1325 mV at 1100 mV [ 2.197934] vdd_core: 925 <--> 1150 mV at 1100 mV [ 2.205976] LDO1: at 1800 mV [ 2.212226] LDO2: at 3300 mV [ 2.218164] LDO3: at 1800 mV [ 2.224240] LDO4: at 3300 mV [ 2.230065] tps65217 0-0024: TPS65217 ID 0xe version 1.2 [ 2.301467] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6 [ 2.307911] davinci_mdio 4a101000.mdio: detected phy mask fffffffe [ 2.318069] libphy: 4a101000.mdio: probed [ 2.322476] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720 [ 2.332671] Random MACID = d2:be:d7:26:fb:7e [ 2.343346] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 23:13:33 UTC (946768413) [ 2.357708] RAMDISK: gzip image found at block 0 [ 2.854280] VFS: Mounted root (ext2 filesystem) on device 1:0. [ 2.861960] devtmpfs: mounted [ 2.866023] Freeing unused kernel memory: 392K (c0718000 - c077a000) mount: mounting none on /var/shm failed: No such file or directory :: :: Enabling hot-plug : [SUCCESS] :: :: : Populating /dev : [SUCCESS] [SUCCESS] :: :: :: Setting PATH :: : syslogd : [SUCCESS] : telnetd : [SUCCESS] Please press Enter to activate this console. :: :: Setting shell environment ... :: : Path : Aliases : Touch Screen :: :: Done :: [root@arago /]# [root@arago /]# [root@arago /]# zcat /proc/config.gz | grep -r ATAG CONFIG_ATAGS=y CONFIG_ATAGS_PROC=y [root@arago /]# [root@arago /]# zcat /proc/config.gz | grep -r APPEND # CONFIG_ARM_APPENDED_DTB is not set [root@arago /]# [root@arago /]#
Tony, Paul, Here is another attempt to send the SOC data files for OMAP5 based devices. As aligned on list, I have dropped clock data from the series. That means for the boot, one clock data patch needs to be applied. It is available on my git tree in 'out_of_tree/omap5_clk_data' branch. With OMAP5 and AM33XX support is DT only, respective hwmod files are cleaned up to remove iospace information and un-used hwmod. For 3.11 since OMAP4 is also targeted as DT only, its hwmod data files is also cleaned up. Diffstat looks something like below. 27 files changed, 9013 insertions(+), 2764 deletions(-) One can easily notice that the OMAP5 SOC data has significantly come down becasue of iospace and rest of the hwmod clean-up. Thanks to Sricharan, Vaibhav Bedia, Vaibhav H, Rajendra and Benoit for the patches and testing. The following changes since commit e4aa937ec75df0eea0bee03bffa3303ad36c986b: Linux 3.10-rc3 (2013-05-26 16:00:47 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git for_3.11/omap5_data_files for you to fetch changes up to 86b6a6dd106973df7f0c097fcb252e9e54b2f971: ARM: OMAP4: hwmod data: Clean up the data file (2013-05-29 11:51:30 -0400) ---------------------------------------------------------------- Benoit Cousson (7): ARM: OMAP5: PRM: Add OMAP54XX register and bitfield files ARM: OMAP5: CM: Add OMAP54XX register and bitfield files ARM: OMAP5: PRCM: Add OMAP54XX local MPU PRCM registers ARM: OMAP5: SCRM: Add OMAP54XX header file. ARM: OMAP5: clockdomain data: Add OMAP54XX data and update the header ARM: OMAP5: powerdomain data: Add OMAP54XX data and update the header ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data Santosh Shilimkar (5): ARM: OMAP4+: PRM: Move function prototypes to common header for re-use ARM: OMAP4+: CM: Move function prototypes to common header for re-use ARM: OMAP4+: PRCM MPU: Move function prototypes to common header for re-use ARM: OMAP5: voltagedomain data: Add OMAP5 voltage domain data ARM: OMAP5: Enable build and frameowrk initialisations Sricharan R (1): ARM: OMAP4: hwmod data: Clean up the data file Vaibhav Hiremath (1): ARM: AM33XX: hwmod data: irq, dma and addr info clean up arch/arm/mach-omap2/Makefile | 4 + arch/arm/mach-omap2/clockdomain.h | 1 + arch/arm/mach-omap2/clockdomains54xx_data.c | 464 +++++ arch/arm/mach-omap2/cm-regbits-54xx.h | 1737 ++++++++++++++++ arch/arm/mach-omap2/cm1_44xx.h | 7 +- arch/arm/mach-omap2/cm1_54xx.h | 218 ++ arch/arm/mach-omap2/cm2_44xx.h | 7 +- arch/arm/mach-omap2/cm2_54xx.h | 394 ++++ arch/arm/mach-omap2/cm_44xx_54xx.h | 36 + arch/arm/mach-omap2/io.c | 7 + arch/arm/mach-omap2/omap_hwmod.h | 1 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1067 ---------- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 1661 +-------------- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 2151 ++++++++++++++++++++ arch/arm/mach-omap2/powerdomain.h | 1 + arch/arm/mach-omap2/powerdomains54xx_data.c | 331 +++ arch/arm/mach-omap2/prcm44xx.h | 6 + arch/arm/mach-omap2/prcm_mpu44xx.h | 14 +- arch/arm/mach-omap2/prcm_mpu54xx.h | 87 + arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h | 36 + arch/arm/mach-omap2/prm-regbits-54xx.h | 2701 +++++++++++++++++++++++++ arch/arm/mach-omap2/prm44xx.h | 33 +- arch/arm/mach-omap2/prm44xx_54xx.h | 58 + arch/arm/mach-omap2/prm54xx.h | 421 ++++ arch/arm/mach-omap2/scrm54xx.h | 231 +++ arch/arm/mach-omap2/voltage.h | 1 + arch/arm/mach-omap2/voltagedomains54xx_data.c | 102 + 27 files changed, 9013 insertions(+), 2764 deletions(-) create mode 100644 arch/arm/mach-omap2/clockdomains54xx_data.c create mode 100644 arch/arm/mach-omap2/cm-regbits-54xx.h create mode 100644 arch/arm/mach-omap2/cm1_54xx.h create mode 100644 arch/arm/mach-omap2/cm2_54xx.h create mode 100644 arch/arm/mach-omap2/cm_44xx_54xx.h create mode 100644 arch/arm/mach-omap2/omap_hwmod_54xx_data.c create mode 100644 arch/arm/mach-omap2/powerdomains54xx_data.c create mode 100644 arch/arm/mach-omap2/prcm_mpu54xx.h create mode 100644 arch/arm/mach-omap2/prcm_mpu_44xx_54xx.h create mode 100644 arch/arm/mach-omap2/prm-regbits-54xx.h create mode 100644 arch/arm/mach-omap2/prm44xx_54xx.h create mode 100644 arch/arm/mach-omap2/prm54xx.h create mode 100644 arch/arm/mach-omap2/scrm54xx.h create mode 100644 arch/arm/mach-omap2/voltagedomains54xx_data.c