Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
On Tue, Mar 18, 2014 at 06:21:22PM -0500, Scott Wood wrote: > On Mon, 2014-03-17 at 18:27 +0800, Chenhui Zhao wrote: > > On Fri, Mar 14, 2014 at 05:51:09PM -0500, Scott Wood wrote: > > > On Wed, 2014-03-12 at 16:34 +0800, Chenhui Zhao wrote: > > > > On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote: > > > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote: > > > > > > + /* Configure the EPU Counters */ > > > > > > + epu_write(EPCCR15, 0x9284); > > > > > > + epu_write(EPCCR14, 0x9284); > > > > > > + epu_write(EPCCR12, 0x9284); > > > > > > + epu_write(EPCCR11, 0x9284); > > > > > > + epu_write(EPCCR10, 0x9284); > > > > > > + epu_write(EPCCR9, 0x9284); > > > > > > + epu_write(EPCCR8, 0x9284); > > > > > > + epu_write(EPCCR5, 0x9284); > > > > > > + epu_write(EPCCR4, 0x9284); > > > > > > + epu_write(EPCCR2, 0x9284); > > > > > > + > > > > > > + /* Configure the SCUs Inputs */ > > > > > > + epu_write(EPSMCR15, 0x7600); > > > > > > + epu_write(EPSMCR14, 0x0031); > > > > > > + epu_write(EPSMCR13, 0x3100); > > > > > > + epu_write(EPSMCR12, 0x7F00); > > > > > > + epu_write(EPSMCR11, 0x3174); > > > > > > + epu_write(EPSMCR10, 0x6530); > > > > > > + epu_write(EPSMCR9, 0x3000); > > > > > > + epu_write(EPSMCR8, 0x6430); > > > > > > + epu_write(EPSMCR7, 0x3000); > > > > > > + epu_write(EPSMCR6, 0x7C00); > > > > > > + epu_write(EPSMCR5, 0x2E00); > > > > > > + epu_write(EPSMCR4, 0x002F); > > > > > > + epu_write(EPSMCR3, 0x2F00); > > > > > > + epu_write(EPSMCR2, 0x6C70); > > > > > > > > > > Where do these magic numbers come from? Which chips are they valid > > > > > for? > > > > > > > > They are for T1040. Can be found in the RCPM chapter of T1040RM. > > > > > > Then put in a comment to that effect, including what part of the RCPM > > > chapter. > > > > > > How do you plan to handle the addition of another SoC with different > > > values? > > > > > > -Scott > > > > Had thought that using an array to put these values (pairs of offset and > > value) > > and passing the array to the function. > > Arrays are better than a long sequence of function calls in any case. > > > However, luckily T104x and LS1 have same values for these registers > > according to the current Reference Manuals. > > If it's likely that the values will remain the same on all chips for the > near future, then a fancy mechanism to select the array to use can wait > -- but you should still use an array, and have a comment acknowledging > the possibility of needing to accommodate different values in the > future. > > -Scott OK. Will use an array to pass the values. -Chenhui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
On Mon, 2014-03-17 at 18:27 +0800, Chenhui Zhao wrote: > On Fri, Mar 14, 2014 at 05:51:09PM -0500, Scott Wood wrote: > > On Wed, 2014-03-12 at 16:34 +0800, Chenhui Zhao wrote: > > > On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote: > > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote: > > > > > + /* Configure the EPU Counters */ > > > > > + epu_write(EPCCR15, 0x9284); > > > > > + epu_write(EPCCR14, 0x9284); > > > > > + epu_write(EPCCR12, 0x9284); > > > > > + epu_write(EPCCR11, 0x9284); > > > > > + epu_write(EPCCR10, 0x9284); > > > > > + epu_write(EPCCR9, 0x9284); > > > > > + epu_write(EPCCR8, 0x9284); > > > > > + epu_write(EPCCR5, 0x9284); > > > > > + epu_write(EPCCR4, 0x9284); > > > > > + epu_write(EPCCR2, 0x9284); > > > > > + > > > > > + /* Configure the SCUs Inputs */ > > > > > + epu_write(EPSMCR15, 0x7600); > > > > > + epu_write(EPSMCR14, 0x0031); > > > > > + epu_write(EPSMCR13, 0x3100); > > > > > + epu_write(EPSMCR12, 0x7F00); > > > > > + epu_write(EPSMCR11, 0x3174); > > > > > + epu_write(EPSMCR10, 0x6530); > > > > > + epu_write(EPSMCR9, 0x3000); > > > > > + epu_write(EPSMCR8, 0x6430); > > > > > + epu_write(EPSMCR7, 0x3000); > > > > > + epu_write(EPSMCR6, 0x7C00); > > > > > + epu_write(EPSMCR5, 0x2E00); > > > > > + epu_write(EPSMCR4, 0x002F); > > > > > + epu_write(EPSMCR3, 0x2F00); > > > > > + epu_write(EPSMCR2, 0x6C70); > > > > > > > > Where do these magic numbers come from? Which chips are they valid for? > > > > > > They are for T1040. Can be found in the RCPM chapter of T1040RM. > > > > Then put in a comment to that effect, including what part of the RCPM > > chapter. > > > > How do you plan to handle the addition of another SoC with different > > values? > > > > -Scott > > Had thought that using an array to put these values (pairs of offset and > value) > and passing the array to the function. Arrays are better than a long sequence of function calls in any case. > However, luckily T104x and LS1 have same values for these registers > according to the current Reference Manuals. If it's likely that the values will remain the same on all chips for the near future, then a fancy mechanism to select the array to use can wait -- but you should still use an array, and have a comment acknowledging the possibility of needing to accommodate different values in the future. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
On Mon, 2014-03-17 at 18:27 +0800, Chenhui Zhao wrote: On Fri, Mar 14, 2014 at 05:51:09PM -0500, Scott Wood wrote: On Wed, 2014-03-12 at 16:34 +0800, Chenhui Zhao wrote: On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote: On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote: + /* Configure the EPU Counters */ + epu_write(EPCCR15, 0x9284); + epu_write(EPCCR14, 0x9284); + epu_write(EPCCR12, 0x9284); + epu_write(EPCCR11, 0x9284); + epu_write(EPCCR10, 0x9284); + epu_write(EPCCR9, 0x9284); + epu_write(EPCCR8, 0x9284); + epu_write(EPCCR5, 0x9284); + epu_write(EPCCR4, 0x9284); + epu_write(EPCCR2, 0x9284); + + /* Configure the SCUs Inputs */ + epu_write(EPSMCR15, 0x7600); + epu_write(EPSMCR14, 0x0031); + epu_write(EPSMCR13, 0x3100); + epu_write(EPSMCR12, 0x7F00); + epu_write(EPSMCR11, 0x3174); + epu_write(EPSMCR10, 0x6530); + epu_write(EPSMCR9, 0x3000); + epu_write(EPSMCR8, 0x6430); + epu_write(EPSMCR7, 0x3000); + epu_write(EPSMCR6, 0x7C00); + epu_write(EPSMCR5, 0x2E00); + epu_write(EPSMCR4, 0x002F); + epu_write(EPSMCR3, 0x2F00); + epu_write(EPSMCR2, 0x6C70); Where do these magic numbers come from? Which chips are they valid for? They are for T1040. Can be found in the RCPM chapter of T1040RM. Then put in a comment to that effect, including what part of the RCPM chapter. How do you plan to handle the addition of another SoC with different values? -Scott Had thought that using an array to put these values (pairs of offset and value) and passing the array to the function. Arrays are better than a long sequence of function calls in any case. However, luckily T104x and LS1 have same values for these registers according to the current Reference Manuals. If it's likely that the values will remain the same on all chips for the near future, then a fancy mechanism to select the array to use can wait -- but you should still use an array, and have a comment acknowledging the possibility of needing to accommodate different values in the future. -Scott -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
On Tue, Mar 18, 2014 at 06:21:22PM -0500, Scott Wood wrote: On Mon, 2014-03-17 at 18:27 +0800, Chenhui Zhao wrote: On Fri, Mar 14, 2014 at 05:51:09PM -0500, Scott Wood wrote: On Wed, 2014-03-12 at 16:34 +0800, Chenhui Zhao wrote: On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote: On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote: + /* Configure the EPU Counters */ + epu_write(EPCCR15, 0x9284); + epu_write(EPCCR14, 0x9284); + epu_write(EPCCR12, 0x9284); + epu_write(EPCCR11, 0x9284); + epu_write(EPCCR10, 0x9284); + epu_write(EPCCR9, 0x9284); + epu_write(EPCCR8, 0x9284); + epu_write(EPCCR5, 0x9284); + epu_write(EPCCR4, 0x9284); + epu_write(EPCCR2, 0x9284); + + /* Configure the SCUs Inputs */ + epu_write(EPSMCR15, 0x7600); + epu_write(EPSMCR14, 0x0031); + epu_write(EPSMCR13, 0x3100); + epu_write(EPSMCR12, 0x7F00); + epu_write(EPSMCR11, 0x3174); + epu_write(EPSMCR10, 0x6530); + epu_write(EPSMCR9, 0x3000); + epu_write(EPSMCR8, 0x6430); + epu_write(EPSMCR7, 0x3000); + epu_write(EPSMCR6, 0x7C00); + epu_write(EPSMCR5, 0x2E00); + epu_write(EPSMCR4, 0x002F); + epu_write(EPSMCR3, 0x2F00); + epu_write(EPSMCR2, 0x6C70); Where do these magic numbers come from? Which chips are they valid for? They are for T1040. Can be found in the RCPM chapter of T1040RM. Then put in a comment to that effect, including what part of the RCPM chapter. How do you plan to handle the addition of another SoC with different values? -Scott Had thought that using an array to put these values (pairs of offset and value) and passing the array to the function. Arrays are better than a long sequence of function calls in any case. However, luckily T104x and LS1 have same values for these registers according to the current Reference Manuals. If it's likely that the values will remain the same on all chips for the near future, then a fancy mechanism to select the array to use can wait -- but you should still use an array, and have a comment acknowledging the possibility of needing to accommodate different values in the future. -Scott OK. Will use an array to pass the values. -Chenhui -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
On Fri, Mar 14, 2014 at 05:51:09PM -0500, Scott Wood wrote: > On Wed, 2014-03-12 at 16:34 +0800, Chenhui Zhao wrote: > > On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote: > > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote: > > > > From: Hongbo Zhang > > > > > > > > In the last stage of deep sleep, software will trigger a Finite > > > > State Machine (FSM) to control the hardware precedure, such as > > > > board isolation, killing PLLs, removing power, and so on. > > > > > > > > When the system is waked up by an interrupt, the FSM controls the > > > > hardware to complete the early resume precedure. > > > > > > > > This patch configure the EPU FSM preparing for deep sleep. > > > > > > > > Signed-off-by: Hongbo Zhang > > > > Signed-off-by: Chenhui Zhao > > > > > > Couldn't this be part of qoriq_pm.c? > > > > Put the code in drivers/platform/fsl/ so that LS1 can share these code. > > How can LS1 share it if it's got hardcoded T1040 values? > > > > > diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig > > > > index 09fde58..6539e6d 100644 > > > > --- a/drivers/platform/Kconfig > > > > +++ b/drivers/platform/Kconfig > > > > @@ -6,3 +6,7 @@ source "drivers/platform/goldfish/Kconfig" > > > > endif > > > > > > > > source "drivers/platform/chrome/Kconfig" > > > > + > > > > +if FSL_SOC > > > > +source "drivers/platform/fsl/Kconfig" > > > > +endif > > > > > > Chrome doesn't need an ifdef -- why does this? > > > > Don't wish other platform see these options, and the X86 and GOLDFISH have > > ifdefs. > > The point is you can implement the dependency inside > drivers/platform/fsl/Kconfig. OK. > > > > > diff --git a/drivers/platform/fsl/Makefile > > > > b/drivers/platform/fsl/Makefile > > > > new file mode 100644 > > > > index 000..d99ca0e > > > > --- /dev/null > > > > +++ b/drivers/platform/fsl/Makefile > > > > @@ -0,0 +1,5 @@ > > > > +# > > > > +# Makefile for linux/drivers/platform/fsl > > > > +# Freescale Specific Power Management Drivers > > > > +# > > > > +obj-$(CONFIG_FSL_SLEEP_FSM)+= sleep_fsm.o > > > > > > Why is this here while the other stuff is in arch/powerpc/sysdev? > > > > > > > +/* Block offsets */ > > > > +#defineRCPM_BLOCK_OFFSET 0x00022000 > > > > +#defineEPU_BLOCK_OFFSET0x > > > > +#defineNPC_BLOCK_OFFSET0x1000 > > > > > > Why don't these block offsets come from the device tree? > > > > Have maped DCSR registers. Don't wish to remap them. > > We don't wish to have hardcoded CCSR/DCSR offsets in the kernel source. > Sorry. OK. > > > > > + /* Configure the EPU Counters */ > > > > + epu_write(EPCCR15, 0x9284); > > > > + epu_write(EPCCR14, 0x9284); > > > > + epu_write(EPCCR12, 0x9284); > > > > + epu_write(EPCCR11, 0x9284); > > > > + epu_write(EPCCR10, 0x9284); > > > > + epu_write(EPCCR9, 0x9284); > > > > + epu_write(EPCCR8, 0x9284); > > > > + epu_write(EPCCR5, 0x9284); > > > > + epu_write(EPCCR4, 0x9284); > > > > + epu_write(EPCCR2, 0x9284); > > > > + > > > > + /* Configure the SCUs Inputs */ > > > > + epu_write(EPSMCR15, 0x7600); > > > > + epu_write(EPSMCR14, 0x0031); > > > > + epu_write(EPSMCR13, 0x3100); > > > > + epu_write(EPSMCR12, 0x7F00); > > > > + epu_write(EPSMCR11, 0x3174); > > > > + epu_write(EPSMCR10, 0x6530); > > > > + epu_write(EPSMCR9, 0x3000); > > > > + epu_write(EPSMCR8, 0x6430); > > > > + epu_write(EPSMCR7, 0x3000); > > > > + epu_write(EPSMCR6, 0x7C00); > > > > + epu_write(EPSMCR5, 0x2E00); > > > > + epu_write(EPSMCR4, 0x002F); > > > > + epu_write(EPSMCR3, 0x2F00); > > > > + epu_write(EPSMCR2, 0x6C70); > > > > > > Where do these magic numbers come from? Which chips are they valid for? > > > > They are for T1040. Can be found in the RCPM chapter of T1040RM. > > Then put in a comment to that effect, including what part of the RCPM > chapter. > > How do you plan to handle the addition of another SoC with different > values? > > -Scott Had thought that using an array to put these values (pairs of offset and value) and passing the array to the function. However, luckily T104x and LS1 have same values for these registers according to the current Reference Manuals. -Chenhui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
On Fri, Mar 14, 2014 at 05:51:09PM -0500, Scott Wood wrote: On Wed, 2014-03-12 at 16:34 +0800, Chenhui Zhao wrote: On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote: On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote: From: Hongbo Zhang hongbo.zh...@freescale.com In the last stage of deep sleep, software will trigger a Finite State Machine (FSM) to control the hardware precedure, such as board isolation, killing PLLs, removing power, and so on. When the system is waked up by an interrupt, the FSM controls the hardware to complete the early resume precedure. This patch configure the EPU FSM preparing for deep sleep. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com Signed-off-by: Chenhui Zhao chenhui.z...@freescale.com Couldn't this be part of qoriq_pm.c? Put the code in drivers/platform/fsl/ so that LS1 can share these code. How can LS1 share it if it's got hardcoded T1040 values? diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig index 09fde58..6539e6d 100644 --- a/drivers/platform/Kconfig +++ b/drivers/platform/Kconfig @@ -6,3 +6,7 @@ source drivers/platform/goldfish/Kconfig endif source drivers/platform/chrome/Kconfig + +if FSL_SOC +source drivers/platform/fsl/Kconfig +endif Chrome doesn't need an ifdef -- why does this? Don't wish other platform see these options, and the X86 and GOLDFISH have ifdefs. The point is you can implement the dependency inside drivers/platform/fsl/Kconfig. OK. diff --git a/drivers/platform/fsl/Makefile b/drivers/platform/fsl/Makefile new file mode 100644 index 000..d99ca0e --- /dev/null +++ b/drivers/platform/fsl/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for linux/drivers/platform/fsl +# Freescale Specific Power Management Drivers +# +obj-$(CONFIG_FSL_SLEEP_FSM)+= sleep_fsm.o Why is this here while the other stuff is in arch/powerpc/sysdev? +/* Block offsets */ +#defineRCPM_BLOCK_OFFSET 0x00022000 +#defineEPU_BLOCK_OFFSET0x +#defineNPC_BLOCK_OFFSET0x1000 Why don't these block offsets come from the device tree? Have maped DCSR registers. Don't wish to remap them. We don't wish to have hardcoded CCSR/DCSR offsets in the kernel source. Sorry. OK. + /* Configure the EPU Counters */ + epu_write(EPCCR15, 0x9284); + epu_write(EPCCR14, 0x9284); + epu_write(EPCCR12, 0x9284); + epu_write(EPCCR11, 0x9284); + epu_write(EPCCR10, 0x9284); + epu_write(EPCCR9, 0x9284); + epu_write(EPCCR8, 0x9284); + epu_write(EPCCR5, 0x9284); + epu_write(EPCCR4, 0x9284); + epu_write(EPCCR2, 0x9284); + + /* Configure the SCUs Inputs */ + epu_write(EPSMCR15, 0x7600); + epu_write(EPSMCR14, 0x0031); + epu_write(EPSMCR13, 0x3100); + epu_write(EPSMCR12, 0x7F00); + epu_write(EPSMCR11, 0x3174); + epu_write(EPSMCR10, 0x6530); + epu_write(EPSMCR9, 0x3000); + epu_write(EPSMCR8, 0x6430); + epu_write(EPSMCR7, 0x3000); + epu_write(EPSMCR6, 0x7C00); + epu_write(EPSMCR5, 0x2E00); + epu_write(EPSMCR4, 0x002F); + epu_write(EPSMCR3, 0x2F00); + epu_write(EPSMCR2, 0x6C70); Where do these magic numbers come from? Which chips are they valid for? They are for T1040. Can be found in the RCPM chapter of T1040RM. Then put in a comment to that effect, including what part of the RCPM chapter. How do you plan to handle the addition of another SoC with different values? -Scott Had thought that using an array to put these values (pairs of offset and value) and passing the array to the function. However, luckily T104x and LS1 have same values for these registers according to the current Reference Manuals. -Chenhui -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
On Wed, 2014-03-12 at 16:34 +0800, Chenhui Zhao wrote: > On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote: > > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote: > > > From: Hongbo Zhang > > > > > > In the last stage of deep sleep, software will trigger a Finite > > > State Machine (FSM) to control the hardware precedure, such as > > > board isolation, killing PLLs, removing power, and so on. > > > > > > When the system is waked up by an interrupt, the FSM controls the > > > hardware to complete the early resume precedure. > > > > > > This patch configure the EPU FSM preparing for deep sleep. > > > > > > Signed-off-by: Hongbo Zhang > > > Signed-off-by: Chenhui Zhao > > > > Couldn't this be part of qoriq_pm.c? > > Put the code in drivers/platform/fsl/ so that LS1 can share these code. How can LS1 share it if it's got hardcoded T1040 values? > > > diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig > > > index 09fde58..6539e6d 100644 > > > --- a/drivers/platform/Kconfig > > > +++ b/drivers/platform/Kconfig > > > @@ -6,3 +6,7 @@ source "drivers/platform/goldfish/Kconfig" > > > endif > > > > > > source "drivers/platform/chrome/Kconfig" > > > + > > > +if FSL_SOC > > > +source "drivers/platform/fsl/Kconfig" > > > +endif > > > > Chrome doesn't need an ifdef -- why does this? > > Don't wish other platform see these options, and the X86 and GOLDFISH have > ifdefs. The point is you can implement the dependency inside drivers/platform/fsl/Kconfig. > > > diff --git a/drivers/platform/fsl/Makefile b/drivers/platform/fsl/Makefile > > > new file mode 100644 > > > index 000..d99ca0e > > > --- /dev/null > > > +++ b/drivers/platform/fsl/Makefile > > > @@ -0,0 +1,5 @@ > > > +# > > > +# Makefile for linux/drivers/platform/fsl > > > +# Freescale Specific Power Management Drivers > > > +# > > > +obj-$(CONFIG_FSL_SLEEP_FSM) += sleep_fsm.o > > > > Why is this here while the other stuff is in arch/powerpc/sysdev? > > > > > +/* Block offsets */ > > > +#define RCPM_BLOCK_OFFSET 0x00022000 > > > +#define EPU_BLOCK_OFFSET0x > > > +#define NPC_BLOCK_OFFSET0x1000 > > > > Why don't these block offsets come from the device tree? > > Have maped DCSR registers. Don't wish to remap them. We don't wish to have hardcoded CCSR/DCSR offsets in the kernel source. Sorry. > > > + /* Configure the EPU Counters */ > > > + epu_write(EPCCR15, 0x9284); > > > + epu_write(EPCCR14, 0x9284); > > > + epu_write(EPCCR12, 0x9284); > > > + epu_write(EPCCR11, 0x9284); > > > + epu_write(EPCCR10, 0x9284); > > > + epu_write(EPCCR9, 0x9284); > > > + epu_write(EPCCR8, 0x9284); > > > + epu_write(EPCCR5, 0x9284); > > > + epu_write(EPCCR4, 0x9284); > > > + epu_write(EPCCR2, 0x9284); > > > + > > > + /* Configure the SCUs Inputs */ > > > + epu_write(EPSMCR15, 0x7600); > > > + epu_write(EPSMCR14, 0x0031); > > > + epu_write(EPSMCR13, 0x3100); > > > + epu_write(EPSMCR12, 0x7F00); > > > + epu_write(EPSMCR11, 0x3174); > > > + epu_write(EPSMCR10, 0x6530); > > > + epu_write(EPSMCR9, 0x3000); > > > + epu_write(EPSMCR8, 0x6430); > > > + epu_write(EPSMCR7, 0x3000); > > > + epu_write(EPSMCR6, 0x7C00); > > > + epu_write(EPSMCR5, 0x2E00); > > > + epu_write(EPSMCR4, 0x002F); > > > + epu_write(EPSMCR3, 0x2F00); > > > + epu_write(EPSMCR2, 0x6C70); > > > > Where do these magic numbers come from? Which chips are they valid for? > > They are for T1040. Can be found in the RCPM chapter of T1040RM. Then put in a comment to that effect, including what part of the RCPM chapter. How do you plan to handle the addition of another SoC with different values? -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
On Wed, 2014-03-12 at 16:34 +0800, Chenhui Zhao wrote: On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote: On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote: From: Hongbo Zhang hongbo.zh...@freescale.com In the last stage of deep sleep, software will trigger a Finite State Machine (FSM) to control the hardware precedure, such as board isolation, killing PLLs, removing power, and so on. When the system is waked up by an interrupt, the FSM controls the hardware to complete the early resume precedure. This patch configure the EPU FSM preparing for deep sleep. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com Signed-off-by: Chenhui Zhao chenhui.z...@freescale.com Couldn't this be part of qoriq_pm.c? Put the code in drivers/platform/fsl/ so that LS1 can share these code. How can LS1 share it if it's got hardcoded T1040 values? diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig index 09fde58..6539e6d 100644 --- a/drivers/platform/Kconfig +++ b/drivers/platform/Kconfig @@ -6,3 +6,7 @@ source drivers/platform/goldfish/Kconfig endif source drivers/platform/chrome/Kconfig + +if FSL_SOC +source drivers/platform/fsl/Kconfig +endif Chrome doesn't need an ifdef -- why does this? Don't wish other platform see these options, and the X86 and GOLDFISH have ifdefs. The point is you can implement the dependency inside drivers/platform/fsl/Kconfig. diff --git a/drivers/platform/fsl/Makefile b/drivers/platform/fsl/Makefile new file mode 100644 index 000..d99ca0e --- /dev/null +++ b/drivers/platform/fsl/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for linux/drivers/platform/fsl +# Freescale Specific Power Management Drivers +# +obj-$(CONFIG_FSL_SLEEP_FSM) += sleep_fsm.o Why is this here while the other stuff is in arch/powerpc/sysdev? +/* Block offsets */ +#define RCPM_BLOCK_OFFSET 0x00022000 +#define EPU_BLOCK_OFFSET0x +#define NPC_BLOCK_OFFSET0x1000 Why don't these block offsets come from the device tree? Have maped DCSR registers. Don't wish to remap them. We don't wish to have hardcoded CCSR/DCSR offsets in the kernel source. Sorry. + /* Configure the EPU Counters */ + epu_write(EPCCR15, 0x9284); + epu_write(EPCCR14, 0x9284); + epu_write(EPCCR12, 0x9284); + epu_write(EPCCR11, 0x9284); + epu_write(EPCCR10, 0x9284); + epu_write(EPCCR9, 0x9284); + epu_write(EPCCR8, 0x9284); + epu_write(EPCCR5, 0x9284); + epu_write(EPCCR4, 0x9284); + epu_write(EPCCR2, 0x9284); + + /* Configure the SCUs Inputs */ + epu_write(EPSMCR15, 0x7600); + epu_write(EPSMCR14, 0x0031); + epu_write(EPSMCR13, 0x3100); + epu_write(EPSMCR12, 0x7F00); + epu_write(EPSMCR11, 0x3174); + epu_write(EPSMCR10, 0x6530); + epu_write(EPSMCR9, 0x3000); + epu_write(EPSMCR8, 0x6430); + epu_write(EPSMCR7, 0x3000); + epu_write(EPSMCR6, 0x7C00); + epu_write(EPSMCR5, 0x2E00); + epu_write(EPSMCR4, 0x002F); + epu_write(EPSMCR3, 0x2F00); + epu_write(EPSMCR2, 0x6C70); Where do these magic numbers come from? Which chips are they valid for? They are for T1040. Can be found in the RCPM chapter of T1040RM. Then put in a comment to that effect, including what part of the RCPM chapter. How do you plan to handle the addition of another SoC with different values? -Scott -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote: > On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote: > > From: Hongbo Zhang > > > > In the last stage of deep sleep, software will trigger a Finite > > State Machine (FSM) to control the hardware precedure, such as > > board isolation, killing PLLs, removing power, and so on. > > > > When the system is waked up by an interrupt, the FSM controls the > > hardware to complete the early resume precedure. > > > > This patch configure the EPU FSM preparing for deep sleep. > > > > Signed-off-by: Hongbo Zhang > > Signed-off-by: Chenhui Zhao > > Couldn't this be part of qoriq_pm.c? Put the code in drivers/platform/fsl/ so that LS1 can share these code. > > > diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h > > index 9b9a34a..eb83a30 100644 > > --- a/arch/powerpc/sysdev/fsl_soc.h > > +++ b/arch/powerpc/sysdev/fsl_soc.h > > @@ -69,5 +69,8 @@ extern const struct fsl_pm_ops *qoriq_pm_ops; > > > > extern int fsl_rcpm_init(void); > > > > +extern void fsl_dp_fsm_setup(void *dcsr_base); > > +extern void fsl_dp_fsm_clean(void *dcsr_base); > > __iomem Thanks. Will add. > > > + > > #endif > > #endif > > diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig > > index 09fde58..6539e6d 100644 > > --- a/drivers/platform/Kconfig > > +++ b/drivers/platform/Kconfig > > @@ -6,3 +6,7 @@ source "drivers/platform/goldfish/Kconfig" > > endif > > > > source "drivers/platform/chrome/Kconfig" > > + > > +if FSL_SOC > > +source "drivers/platform/fsl/Kconfig" > > +endif > > Chrome doesn't need an ifdef -- why does this? Don't wish other platform see these options, and the X86 and GOLDFISH have ifdefs. > > > diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile > > index 3656b7b..37c6f72 100644 > > --- a/drivers/platform/Makefile > > +++ b/drivers/platform/Makefile > > @@ -6,3 +6,4 @@ obj-$(CONFIG_X86) += x86/ > > obj-$(CONFIG_OLPC) += olpc/ > > obj-$(CONFIG_GOLDFISH) += goldfish/ > > obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ > > +obj-$(CONFIG_FSL_SOC) += fsl/ > > diff --git a/drivers/platform/fsl/Kconfig b/drivers/platform/fsl/Kconfig > > new file mode 100644 > > index 000..72ed053 > > --- /dev/null > > +++ b/drivers/platform/fsl/Kconfig > > @@ -0,0 +1,10 @@ > > +# > > +# Freescale Specific Power Management Drivers > > +# > > + > > +config FSL_SLEEP_FSM > > + bool > > + help > > + This driver configures a hardware FSM (Finite State Machine) for deep > > sleep. > > + The FSM is used to finish clean-ups at the last stage of system > > entering deep > > + sleep, and also wakes up system when a wake up event happens. > > diff --git a/drivers/platform/fsl/Makefile b/drivers/platform/fsl/Makefile > > new file mode 100644 > > index 000..d99ca0e > > --- /dev/null > > +++ b/drivers/platform/fsl/Makefile > > @@ -0,0 +1,5 @@ > > +# > > +# Makefile for linux/drivers/platform/fsl > > +# Freescale Specific Power Management Drivers > > +# > > +obj-$(CONFIG_FSL_SLEEP_FSM)+= sleep_fsm.o > > Why is this here while the other stuff is in arch/powerpc/sysdev? > > > +/* Block offsets */ > > +#defineRCPM_BLOCK_OFFSET 0x00022000 > > +#defineEPU_BLOCK_OFFSET0x > > +#defineNPC_BLOCK_OFFSET0x1000 > > Why don't these block offsets come from the device tree? Have maped DCSR registers. Don't wish to remap them. > > > +static void *g_dcsr_base; > > __iomem OK. > > > + /* Configure the EPU Counters */ > > + epu_write(EPCCR15, 0x9284); > > + epu_write(EPCCR14, 0x9284); > > + epu_write(EPCCR12, 0x9284); > > + epu_write(EPCCR11, 0x9284); > > + epu_write(EPCCR10, 0x9284); > > + epu_write(EPCCR9, 0x9284); > > + epu_write(EPCCR8, 0x9284); > > + epu_write(EPCCR5, 0x9284); > > + epu_write(EPCCR4, 0x9284); > > + epu_write(EPCCR2, 0x9284); > > + > > + /* Configure the SCUs Inputs */ > > + epu_write(EPSMCR15, 0x7600); > > + epu_write(EPSMCR14, 0x0031); > > + epu_write(EPSMCR13, 0x3100); > > + epu_write(EPSMCR12, 0x7F00); > > + epu_write(EPSMCR11, 0x3174); > > + epu_write(EPSMCR10, 0x6530); > > + epu_write(EPSMCR9, 0x3000); > > + epu_write(EPSMCR8, 0x6430); > > + epu_write(EPSMCR7, 0x3000); > > + epu_write(EPSMCR6, 0x7C00); > > + epu_write(EPSMCR5, 0x2E00); > > + epu_write(EPSMCR4, 0x002F); > > + epu_write(EPSMCR3, 0x2F00); > > + epu_write(EPSMCR2, 0x6C70); > > Where do these magic numbers come from? Which chips are they valid for? They are for T1040. Can be found in the RCPM chapter of T1040RM. > > > +void fsl_dp_fsm_clean(void *dcsr_base) > > +{ > > + > > + epu_write(EPEVTCR2, 0); > > + epu_write(EPEVTCR9, 0); > > + > > + epu_write(EPGCR, 0); > > + epu_write(EPECR15, 0); > > + > > + rcpm_write(CSTTACR0, 0); > > + rcpm_write(CG1CR0, 0); > > + >
Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
On Tue, Mar 11, 2014 at 07:08:43PM -0500, Scott Wood wrote: On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote: From: Hongbo Zhang hongbo.zh...@freescale.com In the last stage of deep sleep, software will trigger a Finite State Machine (FSM) to control the hardware precedure, such as board isolation, killing PLLs, removing power, and so on. When the system is waked up by an interrupt, the FSM controls the hardware to complete the early resume precedure. This patch configure the EPU FSM preparing for deep sleep. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com Signed-off-by: Chenhui Zhao chenhui.z...@freescale.com Couldn't this be part of qoriq_pm.c? Put the code in drivers/platform/fsl/ so that LS1 can share these code. diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h index 9b9a34a..eb83a30 100644 --- a/arch/powerpc/sysdev/fsl_soc.h +++ b/arch/powerpc/sysdev/fsl_soc.h @@ -69,5 +69,8 @@ extern const struct fsl_pm_ops *qoriq_pm_ops; extern int fsl_rcpm_init(void); +extern void fsl_dp_fsm_setup(void *dcsr_base); +extern void fsl_dp_fsm_clean(void *dcsr_base); __iomem Thanks. Will add. + #endif #endif diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig index 09fde58..6539e6d 100644 --- a/drivers/platform/Kconfig +++ b/drivers/platform/Kconfig @@ -6,3 +6,7 @@ source drivers/platform/goldfish/Kconfig endif source drivers/platform/chrome/Kconfig + +if FSL_SOC +source drivers/platform/fsl/Kconfig +endif Chrome doesn't need an ifdef -- why does this? Don't wish other platform see these options, and the X86 and GOLDFISH have ifdefs. diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile index 3656b7b..37c6f72 100644 --- a/drivers/platform/Makefile +++ b/drivers/platform/Makefile @@ -6,3 +6,4 @@ obj-$(CONFIG_X86) += x86/ obj-$(CONFIG_OLPC) += olpc/ obj-$(CONFIG_GOLDFISH) += goldfish/ obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ +obj-$(CONFIG_FSL_SOC) += fsl/ diff --git a/drivers/platform/fsl/Kconfig b/drivers/platform/fsl/Kconfig new file mode 100644 index 000..72ed053 --- /dev/null +++ b/drivers/platform/fsl/Kconfig @@ -0,0 +1,10 @@ +# +# Freescale Specific Power Management Drivers +# + +config FSL_SLEEP_FSM + bool + help + This driver configures a hardware FSM (Finite State Machine) for deep sleep. + The FSM is used to finish clean-ups at the last stage of system entering deep + sleep, and also wakes up system when a wake up event happens. diff --git a/drivers/platform/fsl/Makefile b/drivers/platform/fsl/Makefile new file mode 100644 index 000..d99ca0e --- /dev/null +++ b/drivers/platform/fsl/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for linux/drivers/platform/fsl +# Freescale Specific Power Management Drivers +# +obj-$(CONFIG_FSL_SLEEP_FSM)+= sleep_fsm.o Why is this here while the other stuff is in arch/powerpc/sysdev? +/* Block offsets */ +#defineRCPM_BLOCK_OFFSET 0x00022000 +#defineEPU_BLOCK_OFFSET0x +#defineNPC_BLOCK_OFFSET0x1000 Why don't these block offsets come from the device tree? Have maped DCSR registers. Don't wish to remap them. +static void *g_dcsr_base; __iomem OK. + /* Configure the EPU Counters */ + epu_write(EPCCR15, 0x9284); + epu_write(EPCCR14, 0x9284); + epu_write(EPCCR12, 0x9284); + epu_write(EPCCR11, 0x9284); + epu_write(EPCCR10, 0x9284); + epu_write(EPCCR9, 0x9284); + epu_write(EPCCR8, 0x9284); + epu_write(EPCCR5, 0x9284); + epu_write(EPCCR4, 0x9284); + epu_write(EPCCR2, 0x9284); + + /* Configure the SCUs Inputs */ + epu_write(EPSMCR15, 0x7600); + epu_write(EPSMCR14, 0x0031); + epu_write(EPSMCR13, 0x3100); + epu_write(EPSMCR12, 0x7F00); + epu_write(EPSMCR11, 0x3174); + epu_write(EPSMCR10, 0x6530); + epu_write(EPSMCR9, 0x3000); + epu_write(EPSMCR8, 0x6430); + epu_write(EPSMCR7, 0x3000); + epu_write(EPSMCR6, 0x7C00); + epu_write(EPSMCR5, 0x2E00); + epu_write(EPSMCR4, 0x002F); + epu_write(EPSMCR3, 0x2F00); + epu_write(EPSMCR2, 0x6C70); Where do these magic numbers come from? Which chips are they valid for? They are for T1040. Can be found in the RCPM chapter of T1040RM. +void fsl_dp_fsm_clean(void *dcsr_base) +{ + + epu_write(EPEVTCR2, 0); + epu_write(EPEVTCR9, 0); + + epu_write(EPGCR, 0); + epu_write(EPECR15, 0); + + rcpm_write(CSTTACR0, 0); + rcpm_write(CG1CR0, 0); + +} Don't put blank lines at the beginning/end of a block. -Scott Thanks. -Chenhui -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message
Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote: > From: Hongbo Zhang > > In the last stage of deep sleep, software will trigger a Finite > State Machine (FSM) to control the hardware precedure, such as > board isolation, killing PLLs, removing power, and so on. > > When the system is waked up by an interrupt, the FSM controls the > hardware to complete the early resume precedure. > > This patch configure the EPU FSM preparing for deep sleep. > > Signed-off-by: Hongbo Zhang > Signed-off-by: Chenhui Zhao Couldn't this be part of qoriq_pm.c? > diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h > index 9b9a34a..eb83a30 100644 > --- a/arch/powerpc/sysdev/fsl_soc.h > +++ b/arch/powerpc/sysdev/fsl_soc.h > @@ -69,5 +69,8 @@ extern const struct fsl_pm_ops *qoriq_pm_ops; > > extern int fsl_rcpm_init(void); > > +extern void fsl_dp_fsm_setup(void *dcsr_base); > +extern void fsl_dp_fsm_clean(void *dcsr_base); __iomem > + > #endif > #endif > diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig > index 09fde58..6539e6d 100644 > --- a/drivers/platform/Kconfig > +++ b/drivers/platform/Kconfig > @@ -6,3 +6,7 @@ source "drivers/platform/goldfish/Kconfig" > endif > > source "drivers/platform/chrome/Kconfig" > + > +if FSL_SOC > +source "drivers/platform/fsl/Kconfig" > +endif Chrome doesn't need an ifdef -- why does this? > diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile > index 3656b7b..37c6f72 100644 > --- a/drivers/platform/Makefile > +++ b/drivers/platform/Makefile > @@ -6,3 +6,4 @@ obj-$(CONFIG_X86) += x86/ > obj-$(CONFIG_OLPC) += olpc/ > obj-$(CONFIG_GOLDFISH) += goldfish/ > obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ > +obj-$(CONFIG_FSL_SOC)+= fsl/ > diff --git a/drivers/platform/fsl/Kconfig b/drivers/platform/fsl/Kconfig > new file mode 100644 > index 000..72ed053 > --- /dev/null > +++ b/drivers/platform/fsl/Kconfig > @@ -0,0 +1,10 @@ > +# > +# Freescale Specific Power Management Drivers > +# > + > +config FSL_SLEEP_FSM > + bool > + help > + This driver configures a hardware FSM (Finite State Machine) for deep > sleep. > + The FSM is used to finish clean-ups at the last stage of system > entering deep > + sleep, and also wakes up system when a wake up event happens. > diff --git a/drivers/platform/fsl/Makefile b/drivers/platform/fsl/Makefile > new file mode 100644 > index 000..d99ca0e > --- /dev/null > +++ b/drivers/platform/fsl/Makefile > @@ -0,0 +1,5 @@ > +# > +# Makefile for linux/drivers/platform/fsl > +# Freescale Specific Power Management Drivers > +# > +obj-$(CONFIG_FSL_SLEEP_FSM) += sleep_fsm.o Why is this here while the other stuff is in arch/powerpc/sysdev? > +/* Block offsets */ > +#define RCPM_BLOCK_OFFSET 0x00022000 > +#define EPU_BLOCK_OFFSET0x > +#define NPC_BLOCK_OFFSET0x1000 Why don't these block offsets come from the device tree? > +static void *g_dcsr_base; __iomem > + /* Configure the EPU Counters */ > + epu_write(EPCCR15, 0x9284); > + epu_write(EPCCR14, 0x9284); > + epu_write(EPCCR12, 0x9284); > + epu_write(EPCCR11, 0x9284); > + epu_write(EPCCR10, 0x9284); > + epu_write(EPCCR9, 0x9284); > + epu_write(EPCCR8, 0x9284); > + epu_write(EPCCR5, 0x9284); > + epu_write(EPCCR4, 0x9284); > + epu_write(EPCCR2, 0x9284); > + > + /* Configure the SCUs Inputs */ > + epu_write(EPSMCR15, 0x7600); > + epu_write(EPSMCR14, 0x0031); > + epu_write(EPSMCR13, 0x3100); > + epu_write(EPSMCR12, 0x7F00); > + epu_write(EPSMCR11, 0x3174); > + epu_write(EPSMCR10, 0x6530); > + epu_write(EPSMCR9, 0x3000); > + epu_write(EPSMCR8, 0x6430); > + epu_write(EPSMCR7, 0x3000); > + epu_write(EPSMCR6, 0x7C00); > + epu_write(EPSMCR5, 0x2E00); > + epu_write(EPSMCR4, 0x002F); > + epu_write(EPSMCR3, 0x2F00); > + epu_write(EPSMCR2, 0x6C70); Where do these magic numbers come from? Which chips are they valid for? > +void fsl_dp_fsm_clean(void *dcsr_base) > +{ > + > + epu_write(EPEVTCR2, 0); > + epu_write(EPEVTCR9, 0); > + > + epu_write(EPGCR, 0); > + epu_write(EPECR15, 0); > + > + rcpm_write(CSTTACR0, 0); > + rcpm_write(CG1CR0, 0); > + > +} Don't put blank lines at the beginning/end of a block. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/9] fsl: add EPU FSM configuration for deep sleep
On Fri, 2014-03-07 at 12:58 +0800, Chenhui Zhao wrote: From: Hongbo Zhang hongbo.zh...@freescale.com In the last stage of deep sleep, software will trigger a Finite State Machine (FSM) to control the hardware precedure, such as board isolation, killing PLLs, removing power, and so on. When the system is waked up by an interrupt, the FSM controls the hardware to complete the early resume precedure. This patch configure the EPU FSM preparing for deep sleep. Signed-off-by: Hongbo Zhang hongbo.zh...@freescale.com Signed-off-by: Chenhui Zhao chenhui.z...@freescale.com Couldn't this be part of qoriq_pm.c? diff --git a/arch/powerpc/sysdev/fsl_soc.h b/arch/powerpc/sysdev/fsl_soc.h index 9b9a34a..eb83a30 100644 --- a/arch/powerpc/sysdev/fsl_soc.h +++ b/arch/powerpc/sysdev/fsl_soc.h @@ -69,5 +69,8 @@ extern const struct fsl_pm_ops *qoriq_pm_ops; extern int fsl_rcpm_init(void); +extern void fsl_dp_fsm_setup(void *dcsr_base); +extern void fsl_dp_fsm_clean(void *dcsr_base); __iomem + #endif #endif diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig index 09fde58..6539e6d 100644 --- a/drivers/platform/Kconfig +++ b/drivers/platform/Kconfig @@ -6,3 +6,7 @@ source drivers/platform/goldfish/Kconfig endif source drivers/platform/chrome/Kconfig + +if FSL_SOC +source drivers/platform/fsl/Kconfig +endif Chrome doesn't need an ifdef -- why does this? diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile index 3656b7b..37c6f72 100644 --- a/drivers/platform/Makefile +++ b/drivers/platform/Makefile @@ -6,3 +6,4 @@ obj-$(CONFIG_X86) += x86/ obj-$(CONFIG_OLPC) += olpc/ obj-$(CONFIG_GOLDFISH) += goldfish/ obj-$(CONFIG_CHROME_PLATFORMS) += chrome/ +obj-$(CONFIG_FSL_SOC)+= fsl/ diff --git a/drivers/platform/fsl/Kconfig b/drivers/platform/fsl/Kconfig new file mode 100644 index 000..72ed053 --- /dev/null +++ b/drivers/platform/fsl/Kconfig @@ -0,0 +1,10 @@ +# +# Freescale Specific Power Management Drivers +# + +config FSL_SLEEP_FSM + bool + help + This driver configures a hardware FSM (Finite State Machine) for deep sleep. + The FSM is used to finish clean-ups at the last stage of system entering deep + sleep, and also wakes up system when a wake up event happens. diff --git a/drivers/platform/fsl/Makefile b/drivers/platform/fsl/Makefile new file mode 100644 index 000..d99ca0e --- /dev/null +++ b/drivers/platform/fsl/Makefile @@ -0,0 +1,5 @@ +# +# Makefile for linux/drivers/platform/fsl +# Freescale Specific Power Management Drivers +# +obj-$(CONFIG_FSL_SLEEP_FSM) += sleep_fsm.o Why is this here while the other stuff is in arch/powerpc/sysdev? +/* Block offsets */ +#define RCPM_BLOCK_OFFSET 0x00022000 +#define EPU_BLOCK_OFFSET0x +#define NPC_BLOCK_OFFSET0x1000 Why don't these block offsets come from the device tree? +static void *g_dcsr_base; __iomem + /* Configure the EPU Counters */ + epu_write(EPCCR15, 0x9284); + epu_write(EPCCR14, 0x9284); + epu_write(EPCCR12, 0x9284); + epu_write(EPCCR11, 0x9284); + epu_write(EPCCR10, 0x9284); + epu_write(EPCCR9, 0x9284); + epu_write(EPCCR8, 0x9284); + epu_write(EPCCR5, 0x9284); + epu_write(EPCCR4, 0x9284); + epu_write(EPCCR2, 0x9284); + + /* Configure the SCUs Inputs */ + epu_write(EPSMCR15, 0x7600); + epu_write(EPSMCR14, 0x0031); + epu_write(EPSMCR13, 0x3100); + epu_write(EPSMCR12, 0x7F00); + epu_write(EPSMCR11, 0x3174); + epu_write(EPSMCR10, 0x6530); + epu_write(EPSMCR9, 0x3000); + epu_write(EPSMCR8, 0x6430); + epu_write(EPSMCR7, 0x3000); + epu_write(EPSMCR6, 0x7C00); + epu_write(EPSMCR5, 0x2E00); + epu_write(EPSMCR4, 0x002F); + epu_write(EPSMCR3, 0x2F00); + epu_write(EPSMCR2, 0x6C70); Where do these magic numbers come from? Which chips are they valid for? +void fsl_dp_fsm_clean(void *dcsr_base) +{ + + epu_write(EPEVTCR2, 0); + epu_write(EPEVTCR9, 0); + + epu_write(EPGCR, 0); + epu_write(EPECR15, 0); + + rcpm_write(CSTTACR0, 0); + rcpm_write(CG1CR0, 0); + +} Don't put blank lines at the beginning/end of a block. -Scott -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/