date:20110819

2011/8/18 Michal Nazarewicz min...@mina86.com:
 On Thu, 18 Aug 2011 11:28:46 +0200, Per Forlin wrote:

 diff --git a/drivers/usb/gadget/f_mass_storage.c
 b/drivers/usb/gadget/f_mass_storage.c
 index 5b93395..3e546d9 100644
 --- a/drivers/usb/gadget/f_mass_storage.c
 +++ b/drivers/usb/gadget/f_mass_storage.c
 @@ -363,7 +363,6 @@ struct fsg_common {
        struct fsg_buffhd       *next_buffhd_to_fill;
        struct fsg_buffhd       *next_buffhd_to_drain;
 -       struct fsg_buffhd       buffhds[FSG_NUM_BUFFERS];
        int                     cmnd_size;
        u8                      cmnd[MAX_COMMAND_SIZE];
 @@ -407,6 +406,8 @@ struct fsg_common {
        char inquiry_string[8 + 16 + 4 + 1];
        struct kref             ref;
 +       /* Must be the last entry */
 +       struct fsg_buffhd       buffhds[0];

 I would rather see it as “struct fsg_buffhd *buffhds;” since this change
 requires both mass_storage.c and multi.c to be changed.

If the allocation of buffhds is done separately in fsg_common_init().
mass_storage.c and multi.c doesn't need to be changed. But it's little
tricky to know whether buffhds should be allocated or not.

if (!common-buffhds)
  common-buffhds = kzalloc()
This works fine if the common is declared static since all data is 0
by default. If common is allocated by kmalloc and then passed to
fsg_commin_init() this check isn't reliable.
memset of common will erase buffhds pointer as well. A minor issue,
storing this pointer before running memset will fix it. I would like
to propose a different approach.

+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -363,7 +363,7 @@ struct fsg_common {
-   struct fsg_buffhd   buffhds[FSG_NUM_BUFFERS];
+   struct fsg_buffhd   buffhds[CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS];

+++ b/drivers/usb/gadget/file_storage.c
@@ -461,7 +461,7 @@ struct fsg_dev {
-   struct fsg_buffhd   buffhds[FSG_NUM_BUFFERS];
+   struct fsg_buffhd   buffhds[CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS];

+++ b/drivers/usb/gadget/storage_common.c
@@ -52,6 +52,12 @@
+/*
+ * There is a num_buffers module param when USB_GADGET_DEBUG is defined.
+ * This parameter sets the length of the fsg_buffhds array.
+ * The valid range of num_buffers is:
+ * num = 2  num = CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS.
+ */

+#ifdef CONFIG_USB_GADGET_DEBUG_FILES
I am in favor of #ifdef some Kconfig option. This simplifies for
automated build/tests farms where def_configs are being used to
configure the system.
This option should not affect the performance significantly.

+
+static unsigned int fsg_num_buffers = CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS;
+module_param_named(num_buffers, fsg_num_buffers, uint, S_IRUGO);
+MODULE_PARM_DESC(fsg_num_buffers, Number of pipeline buffers);
+
+#else
+
+/*
+ * Number of buffers we will use.
+ * 2 is usually enough for good buffering pipeline
+ */
+#define fsg_num_buffersCONFIG_USB_GADGET_STORAGE_NUM_BUFFERS
+
+#endif /* CONFIG_USB_DEBUG */
+
+#define FSG_NUM_BUFFERS_IS_VALID(num) ((num) = 2  \
+   (num) = CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS)

Keep the length of the buffhds array constant. Use a variable
fsg_num_buffers when iterating that array.
This minimize the code to change. But to the price of using
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS to declare
and fsg_num_buffers to access.

Is this proposal better or worse?

Thanks,
Per

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

Re: Linux kernel review tags (Re: [PATCH 0/3] Fix Thumb-2 undef handling for mixed-arch kernels)

2011-08-19 Thread Dave Martin

On Thu, Aug 18, 2011 at 10:18:10PM -0400, Nicolas Pitre wrote:
 On Thu, 18 Aug 2011, Dave Martin wrote:
 
  On Wed, Aug 17, 2011 at 6:24 PM, Nicolas Pitre nicolas.pi...@linaro.org 
  wrote:
   On Wed, 17 Aug 2011, Dave Martin wrote:
  
   Acked-by = This patch is definitely right, or I fully agree with the
         patch and trust the author's judgement (I will share
         responsibility for the correctness and appropriateness of this
         patch).  This implies Reviewed-by.
         Normally an ack shouldn't
         get added unless the acker is confident that the patch is
         adequately tested (where the level of testing deemed adequate
         depends on the complexity of the patch)  Again, this may rely on
         judgement of the comptence of the author and the other
         reviewers.
  
   Reviewed-by = This patch looks correct and appropriate and I judge it
         ok to merge, but I assume the author knows what they're
         doing, and I don't necessarily take responsibility for the
         change.
  
   I think some aspects of the above two are mixed up.
  
   Normally, ACK == acknowledgement i.e. I conceptually agree with the
   patch, but that doesn't necessarily mean that it was reviewed
   thoroughly.  In other words, this quite matches your definition, but
   does not imply a Reviewed-by, and that assumes the author knows what
   they're doing.
  
   Reviewed-by means that you did review the patch content in details,
   whether or not the author knows what they're doing.  A Reviewed-by
   obviously implies an Acked-by.
  
  Interesting... I thought there was a chance I was getting this wrong.
  
  My impression was that an Ack carries more weight with upstream
  maintainers when it comes to merging; but does it instead depend on
  _who_ the tag comes from?  (i.e., if an experienced and well-known
  person takes a cursory glance at the patch and the review that's gone
  on and Acks it, this may carry more weight than a Reviewed-by by a
  less well-known person?)
 
 Absolutely.
 
 And the more experienced a person might be, the more patches that person 
 might be expected to look at.  So it is normal for such person to look 
 at the purpose and general design of a patch only, while trusting the 
 author to get the details right.  Hence the acked-by tag.
 
 This is also where the coding style get important as it is possible for 
 a reviewer to look at the patch and get a feel for that general design 
 more easily.
 
 A Reviewed-by is meant to be more thorough.  See the definition from Ted 
 Tso here:
 
 http://kerneltrap.org/Linux/Introducing_Reviewed-by_Tags
 
 But it is true that the value of any such tag is pondered by the 
 reputation of the person providing it, and that reputation is usually 
 based on the perceived quality of the code that person provided in the 
 past.

Useful advice, thanks

---Dave

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

[PATCH dri2proto] RFC: video support for dri2

2011-08-19 Thread Rob Clark

From: Rob Clark r...@ti.com

To allow the potential use of overlays to display video content, a few
extra parameters are required:

 + source buffer in different format (for example, various YUV formats)
   and size as compared to destination drawable
 + multi-planar formats where discontiguous buffers are used for
   different planes.  For example, luma and chroma split across
   multiple memory banks or with different tiled formats.
 + flipping between multiple back buffers, perhaps not in order (to
   handle video formats with B-frames)
 + cropping during swap.. in case of video, perhaps the required hw
   buffers are larger than the visible picture to account for codec
   borders (for example, reference frames where a block/macroblock
   moves past the edge of the visible picture, but back again in
   subsequent frames).

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.
---
Eventually this should replace Xv.  With a few additions, like attributes,
it could perhaps be possible to implement the client side Xv API on top
of dri2.

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.

In either case, I will implement the xserver side infrastructure, but
I wanted to get some feel for what is the preferred approach (extend
dri2 or new videoproto) first.

 dri2proto.txt |   60 -
 1 files changed, 59 insertions(+), 1 deletions(-)

diff --git a/dri2proto.txt b/dri2proto.txt
index df763c7..aa83b1a 100644
--- a/dri2proto.txt
+++ b/dri2proto.txt
@@ -163,7 +163,8 @@ and DRI2InvalidateBuffers.
 6. Protocol Types
 
 DRI2DRIVER { DRI2DriverDRI
-DRI2DriverVDPAU }
+DRI2DriverVDPAU,
+DRI2DriverXV }
 
These values describe the type of driver the client will want
to load.  The server sends back the name of the driver to use
@@ -184,6 +185,10 @@ 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.
+
 DRI2BUFFER { attachment: CARD32
 name: CARD32
 pitch: CARD32
@@ -203,6 +208,16 @@ DRI2ATTACH_FORMAT { attachment: CARD32
format.  'attachment' describes the attachment point for the buffer,
'format' describes an opaque, device-dependent format for the buffer.
 
+
+DRI2ATTACH_VIDEO { attachment: CARD32
+   format: CARD32,
+   width, height:  CARD32 }
+
+   The DRI2ATTACH_VIDEO describes an attachment and the associated
+   format for video buffers.  'attachment' describes the attachment
+   point for the buffer, 'format' describes a fourcc value for the
+   buffer.
+
 ⚙ ⚙ ⚙  ⚙ ⚙ ⚙
 
 
@@ -367,6 +382,15 @@ The name of this extension is DRI2.
later.
 
 ┌───
+DRI2GetVideoBuffers
+   drawable: DRAWABLE
+   attachments: LISTofDRI2ATTACH_VIDEO
+  ▶
+   width, height: CARD32
+   buffers: LISTofDRI2BUFFER
+└───
+
+┌───
 DRI2GetMSC
drawable: DRAWABLE
   ▶
@@ -585,11 +609,21 @@ A.1 Common Types
4   CARD32  pitch
4   CARD32  cpp
4   CARD32  flags
+   4   n   extra names length
+   4n  LISTof  extra names
 └───
A DRI2 buffer specifies the attachment, the kernel memory
manager name, the pitch and chars per pixel for a buffer
attached to a given drawable.
 
+   In case of multi-planar video formats, 'extra names' will give the
+   list of additional buffer names if there is one buffer per plane.
+   For example, I420 has one Y plane in with a 8bit luma value per
+   pixel, followed by one U plane subsampled 2x2 (with one 8bit U value
+   per 2x2 pixel block), followed by one V plane subsampled 2x2.  This
+   could either be represented as a single buffer name, or three
+   separate buffer names, one each for Y, U, and V.
+
 ┌───
 DRI2ATTACH_FORMAT
4   CARD32  attachment
@@ -599,6 +633,17 @@ A.1 Common Types
This data type is only available with protocol version 1.1 or
later.
 
+┌───
+DRI2ATTACH_VIDEO
+   4   CARD32

Re: [PATCH --mmotm v8 0/3] Make fault injection available for MMC IO

Hi Chris,

It's no longer necessary to merge this through the mm-tree since
Akinobu's patch fault-injection: add ability to export fault_attr in
arbitrary directory is in mainline.
Chris, would you mind merging the fault-injection patches in this
patchset to mmc-next once the mmc part of this patchset is acked and
accepted?

Regards,
Per

On 9 August 2011 14:07, Per Forlin per.for...@linaro.org wrote:
 change log:
  v2 - Resolve build issue in mmc core.c due to multiple init_module by
      removing the fault inject module.
    - Export fault injection functions to make them available for modules
    - Update fault injection documentation on MMC IO
  v3 - add function descriptions in core.c
    - use export GPL for fault injection functions
  v4 - make the fault_attr per host. This prepares for upcoming patch from
      Akinobu that adds support for creating debugfs entries in
      arbitrary directory.
  v5 - Make use of fault_create_debugfs_attr() in Akinobu's
      patch fault-injection: add ability to export fault_attr in
  v6 - Fix typo in commit message in patch export fault injection functions
  v7 - Don't compile in boot param setup function if mmc-core is
      built as module.
  v8 - Update fault injection documentation.
      Add fail_mmc_request to boot option section.

 Per Forlin (3):
  fault-inject: export fault injection functions
  mmc: core: add random fault injection
  fault injection: add documentation on MMC IO fault injection

  Documentation/fault-injection/fault-injection.txt |    8 +++-
  drivers/mmc/core/core.c                           |   44 
 +
  drivers/mmc/core/debugfs.c                        |   27 +
  include/linux/mmc/host.h                          |    7 +++
  lib/Kconfig.debug                                 |   11 +
  lib/fault-inject.c                                |    2 +
  6 files changed, 98 insertions(+), 1 deletions(-)

 --
 1.7.4.1



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

[PATCH 0/4 v4] pin controller subsystem v4

From: Linus Walleij linus.wall...@linaro.org

This is the fourth iteration of the pin controller subsystem, most
changes are described in the first patch, copied here for reference:

ChangeLog v3-v4:
- Define a number space per controller instead of globally,
  Stephen and Grant requested the same thing so now maps need to
  define target controller, and the radix tree of pin descriptors
  is a property on each pin controller device.

- Add a compulsory pinctrl device entry to the pinctrl mapping
  table. This must match the pinctrl device, like pinctrl.0

- Split the file core.c in two: core.c and pinmux.c where the
  latter carry all pinmux stuff, the core is for generic pin
  control, and use local headers to access functionality between
  files. It is now possible to implement a blank pin controller
  without pinmux capabilities. This split will make new additions
  like pindrive.c, pinbias.c etc possible for combined drivers
  and chunks of functionality which is a GoodThing(TM).

- Rewrite the interaction with the GPIO subsystem - the pin
  controller descriptor now handles this by defining an offset
  into the GPIO numberspace for its handled pin range. This is
  used to look up the apropriate pin controller for a GPIO pin.
  Then that specific GPIO range is matched 1-1 for the target
  controller instance.

- Fixed a number of review comments from Joe Perches.

- Broke out a header file pinctrl.h for the core pin handling
  stuff that will be reused by other stuff than pinmux.

- Fixed some erroneous EXPORT() stuff.

- Remove mispatched U300 Kconfig and Makefile entries

- Fixed a number of review comments from Stephen Warren, not all
  of them - still WIP. But I think the new mapping that will
  specify which function goes to which pin mux controller address
  50% of your concerns (else beat me up).

Linus Walleij (4):
  drivers: create a pinmux subsystem v4
  pinmux: add a driver for the U300 pinmux
  amba: request muxing for PrimeCell devices
  mach-u300: activate pinmux driver, delete old padmux driver

 Documentation/ABI/testing/sysfs-class-pinmux |   11 +
 Documentation/pinctrl.txt|  512 +++
 MAINTAINERS  |5 +
 arch/arm/mach-u300/Kconfig   |2 +
 arch/arm/mach-u300/Makefile  |2 +-
 arch/arm/mach-u300/core.c|   31 ++-
 arch/arm/mach-u300/include/mach/syscon.h |  136 -
 arch/arm/mach-u300/mmc.c |   16 -
 arch/arm/mach-u300/padmux.c  |  367 --
 arch/arm/mach-u300/padmux.h  |   39 --
 arch/arm/mach-u300/spi.c |   20 -
 drivers/Kconfig  |4 +
 drivers/Makefile |2 +
 drivers/amba/bus.c   |   49 ++-
 drivers/pinctrl/Kconfig  |   36 ++
 drivers/pinctrl/Makefile |7 +
 drivers/pinctrl/core.c   |  437 
 drivers/pinctrl/core.h   |   22 +
 drivers/pinctrl/pinmux-u300.c|  421 
 drivers/pinctrl/pinmux-u300.h|  141 ++
 drivers/pinctrl/pinmux.c |  700 ++
 drivers/pinctrl/pinmux.h |4 +
 include/linux/amba/bus.h |2 +
 include/linux/pinctrl/machine.h  |   62 +++
 include/linux/pinctrl/pinctrl.h  |  120 +
 include/linux/pinctrl/pinmux.h   |  122 +
 26 files changed, 2687 insertions(+), 583 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-pinmux
 create mode 100644 Documentation/pinctrl.txt
 delete mode 100644 arch/arm/mach-u300/padmux.c
 delete mode 100644 arch/arm/mach-u300/padmux.h
 create mode 100644 drivers/pinctrl/Kconfig
 create mode 100644 drivers/pinctrl/Makefile
 create mode 100644 drivers/pinctrl/core.c
 create mode 100644 drivers/pinctrl/core.h
 create mode 100644 drivers/pinctrl/pinmux-u300.c
 create mode 100644 drivers/pinctrl/pinmux-u300.h
 create mode 100644 drivers/pinctrl/pinmux.c
 create mode 100644 drivers/pinctrl/pinmux.h
 create mode 100644 include/linux/pinctrl/machine.h
 create mode 100644 include/linux/pinctrl/pinctrl.h
 create mode 100644 include/linux/pinctrl/pinmux.h

-- 
1.7.3.2


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

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

From: Linus Walleij linus.wall...@linaro.org

This adds a driver for the U300 pinmux portions of the system
controller SYSCON. It also serves as an example of how to use
the pinmux subsystem. This driver also houses the platform data
for the only supported platform.

Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
 arch/arm/mach-u300/core.c |   19 ++
 drivers/pinctrl/Kconfig   |7 +
 drivers/pinctrl/Makefile  |1 +
 drivers/pinctrl/pinmux-u300.c |  422 +
 drivers/pinctrl/pinmux-u300.h |  141 ++
 5 files changed, 590 insertions(+), 0 deletions(-)
 create mode 100644 drivers/pinctrl/pinmux-u300.c
 create mode 100644 drivers/pinctrl/pinmux-u300.h

diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index 399c89f..b0c45c3 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -25,6 +25,7 @@
 #include linux/err.h
 #include linux/mtd/nand.h
 #include linux/mtd/fsmc.h
+#include linux/pinctrl/machine.h
 
 #include asm/types.h
 #include asm/setup.h
@@ -1630,6 +1631,20 @@ static struct platform_device dma_device = {
},
 };
 
+static struct platform_device pinmux_device = {
+   .name = pinmux-u300,
+   .id = -1,
+   .num_resources = ARRAY_SIZE(pinmux_resources),
+   .resource = pinmux_resources,
+};
+
+/* Padmux settings */
+static struct pinmux_map u300_padmux_map[] = {
+   PINMUX_MAP_PRIMARY(mmc0, mmci),
+   PINMUX_MAP_PRIMARY(spi0, pl022),
+   PINMUX_MAP_PRIMARY(uart0, uart0),
+};
+
 /*
  * Notice that AMBA devices are initialized before platform devices.
  *
@@ -1828,6 +1843,10 @@ void __init u300_init_devices(void)
 
u300_assign_physmem();
 
+   /* Initialize pinmuxing */
+   pinmux_register_mappings(u300_padmux_map,
+ARRAY_SIZE(u300_padmux_map));
+
/* Register subdevices on the I2C buses */
u300_i2c_register_board_devices();
 
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index adb0be0..fdeca2f 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -26,4 +26,11 @@ config DEBUG_PINCTRL
help
  Say Y here to add some extra checks and diagnostics to PINCTRL calls.
 
+config PINMUX_U300
+   bool U300 pinmux driver
+   depends on ARCH_U300
+   select PINMUX
+   help
+ Say Y here to enable the U300 pinmux driver
+
 endif
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 596ce9f..63d4241 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -4,3 +4,4 @@ ccflags-$(CONFIG_DEBUG_PINMUX)  += -DDEBUG
 
 obj-$(CONFIG_PINCTRL)  += core.o
 obj-$(CONFIG_PINMUX)   += pinmux.o
+obj-$(CONFIG_PINMUX_U300)  += pinmux-u300.o
diff --git a/drivers/pinctrl/pinmux-u300.c b/drivers/pinctrl/pinmux-u300.c
new file mode 100644
index 000..c0cefb6
--- /dev/null
+++ b/drivers/pinctrl/pinmux-u300.c
@@ -0,0 +1,422 @@
+/*
+ * Driver for the U300 pin controller
+ *
+ * Based on the original U300 padmux functions
+ * Copyright (C) 2009-2011 ST-Ericsson AB
+ * Author: Martin Persson martin.pers...@stericsson.com
+ * Author: Linus Walleij linus.wall...@linaro.org
+ *
+ * The DB3350 design and control registers are oriented around pads rather than
+ * pins, so we enumerate the pads we can mux rather than actual pins. The pads
+ * are connected to different pins in different packaging types, so it would
+ * be confusing.
+ */
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/pinctrl/pinctrl.h
+#include linux/pinctrl/pinmux.h
+
+#include pinmux-u300.h
+
+#define DRIVER_NAME pinmux-u300
+
+/*
+ * The DB3350 has 467 pads, I have enumerated the pads clockwise around the
+ * edges of the silicon, finger by finger. LTCORNER upper left is pad 0.
+ * Data taken from the PadRing chart, arranged like this:
+ *
+ *   0 . 104
+ * 466105
+ *   ..
+ *   ..
+ * 358224
+ *  357  225
+ */
+#define U300_NUM_PADS 467
+
+/* Pad names for the pinmux subsystem */
+const struct pinctrl_pin_desc __refdata u300_pads[] = {
+   PINCTRL_PIN(0, P PAD VDD 28),
+   PINCTRL_PIN(1, P PAD GND 28),
+   PINCTRL_PIN(2, PO SIM RST N),
+   PINCTRL_PIN(3, VSSIO 25),
+   PINCTRL_PIN(4, VSSA ADDA ESDSUB),
+   PINCTRL_PIN(5, PWR VSSCOMMON),
+   PINCTRL_PIN(6, PI ADC I1 POS),
+   PINCTRL_PIN(7, PI ADC I1 NEG),
+   PINCTRL_PIN(8, PWR VSSAD0),
+   PINCTRL_PIN(9, PWR VCCAD0),
+   PINCTRL_PIN(10, PI ADC Q1 NEG),
+   PINCTRL_PIN(11, PI ADC Q1 POS),
+   PINCTRL_PIN(12, PWR VDDAD),
+   PINCTRL_PIN(13, PWR GNDAD),
+   PINCTRL_PIN(14, PI ADC I2 POS),
+   PINCTRL_PIN(15, PI ADC I2 NEG),
+   PINCTRL_PIN(16, PWR VSSAD1),
+   PINCTRL_PIN(17, PWR VCCAD1),
+   PINCTRL_PIN(18, PI ADC Q2 NEG),
+   PINCTRL_PIN(19, PI ADC Q2 POS),
+

[PATCH 4/4 v4] mach-u300: activate pinmux driver, delete old padmux driver

From: Linus Walleij linus.wall...@linaro.org

This hooks the pinmux driver into the U300 platform and deletes
the old machine-specific driver.

Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
 arch/arm/mach-u300/Kconfig   |2 +
 arch/arm/mach-u300/Makefile  |2 +-
 arch/arm/mach-u300/core.c|   12 +-
 arch/arm/mach-u300/include/mach/syscon.h |  136 ---
 arch/arm/mach-u300/mmc.c |   16 --
 arch/arm/mach-u300/padmux.c  |  367 --
 arch/arm/mach-u300/padmux.h  |   39 
 arch/arm/mach-u300/spi.c |   20 --
 drivers/pinctrl/pinmux-u300.c|   25 +-
 9 files changed, 25 insertions(+), 594 deletions(-)
 delete mode 100644 arch/arm/mach-u300/padmux.c
 delete mode 100644 arch/arm/mach-u300/padmux.h

diff --git a/arch/arm/mach-u300/Kconfig b/arch/arm/mach-u300/Kconfig
index 32a7b0f..449fd6a 100644
--- a/arch/arm/mach-u300/Kconfig
+++ b/arch/arm/mach-u300/Kconfig
@@ -6,6 +6,8 @@ comment ST-Ericsson Mobile Platform Products
 
 config MACH_U300
bool U300
+   select PINCTRL
+   select PINMUX_U300
 
 comment ST-Ericsson U300/U330/U335/U365 Feature Selections
 
diff --git a/arch/arm/mach-u300/Makefile b/arch/arm/mach-u300/Makefile
index 8fd354a..2855381 100644
--- a/arch/arm/mach-u300/Makefile
+++ b/arch/arm/mach-u300/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the linux kernel, U300 machine.
 #
 
-obj-y  := core.o clock.o timer.o padmux.o
+obj-y  := core.o clock.o timer.o
 obj-m  :=
 obj-n  :=
 obj-   :=
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index b0c45c3..c916575 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -1536,6 +1536,14 @@ static struct coh901318_platform coh901318_platform = {
.max_channels = U300_DMA_CHANNELS,
 };
 
+static struct resource pinmux_resources[] = {
+   {
+   .start = U300_SYSCON_BASE,
+   .end   = U300_SYSCON_BASE + SZ_4K - 1,
+   .flags = IORESOURCE_MEM,
+   },
+};
+
 static struct platform_device wdog_device = {
.name = coh901327_wdog,
.id = -1,
@@ -1658,10 +1666,10 @@ static struct platform_device *platform_devs[] 
__initdata = {
gpio_device,
nand_device,
wdog_device,
-   ave_device
+   ave_device,
+   pinmux_device,
 };
 
-
 /*
  * Interrupts: the U300 platforms have two pl190 ARM PrimeCells connected
  * together so some interrupts are connected to the first one and some
diff --git a/arch/arm/mach-u300/include/mach/syscon.h 
b/arch/arm/mach-u300/include/mach/syscon.h
index 7444f5c..6e84f07 100644
--- a/arch/arm/mach-u300/include/mach/syscon.h
+++ b/arch/arm/mach-u300/include/mach/syscon.h
@@ -234,91 +234,6 @@
 #define U300_SYSCON_ECCR_EMIF_1_RET_OUT_CLK_EN_N_DISABLE   (0x0004)
 #define U300_SYSCON_ECCR_EMIF_MEMCLK_RET_EN_N_DISABLE  (0x0002)
 #define U300_SYSCON_ECCR_EMIF_SDRCLK_RET_EN_N_DISABLE  (0x0001)
-/* PAD MUX Control register 1 (LOW) 16bit (R/W) */
-#define U300_SYSCON_PMC1LR (0x007C)
-#define U300_SYSCON_PMC1LR_MASK(0x)
-#define U300_SYSCON_PMC1LR_CDI_MASK(0xC000)
-#define U300_SYSCON_PMC1LR_CDI_CDI (0x)
-#define U300_SYSCON_PMC1LR_CDI_EMIF(0x4000)
-#ifdef CONFIG_MACH_U300_BS335
-#define U300_SYSCON_PMC1LR_CDI_CDI2(0x8000)
-#define U300_SYSCON_PMC1LR_CDI_WCDMA_APP_GPIO  (0xC000)
-#elif CONFIG_MACH_U300_BS365
-#define U300_SYSCON_PMC1LR_CDI_GPIO(0x8000)
-#define U300_SYSCON_PMC1LR_CDI_WCDMA   (0xC000)
-#endif
-#define U300_SYSCON_PMC1LR_PDI_MASK(0x3000)
-#define U300_SYSCON_PMC1LR_PDI_PDI (0x)
-#define U300_SYSCON_PMC1LR_PDI_EGG (0x1000)
-#define U300_SYSCON_PMC1LR_PDI_WCDMA   (0x3000)
-#define U300_SYSCON_PMC1LR_MMCSD_MASK  (0x0C00)
-#define U300_SYSCON_PMC1LR_MMCSD_MMCSD (0x)
-#define U300_SYSCON_PMC1LR_MMCSD_MSPRO (0x0400)
-#define U300_SYSCON_PMC1LR_MMCSD_DSP   (0x0800)
-#define U300_SYSCON_PMC1LR_MMCSD_WCDMA (0x0C00)
-#define U300_SYSCON_PMC1LR_ETM_MASK(0x0300)
-#define U300_SYSCON_PMC1LR_ETM_ACC (0x)
-#define U300_SYSCON_PMC1LR_ETM_APP (0x0100)
-#define U300_SYSCON_PMC1LR_EMIF_1_CS2_MASK (0x00C0)
-#define U300_SYSCON_PMC1LR_EMIF_1_CS2_STATIC   (0x)
-#define U300_SYSCON_PMC1LR_EMIF_1_CS2_NFIF (0x0040)
-#define U300_SYSCON_PMC1LR_EMIF_1_CS2_SDRAM

[PATCH 01/11] MFD: DA9052/53 MFD core module v5

2011-08-19 Thread ashishj3

The DA9052/53 is a highly integrated PMIC subsystem with supply domain 
flexibility
to support wide range of high performance application.

It provides voltage regulators, GPIO controller, Touch Screen, RTC, Battery
control and other functionality.

Signed-off-by: David Dajun Chen dc...@diasemi.com
Signed-off-by: Ashish Jangam ashish.jan...@kpitcummins.com
---
Changes since v5:
- inline device I/O
- Unhandle IRQ return RQ_NONE
- Remove register address conversion
Changes since v4:
- Modify KConfig 
- Use device registration for detemining chip id
- Remove preprocessor directive with runtime bustype variable
- Replace module_init() for spi with subsys_initcall()
- Remove platform string from MODULE_ALIAS of spi module.
Changes since v3:
- Code refactored to use REGMAP API.
- Add Battery resources.
- da9052_set_bits() and da9052_clear_bits() replaced by da9052_reg_update().
- Add support for DA9053 PMIC
Changes since v2:
- Drop da9052_irqs[] table.
- Move struct da9052_subdev_info[].
- Remove initialization of static member.
- Care for NULL pdata init().
- Check removal of subdevices on errors.
- Remove open source spi code.
- Remove '_spi' from the driver name.
- Move tbat_lookup table from header file.
- Remove irq.h 
- Remove num_gpio variable from pdata
---
 drivers/mfd/Kconfig   |   26 ++
 drivers/mfd/Makefile  |7 +
 drivers/mfd/da9052-core.c |  391 +++
 drivers/mfd/da9052-i2c.c  |  142 +++
 drivers/mfd/da9052-irq.c  |  173 
 drivers/mfd/da9052-spi.c  |  166 
 include/linux/mfd/da9052/da9052.h |   93 +
 include/linux/mfd/da9052/pdata.h  |   42 ++
 include/linux/mfd/da9052/reg.h|  777 +
 9 files changed, 1817 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mfd/da9052-core.c
 create mode 100644 drivers/mfd/da9052-i2c.c
 create mode 100644 drivers/mfd/da9052-irq.c
 create mode 100644 drivers/mfd/da9052-spi.c
 create mode 100644 include/linux/mfd/da9052/da9052.h
 create mode 100644 include/linux/mfd/da9052/pdata.h
 create mode 100644 include/linux/mfd/da9052/reg.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 21574bd..572a6a8 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -343,6 +343,32 @@ config PMIC_DA903X
  individual components like LCD backlight, voltage regulators,
  LEDs and battery-charger under the corresponding menus.
 
+config PMIC_DA9052
+   bool
+   select MFD_CORE
+
+config MFD_DA9052_SPI
+   bool Support Dialog Semiconductor DA9052/53 PMIC variants with SPI
+   select REGMAP_SPI
+   select PMIC_DA9052
+   depends on SPI_MASTER=y
+   help
+ Support for the Dialog Semiconductor DA9052 PMIC
+ when controlled using SPI. This driver provides common support
+ for accessing the device, additional drivers must be enabled in
+ order to use the functionality of the device.
+
+config MFD_DA9052_I2C
+   bool Support Dialog Semiconductor DA9052/53 PMIC variants with I2C
+   select REGMAP_I2C
+   select PMIC_DA9052
+   depends on I2C=y
+   help
+ Support for the Dialog Semiconductor DA9052 PMIC
+ when controlled using I2C. This driver provides common support
+ for accessing the device, additional drivers must be enabled in
+ order to use the functionality of the device.
+
 config PMIC_ADP5520
bool Analog Devices ADP5520/01 MFD PMIC Core Support
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index c580203..89a5837 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -67,6 +67,13 @@ endif
 obj-$(CONFIG_UCB1400_CORE) += ucb1400_core.o
 
 obj-$(CONFIG_PMIC_DA903X)  += da903x.o
+
+da9052-objs:= da9052-core.o da9052-irq.o
+obj-$(CONFIG_PMIC_DA9052)  += da9052.o
+
+obj-$(CONFIG_MFD_DA9052_SPI)   += da9052-spi.o
+obj-$(CONFIG_MFD_DA9052_I2C)   += da9052-i2c.o
+
 max8925-objs   := max8925-core.o max8925-i2c.o
 obj-$(CONFIG_MFD_MAX8925)  += max8925.o
 obj-$(CONFIG_MFD_MAX8997)  += max8997.o max8997-irq.o
diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
new file mode 100644
index 000..e45a17a
--- /dev/null
+++ b/drivers/mfd/da9052-core.c
@@ -0,0 +1,391 @@
+/*
+ * Device access for Dialog DA9052 PMICs.
+ *
+ * Copyright(c) 2011 Dialog Semiconductor Ltd.
+ *
+ * Author: David Dajun Chen dc...@diasemi.com
+ *
+ *  This program is free software; you can redistribute  it and/or modify it
+ *  under  the terms of  the GNU General  Public License as published by the
+ *  Free Software Foundation;  either version 2 of the  License, or (at your
+ *  option) any later version.
+ */
+
+#include linux/device.h
+#include linux/delay.h
+#include linux/input.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/mutex.h
+#include linux/mfd/core.h
+#include linux/slab.h
+
+#include

Re: [PATCH v4] usb: gadget: storage_common: make FSG_NUM_BUFFERS variable size

2011-08-19 Thread Michal Nazarewicz

On Fri, 19 Aug 2011 10:39:24 +0200, Per Forlin per.for...@linaro.org  
wrote:



2011/8/18 Michal Nazarewicz min...@mina86.com:

On Thu, 18 Aug 2011 11:28:46 +0200, Per Forlin wrote:


diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index 5b93395..3e546d9 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -363,7 +363,6 @@ struct fsg_common {
   struct fsg_buffhd   *next_buffhd_to_fill;
   struct fsg_buffhd   *next_buffhd_to_drain;
-   struct fsg_buffhd   buffhds[FSG_NUM_BUFFERS];
   int cmnd_size;
   u8  cmnd[MAX_COMMAND_SIZE];
@@ -407,6 +406,8 @@ struct fsg_common {
   char inquiry_string[8 + 16 + 4 + 1];
   struct kref ref;
+   /* Must be the last entry */
+   struct fsg_buffhd   buffhds[0];


I would rather see it as “struct fsg_buffhd *buffhds;” since this change
requires both mass_storage.c and multi.c to be changed.


If the allocation of buffhds is done separately in fsg_common_init().
mass_storage.c and multi.c doesn't need to be changed. But it's little
tricky to know whether buffhds should be allocated or not.


They should be always allocated.  If the code allocate fsg_common itself,  
the

case is obvious.  If caller passes a pointer to fsg_common structure, it is
assumed that the structure is not initialised, thus the function need to
allocate buffers.

--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michal mina86 Nazarewicz(o o)
ooo +-email/xmpp: mnazarew...@google.com-ooO--(_)--Ooo--

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

Re: [PATCH 1/2] drivers: create a pinmux subsystem v3

On Thu, Jul 14, 2011 at 7:57 AM, Barry Song 21cn...@gmail.com wrote:

 has this been ready for 3.1? we have been planning to write pinmux
 driver based on this framework.

On Mon, Aug 8, 2011 at 4:28 AM, Barry Song 21cn...@gmail.com wrote:

 What is the status of pincfg subsystem? what's the plan about merging
 this subsystem?

I failed, we needed feedback from some more players.
If you need this framework, please review and ACK the
patch set when you're happy with it so I know I have users who
are happy with it as it looks.

v4 is out today atleast. If there are no big objections so I have to
re-architect it again, I might be able to ask Stephen to pull it
into linux-next.

Thanks,
Linus Walleij

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

Re: [PATCH 1/2] drivers: create a pinmux subsystem v3

On Sat, Jul 9, 2011 at 12:23 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
 On Mon, Jun 13, 2011 at 01:57:36PM -0600, Grant Likely wrote:
 On Mon, Jun 13, 2011 at 10:58 AM, Linus Walleij

 I would *strongly* recommend against individual device drivers
 accessing the pinmux api.  This is system level configuration code,
 and should be handled at the system level.

 There can also be advantages to putting the pin into the designed mode
 without the driver being loaded from the electrical point of view.  For
 example, selecting appropriate pull values for pads can cut down on
 power consumption.

Since the pin control subsystem is reference counting wrt
mux settings, one does not exclude the other. So for
example a driver may or may not grab a certain set-up of pins
and the core platform may do the same, but when they start to
request different conflicting things the subsystem will complain,
as is apropriate.

So this is a very pure driver framework, without policy, it just
does what it's told, and will prevent undefined and impossible
settings. Atleast that's the idea.

Thanks,
Linus Walleij

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

Re: [PATCH 2/2] pinmux: add a driver for the U300 pinmux

On Thu, Jul 14, 2011 at 5:40 AM, Barry Song 21cn...@gmail.com wrote:

 +static const struct u300_pmx_func u300_pmx_funcs[] = {
 +       {
 +               .name = uart0,
 +               .pins = uart0_pins,
 +               .num_pins = ARRAY_SIZE(uart0_pins),
 +               .mask = uart0_mask,

 if we build a register address/bit shift/value table for every pinmux
 selection, sometimes we even need to write multiple registers for only
 one selection, for example:

 spi0:
 {
 REG      SHIFT   VALUE
 {REG1,    1,         5},
 {REG2,    3,         2},
 }

 we might let the whole enable/disable have common codes in the pinmux
 core but not implemented by every drivers.
 Common Enable:
 for (i = 0; i  MASK_NUM; i++)
 {
     writel(mask[i].reg, readl(mask[i].reg) | mask[i].val  mask[i].shift);
 }

 Common Disable:
 for (i = 0; i  MASK_NUM; i++)
 {
     writel(mask[i].reg, readl(mask[i].reg)  ~(mask[i].val  mask[i].shift));
 }

OK that problem is not unique to the pinmux subsystem though,
I can think of drivers/gpio/ and drivers/mfd/ etc etc plus platforms
having this need.

 ASoC really define some good macros about register layout for audio
 path, audio volume and son on, so every driver doesn't need to write
 so many details about hardware. they just use those macros to define
 register layout.

Can they be made generic so that *any* subsystem can use them?

 If we have common enable/disable for pinmux, every pinmux driver will
 only need to fill the table. Actually,  engineers just want to check
 the datasheet to figure out the table. And they don't want to repeat
 the enable/disable codes for every possible selection of pinmux.

Not all pinmuxes are the same, and not all are memory-mapped
either. Some are on the other end of an I2C, some (like U300)
need to read and write more than one register to do a specific
pin muxing. In the gpio-nomadik driver there is a special horror
about these registers also, one that cannot be solved easily with
a function like that. So it'd have to be optional.

It's a separate subject I think, no problem to do such things any day
on any subsystem.

Else we'll define and refactor what we need as we go along...

Thanks,
Linus Walleij

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

Re: [PATCH --mmotm v8 2/3] mmc: core: add random fault injection

On 19 August 2011 13:40, Linus Walleij linus.wall...@linaro.org wrote:
 On Tue, Aug 9, 2011 at 2:07 PM, Per Forlin per.for...@linaro.org wrote:

 This adds support to inject data errors after a completed host transfer.
 The mmc core will return error even though the host transfer is successful.
 This simple fault injection proved to be very useful to test the
 non-blocking error handling in the mmc_blk_issue_rw_rq().
 Random faults can also test how the host driver handles pre_req()
 and post_req() in case of errors.

 Good idea!

Thanks.

 diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
 index 89bdeae..a4996b0 100644
 --- a/drivers/mmc/core/core.c
 +++ b/drivers/mmc/core/core.c
 @@ -25,6 +25,11 @@
  #include linux/pm_runtime.h
  #include linux/suspend.h

 +#ifdef CONFIG_FAIL_MMC_REQUEST
 +#include linux/fault-inject.h
 +#include linux/random.h
 +#endif

 You don't need to #ifdef around the #include  stuff, and if you
 do, something is wrong with those headers. It's just a bunch of defines
 that aren't used in some circumstances. Stack them with the others,
 simply, just #ifdef the code below.

I added them after suggestion from J Freyensee.  I am also in favor of
no ifdefs here. I'll remove them in the next patchset unless James has
any strong objections.


 @@ -83,6 +88,43 @@ static void mmc_flush_scheduled_work(void)
        flush_workqueue(workqueue);
  }

 +#ifdef CONFIG_FAIL_MMC_REQUEST
 +
 +/*
 + * Internal function. Inject random data errors.
 + * If mmc_data is NULL no errors are injected.
 + */
 +static void mmc_should_fail_request(struct mmc_host *host,
 +                                   struct mmc_request *mrq)
 +{
 +       struct mmc_command *cmd = mrq-cmd;
 +       struct mmc_data *data = mrq-data;
 +       static const int data_errors[] = {
 +               -ETIMEDOUT,
 +               -EILSEQ,
 +               -EIO,
 +       };
 +
 +       if (!data)
 +               return;
 +
 +       if (cmd-error || data-error ||
 +           !should_fail(host-fail_mmc_request, data-blksz * 
 data-blocks))
 +               return;
 +
 +       data-error = data_errors[random32() % ARRAY_SIZE(data_errors)];
 +       data-bytes_xfered = (random32() % (data-bytes_xfered  9))  9;
 +}
 +
 +#else /* CONFIG_FAIL_MMC_REQUEST */
 +
 +static void mmc_should_fail_request(struct mmc_host *host,
 +                                   struct mmc_request *mrq)

 Should be static inline so we know it will be folded in and nullified
 by the compiler, lots of kernel code use that pattern.

I'll fix.

 diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
 index f573753..189581d 100644
 --- a/drivers/mmc/core/debugfs.c
 +++ b/drivers/mmc/core/debugfs.c
 @@ -13,6 +13,9 @@
  #include linux/seq_file.h
  #include linux/slab.h
  #include linux/stat.h
 +#ifdef CONFIG_FAIL_MMC_REQUEST
 +#include linux/fault-inject.h
 +#endif

 No #ifdef:ing...

I'll remove it.

 diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
 index 0f83858..ee472fe 100644
 --- a/include/linux/mmc/host.h
 +++ b/include/linux/mmc/host.h
 @@ -12,6 +12,9 @@

  #include linux/leds.h
  #include linux/sched.h
 +#ifdef CONFIG_FAIL_MMC_REQUEST
 +#include linux/fault-inject.h
 +#endif

 Neither here...

dito

 diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
 index 47879c7..ebff0c9 100644
 --- a/lib/Kconfig.debug
 +++ b/lib/Kconfig.debug

 I'm contemplating if we should create drivers/mmc/Kconfig.debug
 and stash this in there instead, i.e. also move out MMC_DEBUG
 from drivers/mmc/Kconfig and add to that?

 It seems more apropriate to select this from the MMC subsystem.
 However the core of fault injection is in lib/

 So maybe a simple:

 config FAIL_MMC_REQUEST
    bool
    select FAULT_INJECTION

 That can then be selected by a debug option in the MMC subsystem?
 I fear it may be hard to find this otherwise...

 (NB: I have very little clue how the Kconfig.debug files get sourced
 into the Kbuild so I might be misguided...)

The FAIL_MMC_REQUEST sits right next to the rest of the fail injection
functions.

config FAILSLAB
depends on FAULT_INJECTION
depends on SLAB || SLUB

config FAIL_PAGE_ALLOC
depends on FAULT_INJECTION

config FAIL_MAKE_REQUEST
depends on FAULT_INJECTION  BLOCK

config FAIL_IO_TIMEOUT
depends on FAULT_INJECTION  BLOCK

config FAIL_MMC_REQUEST
select DEBUG_FS
depends on FAULT_INJECTION  MMC

I think the proper place is to have it here together with the rest.

 @@ -1090,6 +1090,17 @@ config FAIL_IO_TIMEOUT
          Only works with drivers that use the generic timeout handling,
          for others it wont do anything.

 +config FAIL_MMC_REQUEST
 +       bool Fault-injection capability for MMC IO
 +       select DEBUG_FS
 +       depends on FAULT_INJECTION  MMC

 Isn't:

 depends on MMC
 select FAULT_INJECTION

 Simpler to use? Now you have to select fault injection first
 to even see this option right?

In menuconfig you have to select

Please register for Linaro Connect Q4.11

2011-08-19 Thread Stephen Doel

Hi All,

 

Please can I encourage you to register and organise your attendance at
Linaro Connect Q4.11 as soon as possible. In particular:

· if you're going to need a visa you should register now so we can
get the process going with your respective embassy

· if you need internal company approvals for attendance, make sure
its underway - and let me know if you need any additional supporting
information

· if you are a Canonical secondee to Linaro, you should register to
Linaro Connect (not UDS)

 

The hotel registration and booking details are now here:

http://connect.linaro.org/events/event/linaro-connect-q411/

 

Schedule information should be following in early September.

 

We will archive the existing conn...@linaro.org e-mail alias after this
e-mail and switch over to a new list containing delegates who have
registered for Q4.11 - an additional reason to register.

 

Thx

 

Stephen Doel

Chief Operating Officer

T:  +44 1223 45 00 23 │ M: +44 77 66 014 247 

 http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  http://www.facebook.com/pages/Linaro/155974581091106
Facebook |  http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog

 

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

Re: [PATCH 1/2] drivers: create a pinmux subsystem v3

On Thu, Jun 16, 2011 at 2:47 PM, Linus Walleij linus.wall...@linaro.org wrote:

 So to summarize there are two related areas of discussion
 here:

 1. Whether a pinmux map shall map one or 1..N functions
 2. How to handle per-driver instance namespacing of functions

 In both cases I'm currently using simple strings and claiming
 that by namespacing these strings cleverly we can avoid
 complexity. So my answer to these are:

 1. Use several functions with ovelapping maps, just name
  them differently
 2. Use a string convention and namespace by using
  platform/machine/package data and string conventions
  such as a :: separator

 While I *think* (and DO correct me!) that you would argue:

 1. Make it possible to map several functions to a single
  device map
 2. Namespace device instances by different map field
  members referring to specific instances

 Is this correctly understood, even if we may not agree?

I have now after being massaged by Grant changed opinion
on (2) and each pin controller (e.g. pinmux) instance has it's
struct device * or pinctrl_dev_name field in the mapping
table, so I hope you will find that part solved in an acceptable
way in the v4 patch set. So we'd solved 50% of our
disagreements.

(Please verify!)

So remains (1). I hope you will ACK the patch set if I fix
this also...

I'm thinking about good ways to solve it, reading through
your old mails, new suggestions based on the new patch
set are welcome.

Thanks,
Linus Walleij

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

Re: Android gcc 4.6 1107 optimization benchmark

2011-08-19 Thread Christian Robottom Reis

On Fri, Aug 19, 2011 at 03:40:26AM +0100, Chao Yang wrote:
 The image size increases significantly when -O3 is enabled for thumb files,

Size goes /up/ when enabling thumb? That's definitely unexpected.
-- 
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

[PATCH v9 0/3] mmc: make fault injection available for MMC IO

From: Per Forlin per.for...@linaro.org

change log:
 v2 - Resolve build issue in mmc core.c due to multiple init_module by
  removing the fault inject module.
- Export fault injection functions to make them available for modules
- Update fault injection documentation on MMC IO  
 v3 - add function descriptions in core.c
- use export GPL for fault injection functions
 v4 - make the fault_attr per host. This prepares for upcoming patch from
  Akinobu that adds support for creating debugfs entries in
  arbitrary directory.
 v5 - Make use of fault_create_debugfs_attr() in Akinobu's
  patch fault-injection: add ability to export fault_attr in 
 v6 - Fix typo in commit message in patch export fault injection functions
 v7 - Don't compile in boot param setup function if mmc-core is
  built as module.
 v8 - Update fault injection documentation.
  Add fail_mmc_request to boot option section. 
 v9 - remove ifdef around include files and inline empty function,
  comments from Linus Walleij.

Per Forlin (3):
  fault-inject: export fault injection functions
  mmc: core: add random fault injection
  fault injection: add documentation on MMC IO fault injection

 Documentation/fault-injection/fault-injection.txt |8 -
 drivers/mmc/core/core.c   |   41 +
 drivers/mmc/core/debugfs.c|   25 +
 include/linux/mmc/host.h  |5 +++
 lib/Kconfig.debug |   11 ++
 lib/fault-inject.c|2 +
 6 files changed, 91 insertions(+), 1 deletions(-)


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

[PATCH v9 1/3] fault-inject: export fault injection functions

From: Per Forlin per.for...@linaro.org

export symbols should_fail() and fault_create_debugfs_attr() in order
to let modules utilize the fault injection

Signed-off-by: Per Forlin per.for...@linaro.org
Acked-by: Akinobu Mita akinobu.m...@gmail.com
---
 lib/fault-inject.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/lib/fault-inject.c b/lib/fault-inject.c
index f193b77..328d433 100644
--- a/lib/fault-inject.c
+++ b/lib/fault-inject.c
@@ -130,6 +130,7 @@ bool should_fail(struct fault_attr *attr, ssize_t size)
 
return true;
 }
+EXPORT_SYMBOL_GPL(should_fail);
 
 #ifdef CONFIG_FAULT_INJECTION_DEBUG_FS
 
@@ -243,5 +244,6 @@ fail:
 
return ERR_PTR(-ENOMEM);
 }
+EXPORT_SYMBOL_GPL(fault_create_debugfs_attr);
 
 #endif /* CONFIG_FAULT_INJECTION_DEBUG_FS */
-- 
1.6.3.3


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

[PATCH v9 3/3] fault injection: add documentation on MMC IO fault injection

From: Per Forlin per.for...@linaro.org

Add description on how to enable random fault injection
for MMC IO

Signed-off-by: Per Forlin per.for...@linaro.org
Acked-by: Akinobu Mita akinobu.m...@gmail.com
---
 Documentation/fault-injection/fault-injection.txt |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/Documentation/fault-injection/fault-injection.txt 
b/Documentation/fault-injection/fault-injection.txt
index 82a5d25..70f924e 100644
--- a/Documentation/fault-injection/fault-injection.txt
+++ b/Documentation/fault-injection/fault-injection.txt
@@ -21,6 +21,11 @@ o fail_make_request
   /sys/block/device/make-it-fail or
   /sys/block/device/partition/make-it-fail. (generic_make_request())
 
+o fail_mmc_request
+
+  injects MMC data errors on devices permitted by setting
+  debugfs entries under /sys/kernel/debug/mmc0/fail_mmc_request
+
 Configure fault-injection capabilities behavior
 ---
 
@@ -115,7 +120,8 @@ use the boot option:
 
failslab=
fail_page_alloc=
-   fail_make_request=interval,probability,space,times
+   fail_make_request=
+   fail_mmc_request=interval,probability,space,times
 
 How to add new fault injection capability
 -
-- 
1.6.3.3


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

[PATCH v9 2/3] mmc: core: add random fault injection

From: Per Forlin per.for...@linaro.org

This adds support to inject data errors after a completed host transfer.
The mmc core will return error even though the host transfer is successful.
This simple fault injection proved to be very useful to test the
non-blocking error handling in the mmc_blk_issue_rw_rq().
Random faults can also test how the host driver handles pre_req()
and post_req() in case of errors.

Signed-off-by: Per Forlin per.for...@linaro.org
Acked-by: Akinobu Mita akinobu.m...@gmail.com
---
 drivers/mmc/core/core.c|   41 +
 drivers/mmc/core/debugfs.c |   25 +
 include/linux/mmc/host.h   |5 +
 lib/Kconfig.debug  |   11 +++
 4 files changed, 82 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 91a0a74..d704dfa 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -24,6 +24,8 @@
 #include linux/regulator/consumer.h
 #include linux/pm_runtime.h
 #include linux/suspend.h
+#include linux/fault-inject.h
+#include linux/random.h
 
 #include linux/mmc/card.h
 #include linux/mmc/host.h
@@ -83,6 +85,43 @@ static void mmc_flush_scheduled_work(void)
flush_workqueue(workqueue);
 }
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+
+/*
+ * Internal function. Inject random data errors.
+ * If mmc_data is NULL no errors are injected.
+ */
+static void mmc_should_fail_request(struct mmc_host *host,
+   struct mmc_request *mrq)
+{
+   struct mmc_command *cmd = mrq-cmd;
+   struct mmc_data *data = mrq-data;
+   static const int data_errors[] = {
+   -ETIMEDOUT,
+   -EILSEQ,
+   -EIO,
+   };
+
+   if (!data)
+   return;
+
+   if (cmd-error || data-error ||
+   !should_fail(host-fail_mmc_request, data-blksz * data-blocks))
+   return;
+
+   data-error = data_errors[random32() % ARRAY_SIZE(data_errors)];
+   data-bytes_xfered = (random32() % (data-bytes_xfered  9))  9;
+}
+
+#else /* CONFIG_FAIL_MMC_REQUEST */
+
+static inline void mmc_should_fail_request(struct mmc_host *host,
+  struct mmc_request *mrq)
+{
+}
+
+#endif /* CONFIG_FAIL_MMC_REQUEST */
+
 /**
  * mmc_request_done - finish processing an MMC request
  * @host: MMC host which completed request
@@ -109,6 +148,8 @@ void mmc_request_done(struct mmc_host *host, struct 
mmc_request *mrq)
cmd-error = 0;
host-ops-request(host, mrq);
} else {
+   mmc_should_fail_request(host, mrq);
+
led_trigger_event(host-led, LED_OFF);
 
pr_debug(%s: req done (CMD%u): %d: %08x %08x %08x %08x\n,
diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index 998797e..5acd707 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -12,6 +12,7 @@
 #include linux/seq_file.h
 #include linux/slab.h
 #include linux/stat.h
+#include linux/fault-inject.h
 
 #include linux/mmc/card.h
 #include linux/mmc/host.h
@@ -158,6 +159,23 @@ static int mmc_clock_opt_set(void *data, u64 val)
return 0;
 }
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+
+static DECLARE_FAULT_ATTR(fail_mmc_request);
+
+#ifdef KERNEL
+/*
+ * Internal function. Pass the boot param fail_mmc_request to
+ * the setup fault injection attributes routine.
+ */
+static int __init setup_fail_mmc_request(char *str)
+{
+   return setup_fault_attr(fail_mmc_request, str);
+}
+__setup(fail_mmc_request=, setup_fail_mmc_request);
+#endif /* KERNEL */
+#endif /* CONFIG_FAIL_MMC_REQUEST */
+
 DEFINE_SIMPLE_ATTRIBUTE(mmc_clock_fops, mmc_clock_opt_get, mmc_clock_opt_set,
%llu\n);
 
@@ -188,6 +206,13 @@ void mmc_add_host_debugfs(struct mmc_host *host)
root, host-clk_delay))
goto err_node;
 #endif
+#ifdef CONFIG_FAIL_MMC_REQUEST
+   host-fail_mmc_request = fail_mmc_request;
+   if (IS_ERR(fault_create_debugfs_attr(fail_mmc_request,
+root,
+host-fail_mmc_request)))
+   goto err_node;
+#endif
return;
 
 err_node:
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 1d09562..4c4bddf 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -12,6 +12,7 @@
 
 #include linux/leds.h
 #include linux/sched.h
+#include linux/fault-inject.h
 
 #include linux/mmc/core.h
 #include linux/mmc/pm.h
@@ -302,6 +303,10 @@ struct mmc_host {
 
struct mmc_async_req*areq;  /* active async req */
 
+#ifdef CONFIG_FAIL_MMC_REQUEST
+   struct fault_attr   fail_mmc_request;
+#endif
+
unsigned long   private[0] cacheline_aligned;
 };
 
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c0cb9c4..1c7dbbf 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1070,6

[RFC PATCH 2/4] ARM: EXYNOS4: Fix to work with origen boards.

2011-08-19 Thread Amit Daniel Kachhap

This adds a function to get the revision id.

Signed-off-by: Jaecheol Lee jc@samsung.com
Signed-off-by: Changhwan Youn chaos.y...@samsung.com
---
 arch/arm/mach-exynos4/cpu.c  |   10 ++
 arch/arm/plat-s5p/include/plat/exynos4.h |1 +
 2 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 2d8a40c..8b106b8 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -234,6 +234,16 @@ static int __init exynos4_l2x0_cache_init(void)
 early_initcall(exynos4_l2x0_cache_init);
 #endif
 
+int exynos4_subrev(void)
+{
+   static int subrev = -1;
+
+   if (unlikely(subrev  0))
+   subrev = readl(S5P_VA_CHIPID)  0xf;
+
+   return subrev;
+}
+
 int __init exynos4_init(void)
 {
printk(KERN_INFO EXYNOS4: Initializing architecture\n);
diff --git a/arch/arm/plat-s5p/include/plat/exynos4.h 
b/arch/arm/plat-s5p/include/plat/exynos4.h
index 907caab..d62f7f7 100644
--- a/arch/arm/plat-s5p/include/plat/exynos4.h
+++ b/arch/arm/plat-s5p/include/plat/exynos4.h
@@ -15,6 +15,7 @@
 extern void exynos4_common_init_uarts(struct s3c2410_uartcfg *cfg, int no);
 extern void exynos4_register_clocks(void);
 extern void exynos4_setup_clocks(void);
+extern int exynos4_subrev(void);
 
 #ifdef CONFIG_CPU_EXYNOS4210
 
-- 
1.7.1


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

[RFC PATCH 3/4] ARM: EXYNOS4: Add support AFTR mode cpuidle state on EXYNOS4210

2011-08-19 Thread Amit Daniel Kachhap

This patch adds support AFTR(ARM OFF TOP RUNNING) mode in
cpuidle driver. L2 cache keeps their data in this mode.

Signed-off-by: Jaecheol Lee jc@samsung.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
 arch/arm/mach-exynos4/Makefile   |2 +-
 arch/arm/mach-exynos4/cpuidle.c  |  131 +++-
 arch/arm/mach-exynos4/idle.S |  165 ++
 arch/arm/mach-exynos4/include/mach/pmu.h |5 +-
 4 files changed, 300 insertions(+), 3 deletions(-)
 create mode 100644 arch/arm/mach-exynos4/idle.S

diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
index 2e3a407..12568b0 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -16,7 +16,7 @@ obj-$(CONFIG_CPU_EXYNOS4210)  += cpu.o init.o clock.o 
irq-combiner.o
 obj-$(CONFIG_CPU_EXYNOS4210)   += setup-i2c0.o irq-eint.o dma.o pmu.o
 obj-$(CONFIG_PM)   += pm.o sleep.o
 obj-$(CONFIG_CPU_FREQ) += cpufreq.o
-obj-$(CONFIG_CPU_IDLE) += cpuidle.o
+obj-$(CONFIG_CPU_IDLE) += cpuidle.o idle.o
 
 obj-$(CONFIG_SMP)  += platsmp.o headsmp.o
 
diff --git a/arch/arm/mach-exynos4/cpuidle.c b/arch/arm/mach-exynos4/cpuidle.c
index bf7e96f..1164945 100644
--- a/arch/arm/mach-exynos4/cpuidle.c
+++ b/arch/arm/mach-exynos4/cpuidle.c
@@ -12,12 +12,24 @@
 #include linux/init.h
 #include linux/cpuidle.h
 #include linux/io.h
+#include linux/suspend.h
 
 #include asm/proc-fns.h
+#include asm/hardware/cache-l2x0.h
+#include asm/cacheflush.h
+
+#include mach/regs-pmu.h
+#include mach/pmu.h
+
+#define REG_DIRECTGO_ADDR  (S5P_VA_SYSRAM + 0x24)
+#define REG_DIRECTGO_FLAG  (S5P_VA_SYSRAM + 0x20)
 
 static int exynos4_enter_idle(struct cpuidle_device *dev,
  struct cpuidle_state *state);
 
+static int exynos4_enter_lowpower(struct cpuidle_device *dev,
+ struct cpuidle_state *state);
+
 static struct cpuidle_state exynos4_cpuidle_set[] = {
[0] = {
.enter  = exynos4_enter_idle,
@@ -27,6 +39,14 @@ static struct cpuidle_state exynos4_cpuidle_set[] = {
.name   = IDLE,
.desc   = ARM clock gating(WFI),
},
+   [1] = {
+   .enter  = exynos4_enter_lowpower,
+   .exit_latency   = 300,
+   .target_residency   = 10,
+   .flags  = CPUIDLE_FLAG_TIME_VALID,
+   .name   = LOW_POWER,
+   .desc   = ARM power down,
+   },
 };
 
 static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
@@ -36,6 +56,80 @@ static struct cpuidle_driver exynos4_idle_driver = {
.owner  = THIS_MODULE,
 };
 
+void exynos4_cpu_lp(void *stack_addr)
+{
+   /*
+* Refer to v7 cpu_suspend function.
+* From saveblk to stack_addr + (4 * 3) + (4 * 9)
+* 4byte * (v:p offset, virt sp, phy resume fn)
+* cpu_suspend_size = 4 * 9 (from proc-v7.S)
+* Min L2 cache clean size = 36 + 12 + 36 = 84
+*/
+
+   outer_clean_range(virt_to_phys(stack_addr), 84);
+
+   /* To clean sleep_save_sp area */
+
+   outer_clean_range(virt_to_phys(cpu_resume), 64);
+
+   cpu_do_idle();
+}
+
+/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
+static void exynos4_set_wakeupmask(void)
+{
+   __raw_writel(0xff3e, S5P_WAKEUP_MASK);
+}
+
+static int exynos4_enter_core0_aftr(struct cpuidle_device *dev,
+   struct cpuidle_state *state)
+{
+   struct timeval before, after;
+   int idle_time;
+   unsigned long tmp;
+
+   local_irq_disable();
+   do_gettimeofday(before);
+
+   exynos4_set_wakeupmask();
+
+   __raw_writel(virt_to_phys(exynos4_idle_resume), REG_DIRECTGO_ADDR);
+   __raw_writel(0xfcba0d10, REG_DIRECTGO_FLAG);
+
+   /* Set value of power down register for aftr mode */
+   exynos4_sys_powerdown_conf(SYS_AFTR);
+
+   /* Setting Central Sequence Register for power down mode */
+   tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
+   tmp = ~S5P_CENTRAL_LOWPWR_CFG;
+   __raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
+
+   exynos4_enter_lp(0, PLAT_PHYS_OFFSET - PAGE_OFFSET);
+
+   /*
+* If PMU failed while entering sleep mode, WFI will be
+* ignored by PMU and then exiting cpu_do_idle().
+* S5P_CENTRAL_LOWPWR_CFG bit will not be set automatically
+* in this situation.
+*/
+   tmp = __raw_readl(S5P_CENTRAL_SEQ_CONFIGURATION);
+   if (!(tmp  S5P_CENTRAL_LOWPWR_CFG)) {
+   tmp |= S5P_CENTRAL_LOWPWR_CFG;
+   __raw_writel(tmp, S5P_CENTRAL_SEQ_CONFIGURATION);
+   }
+   cpu_init();
+   /* Clear wakeup state register */
+   __raw_writel(0x0, S5P_WAKEUP_STAT);
+
+

Re: Android gcc 4.6 1107 optimization benchmark

2011-08-19 Thread Ramana Radhakrishnan

On 19 August 2011 13:40, Christian Robottom Reis k...@linaro.org wrote:
 On Fri, Aug 19, 2011 at 03:40:26AM +0100, Chao Yang wrote:
 The image size increases significantly when -O3 is enabled for thumb files,

 Size goes /up/ when enabling thumb? That's definitely unexpected.

The size increas is probably more driven by O3 rather than Thumb I
suspect. If there are where ARM state is smaller than Thumb state but
we should look at those but then you've got to be comparing O3 and
-marm and O3 and -mthumb to be comparing apples and apples.

cheers
Ramana

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

Re: [RFC PATCH 2/4] ARM: EXYNOS4: Fix to work with origen boards.

2011-08-19 Thread Kyungmin Park

On Fri, Aug 19, 2011 at 10:09 PM, Amit Daniel Kachhap
amit.kach...@linaro.org wrote:
 This adds a function to get the revision id.

 Signed-off-by: Jaecheol Lee jc@samsung.com
 Signed-off-by: Changhwan Youn chaos.y...@samsung.com
 ---
  arch/arm/mach-exynos4/cpu.c              |   10 ++
  arch/arm/plat-s5p/include/plat/exynos4.h |    1 +
  2 files changed, 11 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
 index 2d8a40c..8b106b8 100644
 --- a/arch/arm/mach-exynos4/cpu.c
 +++ b/arch/arm/mach-exynos4/cpu.c
 @@ -234,6 +234,16 @@ static int __init exynos4_l2x0_cache_init(void)
  early_initcall(exynos4_l2x0_cache_init);
  #endif

 +int exynos4_subrev(void)
 +{
 +       static int subrev = -1;
 +
 +       if (unlikely(subrev  0))
 +               subrev = readl(S5P_VA_CHIPID)  0xf;
How about to add the clock control here?
1. Register chipid clk
2. Get the chipid clk
3. Read CHPIID,
4. Put tht chipid clk.

Then you can save some power.

Thank you,
Kyungmin Park
 +
 +       return subrev;
 +}
 +
  int __init exynos4_init(void)
  {
        printk(KERN_INFO EXYNOS4: Initializing architecture\n);
 diff --git a/arch/arm/plat-s5p/include/plat/exynos4.h 
 b/arch/arm/plat-s5p/include/plat/exynos4.h
 index 907caab..d62f7f7 100644
 --- a/arch/arm/plat-s5p/include/plat/exynos4.h
 +++ b/arch/arm/plat-s5p/include/plat/exynos4.h
 @@ -15,6 +15,7 @@
  extern void exynos4_common_init_uarts(struct s3c2410_uartcfg *cfg, int no);
  extern void exynos4_register_clocks(void);
  extern void exynos4_setup_clocks(void);
 +extern int exynos4_subrev(void);

  #ifdef CONFIG_CPU_EXYNOS4210

 --
 1.7.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


___
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

On Fri, Aug 19, 2011 at 12:48 PM, Jamie Iles ja...@jamieiles.com wrote:
 On Fri, Aug 19, 2011 at 11:53:50AM +0200, Linus Walleij wrote:
 +Interaction with the GPIO subsystem
 +===
 +
 +The GPIO drivers may want to perform operations of various types on the same
 +physical pins that are also registered as GPIO pins.
 +
 +Since the pin controller subsystem have its pinspace local to the pin
 +controller we need a mapping so that the pin control subsystem can figure 
 out
 +which pin controller handles control of a certain GPIO pin. This member
 +in the pin controller descriptor handles this mapping:
 +
 +static struct pinctrl_desc foo_desc = {
 +     ...
 +     .gpio_base = FIRST_PIN,
 +};
 +
 +When GPIO-specific functions in the pin control subsystem are called, these
 +mappings will be used to look up the apropriate pin controller by inspecting
 +and matching the pin to this pin range.

 On our (difficultly muxed!) platform we have two types of GPIO - a
 Synopsys controller which is a fairly conventional GPIO controller, then
 a sigma-delta GPIO controller which can also do a an analogue type
 output (as well as digital).

Does that mean it is really not a GPIO controller but a kind of D/A converter?

  For lots of our pads they can either be
 ARM GPIO, SD GPIO or some other function, so I don't see how this fits
 in with a single GPIO base.

And each of them are modeled as a separate gpio_chip I guess?

Otherwise it's a bad match with reality. We had this discussion with GRant
where two gpio_chips would use the same number range in the GPIO
global pinspace, and it's basically not allowed IIRC.

But yes, there is an assumption that each pin controller will only
deal with one block of GPIO pins. So if I make it possible to support
several GPIO ranges for one pin controller, does that solve your problem?

Like this:

struct pinctrl_gpio_range {
char *name;
unsigned int base;
unsigned int npins;
}

static unsigned int gpio_ranges[] = {
{
.name=chip1,
.base = 0,
.npins = 16,
},
{
.name = chip2,
.base = 32,
.npins = 16,
},
{
.name = chip3,
.base = 64,
.npins = 16,
},
};

static struct pinctrl_desc foo_desc = {
...
.gpio_ranges = gpio_ranges,
.num_gpio_ranges = ARRAY_SIZE(gpio_ranges),
};

For three different 32-bit GPIO controllers muxed on
pins 0..31 using GPIO space pins from 0..95.

Then I pass the number of the instance down to the
driver in the gpio_request_enable() callback like
this:

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

Would this work?

This has a restriction: the GPIO space must be mapped in
continous ranges, as must the pin controller. Else we need
one entry per pin in the list above...

 +The correspondence for the range from the GPIO subsystem to the pin 
 controller
 +subsystem must be one-to-one. Thus the GPIO pins are in the pin controller
 +range [0 .. maxpin] where maxpin is the specified end of the pin range.

 So doesn't this mean that the enumeration that was initially described
 as arbitrary actually has to enumerate the GPIO pins first?

If you use GPIO accessors, the enumeration has to match.
So I rewrite it like this:

this enumeration was arbitrarily chosen, in practice you need to think
through your numbering system so that it matches the layout of registers
and such things in your driver, or the code may become complicated. You must
also consider matching of offsets to the GPIO ranges that may be handled by
the pin controller.

OK?

 +static struct class pinctrl_class = {
 +     .name = pinctrl,
 +     .dev_release = pinctrl_dev_release,
 +     .dev_attrs = pinctrl_dev_attrs,
 +};

 Greg K-H has mentioned in the past that class is now deprecated for new
 use and that a bus_type should be used instead.

Can you provide a reference with some detail?
The pin control devices are usually aleady on a bus like the
platform_bus or amba_bus or i2c_bus, then they register a
class device in this case.

The kerneldoc documentation says
A bus is a channel between the processor and one or more devices.

This isn't the case here.

Anyhthing that help me understand this is appreciated, Arnd?

 +/**
 + * struct pinctrl_desc - pin controller descriptor, register this to pin
 + * control subsystem
 + * @name: name for the pin controller
 + * @pins: an array of pin descriptors describing all the pins handled by
 + *   this pin controller
 + * @npins: number of descriptors in the array, usually just ARRAY_SIZE()
 + *   of the pins field above
 + * @maxpin: since pin spaces may be sparse, there can he holes in the
 + *   pin range, this attribute gives the maximum pin number in the
 + *   total range. This should not be lower than npins for example,
 + *   but may be equal to npins if you have no holes in the pin range.
 + * @pmxops: pinmux operation vtable, if

RE: [PATCH] ARM: EXYNOS4: ADD USB EHCI device to SMDKV310

2011-08-19 Thread Kukjin Kim

Sachin Kamat wrote:
 
 Signed-off-by: Bhuvana Kakunoori bhuvana.kakuno...@linaro.org
 Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
 ---
  arch/arm/mach-exynos4/Kconfig |2 ++
  arch/arm/mach-exynos4/mach-smdkv310.c |   16 
  2 files changed, 18 insertions(+), 0 deletions(-)
 
 diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
 index bb29d51..cc97d23 100644
 --- a/arch/arm/mach-exynos4/Kconfig
 +++ b/arch/arm/mach-exynos4/Kconfig
 @@ -136,6 +136,7 @@ config MACH_SMDKV310
   bool SMDKV310
   select CPU_EXYNOS4210
   select S5P_DEV_FIMD0
 + select S5P_DEV_USB_EHCI
   select S3C_DEV_RTC
   select S3C_DEV_WDT
   select S3C_DEV_I2C1
 @@ -151,6 +152,7 @@ config MACH_SMDKV310
   select SAMSUNG_DEV_PWM
   select EXYNOS4_DEV_SYSMMU
   select EXYNOS4_SETUP_FIMD0
 + select EXYNOS4_SETUP_USB_PHY
   select EXYNOS4_SETUP_I2C1
   select EXYNOS4_SETUP_KEYPAD
   select EXYNOS4_SETUP_SDHCI
 diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
 exynos4/mach-smdkv310.c
 index 5f62b2b..b6c28ea 100644
 --- a/arch/arm/mach-exynos4/mach-smdkv310.c
 +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
 @@ -33,6 +33,8 @@
  #include plat/gpio-cfg.h
  #include plat/backlight.h
  #include plat/mfc.h
 +#include plat/ehci.h
 +#include plat/clock.h
 
  #include mach/map.h
 
 @@ -167,6 +169,16 @@ static struct i2c_board_info i2c_devs1[] __initdata =
{
   {I2C_BOARD_INFO(wm8994, 0x1a),},
  };
 
 +/* USB EHCI */
 +static struct s5p_ehci_platdata smdkv310_ehci_pdata;
 +
 +static void __init smdkv310_ehci_init(void)
 +{
 + struct s5p_ehci_platdata *pdata = smdkv310_ehci_pdata;
 +
 + s5p_ehci_set_platdata(pdata);
 +}
 +
  static struct platform_device *smdkv310_devices[] __initdata = {
   s3c_device_hsmmc0,
   s3c_device_hsmmc1,
 @@ -175,6 +187,7 @@ static struct platform_device *smdkv310_devices[]
 __initdata = {
   s3c_device_i2c1,
   s3c_device_rtc,
   s3c_device_wdt,
 + s5p_device_ehci,
   exynos4_device_ac97,
   exynos4_device_i2s0,
   samsung_device_keypad,
 @@ -258,6 +271,9 @@ static void __init smdkv310_machine_init(void)
 
   samsung_bl_set(smdkv310_bl_gpio_info, smdkv310_bl_data);
 
 + smdkv310_ehci_init();
 + clk_xusbxti.rate = 2400;
 +
   platform_add_devices(smdkv310_devices,
 ARRAY_SIZE(smdkv310_devices));
   s5p_device_mfc.dev.parent = exynos4_device_pd[PD_MFC].dev;
  }
 --
 1.7.4.1

(Cc'ed Jingoo Han)

Well, this is same with Jingoo's patch on smdkc210 which has been submitted
at 12th Aug.

I requested to him to re-work this on smdkv310 on his patch just now...
Hmm...I don't know :(

Let me think again...

Thanks.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, 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 v9 2/3] mmc: core: add random fault injection

2011/8/19 Per Forlin per.for...@stericsson.com:

 From: Per Forlin per.for...@linaro.org

 This adds support to inject data errors after a completed host transfer.
 The mmc core will return error even though the host transfer is successful.
 This simple fault injection proved to be very useful to test the
 non-blocking error handling in the mmc_blk_issue_rw_rq().
 Random faults can also test how the host driver handles pre_req()
 and post_req() in case of errors.

 Signed-off-by: Per Forlin per.for...@linaro.org
 Acked-by: Akinobu Mita akinobu.m...@gmail.com

OK!

Reviewed-by: Linus Walleij linus.wall...@linaro.org
For the MMC portions in 2/3.

Linus Walleij

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

[PATCH v5] usb: gadget: storage: make FSG_NUM_BUFFERS variable size

From: Per Forlin per.for...@linaro.org

FSG_NUM_BUFFERS is set to 2 as default.
Usually 2 buffers are enough to establish a good buffering pipeline.
The number may be increased in order to compensate a for bursty VFS
behaviour.

Here follows a description of system that may require more than
2 buffers.
 * CPU ondemand governor active
 * latency cost for wake up and/or frequency change
 * DMA for IO

Use case description.
 * Data transfer from MMC via VFS to USB.
 * DMA shuffles data from MMC and to USB.
 * The CPU wakes up every now and then to pass data in and out from VFS,
   which cause the bursty VFS behaviour.

Test set up
 * Running dd on the host reading from the mass storage device
 * cmdline: dd if=/dev/sdb of=/dev/null bs=4k count=$((256*100))
 * Caches are dropped on the host and on the device before each run

Measurements on a Snowball board with ondemand_govenor active.

FSG_NUM_BUFFERS 2
104857600 bytes (105 MB) copied, 5.62173 s, 18.7 MB/s
104857600 bytes (105 MB) copied, 5.61811 s, 18.7 MB/s
104857600 bytes (105 MB) copied, 5.57817 s, 18.8 MB/s

FSG_NUM_BUFFERS 4
104857600 bytes (105 MB) copied, 5.26839 s, 19.9 MB/s
104857600 bytes (105 MB) copied, 5.2691 s, 19.9 MB/s
104857600 bytes (105 MB) copied, 5.2711 s, 19.9 MB/s

There may not be one optimal number for all boards. This is why
the number is added to Kconfig. If selecting USB_GADGET_DEBUG_FILES
this value may be set by a module parameter as well.

Signed-off-by: Per Forlin per.for...@linaro.org
---
Change log.
v2: Update after proofreading comments from Michal Nazarewicz
v3: Clarify the description of this patch based on input from Alan Stern
v4: - Introduce a module_param to set number of pipeline buffers
if USB_DEBUG is set. In order to add this support fsg_common is
allocated at runtime. The fsg_buffhd list size is appended to fsg_dev
and fsg_common at runtime allocation.
- The previous acks from Michal and Alan on v3 are not applicable
for this version since it's a new implementation.
v5: - Separate allocation of buffhds in f_mass_storage.c
- Change FSG_NUM_BUFFERS to fsg_num_buffers to indicate variable value.
- code clean up and document module param, all thanks to Michal and Alan.

 drivers/usb/gadget/Kconfig  |   16 
 drivers/usb/gadget/f_mass_storage.c |   24 
 drivers/usb/gadget/file_storage.c   |   26 --
 drivers/usb/gadget/mass_storage.c   |3 +++
 drivers/usb/gadget/multi.c  |3 +++
 drivers/usb/gadget/storage_common.c |   25 +++--
 6 files changed, 77 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 44b6b40..65ceecf 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -96,6 +96,22 @@ config USB_GADGET_VBUS_DRAW
   This value will be used except for system-specific gadget
   drivers that have more specific information.
 
+config USB_GADGET_STORAGE_NUM_BUFFERS
+   int Number of storage pipeline buffers
+   range 2 4
+   default 2
+   help
+  Usually 2 buffers are enough to establish a good buffering
+  pipeline. The number may be increased in order to compensate
+  for a bursty VFS behaviour. For instance there may be cpu wake up
+  latencies that makes the VFS to appear bursty in a system with
+  an cpu on-demand governor. Especially if DMA is doing IO to
+  offload the CPU. In this case the CPU will go into power
+  save often and spin up occasionally to move data within VFS.
+  If selecting USB_GADGET_DEBUG_FILES this value may be set by
+  a module parameter as well.
+  If unsure, say 2.
+
 #
 # USB Peripheral Controller Support
 #
diff --git a/drivers/usb/gadget/f_mass_storage.c 
b/drivers/usb/gadget/f_mass_storage.c
index 5b93395..49da6a1 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -363,7 +363,7 @@ struct fsg_common {
 
struct fsg_buffhd   *next_buffhd_to_fill;
struct fsg_buffhd   *next_buffhd_to_drain;
-   struct fsg_buffhd   buffhds[FSG_NUM_BUFFERS];
+   struct fsg_buffhd   *buffhds;
 
int cmnd_size;
u8  cmnd[MAX_COMMAND_SIZE];
@@ -2348,7 +2348,7 @@ reset:
if (common-fsg) {
fsg = common-fsg;
 
-   for (i = 0; i  FSG_NUM_BUFFERS; ++i) {
+   for (i = 0; i  fsg_num_buffers; ++i) {
struct fsg_buffhd *bh = common-buffhds[i];
 
if (bh-inreq) {
@@ -2406,7 +2406,7 @@ reset:
clear_bit(IGNORE_BULK_OUT, fsg-atomic_bitflags);
 
/* Allocate the requests */
-   for (i = 0; i  FSG_NUM_BUFFERS; ++i) {
+   for (i = 0; i  fsg_num_buffers; ++i) {
struct fsg_buffhd   *bh = common-buffhds[i];
 
rc =

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

2011-08-19 Thread Arnd Bergmann

On Friday 19 August 2011, Linus Walleij wrote:
 On Fri, Aug 19, 2011 at 12:48 PM, Jamie Iles ja...@jamieiles.com wrote:
 
  +static struct class pinctrl_class = {
  + .name = pinctrl,
  + .dev_release = pinctrl_dev_release,
  + .dev_attrs = pinctrl_dev_attrs,
  +};
 
  Greg K-H has mentioned in the past that class is now deprecated for new
  use and that a bus_type should be used instead.
 
 Can you provide a reference with some detail?
 The pin control devices are usually aleady on a bus like the
 platform_bus or amba_bus or i2c_bus, then they register a
 class device in this case.
 
 The kerneldoc documentation says
 A bus is a channel between the processor and one or more devices.
 
 This isn't the case here.
 
 Anyhthing that help me understand this is appreciated, Arnd?

Taking Greg on Cc as well.

The main difference between a normal device and a class device is
that one is linked from /sys/bus/*/devices/* and the other is linked
from /sys/class/*/*. However, they both live in /sys/devices/.../*
as directories.

I always liked the separation between the two, although there are
a few cases where there is a grey area (e.g. /sys/bus/hid or
/sys/class/mmc_host) and the abstraction doesn't really fit.

IIRC Greg would prefer now to never have had the distinction
and wants to make all future uses use a bus_type.

Arnd

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

Re: Android gcc 4.6 1107 optimization benchmark

2011-08-19 Thread Bernhard Rosenkranzer

Hi,

On 18 August 2011 19:40, Chao Yang chao.y...@linaro.org wrote:
 The results can be found
 at https://wiki.linaro.org/ChaoYang/Sandbox/gccoptimization.

Interesting... I'd have expected getting rid of -fno-strict-aliasing
gives the biggest performance boost, but I'd have expected O3 to be a
bit more effective than it is...
Are you sure the relevant parts actually use O3 (keep in mind that
e.g. -O3 + -Os = -Os -- whatever is specified later (LOCAL_CFLAGS,
...) is effective)?

Could you add another combination to the benchmark? I'm curious about
-O3 -fno-inline-functions (function inlining is always a bit of a
2-edged sword because of the code size increases...)

ttyl
bero

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

Re: Android gcc 4.6 1107 optimization benchmark

2011-08-19 Thread Chao Yang

HI Bero,

What I did was changing both Os and O2 to O3 in TARGET_linux-arm.mk. I did
not change those O2/Os specified in each module internally. As there may be
a reason for the module itself to specify the optimisation level. I think it
is risky to change those. But I don't think it should be a big problem.

Thanks and regards
Chao

On 19 August 2011 15:38, Bernhard Rosenkranzer 
bernhard.rosenkran...@linaro.org wrote:

 Hi,

 On 18 August 2011 19:40, Chao Yang chao.y...@linaro.org wrote:
  The results can be found
  at https://wiki.linaro.org/ChaoYang/Sandbox/gccoptimization.

 Interesting... I'd have expected getting rid of -fno-strict-aliasing
 gives the biggest performance boost, but I'd have expected O3 to be a
 bit more effective than it is...
 Are you sure the relevant parts actually use O3 (keep in mind that
 e.g. -O3 + -Os = -Os -- whatever is specified later (LOCAL_CFLAGS,
 ...) is effective)?

 Could you add another combination to the benchmark? I'm curious about
 -O3 -fno-inline-functions (function inlining is always a bit of a
 2-edged sword because of the code size increases...)

 ttyl
 bero




-- 

Chao Yang
Android Platform Team
Linaro.org │ Open source software for ARM SoCs
Follow Linaro:
http://www.facebook.com/pages/Linaro/155974581091106
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 v2 04/11]Power: DA9052 battery driver

2011-08-19 Thread Anton Vorontsov

On Thu, Aug 04, 2011 at 06:17:52PM +0530, ashishj3 wrote:
 On Fri, 2011-07-22 at 18:22 +0530, ashishj3 wrote: 
  Driver for DA9052 battery charger. This driver depends on DA9052 MFD core 
  dirver
  for definitions and methods.
  
  Signed-off-by: David Dajun Chen dc...@diasemi.com
  Signed-off-by: Ashish Jangam ashish.jan...@kpitcummins.com
  ---
  Changes since v2
  - Correct code styling for inline functions
  - Remove averaging algorithm
  - Set use_for_apm thru board specific parameter
  ---
 Any comments on this patch?

Despite some cosmetic issues, the patch looks OK to me.

So, I'm fine if it goes via MFD tree.

Although, if you ever need to respin this patch, try to make the
code fully conform to the Linux coding style.

Thanks,

-- 
Anton Vorontsov
Email: cbouatmai...@gmail.com

___
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-08-19 Thread Jamie Iles

Hi Linus,

On Fri, Aug 19, 2011 at 04:04:54PM +0200, Linus Walleij wrote:
 On Fri, Aug 19, 2011 at 12:48 PM, Jamie Iles ja...@jamieiles.com wrote:
  On Fri, Aug 19, 2011 at 11:53:50AM +0200, Linus Walleij wrote:
  +Interaction with the GPIO subsystem
  +===
  +
  +The GPIO drivers may want to perform operations of various types on the 
  same
  +physical pins that are also registered as GPIO pins.
  +
  +Since the pin controller subsystem have its pinspace local to the pin
  +controller we need a mapping so that the pin control subsystem can figure 
  out
  +which pin controller handles control of a certain GPIO pin. This member
  +in the pin controller descriptor handles this mapping:
  +
  +static struct pinctrl_desc foo_desc = {
  +     ...
  +     .gpio_base = FIRST_PIN,
  +};
  +
  +When GPIO-specific functions in the pin control subsystem are called, 
  these
  +mappings will be used to look up the apropriate pin controller by 
  inspecting
  +and matching the pin to this pin range.
 
  On our (difficultly muxed!) platform we have two types of GPIO - a
  Synopsys controller which is a fairly conventional GPIO controller, then
  a sigma-delta GPIO controller which can also do a an analogue type
  output (as well as digital).
 
 Does that mean it is really not a GPIO controller but a kind of D/A converter?

Kind of.  In the basic mode it's just a GPIO controller that does 
digital I/O.  In the SD mode it all really depends on what the external 
filter looks like.  As gpio_set_value() takes an int as the value, then 
the gpio controller theoretically _could_ treat that as an analogue 
output value and use the pinctrl api to set the converter and rate sizes 
but I don't really want to go there yet as it's a bit of an abuse of the 
gpio API!

   For lots of our pads they can either be
  ARM GPIO, SD GPIO or some other function, so I don't see how this fits
  in with a single GPIO base.
 
 And each of them are modeled as a separate gpio_chip I guess?
 
 Otherwise it's a bad match with reality. We had this discussion with GRant
 where two gpio_chips would use the same number range in the GPIO
 global pinspace, and it's basically not allowed IIRC.

Yes, the SD-GPIO isn't memory mapped so has a completely separte 
gpio_chip.

 But yes, there is an assumption that each pin controller will only
 deal with one block of GPIO pins. So if I make it possible to support
 several GPIO ranges for one pin controller, does that solve your problem?
 
 Like this:
 
 struct pinctrl_gpio_range {
 char *name;
 unsigned int base;
 unsigned int npins;
 }
 
 static unsigned int gpio_ranges[] = {
 {
 .name=chip1,
 .base = 0,
 .npins = 16,
 },
 {
 .name = chip2,
 .base = 32,
 .npins = 16,
 },
 {
 .name = chip3,
 .base = 64,
 .npins = 16,
 },
 };
 
 static struct pinctrl_desc foo_desc = {
 ...
 .gpio_ranges = gpio_ranges,
 .num_gpio_ranges = ARRAY_SIZE(gpio_ranges),
 };
 
 For three different 32-bit GPIO controllers muxed on
 pins 0..31 using GPIO space pins from 0..95.
 
 Then I pass the number of the instance down to the
 driver in the gpio_request_enable() callback like
 this:
 
 int (*gpio_request_enable) (struct pinctrl_dev *pctldev,
   unsigned instance,
   unsigned offset);
 
 Would this work?
 
 This has a restriction: the GPIO space must be mapped in
 continous ranges, as must the pin controller. Else we need
 one entry per pin in the list above...

OK, that looks perfect!

  +The correspondence for the range from the GPIO subsystem to the pin 
  controller
  +subsystem must be one-to-one. Thus the GPIO pins are in the pin controller
  +range [0 .. maxpin] where maxpin is the specified end of the pin range.
 
  So doesn't this mean that the enumeration that was initially described
  as arbitrary actually has to enumerate the GPIO pins first?
 
 If you use GPIO accessors, the enumeration has to match.
 So I rewrite it like this:
 
 this enumeration was arbitrarily chosen, in practice you need to think
 through your numbering system so that it matches the layout of registers
 and such things in your driver, or the code may become complicated. You must
 also consider matching of offsets to the GPIO ranges that may be handled by
 the pin controller.
 
 OK?

Sounds good.

  +static struct class pinctrl_class = {
  +     .name = pinctrl,
  +     .dev_release = pinctrl_dev_release,
  +     .dev_attrs = pinctrl_dev_attrs,
  +};
 
  Greg K-H has mentioned in the past that class is now deprecated for new
  use and that a bus_type should be used instead.
 
 Can you provide a reference with some detail?
 The pin control devices are usually aleady on a bus like the
 platform_bus or amba_bus or i2c_bus, then they register a
 class device in this case.
 
 The kerneldoc documentation says
 A bus is a channel between the processor and one or more devices.

Re: [PATCH dri2proto] RFC: video support for dri2

2011-08-19 Thread Rob Clark

On Fri, Aug 19, 2011 at 5:18 AM, Pauli Nieminen
pauli.niemi...@linux.intel.com wrote:
 On Thu, Aug 18, 2011 at 09:58:07PM -0500, Rob Clark wrote:
 From: Rob Clark r...@ti.com

 To allow the potential use of overlays to display video content, a few
 extra parameters are required:

  + source buffer in different format (for example, various YUV formats)
    and size as compared to destination drawable
  + multi-planar formats where discontiguous buffers are used for
    different planes.  For example, luma and chroma split across
    multiple memory banks or with different tiled formats.
  + flipping between multiple back buffers, perhaps not in order (to
    handle video formats with B-frames)
  + cropping during swap.. in case of video, perhaps the required hw
    buffers are larger than the visible picture to account for codec
    borders (for example, reference frames where a block/macroblock
    moves past the edge of the visible picture, but back again in
    subsequent frames).

 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.
 ---
 Eventually this should replace Xv.  With a few additions, like attributes,
 it could perhaps be possible to implement the client side Xv API on top
 of dri2.

 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.

 In either case, I will implement the xserver side infrastructure, but
 I wanted to get some feel for what is the preferred approach (extend
 dri2 or new videoproto) first.


 XvPutVideo is already existing alternative to use for video playback
 to overlays. But XvPutVideo API isn't perfect for the job either.

We have until now actually used an unholy marriage of v4l2 and
XvPutVideo.. part of the motivation to either extend dri2 or introduce
a direct-video-rendering proto is have a better solution for some of
the sort-comings of the current solution:

+ currently the client has to realize it is using an overlay.. and
which overlay.. switching between overlay and GPU blitting is not
transparent to the client
+ which results in a resource management issue if there are multiple
videos playing, or if you need to scale beyond what can be done w/
overlay, etc
+ in some cases, you might want some way for the window-manager to
signal to xorg driver to switch to blitting because there are some
transformational effects.. ie. wobbly windows and that sort of thing..
(I'm thinking maybe setting some property on the root window?)
Ideally this would be transparent to the video player app.

some of this could be accomplished w/ XvPutImage, but then you are
restricted to memory that can be obtained from shmem, which is not
sufficient for hw video codecs in most cases.


 How would client know which formats are supported by driver? Xv expose
 list of supported image formats to client.

well, in current version of the patch, the client would just have to
know..  which is sort of how it is on the 3d side for dri2.

Although if there was an attribute mechanism, then I guess we could
actually make it possible to have a completely generic client.  One
other issue to tackle then is what exactly is the buffer name.
Currently for dri2 this is left as an implementation detail between
the client and server.  But we could decree that it is a GEM buffer
flink name, or possibly that it is a dmabuf file-descriptor (see
http://lists.linaro.org/pipermail/linaro-mm-sig/2011-August/000509.html
)

For a first step, I was ok that the client side of the dri2 connection
would have to know some implementation details of the xorg driver that
it is talking too, since this is how it already is for dri2, and it
could be handled by an approach like vaapi/vdpau where there is some
driver specific code on the client side, above dri2.

But on the other hand, allowing for a completely generic client using
the video/dri2 proto could be interesting.  I guess it depends on what
folk's general feeling is.. if completely generic client side is
important, then I'll go back and start adding attributes and this sort
of thing.  I think it is doable although it would require adding more
to dri2proto than what I have proposed so far.

  dri2proto.txt |   60 
 -
  1 files changed, 59 insertions(+), 1 deletions(-)

 diff --git a/dri2proto.txt b/dri2proto.txt
 index df763c7..aa83b1a 100644
 --- a/dri2proto.txt

Re: [PATCH v5] usb: gadget: storage: make FSG_NUM_BUFFERS variable size

2011/8/19 Michal Nazarewicz min...@mina86.com:
 On Fri, 19 Aug 2011 16:28:25 +0200, Per Forlin per.for...@stericsson.com
 wrote:

 @@ -3605,6 +3608,9 @@ static int __init fsg_init(void)
        int             rc;
        struct fsg_dev  *fsg;
 +       if (!FSG_NUM_BUFFERS_IS_VALID(fsg_num_buffers))

 Care to add pr_err() here?  Or better yet, change fsg_num_buffers_is_valid()
 to a function, eg.:

 static inline int fsg_num_buffers_validate()
 {
        if (fsg_num_buffers  fsg_num_buffers = 4)
                return 0;
        pr_err(fsg_num_buffers too high: %u\n, fsg_num_buffers);
        return -EINVAL;
 }

Look good.
This will permit only 1 buffer to be used. Is this intentionally? I'm
fine with it.
In Kconfig the range is 2 to 4. For debug purposes there may be a
point of permitting range 1 to 4.

 +               return -EINVAL;
 +
        if ((rc = fsg_alloc()) != 0)
                return rc;
        fsg = the_fsg;


 diff --git a/drivers/usb/gadget/mass_storage.c
 b/drivers/usb/gadget/mass_storage.c
 index d3eb274..fa6dedf 100644
 --- a/drivers/usb/gadget/mass_storage.c
 +++ b/drivers/usb/gadget/mass_storage.c
 @@ -179,6 +179,9 @@ MODULE_LICENSE(GPL);
 static int __init msg_init(void)
  {
 +       if (!FSG_NUM_BUFFERS_IS_VALID(fsg_num_buffers))
 +               return -EINVAL;
 +
        return usb_composite_probe(msg_driver, msg_bind);
  }
  module_init(msg_init);
 diff --git a/drivers/usb/gadget/multi.c b/drivers/usb/gadget/multi.c
 index 8c7b747..5f146da 100644
 --- a/drivers/usb/gadget/multi.c
 +++ b/drivers/usb/gadget/multi.c
 @@ -360,6 +360,9 @@ static struct usb_composite_driver multi_driver = {
 static int __init multi_init(void)
  {
 +       if (!FSG_NUM_BUFFERS_IS_VALID(fsg_num_buffers))
 +               return -EINVAL;
 +
        return usb_composite_probe(multi_driver, multi_bind);
  }
  module_init(multi_init);

 I'd move the check from those two places to fsg_common_init().

good point.


 Other then the above minor comments and buffers never being freed in
 f_mass_storage.c, the code looks good to me.

I'll fix these and send out a new version.

Many thanks,
Per

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

Re: [PATCH --mmotm v8 0/3] Make fault injection available for MMC IO

2011-08-19 Thread Chris Ball

Hi Per,

On Fri, Aug 19 2011, Per Forlin wrote:
 Hi Chris,

 It's no longer necessary to merge this through the mm-tree since
 Akinobu's patch fault-injection: add ability to export fault_attr in
 arbitrary directory is in mainline.
 Chris, would you mind merging the fault-injection patches in this
 patchset to mmc-next once the mmc part of this patchset is acked and
 accepted?

That's fine -- merged to mmc-next for 3.2 now, with Linus W's review.

Thanks,

- Chris.
-- 
Chris Ball   c...@laptop.org   http://printf.net/
One Laptop Per Child

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

Linaro 11.08 + libjpeg-turbo for linux + android

2011-08-19 Thread Tom Gall

All,

The current 1.1.90 code with mandeep's reworked change that was
accepted yesterday passes all make test and correctly displays the
android reference image that was showing quality problems with the
older 1.1.1 androidized proof of concept.

Given this situation for Linaro's 11.08 release we are going to ship
the upstream 1.1.90 version. I do not believe we should do any further
development with the older 1.1.x branch of code.  This works well for
linux and will make Monday's RC build. (for those on the
libjpeg-turbo-devel list, Linaro ships a reference image every month)

For android the situation is a little less clear. Basically we'll need
to re-forward-port the android specific changes to the 1.1.90 code. It
will take some time and we will submit this upstream to the
libjpeg-turbo project of course. I don't want a hack like the POC for
android was. So for the android team short term I think it's your
choice, you can continue to include the 1.1.1 POC in your builds but
for things that might be busted, you get to keep both halves. I think
the POC has served it's purpose and now's the time to focus on what
will benefit both the Linaro Android WG, the upstream libjpeg-turbo
community longer term.

Thanks!

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

2011-08-19 Thread Greg KH

On Fri, Aug 19, 2011 at 04:36:28PM +0200, Arnd Bergmann wrote:
 On Friday 19 August 2011, Linus Walleij wrote:
  On Fri, Aug 19, 2011 at 12:48 PM, Jamie Iles ja...@jamieiles.com wrote:
  
   +static struct class pinctrl_class = {
   + .name = pinctrl,
   + .dev_release = pinctrl_dev_release,
   + .dev_attrs = pinctrl_dev_attrs,
   +};
  
   Greg K-H has mentioned in the past that class is now deprecated for new
   use and that a bus_type should be used instead.
  
  Can you provide a reference with some detail?
  The pin control devices are usually aleady on a bus like the
  platform_bus or amba_bus or i2c_bus, then they register a
  class device in this case.
  
  The kerneldoc documentation says
  A bus is a channel between the processor and one or more devices.
  
  This isn't the case here.
  
  Anyhthing that help me understand this is appreciated, Arnd?
 
 Taking Greg on Cc as well.
 
 The main difference between a normal device and a class device is
 that one is linked from /sys/bus/*/devices/* and the other is linked
 from /sys/class/*/*. However, they both live in /sys/devices/.../*
 as directories.
 
 I always liked the separation between the two, although there are
 a few cases where there is a grey area (e.g. /sys/bus/hid or
 /sys/class/mmc_host) and the abstraction doesn't really fit.
 
 IIRC Greg would prefer now to never have had the distinction
 and wants to make all future uses use a bus_type.

Yes, that is totally correct.  Kay has also written much more about this
and why this is the way forward many times in the past, see lkml
archives for the details if anyone is interested.

thanks,

greg k-h

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

Re: [PATCH v5] usb: gadget: storage: make FSG_NUM_BUFFERS variable size

2011/8/19 Michal Nazarewicz min...@mina86.com:
 On Fri, 19 Aug 2011 19:15:32 +0200, Per Forlin per.for...@linaro.org
 wrote:

 2011/8/19 Michal Nazarewicz min...@mina86.com:

 On Fri, 19 Aug 2011 16:28:25 +0200, Per Forlin
 per.for...@stericsson.com
 wrote:

 @@ -3605,6 +3608,9 @@ static int __init fsg_init(void)
       int             rc;
       struct fsg_dev  *fsg;
 +       if (!FSG_NUM_BUFFERS_IS_VALID(fsg_num_buffers))

 Care to add pr_err() here?  Or better yet, change
 fsg_num_buffers_is_valid()
 to a function, eg.:

 static inline int fsg_num_buffers_validate()
 {
       if (fsg_num_buffers  fsg_num_buffers = 4)
               return 0;
       pr_err(fsg_num_buffers too high: %u\n, fsg_num_buffers);
       return -EINVAL;
 }

 Look good.
 This will permit only 1 buffer to be used. Is this intentionally? I'm
 fine with it.
 In Kconfig the range is 2 to 4. For debug purposes there may be a
 point of permitting range 1 to 4.

 Ah, sorry, no.  I meant = 2.  Whether we want to allow a single buffer
 is another story (we might, why not?).

I stick with 2 to 4 in this patch. There may be other reasons for
permitting only 1 but for this patch it isn't relevant.

Thanks,
Per

 Best regards,                                         _     _
 .o. | Liege of Serenely Enlightened Majesty of      o' \,=./ `o
 ..o | Computer Science,  Michal mina86 Nazarewicz    (o o)
 ooo +-email/xmpp: mnazarew...@google.com-ooO--(_)--Ooo--


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

[u-boot PATCH] arm, lib/bootm.c: Exclude HIGHMEM from being used by u-boot

2011-08-19 Thread David Long


Reserve any memory above 768MB to prevent u-boot from relocating fdt or initrd
data into memory that Linux cannot reference during early boot. Code taken (with
modifications) from the powerpc bootm.c.

Signed-off-by: David A. Long dave.l...@linaro.org
---
 arch/arm/lib/bootm.c |   24 +++-
 1 files changed, 23 insertions(+), 1 deletions(-)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 802e833..437ef35 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -32,6 +32,10 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+#ifndef CONFIG_SYS_LINUX_LOWMEM_MAX_SIZE
+#define CONFIG_SYS_LINUX_LOWMEM_MAX_SIZE   (768*1024*1024)
+#endif
+
 #if defined (CONFIG_SETUP_MEMORY_TAGS) || \
 defined (CONFIG_CMDLINE_TAG) || \
 defined (CONFIG_INITRD_TAG) || \
@@ -60,7 +64,25 @@ static int bootm_linux_fdt(int machid, bootm_headers_t 
*images);
 
 void arch_lmb_reserve(struct lmb *lmb)
 {
-   ulong sp;
+   phys_size_t bootm_size;
+   ulong size, sp, bootmap_base;
+
+   bootmap_base = getenv_bootm_low();
+   bootm_size = getenv_bootm_size();
+
+#ifdef DEBUG
+   if (((u64)bootmap_base + bootm_size) 
+   (CONFIG_SYS_SDRAM_BASE + (u64) gd-ram_size))
+   puts(WARNING: bootm_low + bootm_size exceed total memory\n);
+#endif
+
+   size = min(bootm_size, CONFIG_SYS_LINUX_LOWMEM_MAX_SIZE);
+
+   if (size  bootm_size) {
+   ulong base = bootmap_base + size;
+   printf(WARNING: adjusting available memory to %lx\n, size);
+   lmb_reserve(lmb, base, bootm_size - size);
+   }
 
/*
 * Booting a (Linux) kernel image
-- 
1.7.4.1




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

Re: About busybox integration.

2011-08-19 Thread Zach Pfeffer

On 19 August 2011 09:36, Botao Sun botao@linaro.org wrote:
 Hi Guys,

 Currently, we have 2 different situations according to our 2 different tool
 chains - old and new.

 For the old tool chain, use branch linaro_android_2.3.4 of my git
 repository: git://git.linaro.org/people/botaosun/busybox.git. This is a
 pre-built version, only contains a binary file of busybox.

 For the new tool chain, use branch linaro_android_2.3.5 of my git
 repository: git://git.linaro.org/people/botaosun/busybox.git. This version
 contains the source code of busybox 1.19.0 release, and the source code will
 be compiled with the other components of entire platform.

 I did this because there are some tricky issues which are related to our old
 tool chain and Android compiling system. I have discussed with Bero about
 the details. It's not impossible to solve it, but time matters. In addition,
 we will move to the new tool chain sooner or later, so there may be no more
 benefits to work on the old version support, and there is a workable busybox
 binary file already.

 If you have more suggestions, feel free to reply this mail.

 Thank you.


 BR
 Botao Sun


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

Re: Input for an optimized slide

2011-08-19 Thread Zach Pfeffer

Thanks Bero. Sending this extremely useful information out to a wider audience.

Alex,

I think you're probably be very interested in this for your Mozilla work.

-O3
* What is is, does, available on

-O3 enables several additional compiler optimizations such as tree
vectorizing and loop unswitching, and optimizes for speed over code
size somewhat more aggressively than -O2, e.g. by inlining all calls
to small static functions.
It is available on any platform supported by gcc.

OpenMP
* What is is, does, available on

OpenMP is a simple API that makes it easier for a programmer to make
use of multi-core or multi-processor systems, e.g. by automatically
splitting marked loops into several threads.
Example:

#pragma omp parallel for
for(int i=0; i100; i++)
do_something(i);

Would use up to 100 threads to do its job.

It is available on plaforms supported by gcc that can use libgomp,
gcc's OpenMP library. This includes most platforms that support POSIX
threads - but -- initially -- not Android.

Loop parallelization
* What is is, does, available on

Loop parallelization takes OpenMP a step further by automatically
determining which loops are suitable for #pragma omp parallel for
and similar constructs. This allows code that was written without
multiprocessing in mind (such as most code written specifically for
ARM platforms - multicore/SMP ARM systems are quite new) to take
advantage of multicore/SMP systems (to some extent) without having to
modify the code.

Compiler flag: -ftree-parallelize-loops=X (where X is the number of
threads to be optimized for - typically the number of CPU cores in the
target system)

Available on anything supported by gcc that has both libgomp and
graphite (incl. CLooG, PPL or ISL) - the original Android toolchain
has neither of those.

...and any other optimizations that you've done.

None of the following is enabled yet (but the support in the toolchain
is there now), but I'm planning to enable them step by step once we
have systems built w/ the new toolchain that actually boot:

binutils: --hash-style=gnu
By default, ld creates SysV style hash tables for function tables
in shared libraries. With --hash-style=gnu, we switch to GNU style
hashes, making symbol lookup a lot faster. (details:
http://sourceware.org/ml/binutils/2006-10/msg00377.html)

binutils: -Bsymbolic-functions
Speed up the dynamic linker by binding references to global
functions in shared libraries where it is known that this doesn't
break things (it's safe for libraries that don't have any users trying
to override their symbols - it's probably safe to assume e.g. skia and
opengl could benefit).
(details:
http://www.fkf.mpg.de/edv/docs/intel_composer/Documentation/en_US/compiler_f/main_for/copts/common_options/option_bsymbolic_functions.htm)

binutils/gcc: -flto, -fwhole-program
Link-Time Optimization - causes code to be optimized again at link
time, when the compiler knows what functions are called form what
parts of the code, what functions are only called with constant
parameters, etc.

gcc: -mtune=cortex-a9 (or whatever the actual target CPU is)
The Android build system uses -march=arm-v7a, which is good -- but
it doesn't do any tuning for the specifc CPU type (e.g. cortex-a8 vs.
cortex-a9).

gcc: -fvisibility-inlines-hidden
Don't export C++ inline methods in shared libraries. Makes the
symbol table smaller, improving startup time and diskspace efficiency

gcc: -fstrict-aliasing -Werror=strict-aliasing
Currently, Android uses -fno-strict-aliasing unconditionally for
thumb code, to work around some pieces of code that violate strict
aliasing rules. Using -Werror=strict-aliasing, we can determine what
pieces of code are affected, and fix them, or limit the use of
-fno-strict-aliasing to the specific files that need it - enabling the
rather useful strict-aliasing optimization for the rest of the build

gcc: Investigate Graphite optimizations that aren't even enabled at -O3:
-fgraphite-identity -floop-block -floop-interchage
-floop-strip-mine -ftree-loop-distribution -ftree-loop-linear

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

[PATCH 2/6] cpumask: introduce cpumask for hotpluggable CPUs

On some platforms it is possible to have some CPUs which support CPU
hotplug and some which do not.  Currently the prescence of an 'online'
sysfs entry in userspace is adequate for applications to know that a CPU
supports hotplug, but there is no convenient way to make the same
determination in the kernel.

To better model this relationship this patch introduces a new cpumask to
track CPUs that support CPU hotplug operations.

This new cpumask is populated at boot-time and remains static for the
life of the machine.  Bits set in the mask indicate a CPU which supports
hotplug, but make no guarantees about whether that CPU is currently
online or not.  Likewise a cleared bit in the mask indicates either a
CPU which cannot hotplug or a lack of a populated CPU.

The purpose of this new cpumask is to aid kernel code which uses CPU to
take CPUs online and offline.  Possible uses are as a thermal event
mitigation technique or as a power capping mechanism.

Signed-off-by: Mike Turquette mturque...@ti.com
---
 include/linux/cpumask.h |   27 ++-
 kernel/cpu.c|   18 ++
 2 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 4f7a632..3569cd3 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -39,10 +39,11 @@ extern int nr_cpu_ids;
  * The following particular system cpumasks and operations manage
  * possible, present, active and online cpus.
  *
- * cpu_possible_mask- has bit 'cpu' set iff cpu is populatable
- * cpu_present_mask - has bit 'cpu' set iff cpu is populated
- * cpu_online_mask  - has bit 'cpu' set iff cpu available to scheduler
- * cpu_active_mask  - has bit 'cpu' set iff cpu available to migration
+ * cpu_possible_mask - has bit 'cpu' set iff cpu is populatable
+ * cpu_hotpluggable_mask - has bit 'cpu' set iff cpu is hotpluggable
+ * cpu_present_mask  - has bit 'cpu' set iff cpu is populated
+ * cpu_online_mask   - has bit 'cpu' set iff cpu available to scheduler
+ * cpu_active_mask   - has bit 'cpu' set iff cpu available to migration
  *
  *  If !CONFIG_HOTPLUG_CPU, present == possible, and active == online.
  *
@@ -51,7 +52,11 @@ extern int nr_cpu_ids;
  *  life of that system boot.  The cpu_present_mask is dynamic(*),
  *  representing which CPUs are currently plugged in.  And
  *  cpu_online_mask is the dynamic subset of cpu_present_mask,
- *  indicating those CPUs available for scheduling.
+ *  indicating those CPUs available for scheduling.  The
+ *  cpu_hotpluggable_mask is also fixed at boot time as the set of CPU
+ *  id's which are possible AND can hotplug.  Cleared bits in this mask
+ *  mean that either the CPU is not possible, or it is possible but does
+ *  not support CPU hotplug operations.
  *
  *  If HOTPLUG is enabled, then cpu_possible_mask is forced to have
  *  all NR_CPUS bits set, otherwise it is just the set of CPUs that
@@ -61,6 +66,9 @@ extern int nr_cpu_ids;
  *  depending on what ACPI reports as currently plugged in, otherwise
  *  cpu_present_mask is just a copy of cpu_possible_mask.
  *
+ *  If HOTPLUG is not enabled then cpu_hotpluggable_mask is the empty
+ *  set.
+ *
  *  (*) Well, cpu_present_mask is dynamic in the hotplug case.  If not
  *  hotplug, it's a copy of cpu_possible_mask, hence fixed at boot.
  *
@@ -76,6 +84,7 @@ extern int nr_cpu_ids;
  */
 
 extern const struct cpumask *const cpu_possible_mask;
+extern const struct cpumask *const cpu_hotpluggable_mask;
 extern const struct cpumask *const cpu_online_mask;
 extern const struct cpumask *const cpu_present_mask;
 extern const struct cpumask *const cpu_active_mask;
@@ -85,19 +94,23 @@ extern const struct cpumask *const cpu_active_mask;
 #define num_possible_cpus()cpumask_weight(cpu_possible_mask)
 #define num_present_cpus() cpumask_weight(cpu_present_mask)
 #define num_active_cpus()  cpumask_weight(cpu_active_mask)
+#define num_hotpluggable_cpus()cpumask_weight(cpu_hotpluggable_mask)
 #define cpu_online(cpu)cpumask_test_cpu((cpu), cpu_online_mask)
 #define cpu_possible(cpu)  cpumask_test_cpu((cpu), cpu_possible_mask)
 #define cpu_present(cpu)   cpumask_test_cpu((cpu), cpu_present_mask)
 #define cpu_active(cpu)cpumask_test_cpu((cpu), cpu_active_mask)
+#define cpu_hotpluggable(cpu)  cpumask_test_cpu((cpu), cpu_hotpluggable_mask)
 #else
 #define num_online_cpus()  1U
 #define num_possible_cpus()1U
 #define num_present_cpus() 1U
 #define num_active_cpus()  1U
+#define num_hotpluggable_cpus()0
 #define cpu_online(cpu)((cpu) == 0)
 #define cpu_possible(cpu)  ((cpu) == 0)
 #define cpu_present(cpu)   ((cpu) == 0)
 #define cpu_active(cpu)((cpu) == 0)
+#define cpu_hotpluggable(cpu)  0
 #endif
 
 /* verify cpu argument to cpumask_* operators */
@@ -692,16 +705,20 @@ extern const DECLARE_BITMAP(cpu_all_bits,

[PATCH 3/6] cpu: update cpu_hotpluggable_mask in register_cpu

Update the cpu_hotpluggable_mask for each registered CPU which supports
hotplug.  This makes it trivial for kernel code to know which CPUs
support hotplug operations.

Signed-off-by: Mike Turquette mturque...@ti.com
---
 drivers/base/cpu.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/base/cpu.c b/drivers/base/cpu.c
index 251acea..91ddcf8 100644
--- a/drivers/base/cpu.c
+++ b/drivers/base/cpu.c
@@ -224,8 +224,10 @@ int __cpuinit register_cpu(struct cpu *cpu, int num)
 
error = sysdev_register(cpu-sysdev);
 
-   if (!error  cpu-hotpluggable)
+   if (!error  cpu-hotpluggable) {
register_cpu_control(cpu);
+   set_cpu_hotpluggable(num, true);
+   }
if (!error)
per_cpu(cpu_sys_devices, num) = cpu-sysdev;
if (!error)
-- 
1.7.4.1


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

[PATCH 0/6] CPUoffline framework

This series is posted for posterity.  It has been NAK'd by the community
since CPU hotplug has been deemed an inappropriate mechanism for power
capping.

CPUoffline is a framework for taking CPU's offline via the hotplug
mechanism.  The framework itself is quite straightforward: a driver
arranges the CPUs into partitions.  Each partition is associated to a
governor thread and that thread implements a policy for taking CPUs in
that partition offline or online, based on some heuristic.

The CPUoffline core code includes a default driver that places all
possible CPUs into a single partition, requiring no code to be written
for a new platform.  There is also a single governor named avgload
which looks at the average load of all of the *online* CPUs in a
partition and makes a hotplug decision based on defined thresholds.

This framework owes a lot to CPUfreq and CPUidle, from which CPUoffline
stole^H^H^H^H^H borrowed lots of code.

Note: since development was cut short to community response, there are
some missing infrastructure bits such as module unregistration and
dynamic govenor switching.  The code does work fine as-is for the
curious-minded who want to test on an SMP system that supports hotplug.

Mike Turquette (6):
  ARM: do not mark CPU 0 as hotpluggable
  cpumask: introduce cpumask for hotpluggable CPUs
  cpu: update cpu_hotpluggable_mask in register_cpu
  cpuoffline core
  governors
  arm kconfig

 arch/arm/Kconfig   |2 +
 arch/arm/kernel/setup.c|3 +-
 drivers/Makefile   |1 +
 drivers/base/cpu.c |4 +-
 drivers/cpuoffline/Kconfig |   26 ++
 drivers/cpuoffline/Makefile|2 +
 drivers/cpuoffline/cpuoffline.c|  488 
 drivers/cpuoffline/governors/Kconfig   |9 +
 drivers/cpuoffline/governors/Makefile  |2 +
 drivers/cpuoffline/governors/avgload.c |  255 +
 include/linux/cpumask.h|   27 ++-
 include/linux/cpuoffline.h |   82 ++
 kernel/cpu.c   |   18 ++
 13 files changed, 912 insertions(+), 7 deletions(-)
 create mode 100644 drivers/cpuoffline/Kconfig
 create mode 100644 drivers/cpuoffline/Makefile
 create mode 100644 drivers/cpuoffline/cpuoffline.c
 create mode 100644 drivers/cpuoffline/governors/Kconfig
 create mode 100644 drivers/cpuoffline/governors/Makefile
 create mode 100644 drivers/cpuoffline/governors/avgload.c
 create mode 100644 include/linux/cpuoffline.h

-- 
1.7.4.1


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

[PATCH 1/6] ARM: do not mark CPU 0 as hotpluggable

A quick poll of the ARM platforms that implement CPU Hotplug support
shows that every platform treats CPU 0 as a special case that cannot be
hotplugged.  In fact every platform has identical code for
platform_cpu_die which returns -EPERM in the case of CPU 0.

The user-facing sysfs interfaces should reflect this by not populating
an 'online' entry for CPU 0 at all.  This better reflects reality by
making it clear to users that CPU 0 cannot be hotplugged.

This patch prevents CPU 0 from being marked as hotpluggable on all ARM
platforms during CPU registration.  This in turn prevents the creation
of an 'online' sysfs interface for that CPU.

Signed-off-by: Mike Turquette mturque...@ti.com
---
 arch/arm/kernel/setup.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 70bca64..5f3f4bb 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -949,7 +949,8 @@ static int __init topology_init(void)
 
for_each_possible_cpu(cpu) {
struct cpuinfo_arm *cpuinfo = per_cpu(cpu_data, cpu);
-   cpuinfo-cpu.hotpluggable = 1;
+   if (cpu)
+   cpuinfo-cpu.hotpluggable = 1;
register_cpu(cpuinfo-cpu, cpu);
}
 
-- 
1.7.4.1


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

[PATCH 6/6] arm kconfig

---
 arch/arm/Kconfig |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2c71a8f..5804b21 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1980,6 +1980,8 @@ endif
 
 source drivers/cpuidle/Kconfig
 
+source drivers/cpuoffline/Kconfig
+
 endmenu
 
 menu Floating point emulation
-- 
1.7.4.1


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

[PATCH 4/6] cpuoffline core

---
 drivers/Makefile|1 +
 drivers/cpuoffline/Kconfig  |   26 ++
 drivers/cpuoffline/Makefile |2 +
 drivers/cpuoffline/cpuoffline.c |  488 +++
 include/linux/cpuoffline.h  |   82 +++
 5 files changed, 599 insertions(+), 0 deletions(-)
 create mode 100644 drivers/cpuoffline/Kconfig
 create mode 100644 drivers/cpuoffline/Makefile
 create mode 100644 drivers/cpuoffline/cpuoffline.c
 create mode 100644 include/linux/cpuoffline.h

diff --git a/drivers/Makefile b/drivers/Makefile
index dde8076..d41e183 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -95,6 +95,7 @@ obj-$(CONFIG_EISA)+= eisa/
 obj-y  += lguest/
 obj-$(CONFIG_CPU_FREQ) += cpufreq/
 obj-$(CONFIG_CPU_IDLE) += cpuidle/
+obj-$(CONFIG_CPU_OFFLINE)  += cpuoffline/
 obj-$(CONFIG_MMC)  += mmc/
 obj-$(CONFIG_MEMSTICK) += memstick/
 obj-y  += leds/
diff --git a/drivers/cpuoffline/Kconfig b/drivers/cpuoffline/Kconfig
new file mode 100644
index 000..57057d4
--- /dev/null
+++ b/drivers/cpuoffline/Kconfig
@@ -0,0 +1,26 @@
+config CPU_OFFLINE
+   bool CPUoffline framework
+   help
+ CPUoffline provides a framework that allows for taking CPUs
+ offline via an in-kernel governor.  The governor itself can
+ implement any number of policies for deciding to offline a
+ core.  Though primarily used for power capping, CPUoffline can
+ also be used to implement a thermal duty to prevent core
+ over-heating, etc.
+
+ For details please see file:Documentation/cpuoffline.
+
+ If in doubt, say N.
+
+config CPU_OFFLINE_DEFAULT_DRIVER
+   bool CPUoffline default driver
+   depends on CPU_OFFLINE
+   help
+ A default driver that creates a single partition containing
+ all possible CPUs.  The benefit of this driver is that a
+ platform does not need any new code to make use of the
+ CPUoffline framework.  Do not select this if your platform
+ implements it's own driver for registering partitions and CPUs
+ with the CPUoffline framework.
+
+ If in doubt, say N.
diff --git a/drivers/cpuoffline/Makefile b/drivers/cpuoffline/Makefile
new file mode 100644
index 000..0b5aa59
--- /dev/null
+++ b/drivers/cpuoffline/Makefile
@@ -0,0 +1,2 @@
+# CPUoffline core
+obj-$(CONFIG_CPU_OFFLINE)  += cpuoffline.o
diff --git a/drivers/cpuoffline/cpuoffline.c b/drivers/cpuoffline/cpuoffline.c
new file mode 100644
index 000..0427df3
--- /dev/null
+++ b/drivers/cpuoffline/cpuoffline.c
@@ -0,0 +1,488 @@
+/*
+ * CPU Offline framework core
+ *
+ * Copyright (C) 2011 Texas Instruments, Inc.
+ * Mike Turquette mturque...@ti.com
+ *
+ * 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.
+ */
+
+#include linux/mutex.h
+#include linux/cpuoffline.h
+#include linux/slab.h
+//#include linux/kobject.h
+#include linux/sysfs.h
+#include linux/err.h
+
+#define MAX_CPU_LEN8
+
+static int nr_partitions = 0;
+
+static struct cpuoffline_driver *cpuoffline_driver;
+DEFINE_MUTEX(cpuoffline_driver_mutex);
+
+static LIST_HEAD(cpuoffline_governor_list);
+static DEFINE_MUTEX(cpuoffline_governor_mutex);
+
+static DEFINE_PER_CPU(struct cpuoffline_partition *, cpuoffline_partition);
+
+struct kobject *cpuoffline_global_kobject;
+EXPORT_SYMBOL(cpuoffline_global_kobject);
+
+/* sysfs interfaces */
+
+static struct cpuoffline_governor *__find_governor(const char *str_governor)
+{
+   struct cpuoffline_governor *gov;
+
+   list_for_each_entry(gov, cpuoffline_governor_list, governor_list)
+   if (!strnicmp(str_governor, gov-name, MAX_NAME_LEN))
+   return gov;
+
+   return NULL;
+}
+
+static ssize_t current_governor_show(struct cpuoffline_partition *partition,
+   char *buf)
+{
+   struct cpuoffline_governor *gov;
+
+   gov = partition-governor;
+
+   if (!gov)
+   return 0;
+
+   return snprintf(buf, MAX_NAME_LEN, %s\n, gov-name);
+}
+
+static ssize_t current_governor_store(struct cpuoffline_partition *partition,
+   const char *buf, size_t count)
+{
+   int ret;
+   char govstring[MAX_NAME_LEN];
+   struct cpuoffline_governor *gov, *tempgov;
+
+   gov = partition-governor;
+
+   ret = sscanf(buf, %15s, govstring);
+
+   if (ret != 1)
+   return -EINVAL;
+
+   tempgov = __find_governor(govstring);
+
+   if (!tempgov)
+   return -EINVAL;
+
+   if (!try_module_get(tempgov-owner))
+   return -EINVAL;
+
+   /* XXX should gov-stop handle the module put?  probably not */
+   if (gov) {
+   gov-stop(partition);
+   module_put(gov-owner);
+   }
+
+   /* XXX

[PATCH 5/6] governors