Re: [PATCH v4 4/7] cpufreq: add clk-reg cpufreq driver
On Mon, Dec 26, 2011 at 09:44:52PM +0800, Richard Zhao wrote: > On Mon, Dec 26, 2011 at 11:10:30AM +, Mark Brown wrote: > > The *call* is there in the regulator subsystem, it's just that none of > > the drivers back it up with an actual implementation yet. Which turns > > out to be a good thing as cpufreq can't currently understand variable > > latencies and the governors don't deal well with non-trivial latencies > > anyway. > but clk API don't have such calls. and many SoCs only adjust clk frequencies, > using > one single voltage. That's because it's often not known - especially in the case of PLLs, data sheets don't tend to specify how long it takes for the PLL to relock after a requested change. If it's important that the PLL be locked, there will be a bit to poll (or they'll cause the CPU itself to stall while the PLL is not locked.) So, for these kinds of situations, how do you suggest that the clk API provides this information? ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: snowball does not compile on linux-next
On Tue, Jan 03, 2012 at 08:19:37AM +0100, Linus Walleij wrote: > On Mon, Jan 2, 2012 at 4:25 PM, Christian Robottom Reis > wrote: > > On Mon, Jan 02, 2012 at 01:59:10PM +0100, Linus Walleij wrote: > >> On Mon, Jan 2, 2012 at 12:49 PM, Daniel Lezcano > >> wrote: > >> > >> > the kernel does not compile when > >> > CONFIG_CLKSRC_DBX500_PRCMU_SCHED_CLOCK is set. > > > > Should this be in our default configs, or one of our tested configs, so > > we can catch this in a CI loop? > > It should be in the defconfig already, the problem showed up > for Daniel exactly because it was configured in. Okay, then the question is what do we need to do to make a box go red and have people notified when it breaks? -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH V4 0/5] ARM: exynos: Add l2 retention mode cpuidle state
amit kachhap wrote: > > Hi Mr kim, > > All the comments have been addressed for the Exynos cpu idle patchset. > The updated patchset was posted about one month back and there have > been no further comments on the patchset since then. > > As this patchset seems to be stable now, do you think these these > patches can merged in this 3.3 merge window? Kindly let me know your > opinion. > This conflicts with local common.[ch] working for ARM restart. Please wait until after the merge window for this patches. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 4/7] cpufreq: add clk-reg cpufreq driver
Hi Russel, On 3 January 2012 17:06, Russell King - ARM Linux wrote: > On Mon, Dec 26, 2011 at 09:44:52PM +0800, Richard Zhao wrote: >> On Mon, Dec 26, 2011 at 11:10:30AM +, Mark Brown wrote: >> > The *call* is there in the regulator subsystem, it's just that none of >> > the drivers back it up with an actual implementation yet. Which turns >> > out to be a good thing as cpufreq can't currently understand variable >> > latencies and the governors don't deal well with non-trivial latencies >> > anyway. >> but clk API don't have such calls. and many SoCs only adjust clk >> frequencies, using >> one single voltage. > > That's because it's often not known - especially in the case of PLLs, > data sheets don't tend to specify how long it takes for the PLL to relock > after a requested change. If it's important that the PLL be locked, > there will be a bit to poll (or they'll cause the CPU itself to stall > while the PLL is not locked.) > > So, for these kinds of situations, how do you suggest that the clk API > provides this information? In latest v6 version, I get clk transition latency from dt property, and get regulator transition latency from regulator API. Could you please help review other arm common changes in v6 version? Thanks Richard ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 4/7] cpufreq: add clk-reg cpufreq driver
On Tue, Jan 03, 2012 at 09:25:30PM +0800, Richard Zhao wrote: > Hi Russel, > > On 3 January 2012 17:06, Russell King - ARM Linux > wrote: > > On Mon, Dec 26, 2011 at 09:44:52PM +0800, Richard Zhao wrote: > >> On Mon, Dec 26, 2011 at 11:10:30AM +, Mark Brown wrote: > >> > The *call* is there in the regulator subsystem, it's just that none of > >> > the drivers back it up with an actual implementation yet. Which turns > >> > out to be a good thing as cpufreq can't currently understand variable > >> > latencies and the governors don't deal well with non-trivial latencies > >> > anyway. > >> but clk API don't have such calls. and many SoCs only adjust clk > >> frequencies, using > >> one single voltage. > > > > That's because it's often not known - especially in the case of PLLs, > > data sheets don't tend to specify how long it takes for the PLL to relock > > after a requested change. If it's important that the PLL be locked, > > there will be a bit to poll (or they'll cause the CPU itself to stall > > while the PLL is not locked.) > > > > So, for these kinds of situations, how do you suggest that the clk API > > provides this information? > In latest v6 version, I get clk transition latency from dt property, and get > regulator transition latency from regulator API. > Could you please help review other arm common changes in v6 version? You didn't get my point: how do you specify a clock transition latency for a clock with a PLL when the data sheets don't tell you what that is, and they instead give you a bit to poll? Do you: (a) make up some number and hope that it's representative (b) not specify any transition latency (c) think about the problem _now_ and define what it means for a clock without a transition latency. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 4/7] cpufreq: add clk-reg cpufreq driver
On 3 January 2012 21:47, Russell King - ARM Linux wrote: > On Tue, Jan 03, 2012 at 09:25:30PM +0800, Richard Zhao wrote: >> Hi Russel, >> >> On 3 January 2012 17:06, Russell King - ARM Linux >> wrote: >> > On Mon, Dec 26, 2011 at 09:44:52PM +0800, Richard Zhao wrote: >> >> On Mon, Dec 26, 2011 at 11:10:30AM +, Mark Brown wrote: >> >> > The *call* is there in the regulator subsystem, it's just that none of >> >> > the drivers back it up with an actual implementation yet. Which turns >> >> > out to be a good thing as cpufreq can't currently understand variable >> >> > latencies and the governors don't deal well with non-trivial latencies >> >> > anyway. >> >> but clk API don't have such calls. and many SoCs only adjust clk >> >> frequencies, using >> >> one single voltage. >> > >> > That's because it's often not known - especially in the case of PLLs, >> > data sheets don't tend to specify how long it takes for the PLL to relock >> > after a requested change. If it's important that the PLL be locked, >> > there will be a bit to poll (or they'll cause the CPU itself to stall >> > while the PLL is not locked.) >> > >> > So, for these kinds of situations, how do you suggest that the clk API >> > provides this information? >> In latest v6 version, I get clk transition latency from dt property, and get >> regulator transition latency from regulator API. >> Could you please help review other arm common changes in v6 version? > > You didn't get my point: how do you specify a clock transition latency > for a clock with a PLL when the data sheets don't tell you what that is, > and they instead give you a bit to poll? clk-trans-latency is not a MUST property. If the datasheet don't provide it or you don't want to measure, you may not specify the property. In such case cpufreq governor ondemand and conservative will not work, because they can not determine the sample rate without the latency value. > > Do you: > > (a) make up some number and hope that it's representative No, I always get it from dt. > (b) not specify any transition latency It's allowed. > (c) think about the problem _now_ and define what it means for a clock > without a transition latency. It's ondemand/conservative governors that strongly need the latency value. If user don't want to use it, it's fine. Thanks Richard ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 4/7] cpufreq: add clk-reg cpufreq driver
On Tue, Jan 03, 2012 at 01:47:09PM +, Russell King - ARM Linux wrote: > On Tue, Jan 03, 2012 at 09:25:30PM +0800, Richard Zhao wrote: > > In latest v6 version, I get clk transition latency from dt property, and get > > regulator transition latency from regulator API. > > Could you please help review other arm common changes in v6 version? > You didn't get my point: how do you specify a clock transition latency > for a clock with a PLL when the data sheets don't tell you what that is, > and they instead give you a bit to poll? I'd rather suspect you'll find there are actually specs for these things but they're hidden in the electrical characteristics which don't tend to go into the published datasheets (though ). Not useful if we don't actually see them though. > Do you: > (a) make up some number and hope that it's representative > (b) not specify any transition latency These are the traditional approaches, pioneered by essentially every existing cpufreq driver (well, "make up" is a bit harsh - usually the numbers are measured, though possibly only on a limited set of systems). > (c) think about the problem _now_ and define what it means for a clock > without a transition latency. This would be nice, in both the clock and cpufreq code (the cpufreq code is pretty limited here in that it assumes an equal transition latency for all transitions which isn't the case usually). You can generally do something useful with measurement, probably we can arrange to measure the times we're seeing on the actua system or something. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [lm-sensors] [RFC PATCH 2/3] thermal: exynos4: Register the tmu sensor with the thermal interface layer
On Wed, 2011-12-21 at 06:59 -0500, Amit Daniel Kachhap wrote:
> Export and register information from the hwmon tmu sensor to the samsung
> exynos kernel thermal framework where different cooling devices and thermal
> zone are binded. The exported information is based according to the data
> structure thermal_sensor_conf present in exynos_thermal.h. HWMON sysfs
> functions are currently left although all of them are present in generic
> linux thermal layer.
> Also the platform data structure is modified to pass frequency cooling
> in percentages for each thermal level.
>
Hi Amit,
wouldn't it make more sense to merge the code as necessary from
hwmon/exynos4_tmu.c into the new thermal/exynos_thermal.c, and drop
hwmon/exynos4_tmu.c entirely ?
With that, you should get the hwmon entries for free, and we would not
have to maintain two drivers with overlapping functionality.
Thanks,
Guenter
> Signed-off-by: Amit Daniel Kachhap
> ---
> drivers/hwmon/exynos4_tmu.c | 34 ++--
> include/linux/platform_data/exynos4_tmu.h |7 ++
> 2 files changed, 38 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hwmon/exynos4_tmu.c b/drivers/hwmon/exynos4_tmu.c
> index f2359a0..6912a7f 100644
> --- a/drivers/hwmon/exynos4_tmu.c
> +++ b/drivers/hwmon/exynos4_tmu.c
> @@ -37,6 +37,9 @@
> #include
>
> #include
> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
> +#include
> +#endif
>
> #define EXYNOS4_TMU_REG_TRIMINFO 0x0
> #define EXYNOS4_TMU_REG_CONTROL 0x20
> @@ -248,10 +251,13 @@ static void exynos4_tmu_work(struct work_struct *work)
>
> kobject_uevent(&data->hwmon_dev->kobj, KOBJ_CHANGE);
>
> - enable_irq(data->irq);
>
> clk_disable(data->clk);
> mutex_unlock(&data->lock);
> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
> + exynos4_report_trigger();
> +#endif
> + enable_irq(data->irq);
> }
>
> static irqreturn_t exynos4_tmu_irq(int irq, void *id)
> @@ -345,6 +351,14 @@ static const struct attribute_group
> exynos4_tmu_attr_group = {
> .attrs = exynos4_tmu_attributes,
> };
>
> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
> +static struct thermal_sensor_conf exynos4_sensor_conf = {
> + .name = "exynos4-therm",
> + .read_temperature = (int (*)(void *))exynos4_tmu_read,
> +};
> +#endif
> +/*CONFIG_SAMSUNG_THERMAL_INTERFACE*/
> +
> static int __devinit exynos4_tmu_probe(struct platform_device *pdev)
> {
> struct exynos4_tmu_data *data;
> @@ -432,9 +446,20 @@ static int __devinit exynos4_tmu_probe(struct
> platform_device *pdev)
> }
>
> exynos4_tmu_control(pdev, true);
> -
> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
> + (&exynos4_sensor_conf)->private_data = data;
> + (&exynos4_sensor_conf)->sensor_data = pdata;
> + ret = exynos4_register_thermal(&exynos4_sensor_conf);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to register thermal interface\n");
> + goto err_hwmon_device;
> + }
> +#endif
> return 0;
> -
> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
> +err_hwmon_device:
> + hwmon_device_unregister(data->hwmon_dev);
> +#endif
> err_create_group:
> sysfs_remove_group(&pdev->dev.kobj, &exynos4_tmu_attr_group);
> err_clk:
> @@ -458,6 +483,9 @@ static int __devexit exynos4_tmu_remove(struct
> platform_device *pdev)
>
> exynos4_tmu_control(pdev, false);
>
> +#ifdef CONFIG_SAMSUNG_THERMAL_INTERFACE
> + exynos4_unregister_thermal();
> +#endif
> hwmon_device_unregister(data->hwmon_dev);
> sysfs_remove_group(&pdev->dev.kobj, &exynos4_tmu_attr_group);
>
> diff --git a/include/linux/platform_data/exynos4_tmu.h
> b/include/linux/platform_data/exynos4_tmu.h
> index 39e038c..642c508 100644
> --- a/include/linux/platform_data/exynos4_tmu.h
> +++ b/include/linux/platform_data/exynos4_tmu.h
> @@ -21,6 +21,7 @@
>
> #ifndef _LINUX_EXYNOS4_TMU_H
> #define _LINUX_EXYNOS4_TMU_H
> +#include
>
> enum calibration_type {
> TYPE_ONE_POINT_TRIMMING,
> @@ -64,6 +65,9 @@ enum calibration_type {
> * in the positive-TC generator block
> * 0 <= reference_voltage <= 31
> * @cal_type: calibration type for temperature
> + * @freq_pctg_table: Table representing frequency reduction percentage.
> + * @freq_tab_count: Count of the above table as frequency reduction may
> + * applicable to only some of the trigger levels.
> *
> * This structure is required for configuration of exynos4_tmu driver.
> */
> @@ -79,5 +83,8 @@ struct exynos4_tmu_platform_data {
> u8 reference_voltage;
>
> enum calibration_type cal_type;
> +
> + struct freq_pctg_table freq_tab[4];
> + unsigned int freq_tab_count;
> };
> #endif /* _LINUX_EXYNOS4_TMU_H */
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] omap: use usleep_range() instead of mdelay()/udelay()
Dmitry Antipov writes:
> From e4db974edb5c46360465462518a88b83f1bdedf6 Mon Sep 17 00:00:00 2001
> From: Dmitry Antipov
> Date: Wed, 21 Dec 2011 10:57:08 +0400
> Subject: [PATCH] omap: use usleep_range() instead of mdelay()/udelay()
Please include a signoff and a descriptive changelog (describing why.)
Thanks,
Kevin
> ---
> arch/arm/mach-omap2/omap_phy_internal.c |2 +-
> arch/arm/mach-omap2/vc.c|2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
> b/arch/arm/mach-omap2/omap_phy_internal.c
> index 58775e3..e5dff64 100644
> --- a/arch/arm/mach-omap2/omap_phy_internal.c
> +++ b/arch/arm/mach-omap2/omap_phy_internal.c
> @@ -145,7 +145,7 @@ int omap4430_phy_suspend(struct device *dev, int suspend)
> /* power on the phy */
> if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) & PHY_PD) {
> __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
> - mdelay(200);
> + usleep_range(20, 201000);
> }
>
> /* restore the context */
> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
> index 031d116..57f44d5 100644
> --- a/arch/arm/mach-omap2/vc.c
> +++ b/arch/arm/mach-omap2/vc.c
> @@ -151,7 +151,7 @@ void omap_vc_post_scale(struct voltagedomain *voltdm,
> /* SMPS slew rate / step size. 2us added as buffer. */
> smps_delay = ((smps_steps * voltdm->pmic->step_size) /
> voltdm->pmic->slew_rate) + 2;
> - udelay(smps_delay);
> + usleep_range(smps_delay, smps_delay + 10);
> }
>
> /* vc_bypass_scale - VC bypass method of voltage scaling */
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v4 3/6] clk: introduce the common clock framework
On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
> On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixner wrote:
> > On Tue, 13 Dec 2011, Mike Turquette wrote:
> >> +void __clk_unprepare(struct clk *clk)
> >> +{
> >> + if (!clk)
> >> + return;
> >> +
> >> + if (WARN_ON(clk->prepare_count == 0))
> >> + return;
> >> +
> >> + if (--clk->prepare_count > 0)
> >> + return;
> >> +
> >> + WARN_ON(clk->enable_count > 0);
> >
> > So this leaves the clock enable count set. I'm a bit wary about
> > that. Shouldn't it either return (including bumping the prepare_count
> > again) or call clk_disable() ?
>
> I've hit this in my port of OMAP. It comes from this simple situation:
>
> driver 1 (adapted for clk_prepare/clk_unprepare):
> clk_prepare(clk);
> clk_enable(clk);
>
> ...
>
> driver2 (not adapted for clk_prepare/clk_unprepare):
> clk_enable(clk);
>
> ...
>
> driver1:
> clk_disable(clk);
> clk_unprepare(clk);
>
> In such a case we don't want to bump the prepare_count, since the
> offending driver2 won't decrement that count. Also we don't want to
> shut down that clk since driver2 is using it.
>
> Returning after the WARN is maybe OK, but the point of this check is
> really to find code which hasn't yet been made prepare-aware, and the
> current implementation is noisy enough about it.
>
> >> +/**
> >> + * clk_get_parent - return the parent of a clk
> >> + * @clk: the clk whose parent gets returned
> >> + *
> >> + * Simply returns clk->parent. It is up to the caller to hold the
> >> + * prepare_lock, if desired. Returns NULL if clk is NULL.
> >
> > Holding the prepare lock in the caller will deadlock. So it's not a
> > real good idea to document it as an option :)
>
> Oops. That comment is left over from before clk_get_parent held the
> lock. Will remove.
>
> >
> >> + */
> >> +struct clk *clk_get_parent(struct clk *clk)
> >> +{
> >> + struct clk *parent;
> >> +
> >> + if (!clk)
> >> + return NULL;
> >> +
> >> + mutex_lock(&prepare_lock);
> >
> >> +/**
> >> + * clk_init - initialize the data structures in a struct clk
> >> + * @dev: device initializing this clk, placeholder for now
> >> + * @clk: clk being initialized
> >> + *
> >> + * Initializes the lists in struct clk, queries the hardware for the
> >> + * parent and rate and sets them both. Adds the clk to the sysfs tree
> >> + * topology.
> >> + *
> >> + * Caller must populate clk->name and clk->flags before calling
> >
> > I'm not too happy about this construct. That leaves struct clk and its
> > members exposed to the world instead of making it a real opaque
> > cookie. I know from my own painful experience, that this will lead to
> > random fiddling in that data structure in drivers and arch code just
> > because the core code has a shortcoming.
> >
> > Why can't we make struct clk a real cookie and confine the data
> > structure to the core code ?
> >
> > That would change the init call to something like:
> >
> > struct clk *clk_init(struct device *dev, const struct clk_hw *hw,
> > struct clk *parent)
> >
> > And have:
> > struct clk_hw {
> > struct clk_hw_ops *ops;
> > const char *name;
> > unsigned long flags;
> > };
> >
> > Implementers can do:
> > struct my_clk_hw {
> > struct clk_hw hw;
> > mydata;
> > };
> >
> > And then change the clk ops callbacks to take struct clk_hw * as an
> > argument.
We have to define static clocks before we adopt DT binding.
If clk is opaque and allocate memory in clk core, it'll make hard
to define static clocks. And register/init will pass a long parameter
list.
> >
> > So the core code can allocate the clk data structure and you return a
> > real opaque cookie. You do the same thing for the basic gated clock in
> > one of the next patches, so doing it for struct clk itself is just
> > consequent.
>
> The opaque cookie would work if platform code never needs any
> information outside of the data a single clk_hw_whatever provides.
> Unfortunately hardware doesn't make things that easy on us and the
> operations we do for a single clk are affected by the state of other
> clks.
>
> Here is an example I've been using a lot lately: on OMAP we have two
> clock inputs to our PLLs: a bypass clk and reference clk (actually we
> can have more than this). When changing the PLL rate both clks must
> be enabled, regardless of which clk ends up driving the PLL. To
> illustrate, the PLL may be driven by clk_ref at 400MHz, and then we
> call clk_set_rate(pll_clk, 19600); which will also leave it
> clocked by clk_ref but at 196MHz. For this to happen however, the
> clk_bypass had to be enabled during the rate change operation. Here
> is the relevant .set_rate implementation:
> http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=blob;f=arch/arm/mach-omap2/dpll3xxx.c;h=b2412574b63829944593c1a7a6eda5fa4350686f;hb=738bde65918ae1ac743b1498801da0b860e2ee32#l461
>
Re: snowball does not compile on linux-next
On Tue, Jan 3, 2012 at 7:20 AM, Christian Robottom Reis wrote: > On Tue, Jan 03, 2012 at 08:19:37AM +0100, Linus Walleij wrote: > > On Mon, Jan 2, 2012 at 4:25 PM, Christian Robottom Reis > wrote: > > > On Mon, Jan 02, 2012 at 01:59:10PM +0100, Linus Walleij wrote: > > >> On Mon, Jan 2, 2012 at 12:49 PM, Daniel Lezcano > > >> wrote: > > >> > > >> > the kernel does not compile when > > >> > CONFIG_CLKSRC_DBX500_PRCMU_SCHED_CLOCK is set. > > > > > > Should this be in our default configs, or one of our tested configs, so > > > we can catch this in a CI loop? > > > > It should be in the defconfig already, the problem showed up > > for Daniel exactly because it was configured in. > It doesn't seem to be one of the currently tested configs - it sounds like it should be added though (infrastructure added to cc list). > Okay, then the question is what do we need to do to make a box go red > and have people notified when it breaks? > The box would go red if it were tested, but the mechanisms for registering, subscribing to, and getting notifications on events does not yet exist so it would require someone to check for things like this. It's on our radar as something that needs to be added. Thanks, Paul Larson ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [PATCH V2 2/2] Exynos: Fix ARM Clock frequency calculation
Dear Chander Kashyap, On 19 December 2011 17:56, Chander Kashyap wrote: > Earliar ARM clock frequency was calculated by: > MOUTAPLL/(DIVAPLL + 1) which is actually returning SCLKAPLL. > It is fixed by calculating it as follows: > ARMCLK=MOUTCORE / (DIVCORE + 1) / (DIVCORE2 + 1) > > Signed-off-by: Chander Kashyap > --- > Changes for V2: > - Fixed commit comment > - Fixed comment in clock.c "exynos4_get_arm_clk ()" > - Renamed dout_apll to armclk in clock.c "exynos4_get_arm_clk ()" > arch/arm/cpu/armv7/exynos/clock.c | 15 +-- > 1 files changed, 9 insertions(+), 6 deletions(-) > applied to u-boot-samsung. Thanks, Minkyu Kang. -- from. prom. www.promsoft.net ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [PATCH V2 1/2] Exynos: PWM: Add TCMPB3 field in pwm structure
Dear Chander Kashyap, On 19 December 2011 17:56, Chander Kashyap wrote: > Add TCMPB3 field in pwm structure, earliar this was res1. > > Signed-off-by: Chander Kashyap > --- > arch/arm/include/asm/arch-exynos/pwm.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > applied to u-boot-samsung. Thanks,Minkyu Kang.-- from. prom. www.promsoft.net ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: snowball does not compile on linux-next
Hello Linus, On Wed, Jan 4, 2012 at 9:37 AM, Paul Larson wrote: > On Tue, Jan 3, 2012 at 7:20 AM, Christian Robottom Reis > wrote: > >> On Tue, Jan 03, 2012 at 08:19:37AM +0100, Linus Walleij wrote: >> > On Mon, Jan 2, 2012 at 4:25 PM, Christian Robottom Reis < >> k...@linaro.org> wrote: >> > > On Mon, Jan 02, 2012 at 01:59:10PM +0100, Linus Walleij wrote: >> > >> On Mon, Jan 2, 2012 at 12:49 PM, Daniel Lezcano >> > >> wrote: >> > >> >> > >> > the kernel does not compile when >> > >> > CONFIG_CLKSRC_DBX500_PRCMU_SCHED_CLOCK is set. >> > > >> > > Should this be in our default configs, or one of our tested configs, >> so >> > > we can catch this in a CI loop? >> > If we need a build to be set up on ci.linaro.org I could do that for you. Please file a bug for the same @ https://bugs.launchpad.net/linaro-ci. Refer to the instructions @ https://wiki.linaro.org/Platform/Infrastructure/LinaroCIQuickReference when for creating a new CI job. > > >> > It should be in the defconfig already, the problem showed up >> > for Daniel exactly because it was configured in. >> > It doesn't seem to be one of the currently tested configs - it sounds like > it should be added though (infrastructure added to cc list). > > >> Okay, then the question is what do we need to do to make a box go red >> and have people notified when it breaks? >> > The box would go red if it were tested, but the mechanisms for > registering, subscribing to, and getting notifications on events does not > yet exist so it would require someone to check for things like this. It's > on our radar as something that needs to be added. > > Thanks, > Paul Larson > -- Thanks and Regards, Deepti Infrastructure Team Member, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [U-Boot] [PATCH] Origen: Select SCLKMPLL as FIMD0 parent clock
Dear Chander Kashyap, On 19 December 2011 15:16, Chander Kashyap wrote: > Signed-off-by: Chander Kashyap > --- > board/samsung/origen/lowlevel_init.S | 5 + > board/samsung/origen/origen_setup.h | 12 > 2 files changed, 17 insertions(+), 0 deletions(-) > applied to u-boot-samsung. Thanks, Minkyu Kang. -- from. prom. www.promsoft.net ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
