On Tuesday 30 July 2013 06:11 PM, Nishanth Menon wrote: > On 07/30/2013 07:38 AM, Rajendra Nayak wrote: >> On Tuesday 30 July 2013 05:56 PM, Nishanth Menon wrote: >>> On 07/30/2013 06:25 AM, Rajendra Nayak wrote: >>>> From: R Sricharan <r.sricha...@ti.com> >>> [...] >>>> # Clock framework >>>> obj-$(CONFIG_ARCH_OMAP2) += $(clock-common) clock2xxx.o >>>> @@ -181,6 +187,8 @@ obj-$(CONFIG_SOC_AM33XX) += $(clock-common) >>>> dpll3xxx.o >>>> obj-$(CONFIG_SOC_AM33XX) += cclock33xx_data.o >>>> obj-$(CONFIG_SOC_OMAP5) += $(clock-common) >>>> obj-$(CONFIG_SOC_OMAP5) += dpll3xxx.o dpll44xx.o >>>> +obj-$(CONFIG_SOC_DRA7XX) += $(clock-common) >>>> +obj-$(CONFIG_SOC_DRA7XX) += dpll3xxx.o dpll44xx.o >>>> >>> >>> are these in sync with DRA7 support being introduced for clock data in [1]? >> >> I don't want to have a dependency on those patches since I am not sure of >> them >> making it into 3.12. > > Then we have to undo these changes again in clock data support. the chip wont > bootup anyways without clock data information, so why not try and keep the > changes that Tero is doing independent of these changes?
I still have something with clock data information which boots which I am maintaining out of tree till the clock movement to DT is sorted out. Maybe what you are suggesting is quite trivial and I am unable to understand. Are you suggesting we do no compile $(clock-common) and the dpll files for DRA7? Is that what you are worried we might have to revert? > >> >>> >>> >>> [1] http://marc.info/?l=linux-omap&m=137456411706971&w=2 >>> >> > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
