> -----Original Message----- > From: linux-clk-owner@xxxxxxxxxxxxxxx [mailto:linux-clk-owner@xxxxxxxxxxxxxxx] On Behalf Of Stephen Boyd > Sent: 15 September, 2016 0:30 > To: Tirdea, Irina > Cc: linux-clk@xxxxxxxxxxxxxxx; Michael Turquette; alsa-devel@xxxxxxxxxxxxxxxx; Mark Brown; Takashi Iwai; Bossart, Pierre-louis; Pierre- > Louis Bossart > Subject: Re: [PATCH v3] clk: x86: Add Atom PMC platform clocks > > On 09/09, Irina Tirdea wrote: > > The BayTrail and CherryTrail platforms provide platform clocks > > through their Power Management Controller (PMC). > > > > The SoC supports up to 6 clocks (PMC_PLT_CLK[5:0]) with a > > frequency of either 19.2 MHz (PLL) or 25 MHz (XTAL) for BayTrail > > an a frequency of 19.2 MHz (XTAL) for CherryTrail. These clocks > > are available for general system use, where appropriate, and each > > have Control & Frequency register fields associated with them. > > > > For example, the usage for platform clocks suggested in the datasheet > > is the following: > > PLT_CLK[2:0] - Camera > > PLT_CLK[3] - Audio Codec > > PLT_CLK[4] - > > PLT_CLK[5] - COMMs > > > > Signed-off-by: Irina Tirdea <irina.tirdea@xxxxxxxxx> > > Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> > > --- > > > > Notes: > > Submitting this patch through the clock tree as requested by > > Mark Brown. This patch specifically enables the audio MCLK > > required by Baytrail CR devices (support already merged in > > Mark's tree) > > > > Changes from v2: > > - move clk platform data structures to a separate include file > > - store clk_hw pointer for the fixed rate clocks > > > > Changes from v1: > > - register the clk device as child of pmc device > > - pass iomem pointer from pmc driver to clk driver to avoid using > > pmc_atom_read()/write() and use readl/writel API instead > > - use devm_clk_hw_register/clkdev_hw_create instead of > > clk_register/clkdev_create > > > > arch/x86/Kconfig | 1 + > > arch/x86/include/asm/pmc_atom.h | 3 + > > arch/x86/platform/atom/pmc_atom.c | 78 +++++- > > Will there be problems if this merges through clk tree? If so we > could take the clk driver part and the platform data include part > could be duplicated into both trees. Or clk tree could be pulled > into x86? > > The patch looks fine to me. Adding the x86 list and maintainers to this thread, as they should be able to answer this question. I already sent a new version of this patch, this time also including the x86 platform list and maintainers [1]. Thanks, Irina [1] http://www.spinics.net/lists/linux-clk/msg12169.html _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel