On Tuesday 30 July 2013 06:27 PM, Nishanth Menon wrote: > On 07/30/2013 07:48 AM, Rajendra Nayak wrote: >> 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? > > yes - lets just drop that change. that allows what ever alignment we have for > clock data/driver to handle it appropriately. IMHO, could also keeps your > series independent from Tero's series.
I can drop those. no issues. > >>> >>>> >>>>> >>>>> >>>>> [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
