headers
Maya Erez | 2 Jul 2012 14:15

[PATCH v4 1/2] mmc: card: Move MMC specific attributes to mmc sub-directory

Separate MMC specific attributes from general block device
attributes and move them from the /sys/block/≤BLOCK_DEV> directory
to /sys/block/≤BLOCK_DEV>/mmc directory

Signed-off-by: Maya Erez <merez <at> codeaurora.org>

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c965f2b..c23034d 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
 <at>  <at>  -114,6 +114,9  <at>  <at>  struct mmc_blk_data {
 	struct device_attribute force_ro;
 	struct device_attribute power_ro_lock;
 	int	area_type;
+
+	struct kobject kobj;
+	struct kobj_type kobj_type;
 };

 static DEFINE_MUTEX(open_lock);
 <at>  <at>  -185,6 +188,51  <at>  <at>  static void mmc_blk_put(struct mmc_blk_data *md)
 	mutex_unlock(&open_lock);
 }

+static ssize_t mmc_blk_attr_show(struct kobject *kobj, struct attribute *attr,
+			    char *buf)
+{
+	struct device_attribute *dev_attr;
+	struct mmc_blk_data *md;
+	ssize_t ret;
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rabin Vincent | 5 Jul 2012 11:28
Picon

Re: Bad use of highmem with buffer_migrate_page?

On Sat, May 12, 2012 at 3:21 AM, Laura Abbott <lauraa <at> codeaurora.org> wrote:
> On 5/11/2012 1:30 AM, Marek Szyprowski wrote:
>> On Thursday, May 10, 2012 10:08 PM Laura Abbott wrote:
>>> I did a backport of the Contiguous Memory Allocator to a 3.0.8 tree. I
>>> wrote fairly simple test case that, in 1MB chunks, allocs up to 40MB
>>> from a reserved area, maps, writes, unmaps and then frees in an infinite
>>> loop. When running this with another program in parallel to put some
>>> stress on the filesystem, I hit data aborts in the filesystem/journal
>>> layer, although not always the same backtrace. As an example:
>>>
>>> [<c02907a4>] (__ext4_check_dir_entry+0x20/0x184) from [<c029e1a8>]
>>> (add_dirent_to_buf+0x70/0x2ac)
>>> [<c029e1a8>] (add_dirent_to_buf+0x70/0x2ac) from [<c029f3f0>]
>>> (ext4_add_entry+0xd8/0x4bc)
>>> [<c029f3f0>] (ext4_add_entry+0xd8/0x4bc) from [<c029fe90>]
>>> (ext4_add_nondir+0x14/0x64)
>>> [<c029fe90>] (ext4_add_nondir+0x14/0x64) from [<c02a04c4>]
>>> (ext4_create+0xd8/0x120)
>>> [<c02a04c4>] (ext4_create+0xd8/0x120) from [<c022e134>]
>>> (vfs_create+0x74/0xa4)
>>> [<c022e134>] (vfs_create+0x74/0xa4) from [<c022ed3c>]
>>> (do_last+0x588/0x8d4)
>>> [<c022ed3c>] (do_last+0x588/0x8d4) from [<c022fe64>]
>>> (path_openat+0xc4/0x394)
>>> [<c022fe64>] (path_openat+0xc4/0x394) from [<c0230214>]
>>> (do_filp_open+0x30/0x7c)
>>> [<c0230214>] (do_filp_open+0x30/0x7c) from [<c0220cb4>]
>>> (do_sys_open+0xd8/0x174)
>>> [<c0220cb4>] (do_sys_open+0xd8/0x174) from [<c0105ea0>]
>>> (ret_fast_syscall+0x0/0x30)
(Continue reading)

Permalink | Reply | 4 comments |
headers
Michał Nazarewicz | 5 Jul 2012 21:21
Favicon
Gravatar

Re: Bad use of highmem with buffer_migrate_page?

2012/7/5 Rabin Vincent <rabin <at> rab.in>:
> From 8a94126eb3aa2824866405fb78bb0b8316f8fd00 Mon Sep 17 00:00:00 2001
> From: Rabin Vincent <rabin <at> rab.in>
> Date: Thu, 5 Jul 2012 15:52:23 +0530
> Subject: [PATCH] mm: cma: don't replace lowmem pages with highmem
>
> The filesystem layer expects pages in the block device's mapping to not
> be in highmem (the mapping's gfp mask is set in bdget()), but CMA can
> currently replace lowmem pages with highmem pages, leading to crashes in
> filesystem code such as the one below:
>
>   Unable to handle kernel NULL pointer dereference at virtual address 00000400
>   pgd = c0c98000
>   [00000400] *pgd=00c91831, *pte=00000000, *ppte=00000000
>   Internal error: Oops: 817 [#1] PREEMPT SMP ARM
>   CPU: 0    Not tainted  (3.5.0-rc5+ #80)
>   PC is at __memzero+0x24/0x80
>   ...
>   Process fsstress (pid: 323, stack limit = 0xc0cbc2f0)
>   Backtrace:
>   [<c010e3f0>] (ext4_getblk+0x0/0x180) from [<c010e58c>] (ext4_bread+0x1c/0x98)
>   [<c010e570>] (ext4_bread+0x0/0x98) from [<c0117944>] (ext4_mkdir+0x160/0x3bc)
>    r4:c15337f0
>   [<c01177e4>] (ext4_mkdir+0x0/0x3bc) from [<c00c29e0>] (vfs_mkdir+0x8c/0x98)
>   [<c00c2954>] (vfs_mkdir+0x0/0x98) from [<c00c2a60>] (sys_mkdirat+0x74/0xac)
>    r6:00000000 r5:c152eb40 r4:000001ff r3:c14b43f0
>   [<c00c29ec>] (sys_mkdirat+0x0/0xac) from [<c00c2ab8>] (sys_mkdir+0x20/0x24)
>    r6:beccdcf0 r5:00074000 r4:beccdbbc
>   [<c00c2a98>] (sys_mkdir+0x0/0x24) from [<c000e3c0>] (ret_fast_syscall+0x0/0x30)
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Girish K S | 9 Jul 2012 10:37
Favicon

Re: [PATCH RESEND v7 1/2] block: ioctl support for sanitize in eMMC 4.5

On 28 June 2012 14:02, Yaniv Gardi <ygardi <at> codeaurora.org> wrote:
> Adding a new ioctl to support sanitize operation in eMMC
> cards version 4.5.
> The sanitize ioctl support helps performing this operation
> via user application.
>
> Signed-off-by: Yaniv Gardi <ygardi <at> codeaurora.org>
>
> ---
>  block/blk-core.c          |   15 ++++++++++--
>  block/blk-lib.c           |   51 +++++++++++++++++++++++++++++++++++++++++++++
>  block/blk-merge.c         |    4 +++
>  block/elevator.c          |    2 +-
>  block/ioctl.c             |    9 ++++++++
>  include/linux/blk_types.h |    5 +++-
>  include/linux/blkdev.h    |    3 ++
>  include/linux/fs.h        |    1 +
>  kernel/trace/blktrace.c   |    2 +
>  9 files changed, 87 insertions(+), 5 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 3c923a7..4a56102b 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
>  <at>  <at>  -1641,7 +1641,7  <at>  <at>  generic_make_request_checks(struct bio *bio)
>                 goto end_io;
>         }
>
> -       if (unlikely(!(bio->bi_rw & REQ_DISCARD) &&
> +       if (unlikely(!(bio->bi_rw & (REQ_DISCARD | REQ_SANITIZE)) &&
(Continue reading)

Permalink | Reply | 0 comments |
headers
Girish K S | 9 Jul 2012 12:02
Favicon

Re: [PATCH RESEND v7 1/2] block: ioctl support for sanitize in eMMC 4.5

On 28 June 2012 14:02, Yaniv Gardi <ygardi <at> codeaurora.org> wrote:
> Adding a new ioctl to support sanitize operation in eMMC
> cards version 4.5.
> The sanitize ioctl support helps performing this operation
> via user application.
>
> Signed-off-by: Yaniv Gardi <ygardi <at> codeaurora.org>
>
> ---
>  block/blk-core.c          |   15 ++++++++++--
>  block/blk-lib.c           |   51 +++++++++++++++++++++++++++++++++++++++++++++
>  block/blk-merge.c         |    4 +++
>  block/elevator.c          |    2 +-
>  block/ioctl.c             |    9 ++++++++
>  include/linux/blk_types.h |    5 +++-
>  include/linux/blkdev.h    |    3 ++
>  include/linux/fs.h        |    1 +
>  kernel/trace/blktrace.c   |    2 +
>  9 files changed, 87 insertions(+), 5 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 3c923a7..4a56102b 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
>  <at>  <at>  -1641,7 +1641,7  <at>  <at>  generic_make_request_checks(struct bio *bio)
>                 goto end_io;
>         }
>
> -       if (unlikely(!(bio->bi_rw & REQ_DISCARD) &&
> +       if (unlikely(!(bio->bi_rw & (REQ_DISCARD | REQ_SANITIZE)) &&
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rajaram R | 12 Jul 2012 13:23
Picon

Re: [PATCH v4 2/4] usb gadget: Configure endpoint according to gadget speed.

Hi

On Thu, Nov 18, 2010 at 6:17 PM, Tatyana Brokhman
<tlinder <at> codeaurora.org> wrote:
>
> Add config_ep_by_speed() to configure the endpoint according to the gadget
> speed. Using this function will spare the FDs from handling the endpoint
> chosen descriptor.
>
> Signed-off-by: Tatyana Brokhman <tlinder <at> codeaurora.org>
> ---
>  drivers/usb/gadget/composite.c  |   76 +++++++++++++++++++++++++++++++++++++++
>  drivers/usb/gadget/epautoconf.c |    1 +
>  include/linux/usb/composite.h   |   21 +++++++++++
>  include/linux/usb/gadget.h      |    3 ++
>  4 files changed, 101 insertions(+), 0 deletions(-)
>
---cut---

> + */
> +int config_ep_by_speed(struct usb_gadget *g,
> +                       struct usb_function *f,
> +                       struct usb_ep *_ep)
> +{
> +       struct usb_endpoint_descriptor *chosen_desc = NULL;
> +       struct usb_descriptor_header **speed_desc = NULL;
> +
> +       struct usb_descriptor_header **d_spd; /* cursor for speed desc */
> +
> +       if (!g || !f || !_ep)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Laura Abbott | 13 Jul 2012 20:01

[RFc] Map CMA pages as cached

Current APIs only support allocating CMA pages as either coherent or
writecombine. This seems to miss support for cached pages completely.
The following patch seems to be the first obvious solution.

More generally though, what should be the strategy for remapping with
other memory types? Add a new function call each time?

Thanks,
Laura
Permalink | Reply | 7 comments |
headers
Laura Abbott | 13 Jul 2012 20:01

[PATCH][RFC] arm: dma-mapping: Add support for allocating/mapping cached buffers

There are currently no dma allocation APIs that support cached
buffers. For some use cases, caching provides a signficiant
performance boost that beats write-combining regions. Add
apis to allocate and map a cached DMA region.

Signed-off-by: Laura Abbott <lauraa <at> codeaurora.org>
---
 arch/arm/include/asm/dma-mapping.h |   21 +++++++++++++++++++++
 arch/arm/mm/dma-mapping.c          |   21 +++++++++++++++++++++
 2 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index dc988ff..1565403 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
 <at>  <at>  -239,12 +239,33  <at>  <at>  int dma_mmap_coherent(struct device *, struct vm_area_struct *,
 extern void *dma_alloc_writecombine(struct device *, size_t, dma_addr_t *,
 		gfp_t);

+/**
+ * dma_alloc_cached - allocate cached memory for DMA
+ *  <at> dev: valid struct device pointer, or NULL for ISA and EISA-like devices
+ *  <at> size: required memory size
+ *  <at> handle: bus-specific DMA address
+ *
+ * Allocate some cached memory for a device for
+ * performing DMA.  This function allocates pages, and will
+ * return the CPU-viewed address, and sets  <at> handle to be the
+ * device-viewed address.
+ */
(Continue reading)

Permalink | Reply | 6 comments |
headers
Clark, Rob | 14 Jul 2012 15:53
Picon
Favicon
Gravatar

Re: [Linaro-mm-sig] [PATCH][RFC] arm: dma-mapping: Add support for allocating/mapping cached buffers

On Fri, Jul 13, 2012 at 1:01 PM, Laura Abbott <lauraa <at> codeaurora.org> wrote:
> There are currently no dma allocation APIs that support cached
> buffers. For some use cases, caching provides a signficiant
> performance boost that beats write-combining regions. Add
> apis to allocate and map a cached DMA region.

btw, there were recent patches for allocating dma memory without a
virtual mapping.  With this you could map however you want to
userspace (for example, cached)

I'm assuming that you are not needing it to be mapped cached to kernel?

BR,
-R

> Signed-off-by: Laura Abbott <lauraa <at> codeaurora.org>
> ---
>  arch/arm/include/asm/dma-mapping.h |   21 +++++++++++++++++++++
>  arch/arm/mm/dma-mapping.c          |   21 +++++++++++++++++++++
>  2 files changed, 42 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
> index dc988ff..1565403 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
>  <at>  <at>  -239,12 +239,33  <at>  <at>  int dma_mmap_coherent(struct device *, struct vm_area_struct *,
>  extern void *dma_alloc_writecombine(struct device *, size_t, dma_addr_t *,
>                 gfp_t);
>
> +/**
(Continue reading)

Permalink | Reply | 1 comment |
headers
Maya Erez | 14 Jul 2012 20:46

[PATCH RESEND v4 0/2] mmc: block: Add write packing control

Our experiments showed that the write packing causes degradation of the read
throughput, in parallel read and write operations.
Since the read latency is critical for user experience we added a write packing control
mechanism that disables the write packing in case of read requests.
This will ensure that read requests latency is not increased due to long write packed commands.

The trigger for enabling the write packing is managing to pack several write requests.
The number of potential packed requests that will trigger the packing can be configured via sysfs.
The trigger for disabling the write packing is a fetch of a read request.

Changes in v4:
    - Move MMC specific attributes to mmc sub-directory

Changes in v3:
    - Fix the settings of num_of_potential_packed_wr_reqs

Changes in v2:
    - Move the attribute for setting the packing enabling trigger to the block device
    - Add documentation of the new attribute

Maya Erez (2):
  mmc: card: Move MMC specific attributes to mmc sub-directory
  mmc: block: Add write packing control

 Documentation/mmc/mmc-dev-attrs.txt |   17 ++++
 drivers/mmc/card/block.c            |  176 +++++++++++++++++++++++++++++++++--
 drivers/mmc/card/queue.c            |    8 ++
 drivers/mmc/card/queue.h            |    3 +
 include/linux/mmc/host.h            |    1 +
 5 files changed, 197 insertions(+), 8 deletions(-)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane