Re: [PATCH 2/2] pinctrl: add a generic control interface
On Thu, Oct 20, 2011 at 10:26:43AM -0700, Stephen Warren wrote:
> Shawn Guo wrote at Wednesday, October 19, 2011 8:32 PM:
> > On Wed, Oct 19, 2011 at 06:21:14PM +0200, Linus Walleij wrote:
> ...
> > > +int pin_config_group(struct pinctrl_dev *pctldev, const char *pin_group,
> > > + enum pin_config_param param, unsigned long data)
> ...
> > > +enum pin_config_param {
> > > + PIN_CONFIG_BIAS_UNKNOWN,
> > > + PIN_CONFIG_BIAS_FLOAT,
> > > + PIN_CONFIG_BIAS_HIGH_IMPEDANCE,
> > > + PIN_CONFIG_BIAS_PULL_UP,
> > > + PIN_CONFIG_BIAS_PULL_DOWN,
> > > + PIN_CONFIG_BIAS_HIGH,
> > > + PIN_CONFIG_BIAS_GROUND,
> > > + PIN_CONFIG_DRIVE_UNKNOWN,
> > > + PIN_CONFIG_DRIVE_PUSH_PULL,
> > > + PIN_CONFIG_DRIVE_OPEN_DRAIN,
> > > + PIN_CONFIG_DRIVE_OPEN_SOURCE,
> > > + PIN_CONFIG_DRIVE_OFF,
> > > + PIN_CONFIG_INPUT_SCHMITT,
> > > + PIN_CONFIG_SLEW_RATE_RISING,
> > > + PIN_CONFIG_SLEW_RATE_FALLING,
> > > + PIN_CONFIG_LOAD_CAPACITANCE,
> > > + PIN_CONFIG_WAKEUP_ENABLE,
> > > + PIN_CONFIG_END,
> > > +};
> >
> > IMO, trying to enumerate all possible pin_config options is just to
> > make everyone's life harder. Firstly, this enumeration is far from
> > completion, for imx6 iomuxc example, we have 3 options for pull-up,
> > 22, 47 and 100 kOhm, and 7 options for driver-strength, 34, 40, 48,
> > 60, 80, 120, and 240 Ohm. It's just so hard to make this enumeration
> > complete. Secondly, defining this param as enum requires the API
> > user to call the function multiple times to configure one pin. For
> > example, if I want to configure pin_foo as slow-slew, open-drain,
> > 100 kOhm pull-up and 120 Ohm driver-strength, I will have to call
> > pin_config(pctldev, pin_foo, ...) 4 times to achieve that.
> >
> > I like Stephen's idea about having 'u32 param' and let pinctrl drivers
> > to encode/decode this u32 for their pinctrl controller. It makes
> > people's life much easier.
>
> That's not quite what I meant.
>
> I meant that I thought the types for param and value should be simple
> integers, with meanings of the values defined by the individual drivers,
> rather than a system-defined enum.
>
> However, I wasn't envisaging packing multiple fields into the "value"
> parameter; that would essentially be packing a struct into a u32 for
> transport. I still figured that "param" would logically be an enum,
> and represent a single modifiable parameter, and "data"/"value" would
> be the single value of that one parameter.
>
Oops, I misread your idea. Reading it correctly, I do not like it
either :) It does not resolve my concern that we need to call the API
multiple times to configure one pin.
> Still, perhaps packing stuff is an option that makes sense in some cases,
I feel strongly that this is what we want.
> depending on what API we end up with to manipulate the parameters, and
> where the source of "data"/"value" is (encoded into client driver, or
> from some hidden table passed to pinmux core by board, with the values
> being passed directly to the pinmux drivers without the client drivers
> seeing them)
I do not think client drivers care about the parameters. For the mmc
example I put earlier, all it needs from pinctrl subsystem is "Hey,
I'm going to switch bus clock to a higher frequency 100 MHz, please
configure mmc pins properly for that."
--
Regards,
Shawn
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/2] pinctrl: add a generic control interface
On Thu, Oct 20, 2011 at 04:18:49PM +0200, Linus Walleij wrote: > On Thu, Oct 20, 2011 at 3:10 PM, Shawn Guo wrote: > > >> without the common definition from PIN_CONFIG_PULL to > >> PIN_CONFIG_USER, many platforms will need to definite them repeatedly. > >> that is what we hate. > >> > > I prefer to completely leave the encoding of this 'u32 param' to pinctrl > > drivers, so that they can map the bit definition of 'param' to the > > controller register as much as they can. On imx, we have one register > > accommodating all pin configuration options for one pin, so we can > > write 'param' directly into register with exactly same bit definition > > as register. > > I understand this argument, because it makes it more convenient to > write drivers and you can cut a few corners. > > However I would prefer to keep things more abstract, and the reason > is that we strive to have drivers reused across SoCs. For example > drivers/tty/serial/amba-pl011.c is used on a multitude of SoCs, > U300, Nomadik, Ux500, ARM Versatile, ARM Vexpress, LPC32XX > etc etc. > > What if this common driver suddenly need to bias a pin? Is it: > > #include > > ret = pin_config(pctldev, pin, PIN_CONFIG_BIAS_HIGH, 0); > > Or (OK silly example but you get the point): > > #include > > if (machine_is_u300()) > ret = pin_config(pctldev, pin, PIN_CONFIG_U300_BIAS_VDD, 0); > else if (machine_is_nomadik()) > ret = pin_config(pctldev, pin, PIN_CONFIG_NOMADIK_BIAS_UP, 0); > else if (machine_is_ux500()) > ret = pin_config(pctldev, pin, PIN_CONFIG_UX500_PULLHIGH, 0); > else if (machine_is_versatile()) > ret = pin_config(pctldev, pin, PIN_CONFIG_VERSATILE_POW, 0); > else if (machine_is_vexpress()) > ret = pin_config(pctldev, pin, PIN_CONFIG_VEXPRESS_XTRA, 0); > else if (machine_is_lpc32xx()) > ret = pin_config(pctldev, pin, PIN_CONFIG_LPC_SUPPLY, 0); > ... > > IMO we have enough strange and custom things in the kernel > already and we need to make things more abstract, not the least > so that people can understand what the code is doing. > To me, pin_config() and its parameters should be invisible to client drivers. For amba-pl011 example, do you think any of those SoCs will need multiple sets of uart pin configurations to switch for different working modes? If that's case, the individual SoC pinctrl driver should be responsible for mapping particular pin configuration to specific pl011 working mode. Otherwise, the amba-pl011 can simply call pinmux_enable(...) to have both mux and cfg set up. -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: request/suggestion to work together to get hardfp/OSS ARM GPU drivers and/or to get documentation
On Sat, October 22, 2011 3:52 pm, Konstantinos Margaritis wrote: > On 22 October 2011 16:17, Joop Boonen wrote: >> Hi all, >> >> Most of the (ARM) distros are currently working on or in the transition >> to >> hardfp, but until now most GPU's in de ARM Cortex SOCs don't have any >> hardfp drivers yet. >> >> To be able to have a ARM hardfp compiled X Window desktop >> system/notebook >> with 3D support we need hardfp compiled drivers. >> >> I was thinking it might be more efficient is all Linux distro's work >> together to get these drivers as it's equally important for all distro >> that wants to move to a hardfp distro. >> >> What do you all think, who wants to work together to get full hardfp >> support for as most as possible ARM SOC GPUs? >> >> It would be great if we can in the end even have OSS drivers. > > Hi, > > Nvidia was the first to release hardfp drivers for tegra2 gpus for > armhf, and we also have working drivers for hardfloat for the > Freescale i.MX51 and i.MX53 gpus, which we use on our current and > upcoming products (Genesi Smarttop/Smartbooks). It took a lot of time > and effort on our side to push for that, and obviously not for > technical reasons -it was just a 5 minute recompile of a binary static > library. I can imagine. I understood that the MX51 has a AMD Z430 GPU. Which has been renamed to Adreno 200 (AMD Z430), as Qualcomm bought the handheld graphics unit from AMD. http://en.wikipedia.org/wiki/Imageon So you probably have to go through FreeScale that might need approval from Qualcomm to build a hardfp driver. I understood that in the ARM SOC world the SOC producer is responsible for the video driver, which is very different from the PC world where the designer is delivers the driver (NVidia/AMD/Intel). > But in the end it was worth it. We're getting 15-20% increase > in performance on average -sometimes more- in our GLES benchmarks, and > we're working to squeeze more performance out of that -I'm currently > working on neon-optimizations in the GLES1 backend, which may not be > current, but it's still used by some important and very much needed > applications (i.e. quake3 :). > > So, the list is short right now, but that is the least of our > problems. The real problem is getting all of the kernel gpu drivers > into a single (mainline?Linaro?) kernel tree. The vendors are very > resistant in releasing specs or source code, and the kernel guys are > equally -if not more- resistant in accepting half-open/half-closed > drivers into the kernel tree. I think this is de to GPL, that why they only allow open source modules for the kernel. That's also why the proprietary kernel modules for NVidia and AMD are not in the standard kernel. > It's going to be a long road, but I > think that eventually we're getting there, unless of course a miracle > happens and all vendors simultaneously opensource their drivers :) I hope it will happen soon. It feels the time when NVidia and ATI didn't build any (3D) drivers for Linux. This slows down Linux development a lot and it'll limit that hardware you'll be able to use Linux on. > > Regards > > Konstantinos > > ___ > linaro-dev mailing list > linaro-dev@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev > Regards, Joop. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 1/7] clk: Add a generic clock infrastructure
Hi Mike,
Some random comments/nits ...
On Thu, Sep 22, 2011 at 03:26:56PM -0700, Mike Turquette wrote:
> +struct clk *clk_register(const struct clk_hw_ops *ops, struct clk_hw *hw,
> + const char *name)
> +{
> + struct clk *clk;
> +
> + clk = kzalloc(sizeof(*clk), GFP_KERNEL);
> + if (!clk)
> + return NULL;
> +
> + INIT_HLIST_HEAD(&clk->children);
> + INIT_HLIST_NODE(&clk->child_node);
> +
The children and child_node are introduced in patch #2, and should not
be used in patch #1.
> + clk->name = name;
> + clk->ops = ops;
> + clk->hw = hw;
> + hw->clk = clk;
> +
> + /* Query the hardware for parent and initial rate */
> +
> + if (clk->ops->get_parent)
> + /* We don't to lock against prepare/enable here, as
> + * the clock is not yet accessible from anywhere */
/*
* Multiple line comments
*/
> + clk->parent = clk->ops->get_parent(clk->hw);
> +
> + if (clk->ops->recalc_rate)
> + clk->rate = clk->ops->recalc_rate(clk->hw);
> +
> +
One blank line is good enough.
> + return clk;
> +}
--
Regards,
Shawn
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 2/7] clk: Implement clk_set_rate
On Thu, Sep 22, 2011 at 03:26:57PM -0700, Mike Turquette wrote: > From: Jeremy Kerr > > Implement clk_set_rate by adding a set_rate callback to clk_hw_ops. > Rates are propagated down the clock tree and recalculated. Also adds a > flag for signaling that parents must change rates to achieve the desired > frequency (upstream propagation). > > TODO: > Upstream propagation is not yet implemented. > Device pre-change and post-change notifications are not implemented, but > are marked up as FIXME comments. > > Signed-off-by: Jeremy Kerr > Signed-off-by: Mark Brown > Signed-off-by: Mike Turquette > --- > Changes since v1: > Remove upstream propagation (for now) > Rename CLK_SET_RATE_PROPAGATE to CLK_PARENT_RATE_CHANGE [...] > + * @set_rate Change the rate of this clock. If this callback returns > + * CLK_SET_RATE_PROPAGATE, the rate change will be propagated to s/CLK_SET_RATE_PROPAGATE/CLK_PARENT_RATE_CHANGE, as suggested by your change log above? > + * the parent clock (which may propagate again). The requested > + * rate of the parent is passed back from the callback in the > + * second 'unsigned long *' argument. > + * -- Regards, Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 3/7] clk: Add fixed-rate clock
On Thu, Sep 22, 2011 at 03:26:58PM -0700, Mike Turquette wrote:
> From: Jeremy Kerr
>
> Signed-off-by: Jeremy Kerr
> Signed-off-by: Mark Brown
> Signed-off-by: Mike Turquette
> ---
> Changes since v1:
> Add copyright header
>
> drivers/clk/Kconfig |4
> drivers/clk/Makefile|1 +
> drivers/clk/clk-fixed.c | 24
> include/linux/clk.h | 14 ++
> 4 files changed, 43 insertions(+), 0 deletions(-)
> create mode 100644 drivers/clk/clk-fixed.c
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index c53ed59..d8313d7 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -8,3 +8,7 @@ config HAVE_MACH_CLKDEV
>
> config GENERIC_CLK
> bool
> +
> +config GENERIC_CLK_FIXED
> + bool
> + depends on GENERIC_CLK
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 570d5b9..9a3325a 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -1,3 +1,4 @@
>
> obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o
> obj-$(CONFIG_GENERIC_CLK)+= clk.o
> +obj-$(CONFIG_GENERIC_CLK_FIXED) += clk-fixed.o
> diff --git a/drivers/clk/clk-fixed.c b/drivers/clk/clk-fixed.c
> new file mode 100644
> index 000..956fb9a
> --- /dev/null
> +++ b/drivers/clk/clk-fixed.c
> @@ -0,0 +1,24 @@
> +/*
> + * Copyright (C) 2010-2011 Canonical Ltd
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * Simple fixed-rate clock implementation
> + */
> +
> +#include
> +#include
> +
> +#define to_clk_fixed(c) container_of(c, struct clk_hw_fixed, hw)
> +
> +static unsigned long clk_fixed_recalc_rate(struct clk_hw *hw)
> +{
> + return to_clk_fixed(hw)->rate;
> +}
> +
> +struct clk_hw_ops clk_fixed_ops = {
> + .recalc_rate = clk_fixed_recalc_rate,
> +};
> +EXPORT_SYMBOL_GPL(clk_fixed_ops);
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 0d2cd5e..1903dd8 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -110,6 +110,20 @@ int clk_prepare(struct clk *clk);
> */
> void clk_unprepare(struct clk *clk);
>
> +/* Base clock implementations. Platform clock implementations can use these
> + * directly, or 'subclass' as approprate */
> +
/*
* Multiple lines comments
*/
Regards,
Shawn
> +#ifdef CONFIG_GENERIC_CLK_FIXED
> +
> +struct clk_hw_fixed {
> + struct clk_hw hw;
> + unsigned long rate;
> +};
> +
> +extern struct clk_hw_ops clk_fixed_ops;
> +
> +#endif /* CONFIG_GENERIC_CLK_FIXED */
> +
> /**
> * clk_register - register and initialize a new clock
> *
> --
> 1.7.4.1
>
>
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 1/7] clk: Add a generic clock infrastructure
On Sun, Oct 23, 2011 at 5:55 AM, Shawn Guo wrote: > Hi Mike, > > Some random comments/nits ... Thanks for reviewing Shawn. Will roll changes into V3. Regards, Mike ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 2/7] clk: Implement clk_set_rate
On Sun, Oct 23, 2011 at 7:24 AM, Shawn Guo wrote: > On Thu, Sep 22, 2011 at 03:26:57PM -0700, Mike Turquette wrote: >> From: Jeremy Kerr > [...] > >> + * @set_rate Change the rate of this clock. If this callback returns >> + * CLK_SET_RATE_PROPAGATE, the rate change will be propagated to > > s/CLK_SET_RATE_PROPAGATE/CLK_PARENT_RATE_CHANGE, as suggested by your > change log above? Thanks for reviewing. Will roll into V3 patchset. Regards, Mike > >> + * the parent clock (which may propagate again). The requested >> + * rate of the parent is passed back from the callback in the >> + * second 'unsigned long *' argument. >> + * > > -- > Regards, > Shawn > > ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 3/7] clk: Add fixed-rate clock
On Sun, Oct 23, 2011 at 7:30 AM, Shawn Guo wrote: > On Thu, Sep 22, 2011 at 03:26:58PM -0700, Mike Turquette wrote: >> From: Jeremy Kerr >> +/* Base clock implementations. Platform clock implementations can use these >> + * directly, or 'subclass' as approprate */ >> + > /* > * Multiple lines comments > */ Thanks for the review Shawn. Will roll into V3 patchset. Regards, Mike > Regards, > Shawn ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Final 11.10 Android Release Candidate Images
Due to ELC-E the Android team has been working hard to get its RC out and tested. The following Images are available for the 11.10 release: https://android-build.linaro.org/builds/~linaro-android/tracking-panda-11.10-release/#build=5, 4460, panda https://android-build.linaro.org/builds/~linaro-android/staging-panda-11.10-release/#build=4, 4460, panda https://android-build.linaro.org/builds/~linaro-android/panda-11.10-release/#build=2, 4460, panda https://android-build.linaro.org/builds/~linaro-android/beagle-11.10-release/#build=4, beagle beagle xM https://android-build.linaro.org/builds/~linaro-android/staging-snowball-11.10-release/#build=7 https://android-build.linaro.org/builds/~linaro-android/landing-snowball-11.10-release/#build=5 https://android-build.linaro.org/builds/~linaro-android/staging-origen-11.10-release/#build=5 https://android-build.linaro.org/builds/~linaro-android/staging-imx53-11.10-release/#build=4 The test results are here: https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AnpUtxWjZbP9dGFDUk5kNXBoeWZDb3MyUmJ4cnBHTEE&hl=en_US&pli=1#gid=0 The 11.10 bug summary is here: https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AnpUtxWjZbP9dGFDUk5kNXBoeWZDb3MyUmJ4cnBHTEE&hl=en_US&pli=1#gid=1 There are a bunch of great things in these builds, one of which is USB camera support. Plug a camera in, boot and launch the Camera app! Enjoy! -- Zach Pfeffer Android Platform Team Lead, 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: [PATCH] drivers: create a pin control subsystem v8
On Tue, Oct 4, 2011 at 16:35, Grant Likely wrote: > On Sat, Oct 01, 2011 at 12:39:21PM +0200, Linus Walleij wrote: >> 2011/9/30 Grant Likely: >> > I'm not convinced that the sysfs approach is >> > actually the right interface here (I'm certainly not a fan of the gpio >> > sysfs i/f), and I'd rather not be putting in unneeded stuff until the >> > userspace i/f is hammered out. >> >> Actually, thinking about it I cannot see what would be wrong >> with /dev/gpio0 & friends in the first place. >> >> Using sysfs as swiss army knife for custom I/O does not >> seem like it would be long-term viable so thanks for this >> observation, and I think we need /dev/gpio* put on some >> mental roadmap somewhere. > > Agreed. I don't want to be in the situation we are now with GPIO, > where every time I look at the sysfs interface I shudder. the problem with that is it doesn't scale. if i have a device with over 150 GPIOs on the SoC itself (obviously GPIO expanders can make that much bigger), i don't want to see 150+ device nodes in /dev/. that's a pretty big waste. sysfs only allocates/frees resources when userspace actually wants to utilize a GPIO. -mike ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Epic Battle and substantial speed ups with Skia on 4.6
On 10/22/2011 01:31 PM, Ramana Radhakrishnan wrote: > > > On Sat, 22 Oct 2011, Zach Pfeffer wrote: > >> After an epic battle the tips of each Android build are ready to be >> released. >> >> >> skia: Add -ffast-math, -flto >> http://review.android.git.linaro.org/#change,773 > > Good to see that ffast-math is making a difference at O3 but how does > this affect your benchmarking activity ? Do we know why this difference > occurs ? Is this because of extra vectorization for Floating point in > skia or some other reason ? > > Also, I'm sure you've considered this but I thought it better to check. > > Given that the benchmarking pages plot skia results - > https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-09#skia_results > > > a double check that this doesn't result in there being a spike in the > results for 2011.10 would be good. If not, historical data needs to be > measured for this change given that the said options weren't used while > measuring the historical data. Neither the 2011.09 nor the soon to be published 2011.10 benchmarking was done using these flags. I'm not sure if I'll have the cycles to try this out this month or not. However, I'll add this to next month's testing. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Epic Battle and substantial speed ups with Skia on 4.6
On 23 October 2011 20:48, Andy Doan wrote: > On 10/22/2011 01:31 PM, Ramana Radhakrishnan wrote: >> >> >> On Sat, 22 Oct 2011, Zach Pfeffer wrote: >> >>> After an epic battle the tips of each Android build are ready to be >>> released. >>> >>> >>> skia: Add -ffast-math, -flto >>> http://review.android.git.linaro.org/#change,773 >> >> Good to see that ffast-math is making a difference at O3 but how does >> this affect your benchmarking activity ? Do we know why this difference >> occurs ? Is this because of extra vectorization for Floating point in >> skia or some other reason ? >> >> Also, I'm sure you've considered this but I thought it better to check. >> >> Given that the benchmarking pages plot skia results - >> https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-09#skia_results >> >> >> a double check that this doesn't result in there being a spike in the >> results for 2011.10 would be good. If not, historical data needs to be >> measured for this change given that the said options weren't used while >> measuring the historical data. > > Neither the 2011.09 nor the soon to be published 2011.10 benchmarking > was done using these flags. I'm not sure if I'll have the cycles to try > this out this month or not. However, I'll add this to next month's testing. Cool. Thanks Andy! -- Zach Pfeffer Android Platform Team Lead, 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
