date:20110902

On Fri, Sep 2, 2011 at 9:02 AM, Stijn Devriendt high...@gmail.com wrote:
 On Fri, Aug 19, 2011 at 11:53 AM, Linus Walleij
 linus.wall...@stericsson.com wrote:

 +       if (desc-mux_requested) {
 +               pr_err(pin already requested\n);
 +               goto out;
 +       }

 Isn't locking missing here?

You're right, I have now introduced a spinlock to the pin descriptor
and take that before reading or writing descriptor fields like this.

Thanks!
Linus Walleij

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 1/4 v5] drivers: create a pin control subsystem v5

On Thu, Sep 1, 2011 at 9:43 PM, Stephen Warren swar...@nvidia.com wrote:

 Looking forward a little, I expect that different SoCs have such a
 different set of biasing/driver-strength/... options that actually having
 some formalized semantic representation of what those options are doesn't
 make sense; all we need is a standard API to set the values for a given
 pin or pingroup;

I'm still thinking about this thing, when I (and others) wer trying to
shoehorn this kind of stuff into the GPIO layer I actually started to
enumerate the different things you could do with a pin, beginning
like this:

+/*
+ * Bias modes for GPIOs - if you have more biases, add them here or provide
+ * custom enumerators for your driver if you find they are not generally
+ * useful.
+ *
+ * GPIO_CONFIG_BIAS_UNKNOWN: this bias mode is not known to us
+ * GPIO_CONFIG_BIAS_FLOAT: no specific bias, the GPIO will float or state
+ * is not controlled by software
+ * GPIO_CONFIG_BIAS_PULL_UP: the GPIO will be pulled up (usually with high
+ * impedance to VDD)
+ * GPIO_CONFIG_BIAS_PULL_DOWN: the GPIO will be pulled down (usually with high
+ * impedance to GROUND)
+ * GPIO_BIAS_HIGH: the GPIO will be wired high, connected to VDD
+ * GPIO_BIAS_GROUND: the GPIO will be grounded, connected to GROUND
+ */
+#define GPIO_CONFIG_BIAS_UNKNOWN   0x1000
+#define GPIO_CONFIG_BIAS_FLOAT 0x1001
+#define GPIO_CONFIG_BIAS_PULL_UP   0x1002
+#define GPIO_CONFIG_BIAS_PULL_DOWN 0x1003
+#define GPIO_CONFIG_BIAS_HIGH  0x1004
+#define GPIO_CONFIG_BIAS_GROUND0x1005
+
+/*
+ * Drive modes for GPIOs (output) - if you have more custom modes either
+ * add them here or keep them to your driver if you think they are not
+ * generally useful.
+ *
+ * GPIO_CONFIG_DRIVE_UNKNOWN: we don't know the drive mode of this GPIO, for
+ * example since it is controlled by hardware or the information is not
+ * accessible but we need a meaningful enumerator in e.g. initialization
+ * code
+ * GPIO_CONFIG_DRIVE_PUSH_PULL: the GPIO will be driven actively high and
+ * low, this is the most typical case and is typically achieved with two
+ * active transistors on the output
+ * GPIO_CONFIG_DRIVE_OPEN_DRAIN: the GPIO will be driven with open drain (open
+ * collector) which means it is usually wired with other output ports
+ * which are then pulled up with an external resistor
+ * GPIO_CONFIG_DRIVE_OPEN_SOURCE: the GPIO will be driven with open drain
+ * (open emitter) which is the same as open drain mutatis mutandis but
+ * pulled to ground
+ * GPIO_CONFIG_DRIVE_OFF: the GPIO pin is set to inactive mode, off
+ */
+#define GPIO_CONFIG_DRIVE_UNKNOWN  0x2010
+#define GPIO_CONFIG_DRIVE_PUSH_PULL0x2011
+#define GPIO_CONFIG_DRIVE_OPEN_DRAIN   0x2012
+#define GPIO_CONFIG_DRIVE_OPEN_SOURCE  0x2013
+#define GPIO_CONFIG_DRIVE_OFF  0x2014

The basic assumption is that there are not that infinitely many
things you may want to do with a pin after all.

I can already think about interesting enumerators for
GPIO_CONFIG_INPUT_SCHMITT_TRIGGER
GPIO_CONFIG_INPUT_LOAD_CAPACITANCE
etc. But not unenumerable things.

The upside of this scheme is that we might have some handle on
trying to consolidate common functionality between drivers,
also to sort of consolidate the knowledge of what you can
do with pins in one place, even if you can't share any code.

For a stupid example the generic debugfs files could give you a list
of all pins in any system and what bias mode they're in, no
matter what platform we're dealing with, which would give the
some kind of cosy consensus for developers that platforms
are not that different after all.

Yours,
Linus Walleij

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [U-Boot] [PATCH] s5p-mmc: Fix ambiguous setting of data transfer width

2011-09-02 Thread Minkyu Kang

Dear Wolfgang Denk,

On 1 September 2011 14:51, Wolfgang Denk w...@denx.de wrote:
 Dear Minkyu Kang,

 In message 
 calrbrz3h+k8bu-1owf5c5bnhuphj_j8jxxv2xgu6jpo5gmj...@mail.gmail.com you 
 wrote:

  I know these were like this before, but those numbers are awfully
  magical. You should really define constants for them.

 We decided to use comments instead of defines.

 And now we ask you to fix this, because we don;t want such magic
 constants.  So please go on and change this.


OK.

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: [PATCH 2/4 v6] pinmux: add a driver for the U300 pinmux

On Thu, Sep 1, 2011 at 11:33 PM, Stephen Warren swar...@nvidia.com wrote:

 +static const struct u300_pmx_func u300_pmx_functions[] = {
 +     {
 +             .name = power,
 +             .groups = { POWERGRP_INDEX },
 +             /* Mask is N/A */
 +     },

 Hmmm. That's a lot of _INDEX defines that'd need to be set up, at least
 to fully represent a chip like Tegra. Can the pinmux core be modified
 such that the group list is an array of names (char*) rather than the
 actual numeric IDs of the groups? Still, perhaps we could use the enum
 we already have for this, so perhaps it isn't a big deal...

Well I could think about a lot of ways to do this, but it's basically up
to the driver, the U300 is just some simple example of what you can
do, it's just trying to satisfy the API.

Maybe as part of writing the nVidia driver you find a clever
mechanism for doing this, if it's looking generally useful at that
point then let's move it to the core I'd say.

Thanks,
Linus Walleij

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 1/4 v4] drivers: create a pin control subsystem

2011-09-02 Thread Stijn Devriendt

On Fri, Aug 19, 2011 at 11:53 AM, Linus Walleij
linus.wall...@stericsson.com wrote:
 +
 +/**
 + * pin_request() - request a single pin to be muxed in, typically for GPIO
 + * @pin: the pin number in the global pin space
 + * @function: a functional name to give to this pin, passed to the driver
 + *     so it knows what function to mux in, e.g. the string gpioNN
 + *     means that you want to mux in the pin for use as GPIO number NN
 + * @gpio: if this request concerns a single GPIO pin
 + */
 +static int pin_request(struct pinctrl_dev *pctldev,
 +                      int pin, const char *function, bool gpio)
 +{
 +       struct pin_desc *desc;
 +       const struct pinmux_ops *ops;
 +       int status = -EINVAL;
 +
 +       pr_debug(request pin %d for %s\n, pin, function);
 +
 +       if (!pin_is_valid(pctldev, pin)) {
 +               pr_err(pin is invalid\n);
 +               return -EINVAL;
 +       }
 +
 +       if (!function) {
 +               pr_err(no function name given\n);
 +               return -EINVAL;
 +       }
 +
 +       desc = pin_desc_get(pctldev, pin);
 +       if (desc == NULL) {
 +               pr_err(pin is not registered so it cannot be requested\n);
 +               goto out;
 +       }
 +       if (desc-mux_requested) {
 +               pr_err(pin already requested\n);
 +               goto out;
 +       }

Isn't locking missing here?

 +       ops = pctldev-desc-pmxops;
 +
 +       /* Let each pin increase references to this module */
 +       if (!try_module_get(pctldev-owner)) {
 +               pr_err(could not increase module refcount for pin %d\n, 
 pin);
 +               status = -EINVAL;
 +               goto out;
 +       }
 +
 +       /*
 +        * If there is no kind of request function for the pin we just assume
 +        * we got it by default and proceed.
 +        */
 +       if (gpio  ops-gpio_request_enable)
 +               /* This requests and enables a single GPIO pin */
 +               status = ops-gpio_request_enable(pctldev, pin);
 +       else if (ops-request)
 +               status = ops-request(pctldev, pin);
 +       else
 +               status = 0;
 +
 +       if (status) {
 +               pr_err(-request on device %s failed 
 +                      for pin %d\n,
 +                      pctldev-desc-name, pin);
 +               goto out;
 +       }
 +
 +       desc-mux_requested = true;
 +       strncpy(desc-mux_function, function, sizeof(desc-mux_function));
 +
 +out:
 +       if (status)
 +               pr_err(pin-%d (%s) status %d\n,
 +                      pin, function ? : ?, status);
 +
 +       return status;
 +}
 +

Regards,
Stijn

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: 11.08 Pre-built Images

2011-09-02 Thread David Gilbert

On 2 September 2011 05:35, Anca Emanuel anca.eman...@gmail.com wrote:
 Is there an tutorial to install qemu in ubuntu and run some linaro image ?

 I want to test it.

I'm not aware of a tutorial;

You can grab the latest qemu-linaro release from:

https://launchpad.net/qemu-linaro/+download

If you just want to test with running an image then I would configure with

./configure --target-list=arm-softmmu

The easiest image to test with is the Overo image; so if you grab the
prebuilt image
from:

http://releases.linaro.org/images/linaro-n/ubuntu-desktop/11.08/overo-ubuntu-desktop.img.gz

decompress it and then do something like:

./arm-softmmu/qemu-system-arm -M overo -m 256 -serial
telnet::,server -drive
file=overo-ubuntu-desktop.img,if=sd,cache=writeback -device usb-kbd
-device usb-mouse

Then in another terminal do a

telnet localhost 

That should get you the serial console; if you didn't have SDL then
you'll have to connect using vnc:

vncviewer localhost:0


Note that the Overo is a bit low on RAM for the full desktop image, so
it's a bit slow, but it's the easiest combination to get going.

Dave

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Fwd: Would you send me your hard float experiment results you presented in Budapest?

Steve,

I'd like you to meet Jim who did the initial hardfloat work. This
email contains the results that Jim produced.

I believe that the conclusion was that skia and webkit may benefit,
but that such benefits would impose an undue burden on Android's
distribution model which tries to create libs that can run on as many
architectures as possible.

-Zach


-- Forwarded message --
From: Jim Huang js...@0xlab.org
Date: 7 August 2011 18:01
Subject: Re: Would you send me your hard float experiment results you
presented in Budapest?
To: Zach Pfeffer zach.pfef...@linaro.org


2011/8/7 Zach Pfeffer zach.pfef...@linaro.org:
 Jim,

 Thanks. Would it be possible to post them by the end of the day?

skia -

   Switch from VFP back to fixed scalar based calculation

   Previous configuration enabled ARM VFP for scalar float, but VFP on
   ARM11 is not as powerful as VFPv3 or NEON.

   Reference benchmark:
   Item            Fixed based     VFP-based
       ---     -
   Draw Canvas     58.37 fps       58.40 fps
   Draw Circle     37.48 fps       22.93 fps
   Draw Circle2    17.14 fps       18.31 fps
   Draw Rect       17.62 fps       20.69 fps
   Draw Arc        24.79 fps       27.45 fps
   Draw Image      19.08 fps       18.73 fps
   Draw Text       29.22 fps       25.79 fps



 Also, have you sync'd up with Mike? He wants to negotiate on your contract.

I sent mail to Mike already.  I don't know how to proceed.

Thanks,
-jserv
 message/external-body; access-type=x-mutt-deleted;	expiration="Fri, 2 Sep 2011 11:15:26 +0200"; length=663213: Unrecognized 


NOTE
Description: Binary data
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [Request] Can Linaro-dev not send duplicate mail to recipients?

2011-09-02 Thread Loïc Minier

On Thu, Sep 01, 2011, Christian Robottom Reis wrote:
 On Wed, Aug 31, 2011 at 09:05:55PM -0700, John Stultz wrote:
  It seems the linaro-dev list isn't configed to avoid mailing folks who
  are already recipients of the email. So if you're on linaro-dev and
  you're also To/CC'ed in the email, you get it twice (three times if your
  other work email was CC'ed as well, but that cannot be helped).

 Someone else already told you about your personal mailing-list settings
 to avoid multiple copies of messages; I wanted to add that the default
 config on linaro-dev@ has always been for copies to be discarded by
 default.

 You might be getting copies from other lists though (e.g. I get bug
 updates from launchpad and from launchpad team mailing-lists), which
 you can confirm by looking at the List-Id header or at the Received
 headers.  The big hammer is filtering copies out yourself as others
 have suggested (procmail's formail -D is one example).

 I know this is controversial, but I really like that pattern. It ensures
 that I filter messages that are directly to me specially, while the rest
 just goes into a lower priority archive folder.

 (same here; mailing-list traffic is kept in folders and mail directed
 to me in a different one)

-- 
Loïc Minier

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH] RFCv2: video support for dri2 (Rob Clark)

2011-09-02 Thread Christian König

Hi Rob,

  + flipping between multiple back buffers, perhaps not in order (to
handle video formats with B-frames)
Oh, yes please. The closed source drivers seems to do this also all the
time, and I never really understood why DRI is limiting the buffers to
the OGL attachment points.

...

 Current solutions use the GPU to do a scaled/colorconvert into a DRI2
 buffer from the client context.  The goal of this protocol change is
 to push the decision to use overlay or GPU blit to the xorg driver.
You left one corner case out, HDMI allows for the framebuffer to be in
YUV 4:4:4 format. So it is possible to send YUV data to the display
(usually a TV) without color conversion at all, but I think with the
current state of X we are years away from that.

...

 In many cases, an overlay will avoid several passes through memory
 (blit/scale/colorconvert to DRI back-buffer on client side, blit to
 front and fake-front, and then whatever compositing is done by the
 window manager).  On the other hand, overlays can often be handled
 directly by the scanout engine in the display hardware, with the GPU
 switched off.
Actually AMD has thrown out the hardware support for overlay with the
R7xx (or was it evergreen?) series, because they got support for turning
shader pipes off separately and figured out that it use less power to
turn off all shaders except one and then use this one for color
conversion and scaling, compared to having a distinct hardware block
doing the job. But there are tendencies to get a distinct color
conversion block back again.

...

 Note: video is not exactly the same as 3d, there are a number of other
 things to consider (scaling, colorconvert, multi-planar formats).  But
 on the other hand the principle is similar (direct rendering from hw
 video codecs).  And a lot infrastructure of connection, authentication,
 is same.  So there are two options, either extend DRI2 or add a new
 protocol which duplicates some parts.  I'd like to consider extending
 DRI2 first, but if people think the requirements for video are too
 much different from 3d, then I could split this into a new protocol.
If you ask me extending things seems the better way to do this.

..

 @@ -184,6 +185,11 @@ DRI2ATTACHMENT { DRI2BufferFrontLeft
   These values describe various attachment points for DRI2
   buffers.
  
 + In the case of video driver (DRI2DriverXV) the attachment,
 + other than DRI2BufferFrontLeft, just indicates buffer
 + number and has no other special significance.  There is no
 + automatic maintenance of DRI2BufferFakeFrontLeft.
I think that will created compatibility problems with existing
implementations, because the DDX side doesn't know if it's talking to a
video or 3D client side.

...

 + The XV_OSD attribute specifies the XID of a pixmap containing
 + ARGB data to be non-destructively overlayed over the video.  This
 + could be used to implement subtiles, on-screen-menus, etc.
Why an XID? I'm not 100% sure about it, but using a DRI buffer name
directly here seems to be the better alternative.

  Are you targeting/limiting this to a particular API (or the customary
  limitations of overlay HW)? I ask because VDPAU allows clients to pass
  in an arbitrary colour conversion matrix rather than color
  standard/hue/sat/bri/con, so it wouldn't be possible to use this in
  that context.
 
 Ideally it would something that could be used either from
 device-dependent VDPAU or VAAPI driver back-end, or something that
 could be used in a generic way, for example GStreamer sink element
 that could be used with software codecs.
AFAIK DRI mostly isn't a device driver dependent protocol, and the
client side doesn't necessary know to which hardware it is talking, just
look at how gallium 3D is working, talking with X over the DRI protocol
is part of the driver independent state tracker, and NOT part of the
driver itself.

So having this driver independent is just a must have, and not optional.

 Well, this is the goal anyways.  There is one slight other
 complication for use in a generic way..  it would need to be a bit
 better defined what the buffer 'name' is, so that the client side
 would know how to interpret it, mmap it if needed.  But I think there
 is a solution brewing:
 http://lists.linaro.org/pipermail/linaro-mm-sig/2011-August/000509.html

That's indeed true, but currently it is the only parameter that must be
interpreted in a driver dependent fashion. And I really think it should
stay that way.

 As far as color conversion matrix... well, the attribute system can
 have arbitrary device-dependent attributes.  In the VDPAU case, I
 suppose the implementation on the client side knows which xorg driver
 it is talking to, and could introduce it's own attributes.  Perhaps a
 bit awkward for communicating a matrix, but you could in theory have
 4*3 different attributes (ie. XV_M00, XV_M01, ... XV_M23) for each
 entry in the matrix.
Yes, but you should define that clearly in the

Re: Would you send me your hard float experiment results you presented in Budapest?

2011-09-02 Thread David Rusling

Zach,
you'd need to use multiarch and have multiple installed libraries so 
that you could support both hard and soft float ABI.   Does Android do anything 
different / interesting in its image / shared library loader(s)?
Dave

On 30 Aug 2011, at 17:24, Zach Pfeffer wrote:

 Steve,
 
 I'd like you to meet Jim who did the initial hardfloat work. This
 email contains the results that Jim produced.
 
 I believe that the conclusion was that skia and webkit may benefit,
 but that such benefits would impose an undue burden on Android's
 distribution model which tries to create libs that can run on as many
 architectures as possible.
 
 -Zach
 
 
 -- Forwarded message --
 From: Jim Huang js...@0xlab.org
 Date: 7 August 2011 18:01
 Subject: Re: Would you send me your hard float experiment results you
 presented in Budapest?
 To: Zach Pfeffer zach.pfef...@linaro.org
 
 
 2011/8/7 Zach Pfeffer zach.pfef...@linaro.org:
 Jim,
 
 Thanks. Would it be possible to post them by the end of the day?
 
 skia -
 
Switch from VFP back to fixed scalar based calculation
 
Previous configuration enabled ARM VFP for scalar float, but VFP on
ARM11 is not as powerful as VFPv3 or NEON.
 
Reference benchmark:
ItemFixed based VFP-based
--- -
Draw Canvas 58.37 fps   58.40 fps
Draw Circle 37.48 fps   22.93 fps
Draw Circle217.14 fps   18.31 fps
Draw Rect   17.62 fps   20.69 fps
Draw Arc24.79 fps   27.45 fps
Draw Image  19.08 fps   18.73 fps
Draw Text   29.22 fps   25.79 fps
 
 
 
 Also, have you sync'd up with Mike? He wants to negotiate on your contract.
 
 I sent mail to Mike already.  I don't know how to proceed.
 
 Thanks,
 -jserv
 Mail AttachmentNOTE___
 linaro-dev mailing list
 linaro-dev@lists.linaro.org
 http://lists.linaro.org/mailman/listinfo/linaro-dev


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 3/3] ARM: EXYNOS4: Add support for 8-bit bus width in SDHCI for ORIGEN

2011-09-02 Thread Tushar Behera


On Wednesday 31 August 2011 06:31 AM, Kukjin Kim wrote:

Tushar Behera wrote:


Platform data for SDHCI controller on ORIGEN board is missing the
support for 8-bit bus width. The platform data is extended in sync
with other EXYNOS4 machines.

Signed-off-by: Tushar Beheratushar.beh...@linaro.org
---
  arch/arm/mach-exynos4/mach-origen.c |8 
  1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/mach-origen.c

b/arch/arm/mach-exynos4/mach-

origen.c
index ae18812..6b6cd77 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -75,11 +75,19 @@ static struct s3c2410_uartcfg origen_uartcfgs[]

__initdata =

{
  static struct s3c_sdhci_platdata origen_hsmmc0_pdata __initdata = {
.cd_type= S3C_SDHCI_CD_INTERNAL,
.clk_type   = S3C_SDHCI_CLK_DIV_EXTERNAL,
+#ifdef CONFIG_EXYNOS4_SDHCI_CH0_8BIT
+   .max_width  = 8,
+   .host_caps  = MMC_CAP_8_BIT_DATA,
+#endif
  };

  static struct s3c_sdhci_platdata origen_hsmmc2_pdata __initdata = {
.cd_type= S3C_SDHCI_CD_INTERNAL,
.clk_type   = S3C_SDHCI_CLK_DIV_EXTERNAL,
+#ifdef CONFIG_EXYNOS4_SDHCI_CH2_8BIT
+   .max_width  = 8,
+   .host_caps  = MMC_CAP_8_BIT_DATA,
+#endif
  };

  static struct platform_device *origen_devices[] __initdata = {
--
1.7.4.1


Hi Tushar,

I wonder the bus width of SDHCI controller can be changed manually on ORIGEN
like SMDK board.


Thanks for your review.

On ORIGEN board, we have wire connections for HSMMC-0/2/3 between the 
MMC port and the SoC. Hence ideally we can work with HSMMC2 in both 
4-bit and 8-bit mode. However HSMMC0 can only work in 4-bit mode.


Also IIRC WLAN would be using HSMMC-3 controller for its operations. So 
we would have conflict when HSMMC2 is working in 8-bit mode and WLAN is 
also enabled. Hence it appears better to drop this patch now.



Thanks.

Best regards,
Kgene.
--
Kukjin Kimkgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.


--
Tushar Behera

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 0/4] dmaeninge/ste_dma40: bug fixes for 3.1

2011-09-02 Thread Vinod Koul

On Mon, 2011-08-29 at 13:33 +0200, Per Forlin wrote:
 Started off fixing a memory leak due to not freed dma descriptors
 in mmci. The descriptor allocated at device_prep...(), not submitted,
 isn't freed at dmaeninge_terminate_all() or dmaengine_release().
 While sorting this one out some other issues were found as well.
 * kernel doc missing
 * duplication of d40_pool_lli_free()
 * free of client descriptor triggers an oops.
 
 Per Forlin (4):
   dmaengine/ste_dma40: add missing kernel doc for pending_queue
   dmaengine/ste_dma40: remove duplicate call to d40_pool_lli_free().
   dmaengine/ste_dma40: fix Oops due to double free of client descriptor
   dmaengine/ste_dma40: fix memory leak due to prepared descriptors
 
  drivers/dma/ste_dma40.c |   42 +-
  1 files changed, 29 insertions(+), 13 deletions(-)
 
Applied, Thanks

-- 
~Vinod


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: 11.07 oprofile on panda busted?

2011-09-02 Thread Avik Sil

On Wednesday 31 August 2011 08:26 PM, Dave Martin wrote:
 On Thu, Aug 25, 2011 at 04:48:57PM -0500, Tom Gall wrote:
 Hi all,

 Say has anyone else run oprofile on recent builds on panda?

 By recent I mean say anything since 11.07? Reason for asking is I'm
 seeing basically a very very small number of samples being recorded...
  as in there's no way this is right.
 
 These days, I believe the separate oprofile backend for ARM has gone
 away, and oprofile is implemented using the perf backend anyway.
 
 So, perhaps a more interesting question is: does perf work?
 
 See whether this works:
 
 apt-get install linux-linaro-tools-`uname -r`
 perf stat apt-get update  # or something
 
 
 I think there was an issue with a patch which enabled perf on omap4
 but broke it on all other platforms.  This patch is present in the
 linux-linaro-natty tree, but I can't see it in -oneiric.  I think
 it may have been dropped / backed out from the oneiric tree because
 of the problems it caused:
 
 In linux-linaro-natty/master:
 commit 457520e3fbce80812c6901c226ec242fdb906c63
 (arm: pmu: support pmu/perf on OMAP4)

The perf patch was dropped from linux-linaro-2.6.39 onwards as it
apparently caused Panda boot hang
(https://bugs.launchpad.net/linux-linaro/+bug/802693).
 
 Mark Rutland posted a patch to fix the introduced problem --
 search the linaro-dev archives for
 [PATCH] Fix NULL-dereference introduced by OMAP4 PMU patch
 
 
 ...however, I don't know whether or not this is still relevant.
 
 
 
 If perf works but oprofile doesn't, that's a separate problem and
 should be investigated.  You might want to consider switching to
 perf anyway though -- in my experience it's less problem-prone
 than using oprofile.
 
 Cheers
 ---Dave
 
 

Regards,
Avik

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Code review request.

2011-09-02 Thread Vishal Bhoj

Hi,


Bluetooth is working now on pandaboard now.I could scan and pair with my
phone.I have not tried file transfer yet.

These are multiple commits to gerrit to enable  single feature i.e bluetooth
on pandaboard.

 I had question, Can we commit multiple projects into gerrit in a single
commit so that review would be easy ?

http://review.android.git.linaro.org/#change,139
http://review.android.git.linaro.org/#change,140
http://review.android.git.linaro.org/#change,141
http://review.android.git.linaro.org/#change,142



Thanks and Regards,
Vishal
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Code review request.

2011-09-02 Thread Alexander Sack

On Fri, Sep 2, 2011 at 2:06 PM, Vishal Bhoj vishal.b...@linaro.org wrote:

 Hi,


 Bluetooth is working now on pandaboard now.I could scan and pair with my
 phone.I have not tried file transfer yet.


Thats really great news Vishal. Well done!



 These are multiple commits to gerrit to enable  single feature i.e
 bluetooth on pandaboard.

  I had question, Can we commit multiple projects into gerrit in a single
 commit so that review would be easy ?


I thought thats possible. Now waiting for an answer as well :)


-- 

 - Alexander
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Code review request.

2011-09-02 Thread Paul Sokolovsky

Hello Vishal,

On Fri, 2 Sep 2011 17:36:54 +0530
Vishal Bhoj vishal.b...@linaro.org wrote:

[]
  I had question, Can we commit multiple projects into gerrit in a
 single commit so that review would be easy ?

Some people wonder if that possible at all either, but Zach said he did
it once ;-). So, up to you to try (but please post instructions if you
figure it out).

 
 http://review.android.git.linaro.org/#change,139
 http://review.android.git.linaro.org/#change,140
 http://review.android.git.linaro.org/#change,141
 http://review.android.git.linaro.org/#change,142
 
 
 
 Thanks and Regards,
 Vishal



-- 
Best Regards,
Paul

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 1/4 v6] drivers: create a pin control subsystem v6

Thanks Stephen,

we really make progress now, thanks to your eternal patience with
me :-)

On Thu, Sep 1, 2011 at 11:17 PM, Stephen Warren swar...@nvidia.com wrote:

 I want to check one thing: A given pin can be in multiple pin groups at
 once. This will be important when biasing/... is added, since Tegra will
 then having 2 sets of overlapping pin groups that cover all/most pins;
 one set for muxing and one for biasing etc. Each pin will be in one of
 the mux groups and one of the bias groups. I'm pretty sure this is the
 case, but just wanted to double-check.

Yes any pin can be in any number of pin groups.

 As you already acknowledge, one missing feature is handling multiple map
 entries for each pinmux_get()/enable().

It'll be in v7 I hope.

 The only thing pinmux allows you to do with the GPIO ranges are
 request_gpio and free_gpio. Some thoughts:

 * These only exist to prevent an explosion in the number of functions. I
 don't think we need these APIs to avoid this; see my discussion below.

 * These APIs don't work in the same way as mapping table entries; what
 if switching a controller between two sets of pins also required
 using a different GPIO; I might want to put the equivalent of
 request_gpio and free_gpio into the mapping table. This can only be done
 if we represent GPIOs as just another function, rather than special-
 casing them.

I actually think this usecase will work, as long as these two GPIO
controllers use different ranges in the global GPIO pin space (and
Grant say they should IIRC).

The pinmux core will map the pin to the matching range and pass
it to the driver in this callback:

int (*gpio_request_enable) (struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *range,
unsigned offset);

By checking which range you got you know which chip
you want to mux in on the given offset. It's true that this
is orthogonal to other functions however.

 * If we get rid of the GPIO APIs, we can then get rid of the GPIO ranges
 too, which cuts out a lot of code.

That is true.

 I would imagine treating GPIOs as just another function. I'll repeat
 some text I wrote previously (https://lkml.org/lkml/2011/8/26/298) about
 how I see this working:

SW For reference, here's how I'd imagine modeling those three cases in
SW pinmux (all based on my earlier comments about the data model I imagine,
SW rather than what's currently in the pinmux patches):

SW 1) Have a single function gpio that can be applied to any pin that
SW supports it. The actual GPIO number that gets mux'd onto the pin differs
SW per pin, and is determine by HW design. But logically, we're connecting
SW that pin to function gpio, so we only need one function name for that.

 So here, the only issue is that if GPIO can be assigned per pin, we'd
 need to define a pingroup per pin, even if we had a set of other groups
 for muxing. (And a pin would have to be in its per-pin pingroup, and
 mux group, which goes back to my very first comment above.) I suppose this
 might end up being a lot of pingroups. However, this is all data, and
 it seems like having large data is better than having large code? Still,
 these per-pin groups might end up existing for other functionality like
 biasing anyway, depending on HW.

Hm I have a hard time figuring out how that code would look...
I'm worried that the drivers could get pretty hard to read.

SW 2) Have a function for each GPIO controller that can be attached to a
SW pin; gpioa or gpiob. Based on the pin being configured, and which of
SW those two GPIO functions is selected, the HW determines the specific GPIO
SW number that's assigned to the pin.

SW 3) Where the GPIO ID assigned to pins is user-selectable, have a function
SW per GPIO ID; gpio1, gpio2, gpio3, ... gpio31. This sounds like
SW it'd cause a huge explosion in the number of functions; one to represent
SW each GPIO ID. However, I suspect this won't be too bad in practice, since
SW there's presumably some practical limit to the amount of muxing logic that
SW can be applied to each pin in HW, so the set of options won't be too large.

 In https://lkml.org/lkml/2011/8/29/74, it sounded like you weren't averse
 to the idea of treating GPIOs like any other function.

Right now I have resorted to the diplomatic solution of actually
supporting both.

pinmux_request_gpio() will request a gpio pin named
gpioN where N is the global GPIO number.

This fragment from pinmux.c sort of specifies it:

if (gpio  ops-gpio_request_enable)
/* This requests and enables a single GPIO pin */
status = ops-gpio_request_enable(pctldev, gpio_range, pin);
else if (ops-request)
status = ops-request(pctldev, pin);
else
status = 0;

So if the driver doesn't implement the quick -gpio_request_enable()
the second else-clause will attempt to get the function gpioN.

So if the driver just wants to

Re: [PATCH] RFCv2: video support for dri2 (Rob Clark)

2011-09-02 Thread Alex Deucher

2011/9/2 Christian König deathsim...@vodafone.de:
 Hi Rob,

  + flipping between multiple back buffers, perhaps not in order (to
    handle video formats with B-frames)
 Oh, yes please. The closed source drivers seems to do this also all the
 time, and I never really understood why DRI is limiting the buffers to
 the OGL attachment points.

 ...

 Current solutions use the GPU to do a scaled/colorconvert into a DRI2
 buffer from the client context.  The goal of this protocol change is
 to push the decision to use overlay or GPU blit to the xorg driver.
 You left one corner case out, HDMI allows for the framebuffer to be in
 YUV 4:4:4 format. So it is possible to send YUV data to the display
 (usually a TV) without color conversion at all, but I think with the
 current state of X we are years away from that.

 ...

 In many cases, an overlay will avoid several passes through memory
 (blit/scale/colorconvert to DRI back-buffer on client side, blit to
 front and fake-front, and then whatever compositing is done by the
 window manager).  On the other hand, overlays can often be handled
 directly by the scanout engine in the display hardware, with the GPU
 switched off.
 Actually AMD has thrown out the hardware support for overlay with the
 R7xx (or was it evergreen?) series, because they got support for turning
 shader pipes off separately and figured out that it use less power to
 turn off all shaders except one and then use this one for color
 conversion and scaling, compared to having a distinct hardware block
 doing the job. But there are tendencies to get a distinct color
 conversion block back again.

The overlays are still there, but the old video overlay (with scaling
and format conversion) was removed for r5xx.  The current overlays are
just overlay planes and mostly there for things like GL overlays.  You
could use them for video, but you'd need to do the scaling and format
conversion in the 3D engine.

Alex

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH] RFCv2: video support for dri2 (Rob Clark)

2011-09-02 Thread Michel Dänzer

On Fre, 2011-09-02 at 12:04 +0200, Christian König wrote: 
 
   + flipping between multiple back buffers, perhaps not in order (to
 handle video formats with B-frames)
 Oh, yes please. The closed source drivers seems to do this also all the
 time, and I never really understood why DRI is limiting the buffers to
 the OGL attachment points.

Probably because DRI2 was designed mainly with GL direct rendering in
mind.


  Note: video is not exactly the same as 3d, there are a number of other
  things to consider (scaling, colorconvert, multi-planar formats).  But
  on the other hand the principle is similar (direct rendering from hw
  video codecs).  And a lot infrastructure of connection, authentication,
  is same.  So there are two options, either extend DRI2 or add a new
  protocol which duplicates some parts.  I'd like to consider extending
  DRI2 first, but if people think the requirements for video are too
  much different from 3d, then I could split this into a new protocol.
 If you ask me extending things seems the better way to do this.

Probably, though I'm not sure it's a good idea to extend existing DRI2
protocol requests. Even if it's theoretically possible, it'll probably
be much easier and less problematic to add new requests instead.


   Are you targeting/limiting this to a particular API (or the customary
   limitations of overlay HW)? I ask because VDPAU allows clients to pass
   in an arbitrary colour conversion matrix rather than color
   standard/hue/sat/bri/con, so it wouldn't be possible to use this in
   that context.
  
  Ideally it would something that could be used either from
  device-dependent VDPAU or VAAPI driver back-end, or something that
  could be used in a generic way, for example GStreamer sink element
  that could be used with software codecs.
 AFAIK DRI mostly isn't a device driver dependent protocol, and the
 client side doesn't necessary know to which hardware it is talking, just
 look at how gallium 3D is working, talking with X over the DRI protocol
 is part of the driver independent state tracker, and NOT part of the
 driver itself.
 
 So having this driver independent is just a must have, and not optional.

Well, what's implemented in the Gallium DRI state tracker is just a de
facto standard which works with the current X drivers. The intention was
certainly for this to be opaque at the DRI2 protocol level. Once there
is divergence between how drivers handle this, the Gallium DRI state
tracker will probably need to grow some kind of driver specific hooks
for this.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH] RFCv2: video support for dri2 (Rob Clark)

2011-09-02 Thread Rob Clark

2011/9/2 Christian König deathsim...@vodafone.de:
 Hi Rob,

  + flipping between multiple back buffers, perhaps not in order (to
    handle video formats with B-frames)
 Oh, yes please. The closed source drivers seems to do this also all the
 time, and I never really understood why DRI is limiting the buffers to
 the OGL attachment points.

 ...

 Current solutions use the GPU to do a scaled/colorconvert into a DRI2
 buffer from the client context.  The goal of this protocol change is
 to push the decision to use overlay or GPU blit to the xorg driver.
 You left one corner case out, HDMI allows for the framebuffer to be in
 YUV 4:4:4 format. So it is possible to send YUV data to the display
 (usually a TV) without color conversion at all, but I think with the
 current state of X we are years away from that.

heh, yeah..

possibly w/ overlays, at least when fullscreen and gfx layer is not
visible, we could send YUV direct to the TV.. but I'm not really sure
the practicality of switching back and forth between RGB and YUV

 ...

 In many cases, an overlay will avoid several passes through memory
 (blit/scale/colorconvert to DRI back-buffer on client side, blit to
 front and fake-front, and then whatever compositing is done by the
 window manager).  On the other hand, overlays can often be handled
 directly by the scanout engine in the display hardware, with the GPU
 switched off.
 Actually AMD has thrown out the hardware support for overlay with the
 R7xx (or was it evergreen?) series, because they got support for turning
 shader pipes off separately and figured out that it use less power to
 turn off all shaders except one and then use this one for color
 conversion and scaling, compared to having a distinct hardware block
 doing the job. But there are tendencies to get a distinct color
 conversion block back again.


The nice thing would be, by pushing this decision of *how* to render
video to the DDX, the xorg driver can make intelligent choices about
how best to implement it for a particular generation of gfx card or
SoC.  Nothing forces the use of overlays, but the goal is just to
allow overlays to be used when/if it makes sense.


 ...

 Note: video is not exactly the same as 3d, there are a number of other
 things to consider (scaling, colorconvert, multi-planar formats).  But
 on the other hand the principle is similar (direct rendering from hw
 video codecs).  And a lot infrastructure of connection, authentication,
 is same.  So there are two options, either extend DRI2 or add a new
 protocol which duplicates some parts.  I'd like to consider extending
 DRI2 first, but if people think the requirements for video are too
 much different from 3d, then I could split this into a new protocol.
 If you ask me extending things seems the better way to do this.

Ok, I'm glad that folks don't seem too scared off by adding some video
stuff in dri2proto :-)

 ..

 @@ -184,6 +185,11 @@ DRI2ATTACHMENT { DRI2BufferFrontLeft
       These values describe various attachment points for DRI2
       buffers.

 +     In the case of video driver (DRI2DriverXV) the attachment,
 +     other than DRI2BufferFrontLeft, just indicates buffer
 +     number and has no other special significance.  There is no
 +     automatic maintenance of DRI2BufferFakeFrontLeft.
 I think that will created compatibility problems with existing
 implementations, because the DDX side doesn't know if it's talking to a
 video or 3D client side.

On the xorg/DDX side, we'd have to expose the 'driverType' to the DRI2
implementation somehow.  I'm not sure yet the best way to handle this,
but I guess it is a solvable problem.

Once it seems like I'm basically the right track I'll start putting
together some patches for xserver tree to go along with the proto
changes and sort out these details.  I wanted to at least make sure I
was on the right track by extending dri2 as opposed to adding a new
extension first.

 ...

 +     The XV_OSD attribute specifies the XID of a pixmap containing
 +     ARGB data to be non-destructively overlayed over the video.  This
 +     could be used to implement subtiles, on-screen-menus, etc.
 Why an XID? I'm not 100% sure about it, but using a DRI buffer name
 directly here seems to be the better alternative.

I'm debating back and forth between two approaches here..

1) attribute w/ pixmap XID (which itself could be
DRI2CreateDrawable()'d if needed, which would give you DRI buffers)

2) have some special attachment points

In the second case, it seemed a bit awkward to me, because we'd
probably need a way to SwapBuffers w/ both a src and dst specified (so
you aren't always swapping to the front)..  (well, maybe CopyRegion is
sufficient).  And also, now some of the non-front buffers are RGB and
not scaled vs YUV and scaled.  But with the first approach it is
consistent, all non-front buffers are same dimensions/format.

Also, for a generic (non-3d) client, w/ the XID attribute approach, it
is just a normal drawable that they

libjpeg-turbo for Android available

2011-09-02 Thread Tom Gall

The initial port of Android's extensions to the current libjpeg-turbo
codebase is complete.

With Chao Yang's help we've validated using both the Linaro Android
LEB panda as well as CyanogenMod 7 on the Nook. (I'd validate on my
Nexus One too but I'm short of microSD cards)

It runs, image encode and decode tests pass and use of the library by
android components such as the browser and skia appears to be fine
with no issues. The past bugs seen with the 1.1.1 based proof of
concept are gone.

The code can currently be found in git at:

http://git.linaro.org/gitweb?p=people/tomgall/libjpeg-turbo/libjpeg-turbo.git;a=summary

from the 1.2-beta-linaro-andoid branch.

Be sure to read the ANDROID.txt file for build instructions. This
branch is SPECIFICALLY for android. It's not a wise idea (yet) to take
these contents and use for a traditional linux system (tho I have also
tested on linux with the extensions compiled in, I have not yet tested
with all the extensions turned off to make sure a pre android build
and a post android build without android support on are equal)

As soon as sourceforge sends me an email so I can confirm my account
there, I'll get a patch posted to the libjpeg-turbo patch tracker for
review. I anticipate there will be a comment or two and some slight
rework here and there but generally speaking the code should be in
good shape.

I have not yet started to do performance comparisons between the old
jpeg and libjpeg-turbo on android. That needs to be done.

Further neon hardware support is assumed, likely there will be a patch
to enable / disable optimization that counts on neon.

Also from the android extensions, support for ash and one optimization
for armv6 was not included. Both however are reasonable optimizations
and I can see including them at a future date.

I would include a pointer to the original android jpeg source but
android.git.kernel.org is still down.

-- 
Regards,
Tom

We want great men who, when fortune frowns will not be discouraged.
- Colonel Henry Knox
Linaro.org │ Open source software for ARM SoCs
w) tom.gall att linaro.org
w) tom_gall att vnet.ibm.com
h) tom_gall att mac.com

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: libjpeg-turbo for Android available

On Fri, Sep 02, 2011 at 10:34:47AM -0500, Tom Gall wrote:
The initial port of Android's extensions to the current libjpeg-turbo
codebase is complete.

Tom, you've done a spectacular job carrying the -turbo work into the
developer platform and now Android. I'm thrilled to see this come to
fruition now, and the CyanogenMod test is a great bonus -- seeing this
used on a real form-factor device means I can actually believe in it.

The code can currently be found in git at:

http://git.linaro.org/gitweb?p=people/tomgall/libjpeg-turbo/libjpeg-turbo.git;a=summary

from the 1.2-beta-linaro-andoid branch.

Be sure to read the ANDROID.txt file for build instructions. This
branch is SPECIFICALLY for android.

Can you give a summary of what's being added here? i.e. what happened to
Android when using libjpeg-turbo without these added patches?

I see some pretty major changes in:

http://git.linaro.org/gitweb?p=people/tomgall/libjpeg-turbo/libjpeg-turbo.git;a=commitdiff;h=ff1f5e7ce17701b48e53b7fcb3509f40715fd2e4

It looks to me like the main changes are protected by the following
defines, which probably answers part of my question above:

ENABLE_ANDROID_NULL_CONVERT
ANDROID_TILE_BASED_DECODE
ANDROID_RGB

(Ald yes, I have read ANDROID.txt which confirms the above but doesn't
tell me much else ;-)

Also, I see you adding config.h and jconfig.h files which I don't think
you want to have committed, right?

Do you really want an android/ config subdirectory?

I have not yet started to do performance comparisons between the old
jpeg and libjpeg-turbo on android. That needs to be done.

This might be Zach's next favorite demo!

You might want to try out the toolchain guys' latest -03 and assorted
optimization madness to see if they make a difference when you do that.

Also from the android extensions, support for ash and one optimization
for armv6 was not included. Both however are reasonable optimizations
and I can see including them at a future date.

What is the support for ash piece?

Good job!
--
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: Would you send me your hard float experiment results you presented in Budapest?

Including Bero who's looked at this recently.

On 2 September 2011 05:41, David Rusling david.rusl...@linaro.org wrote:
 Zach,
        you'd need to use multiarch and have multiple installed libraries so 
 that you could support both hard and soft float ABI.   Does Android do 
 anything different / interesting in its image / shared library loader(s)?
 Dave

 On 30 Aug 2011, at 17:24, Zach Pfeffer wrote:

 Steve,

 I'd like you to meet Jim who did the initial hardfloat work. This
 email contains the results that Jim produced.

 I believe that the conclusion was that skia and webkit may benefit,
 but that such benefits would impose an undue burden on Android's
 distribution model which tries to create libs that can run on as many
 architectures as possible.

 -Zach


 -- Forwarded message --
 From: Jim Huang js...@0xlab.org
 Date: 7 August 2011 18:01
 Subject: Re: Would you send me your hard float experiment results you
 presented in Budapest?
 To: Zach Pfeffer zach.pfef...@linaro.org


 2011/8/7 Zach Pfeffer zach.pfef...@linaro.org:
 Jim,

 Thanks. Would it be possible to post them by the end of the day?

 skia -

    Switch from VFP back to fixed scalar based calculation

    Previous configuration enabled ARM VFP for scalar float, but VFP on
    ARM11 is not as powerful as VFPv3 or NEON.

    Reference benchmark:
    Item            Fixed based     VFP-based
        ---     -
    Draw Canvas     58.37 fps       58.40 fps
    Draw Circle     37.48 fps       22.93 fps
    Draw Circle2    17.14 fps       18.31 fps
    Draw Rect       17.62 fps       20.69 fps
    Draw Arc        24.79 fps       27.45 fps
    Draw Image      19.08 fps       18.73 fps
    Draw Text       29.22 fps       25.79 fps



 Also, have you sync'd up with Mike? He wants to negotiate on your contract.

 I sent mail to Mike already.  I don't know how to proceed.

 Thanks,
 -jserv
 Mail AttachmentNOTE___
 linaro-dev mailing list
 linaro-dev@lists.linaro.org
 http://lists.linaro.org/mailman/listinfo/linaro-dev



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

RE: [PATCH 2/4 v6] pinmux: add a driver for the U300 pinmux

2011-09-02 Thread Stephen Warren

Linus Walleij wrote at Friday, September 02, 2011 2:12 AM:
 On Thu, Sep 1, 2011 at 11:33 PM, Stephen Warren swar...@nvidia.com wrote:
 
  +static const struct u300_pmx_func u300_pmx_functions[] = {
  +     {
  +             .name = power,
  +             .groups = { POWERGRP_INDEX },
  +             /* Mask is N/A */
  +     },
 
  Hmmm. That's a lot of _INDEX defines that'd need to be set up, at least
  to fully represent a chip like Tegra. Can the pinmux core be modified
  such that the group list is an array of names (char*) rather than the
  actual numeric IDs of the groups? Still, perhaps we could use the enum
  we already have for this, so perhaps it isn't a big deal...
 
 Well I could think about a lot of ways to do this, but it's basically up
 to the driver, the U300 is just some simple example of what you can
 do, it's just trying to satisfy the API.
 
 Maybe as part of writing the nVidia driver you find a clever
 mechanism for doing this, if it's looking generally useful at that
 point then let's move it to the core I'd say.

The reason I asked about the pinmux core handling this is because the
driver op get_function_groups:

+   int (*get_function_groups) (struct pinctrl_dev *pctldev,
+ unsigned selector,
+ unsigned ** const groups,
+ unsigned * const num_groups);

returns an array of integer indexes. I think the only way to get rid of
the index definitions in the drivers is to allow get_function_groups to
return an array of strings instead.

Well, I suppose the implementation of get_function_groups could convert
from an internal array of strings to the returned array of integers at
run-time, but that doesn't seem like a great idea.

-- 
nvpublic


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: 11.08 Pre-built Images

2011-09-02 Thread Andy Doan


On 09/01/2011 11:35 PM, Anca Emanuel wrote:

Is there an tutorial to install qemu in ubuntu and run some linaro image ?

I want to test it.


This page:
  http://www.linaro.org/getting-started/

has a screencast of running linaro in 5 minutes under qemu. Here's the 
actual file:


  http://people.linaro.org/~doanac/linaro-qemu-5min.ogv

There's also the wiki page which includes the steps done in the video:

  https://wiki.linaro.org/Resources/HowTo/Qemu-5

-andy

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

RE: [PATCH 1/4 v6] drivers: create a pin control subsystem v6

2011-09-02 Thread Stephen Warren

Linus Walleij wrote at Friday, September 02, 2011 6:59 AM:
  I would imagine treating GPIOs as just another function. I'll repeat
  some text I wrote previously (https://lkml.org/lkml/2011/8/26/298) about
  how I see this working:
 
 SW For reference, here's how I'd imagine modeling those three cases in
 SW pinmux (all based on my earlier comments about the data model I imagine,
 SW rather than what's currently in the pinmux patches):
 
 SW 1) Have a single function gpio that can be applied to any pin that
 SW supports it. The actual GPIO number that gets mux'd onto the pin differs
 SW per pin, and is determine by HW design. But logically, we're connecting
 SW that pin to function gpio, so we only need one function name for that.
 
  So here, the only issue is that if GPIO can be assigned per pin, we'd
  need to define a pingroup per pin, even if we had a set of other groups
  for muxing. (And a pin would have to be in its per-pin pingroup, and
  mux group, which goes back to my very first comment above.) I suppose this
  might end up being a lot of pingroups. However, this is all data, and
  it seems like having large data is better than having large code? Still,
  these per-pin groups might end up existing for other functionality like
  biasing anyway, depending on HW.
 
 Hm I have a hard time figuring out how that code would look...
 I'm worried that the drivers could get pretty hard to read.

For a simple chip that allowed everything to be configured at a pin level
rather than pingroup level:

Functions:
spi
i2c
gpio

pins:
A1
A2
A3
A4

Groups, with pin list and legal functions:
A1: A1: gpio spi
A2: A2: gpio spi
A3: A3: gpio i2c
A4: A4: gpio i2c

For a chip that allowed muxing to be configured at a group level, but
GPIOs to be configured at a pin level:

Functions:
spi
i2c
gpio

pins:
A1
A2
A3
A4

Groups, with legal functions:
A1: A1: gpio
A2: A2: gpio
A3: A3: gpio
A4: A4: gpio
GROUPA: A1, A2: spi
GROUPB: A3, A4: i2c

...
 Right now I have resorted to the diplomatic solution of actually
 supporting both.
 
 pinmux_request_gpio() will request a gpio pin named
 gpioN where N is the global GPIO number.
 
 This fragment from pinmux.c sort of specifies it:
 
 if (gpio  ops-gpio_request_enable)
 /* This requests and enables a single GPIO pin */
 status = ops-gpio_request_enable(pctldev, gpio_range, pin);
 else if (ops-request)
 status = ops-request(pctldev, pin);
 else
 status = 0;
 
 So if the driver doesn't implement the quick -gpio_request_enable()
 the second else-clause will attempt to get the function gpioN.
 
 So if the driver just wants to present a single function per pin instead,
 it can readily do so, but it must still specify which GPIO ranges it
 supports.

Ah, OK.

The only issue I see with that is that is there end up being a whole ton
of functions named gpio0, gpio1, ..., gpio125 etc. Do those functions
have to be listed in the table of functions exported by the driver, or does
the core expect to pass these created function names to the driver without
their previously existing?

Whereas if you do a function-per-gpio-controller, or function-per-gpio-
that- can-be-configured-on-the-pin, you limit the number of function
names that are required.

  diff --git a/include/linux/pinctrl/pinmux.h 
  b/include/linux/pinctrl/pinmux.h
 
  +/**
  + * struct pinmux_ops - pinmux operations, to be implemented by pin 
  controller
  + * drivers that support pinmuxing
  + * @request: called by the core to see if a certain pin can be made 
  available
  + *   available for muxing. This is called by the core to acquire the pins
  + *   before selecting any actual mux setting across a function. The driver
  + *   is allowed to answer no by returning a negative error code
  + * @free: the reverse function of the request() callback, frees a pin 
  after
  + *   being requested
 
  Shouldn't request/free be for a pingroup, not a pin, since that's what
  functions are assigned to? Also, the function should be passed, since
  some restrictions these functions might need to check for might depend
  on what the pin/group will be used for.
 
 This is not for checking anything on function or group level.
 It's exclusively for things that need to be on a per-pin level, so any
 pin can deny being selected for muxing at any time.
 
 So what you're saying is that you need a function to check
 also on group level as part of the pinmux_get() sematics?
 
 We can add that and have two optional checks: @request_pin()
 on pin level and say @request_function_and_group() on the
 group+function level, would that work for your scenarios?

Well, that's a move in the right direction, but not quite everything I'd
like.

The basic issue is that a single logical function (I2C controller 0) can
be mux'd out onto more than one pingroup. However, the HW requires that
at /any given time/ it only be mux'd out onto a single pingroup.

To fully enforce this,

Re: Tracking Android kernel tips and Android builds

2011-09-02 Thread Paul Sokolovsky

On Thu, 01 Sep 2011 18:21:30 -0400
James Westby james.wes...@canonical.com wrote:

 On Thu, 1 Sep 2011 17:10:03 -0500, Zach Pfeffer
 zach.pfef...@linaro.org wrote:
  We've had two instances of this problem for all the builds we've
  ever done. One instance was trying to sync u-boot and the other was
  trying to sync the TI LT kernel. John Rigby suggested the branch
  approach and it seems to have worked, so I'd like to go with that.
 
 Paul is working on a change to make tags usable as well. It seems to
 me that we have a couple of options
 
   1) Use branches long term. Paul can continue to push the patch for
   correctness sake, but we don't plan to use it.
 
   2) Use branches for now. Paul fixes repo to make tags usable, at
 which point we allow people (e.g. Andy) to use those too.
 
 Which would you advocate?

But we already seem to have decided to use patched repo, no??

 
 Thanks,
 
 James


-- 
Best Regards,
Paul

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: [ACTIVITY] Power Management WG Weekly Status report week ending 2011-09-02

On Thu, Sep 01, 2011 at 02:22:03PM -0500, Mounir Bsaibes wrote:
  * Made hotplug power measurements on st-e u8500 platform
* mp3 playback test showed between 7 to 8% power improvement
* cpuhotplug - For Linux idle case, no visible improvement as power is
 already very low

This is using hotplug versus plain cpuidle -- and if so, does this mean
that the proper fix is extending cpuidle to go to the lowest power state?

  * Re-writing cpuidle driver

For which platforms?
-- 
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: Tracking Android kernel tips and Android builds

On 2 September 2011 12:39, Paul Sokolovsky paul.sokolov...@linaro.org wrote:
 On Thu, 01 Sep 2011 18:21:30 -0400
 James Westby james.wes...@canonical.com wrote:

 On Thu, 1 Sep 2011 17:10:03 -0500, Zach Pfeffer
 zach.pfef...@linaro.org wrote:
  We've had two instances of this problem for all the builds we've
  ever done. One instance was trying to sync u-boot and the other was
  trying to sync the TI LT kernel. John Rigby suggested the branch
  approach and it seems to have worked, so I'd like to go with that.

 Paul is working on a change to make tags usable as well. It seems to
 me that we have a couple of options

   1) Use branches long term. Paul can continue to push the patch for
   correctness sake, but we don't plan to use it.

   2) Use branches for now. Paul fixes repo to make tags usable, at
 which point we allow people (e.g. Andy) to use those too.

 Which would you advocate?

 But we already seem to have decided to use patched repo, no??

Seems to be the consensus.

Would you write up where to pull Linaro's repo from and why its
different? Make sure the release engineers are in the loop. Adding
fabo.


 Thanks,

 James


 --
 Best Regards,
 Paul

 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: Fwd: Would you send me your hard float experiment results you presented in Budapest?

On Tue, Aug 30, 2011 at 11:24:59AM -0500, Zach Pfeffer wrote:
 I'd like you to meet Jim who did the initial hardfloat work. This
 email contains the results that Jim produced.

Hmm, but the email seems to not actually contain a hard-float run. Or am
I misreading what he means by Fixed vs VFP?

 I believe that the conclusion was that skia and webkit may benefit,
 but that such benefits would impose an undue burden on Android's
 distribution model which tries to create libs that can run on as many
 architectures as possible.

You may be confusing things here. Hard-float is a pure software ABI
change, and any platform which supports VFP can use it if you build it
that way. However, since it is an ABI change it requires that hard-float
libraries be available.

What /would/ stop code from running on certain platforms is using
NEON (it would exclude the Tegra2 and some existing Marvell v7s). But
that doesn't seem to be in question here.

 -- Forwarded message --
 From: Jim Huang js...@0xlab.org
 Date: 7 August 2011 18:01
 Subject: Re: Would you send me your hard float experiment results you
 presented in Budapest?
 To: Zach Pfeffer zach.pfef...@linaro.org
 
 
 2011/8/7 Zach Pfeffer zach.pfef...@linaro.org:
  Jim,
 
  Thanks. Would it be possible to post them by the end of the day?
 
 skia -
 
    Switch from VFP back to fixed scalar based calculation
 
    Previous configuration enabled ARM VFP for scalar float, but VFP on
    ARM11 is not as powerful as VFPv3 or NEON.
 
    Reference benchmark:
    Item            Fixed based     VFP-based
        ---     -
    Draw Canvas     58.37 fps       58.40 fps
    Draw Circle     37.48 fps       22.93 fps
    Draw Circle2    17.14 fps       18.31 fps
    Draw Rect       17.62 fps       20.69 fps
    Draw Arc        24.79 fps       27.45 fps
    Draw Image      19.08 fps       18.73 fps
    Draw Text       29.22 fps       25.79 fps
 
 
 
  Also, have you sync'd up with Mike? He wants to negotiate on your contract.
 
 I sent mail to Mike already.  I don't know how to proceed.
 
 Thanks,
 -jserv



 ___
 linaro-dev mailing list
 linaro-dev@lists.linaro.org
 http://lists.linaro.org/mailman/listinfo/linaro-dev

-- 
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: Tracking Android kernel tips and Android builds

On 30 August 2011 10:50, Christian Robottom Reis k...@linaro.org wrote:
 On Tue, Aug 30, 2011 at 10:46:55AM -0500, Zach Pfeffer wrote:
 Because we push everything upstream.

 While I agree with that blanket statement, there's no reason we wouldn't
 provide a [potentially temporary] version of repo that included the
 changes we're pushing upstream.

 We do this for every one of the components we ship, so I see no
 philosophical reason why we wouldn't do so for repo.

 Is there a technical reason?

repo bootstraps itself by syncing the repo guts from google, google
signs the repo guts so that people know that they're using a trusted
source. As our repo in not a trusted source, people may be reluctant
to use it and will instead use Google's version  which won't work 100%
of the time for the reasons already discussed.

 --
 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: Preliminary wiki starting page for i.MX53 QuickStart board