RE: [RESEND PATCH v4] clk: x86: Add Atom PMC platform clocks

2016-10-27 Thread Tirdea, Irina 
Darren Hart wrote:
> On Wed, Oct 26, 2016 at 11:43:24PM +0200, Thomas Gleixner wrote:
> > On Wed, 26 Oct 2016, Darren Hart wrote:
> > > On Mon, Oct 24, 2016 at 01:38:54PM +, Tirdea, Irina wrote:
> > > > intel_pmc_* drivers or is it enough to move it as a standalone
> > > > driver for now?
> > > 
> > > If the functionality is substantially different, then I don't see a
> > > compelling, and certainly not an immediate, need to merge them.
> > > Assume for now they are to remain as separate drivers. I suggest
> > > keeping the existing name for now as well. Let's just complete the
> > > move with as little user-visible changes as possible.
> > > 
> > > The placement of the header file is a bit tricky as it is being used
> > > in drivers/clk/x86 in addition to the pmc_atom driver in
> > > drivers/platform/x86.
> > > 
> > > The best existing location would appear to be include/platform_data/
> > > 
> > > Thomas, is that acceptable to you?
> > 
> > Yes
> > 
> > > arch/x86/platform/atom/pmc_atom.c -> drivers/platform/x86
> > > arch/x86/include/asm/pmc_atom.h -> include/platform_data/
> > > 
> > > If there are enough of these, it might make sense to create:
> > > 
> > > include/platform/x86/
> > > 
> > > but I suggest we start with minimal change.
> > 
> > No. Make that x86 directory right away. include/platform_data is
> > already a maze of 224 files. Start structuring it now.
> 
> OK, that's fine with me too.
> 
> (but I typo'd, should have been: include/linux/platform_data/x86)
> 
> Irina, does this give you enough to go on?
> 

Yes, everything is clear now. I will make the change and send a patch
in a few days.

Thanks,
Irina

Re: [RESEND PATCH v4] clk: x86: Add Atom PMC platform clocks

2016-10-26 Thread Darren Hart 
On Wed, Oct 26, 2016 at 11:43:24PM +0200, Thomas Gleixner wrote:
> On Wed, 26 Oct 2016, Darren Hart wrote:
> > On Mon, Oct 24, 2016 at 01:38:54PM +, Tirdea, Irina wrote:
> > > intel_pmc_* drivers or is it enough to move it as a standalone driver for 
> > > now?
> > 
> > If the functionality is substantially different, then I don't see a
> > compelling, and certainly not an immediate, need to merge them. Assume
> > for now they are to remain as separate drivers. I suggest keeping the
> > existing name for now as well. Let's just complete the move with as
> > little user-visible changes as possible.
> > 
> > The placement of the header file is a bit tricky as it is being used in
> > drivers/clk/x86 in addition to the pmc_atom driver in
> > drivers/platform/x86.
> > 
> > The best existing location would appear to be include/platform_data/
> > 
> > Thomas, is that acceptable to you?
> 
> Yes
> 
> > arch/x86/platform/atom/pmc_atom.c -> drivers/platform/x86
> > arch/x86/include/asm/pmc_atom.h -> include/platform_data/
> > 
> > If there are enough of these, it might make sense to create:
> > 
> > include/platform/x86/
> > 
> > but I suggest we start with minimal change.
> 
> No. Make that x86 directory right away. include/platform_data is already a
> maze of 224 files. Start structuring it now.

OK, that's fine with me too.

(but I typo'd, should have been: include/linux/platform_data/x86)

Irina, does this give you enough to go on?

-- 
Darren Hart
Intel Open Source Technology Center

Re: [RESEND PATCH v4] clk: x86: Add Atom PMC platform clocks

2016-10-26 Thread Thomas Gleixner 
On Wed, 26 Oct 2016, Darren Hart wrote:
> On Mon, Oct 24, 2016 at 01:38:54PM +, Tirdea, Irina wrote:
> > intel_pmc_* drivers or is it enough to move it as a standalone driver for 
> > now?
> 
> If the functionality is substantially different, then I don't see a
> compelling, and certainly not an immediate, need to merge them. Assume
> for now they are to remain as separate drivers. I suggest keeping the
> existing name for now as well. Let's just complete the move with as
> little user-visible changes as possible.
> 
> The placement of the header file is a bit tricky as it is being used in
> drivers/clk/x86 in addition to the pmc_atom driver in
> drivers/platform/x86.
> 
> The best existing location would appear to be include/platform_data/
> 
> Thomas, is that acceptable to you?

Yes

> arch/x86/platform/atom/pmc_atom.c -> drivers/platform/x86
> arch/x86/include/asm/pmc_atom.h -> include/platform_data/
> 
> If there are enough of these, it might make sense to create:
> 
> include/platform/x86/
> 
> but I suggest we start with minimal change.

No. Make that x86 directory right away. include/platform_data is already a
maze of 224 files. Start structuring it now.

Thanks,

tglx

Re: [RESEND PATCH v4] clk: x86: Add Atom PMC platform clocks

2016-10-26 Thread Darren Hart 
On Mon, Oct 24, 2016 at 01:38:54PM +, Tirdea, Irina wrote:
> > On Thu, Oct 20, 2016 at 11:52:38PM +0200, Thomas Gleixner wrote:
> > > On Mon, 17 Oct 2016, Irina Tirdea wrote:
> > > > The patch has already been reviewed by Stephen Boyd [1].
> > > > The only remaining question is the one pointed out by Stephen:
> > > > "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?" [1]
> > >
> > > The proper thing to do is:
> > >
> > > Move all that cruft including arch/x86/platform/atom/pmc_atom.c into
> > > drivers/platform/x86. There is nothing architecture specific in these
> > > files. It's pure peripheral driver enablement. So drivers/platform/x86 is
> > > the proper location for this. Please discuss this with Darren Hart 
> > > (cc'ed).
> > 
> 
> Thanks for pointing me in the right direction, Thomas!
> 
> > We've been adding more of the pmc and punit drivers to drivers/platform/x86.
> > This makes more sense than being under "arch". Thomas and I have discussed
> > moving more of the non architectural stuff in arch/x86/platform to my tree 
> > under
> > platform/drivers/x86.
> > 
> 
> Thanks for the reply, Darren.
> 
> I could move the arch/x86/platform/atom/pmc_atom.c into drivers/platform/x86,
> but I'm not sure what the process is in this case. I took a look at your tree 
> and noticed
> some intel_pmc_* drivers, but they are quite different from pmc_atom.c in 
> terms of
> HW registers and capabilities. Should the code from pmc_atom.c be integrated 
> in the
> intel_pmc_* drivers or is it enough to move it as a standalone driver for now?

If the functionality is substantially different, then I don't see a
compelling, and certainly not an immediate, need to merge them. Assume
for now they are to remain as separate drivers. I suggest keeping the
existing name for now as well. Let's just complete the move with as
little user-visible changes as possible.

The placement of the header file is a bit tricky as it is being used in
drivers/clk/x86 in addition to the pmc_atom driver in
drivers/platform/x86.

The best existing location would appear to be include/platform_data/

Thomas, is that acceptable to you?

arch/x86/platform/atom/pmc_atom.c -> drivers/platform/x86
arch/x86/include/asm/pmc_atom.h -> include/platform_data/

If there are enough of these, it might make sense to create:

include/platform/x86/

but I suggest we start with minimal change.

> 
> > Irina, please point me at the relevant context if it's more than just this
> > particular patch.
> 
> This patch comes from a set of patches that enable sound for Baytrail CR 
> devices
> (especially Asus T100TAF) [1]. The rest of the patches have been already 
> merged in
> Mark's sound tree. This is the only change remaining for enabling sound on 
> these
> platforms, so there are no additional changes to the x86 platform code.
> 
> Thanks,
> Irina
> 
> [1] 
> http://mailman.alsa-project.org/pipermail/alsa-devel/2016-August/111704.html
> 
> 

-- 
Darren Hart
Intel Open Source Technology Center

RE: [RESEND PATCH v4] clk: x86: Add Atom PMC platform clocks

2016-10-24 Thread Tirdea, Irina 


> -Original Message-
> From: Darren Hart [mailto:dvh...@infradead.org]
> Sent: 21 October, 2016 8:00
> To: Thomas Gleixner
> Cc: Tirdea, Irina; linux-...@vger.kernel.org; x...@kernel.org; Stephen Boyd; 
> Ingo Molnar; Michael Turquette; H. Peter Anvin; alsa-
> de...@alsa-project.org; Mark Brown; Takashi Iwai; Bossart, Pierre-louis; 
> LKML; Pierre-Louis Bossart
> Subject: Re: [RESEND PATCH v4] clk: x86: Add Atom PMC platform clocks
> 
> On Thu, Oct 20, 2016 at 11:52:38PM +0200, Thomas Gleixner wrote:
> > On Mon, 17 Oct 2016, Irina Tirdea wrote:
> > > The patch has already been reviewed by Stephen Boyd [1].
> > > The only remaining question is the one pointed out by Stephen:
> > > "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?" [1]
> >
> > The proper thing to do is:
> >
> > Move all that cruft including arch/x86/platform/atom/pmc_atom.c into
> > drivers/platform/x86. There is nothing architecture specific in these
> > files. It's pure peripheral driver enablement. So drivers/platform/x86 is
> > the proper location for this. Please discuss this with Darren Hart (cc'ed).
> 

Thanks for pointing me in the right direction, Thomas!

> We've been adding more of the pmc and punit drivers to drivers/platform/x86.
> This makes more sense than being under "arch". Thomas and I have discussed
> moving more of the non architectural stuff in arch/x86/platform to my tree 
> under
> platform/drivers/x86.
> 

Thanks for the reply, Darren.

I could move the arch/x86/platform/atom/pmc_atom.c into drivers/platform/x86,
but I'm not sure what the process is in this case. I took a look at your tree 
and noticed
some intel_pmc_* drivers, but they are quite different from pmc_atom.c in terms 
of
HW registers and capabilities. Should the code from pmc_atom.c be integrated in 
the
intel_pmc_* drivers or is it enough to move it as a standalone driver for now?

> Irina, please point me at the relevant context if it's more than just this
> particular patch.

This patch comes from a set of patches that enable sound for Baytrail CR devices
(especially Asus T100TAF) [1]. The rest of the patches have been already merged 
in
Mark's sound tree. This is the only change remaining for enabling sound on these
platforms, so there are no additional changes to the x86 platform code.

Thanks,
Irina

[1] http://mailman.alsa-project.org/pipermail/alsa-devel/2016-August/111704.html

Re: [RESEND PATCH v4] clk: x86: Add Atom PMC platform clocks

2016-10-20 Thread Darren Hart 
On Thu, Oct 20, 2016 at 11:52:38PM +0200, Thomas Gleixner wrote:
> On Mon, 17 Oct 2016, Irina Tirdea wrote:
> > The patch has already been reviewed by Stephen Boyd [1].
> > The only remaining question is the one pointed out by Stephen:
> > "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?" [1]
> 
> The proper thing to do is:
> 
> Move all that cruft including arch/x86/platform/atom/pmc_atom.c into
> drivers/platform/x86. There is nothing architecture specific in these
> files. It's pure peripheral driver enablement. So drivers/platform/x86 is
> the proper location for this. Please discuss this with Darren Hart (cc'ed).

We've been adding more of the pmc and punit drivers to drivers/platform/x86.
This makes more sense than being under "arch". Thomas and I have discussed
moving more of the non architectural stuff in arch/x86/platform to my tree under
platform/drivers/x86.

Irina, please point me at the relevant context if it's more than just this
particular patch.


-- 
Darren Hart
Intel Open Source Technology Center

Re: [RESEND PATCH v4] clk: x86: Add Atom PMC platform clocks

2016-10-20 Thread Thomas Gleixner 
On Mon, 17 Oct 2016, Irina Tirdea wrote:
> The patch has already been reviewed by Stephen Boyd [1].
> The only remaining question is the one pointed out by Stephen:
> "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?" [1]

The proper thing to do is:

Move all that cruft including arch/x86/platform/atom/pmc_atom.c into
drivers/platform/x86. There is nothing architecture specific in these
files. It's pure peripheral driver enablement. So drivers/platform/x86 is
the proper location for this. Please discuss this with Darren Hart (cc'ed).

Thanks,

tglx

[RESEND PATCH v4] clk: x86: Add Atom PMC platform clocks

2016-10-17 Thread Irina Tirdea 
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 
Signed-off-by: Pierre-Louis Bossart 
---
Hi,

This patch specifically enables the audio MCLK required by Baytrail CR
devices (support already merged in Mark's tree).

The patch has already been reviewed by Stephen Boyd [1].
The only remaining question is the one pointed out by Stephen:
"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?" [1]

Ingo, can you help answer this question (or point me to the right person)?
I am not sure what the process should be in this case.

Thank you,
Irina

[1] http://www.spinics.net/lists/alsa-devel/msg54832.html

Changes from v3:
 - replace devm_kzalloc with devm_kcalloc
 - add x86 architecture maintainers

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 +-
 drivers/clk/x86/Makefile  |   1 +
 drivers/clk/x86/clk-byt-plt.c | 380 ++
 include/linux/platform_data/clk-byt-plt.h |  31 +++
 6 files changed, 491 insertions(+), 3 deletions(-)
 create mode 100644 drivers/clk/x86/clk-byt-plt.c
 create mode 100644 include/linux/platform_data/clk-byt-plt.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bada636..233898e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2756,6 +2756,7 @@ config X86_DMA_REMAP
 config PMC_ATOM
def_bool y
 depends on PCI
+   select COMMON_CLK
 
 source "net/Kconfig"
 
diff --git a/arch/x86/include/asm/pmc_atom.h b/arch/x86/include/asm/pmc_atom.h
index aa8744c..2d310cf 100644
--- a/arch/x86/include/asm/pmc_atom.h
+++ b/arch/x86/include/asm/pmc_atom.h
@@ -50,6 +50,9 @@
BIT_ORED_DEDICATED_IRQ_GPSC | \
BIT_SHARED_IRQ_GPSS)
 
+/* Platform clock control registers */
+#define PMC_CLK_CTL_0  0x60
+
 /* The timers acumulate time spent in sleep state */
 #definePMC_S0IR_TMR0x80
 #definePMC_S0I1_TMR0x84
diff --git a/arch/x86/platform/atom/pmc_atom.c 
b/arch/x86/platform/atom/pmc_atom.c
index 964ff4f..b353893 100644
--- a/arch/x86/platform/atom/pmc_atom.c
+++ b/arch/x86/platform/atom/pmc_atom.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 
@@ -37,6 +39,11 @@ struct pmc_reg_map {
const struct pmc_bit_map *pss;
 };
 
+struct pmc_data {
+   const struct pmc_reg_map *map;
+   const struct pmc_clk *clks;
+};
+
 struct pmc_dev {
u32 base_addr;
void __iomem *regmap;
@@ -50,6 +57,29 @@ struct pmc_dev {
 static struct pmc_dev pmc_device;
 static u32 acpi_base_addr;
 
+static const struct pmc_clk byt_clks[] = {
+   {
+   .name = "xtal",
+   .freq = 2500,
+   .parent_name = NULL,
+   },
+   {
+   .name = "pll",
+   .freq = 1920,
+   .parent_name = "xtal",
+   },
+   {},
+};
+
+static const struct pmc_clk cht_clks[] = {
+   {
+   .name = "xtal",
+   .freq = 1920,
+   .parent_name = NULL,
+   },
+   {},
+};
+
 static const struct pmc_bit_map d3_sts_0_map[] = {
{"LPSS1_F0_DMA",BIT_LPSS1_F0_DMA},
{"LPSS1_F1_PWM1",   BIT_LPSS1_F1_PWM1},
@@ -169,6 +199,16 @@ struct pmc_dev {
.pss= cht_pss_map,
 };
 
+static const struct pmc_data byt_data = {
+   .map = &byt_reg_map,
+   .clks = byt_clks,
+};
+
+static const struct pmc_data cht_data = {
+   .map = &cht_reg_map,
+   .clks = cht_clks,
+};
+
 static inline u32 pmc_reg_read(struct pmc_dev *pmc, int reg_offset)
 {
return readl(pmc->regmap + reg_offset);
@@ -382,10 +422,36 @@ static int pmc_dbgfs_register(struct pmc_dev *pmc)
 }
 #endif /* CONFIG_DEBUG_FS */
 
+static int