[PATCH v3 6/17] arcmsr: precise checking adapter ID

[Ching Huang]

From: Ching Huang 

change since v2:
1. This patch pre-define the adapter->type in private data of struct 
pci_device_id.
2. Remove arcmsr_define_adapter_type function.

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2014-08-08 19:36:00.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2014-08-14 18:36:38.0 +0800
@@ -144,25 +144,25 @@ static struct scsi_host_template arcmsr_
.no_write_same  = 1,
 };
 static struct pci_device_id arcmsr_device_id_table[] = {
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1110)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1120)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1130)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1160)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1170)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1200)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1201)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1202)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1210)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1220)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1230)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1260)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1270)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1280)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1380)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1381)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1680)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1681)},
-   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1880)},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1110), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1120), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1130), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1160), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1170), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1200), 
.driver_data = ACB_ADAPTER_TYPE_B,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1201), 
.driver_data = ACB_ADAPTER_TYPE_B,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1202), 
.driver_data = ACB_ADAPTER_TYPE_B,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1210), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1220), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1230), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1260), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1270), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1280), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1380), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1381), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1680), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1681), 
.driver_data = ACB_ADAPTER_TYPE_A,},
+   {PCI_DEVICE(PCI_VENDOR_ID_ARECA, PCI_DEVICE_ID_ARECA_1880), 
.driver_data = ACB_ADAPTER_TYPE_C,},
{0, 0}, /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(pci, arcmsr_device_id_table);
@@ -295,26 +295,6 @@ static int arcmsr_bios_param(struct scsi
return 0;
 }
 
-static void arcmsr_define_adapter_type(struct AdapterControlBlock *acb)
-{
-   struct pci_dev *pdev = acb->pdev;
-   u16 dev_id;
-   pci_read_config_word(pdev, PCI_DEVICE_ID, &dev_id);
-   acb->dev_id = dev_id;
-   switch (dev_id) {
-   case 0x1880: {
-   acb->adapter_type = ACB_ADAPTER_TYPE_C;
-   }
-   break;
-   case 0x1201: {
-   acb->adapter_type = ACB_ADAPTER_TYPE_B;
-   }
-   break;
-
-   default: acb->adapter_type = ACB_ADAPTER_TYPE_A;
-   }
-}
-
 static uint8_t arcmsr_hba_wait_msgint_ready(struct AdapterControlBlock *acb)
 {
struct MessageUnit_A __iomem *reg = acb->pmuA;
@@ -710,7 +690,7 @@ static int arcmsr_probe(struct pci_dev *
ACB_F_MESSAGE_WQBUFFER_READED);
acb->acb_flags &= ~ACB_F_SCSISTOPADAPTER;
INIT_LIST_HEAD(&a

[PATCHv2 3/3] jbd/jbd2: allocate buffer-cache for superblock inode in non-movable area

[Gioh Kim]

A long-lasting buffer-cache can distrub page migration so that
it must be allocated from non-movable area.

The journal_init_inode is creating a buffer-cache for superblock journaling.
The superblock exists until system shutdown so that the buffer-cache
for the superblock would also exist for a long time
and it can distrub page migration.

This patch make the buffer-cache be allocated from non-movable area
not to distrub page migration.

Signed-off-by: Gioh Kim 
---
 fs/jbd/journal.c  |2 +-
 fs/jbd2/journal.c |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/jbd/journal.c b/fs/jbd/journal.c
index 06fe11e..a9f8aaf 100644
--- a/fs/jbd/journal.c
+++ b/fs/jbd/journal.c
@@ -886,7 +886,7 @@ journal_t * journal_init_inode (struct inode *inode)
goto out_err;
}

-   bh = __getblk(journal->j_dev, blocknr, journal->j_blocksize);
+   bh = __getblk_gfp(journal->j_dev, blocknr, journal->j_blocksize, 0);
if (!bh) {
printk(KERN_ERR
   "%s: Cannot get buffer for journal superblock\n",
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 67b8e30..0461998 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -1237,7 +1237,7 @@ journal_t * jbd2_journal_init_inode (struct inode *inode)
goto out_err;
}

-   bh = __getblk(journal->j_dev, blocknr, journal->j_blocksize);
+   bh = __getblk_gfp(journal->j_dev, blocknr, journal->j_blocksize, 0);
if (!bh) {
printk(KERN_ERR
   "%s: Cannot get buffer for journal superblock\n",
--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 2/3] ext4: allocate buffer-cache for superblock in non-movable area

[Gioh Kim]

A buffer-cache for superblock is disturbing page migration,
because the buffer-cache is not released until unmount.
The buffer-cache must be allocated from non-movable area.

Signed-off-by: Gioh Kim 
---
 fs/ext4/super.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 32b43ad..13d7770 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -3435,7 +3435,7 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
logical_sb_block = sb_block;
}

-   if (!(bh = sb_bread(sb, logical_sb_block))) {
+   if (!(bh = sb_bread_gfp(sb, logical_sb_block, 0))) {
ext4_msg(sb, KERN_ERR, "unable to read superblock");
goto out_fail;
}
@@ -3645,7 +3645,7 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
brelse(bh);
logical_sb_block = sb_block * EXT4_MIN_BLOCK_SIZE;
offset = do_div(logical_sb_block, blocksize);
-   bh = sb_bread(sb, logical_sb_block);
+   bh = sb_bread_gfp(sb, logical_sb_block, 0);
if (!bh) {
ext4_msg(sb, KERN_ERR,
   "Can't read superblock on 2nd try");
@@ -3867,7 +3867,7 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)

for (i = 0; i < db_count; i++) {
block = descriptor_loc(sb, logical_sb_block, i);
-   sbi->s_group_desc[i] = sb_bread(sb, block);
+   sbi->s_group_desc[i] = sb_bread_gfp(sb, block, 0);
if (!sbi->s_group_desc[i]) {
ext4_msg(sb, KERN_ERR,
   "can't read group descriptor %d", i);
--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 1/3] fs/buffer.c: allocate buffer cache with user specific flag

[Gioh Kim]

A buffer cache is allocated from movable area
because it is referred for a while and released soon.
But some filesystems are taking buffer cache for a long time
and it can disturb page migration.

A new API should be introduced to allocate buffer cache
with user specific flag.
For instance if user set flag to zero, buffer cache is allocated from
non-movable area.

Signed-off-by: Gioh Kim 
---
 fs/buffer.c |   52 +--
 include/linux/buffer_head.h |   12 +-
 2 files changed, 46 insertions(+), 18 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index 8f05111..14f2f21 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -993,7 +993,7 @@ init_page_buffers(struct page *page, struct block_device 
*bdev,
  */
 static int
 grow_dev_page(struct block_device *bdev, sector_t block,
-   pgoff_t index, int size, int sizebits)
+ pgoff_t index, int size, int sizebits, gfp_t gfp)
 {
struct inode *inode = bdev->bd_inode;
struct page *page;
@@ -1002,10 +1002,10 @@ grow_dev_page(struct block_device *bdev, sector_t block,
int ret = 0;/* Will call free_more_memory() */
gfp_t gfp_mask;

-   gfp_mask = mapping_gfp_mask(inode->i_mapping) & ~__GFP_FS;
-   gfp_mask |= __GFP_MOVABLE;
+   gfp_mask = (mapping_gfp_mask(inode->i_mapping) & ~__GFP_FS) | gfp;
+
/*
-* XXX: __getblk_slow() can not really deal with failure and
+* XXX: __getblk_gfp() can not really deal with failure and
 * will endlessly loop on improvised global reclaim.  Prefer
 * looping in the allocator rather than here, at least that
 * code knows what it's doing.
@@ -1058,7 +1058,7 @@ failed:
  * that page was dirty, the buffers are set dirty also.
  */
 static int
-grow_buffers(struct block_device *bdev, sector_t block, int size)
+grow_buffers(struct block_device *bdev, sector_t block, int size, gfp_t gfp)
 {
pgoff_t index;
int sizebits;
@@ -1085,11 +1085,12 @@ grow_buffers(struct block_device *bdev, sector_t block, 
int size)
}

/* Create a page with the proper size buffers.. */
-   return grow_dev_page(bdev, block, index, size, sizebits);
+   return grow_dev_page(bdev, block, index, size, sizebits, gfp);
 }

-static struct buffer_head *
-__getblk_slow(struct block_device *bdev, sector_t block, int size)
+struct buffer_head *
+__getblk_gfp(struct block_device *bdev, sector_t block,
+unsigned size, gfp_t gfp)
 {
/* Size must be multiple of hard sectorsize */
if (unlikely(size & (bdev_logical_block_size(bdev)-1) ||
@@ -,13 +1112,14 @@ __getblk_slow(struct block_device *bdev, sector_t 
block, int size)
if (bh)
return bh;

-   ret = grow_buffers(bdev, block, size);
+   ret = grow_buffers(bdev, block, size, gfp);
if (ret < 0)
return NULL;
if (ret == 0)
free_more_memory();
}
 }
+EXPORT_SYMBOL(__getblk_gfp);

 /*
  * The relationship between dirty buffers and dirty pages:
@@ -1381,12 +1383,7 @@ EXPORT_SYMBOL(__find_get_block);
 struct buffer_head *
 __getblk(struct block_device *bdev, sector_t block, unsigned size)
 {
-   struct buffer_head *bh = __find_get_block(bdev, block, size);
-
-   might_sleep();
-   if (bh == NULL)
-   bh = __getblk_slow(bdev, block, size);
-   return bh;
+   return __getblk_gfp(bdev, block, size, __GFP_MOVABLE);
 }
 EXPORT_SYMBOL(__getblk);

@@ -1410,18 +1407,39 @@ EXPORT_SYMBOL(__breadahead);
  *  @size: size (in bytes) to read
  *
  *  Reads a specified block, and returns buffer head that contains it.
+ *  The page cache is allocated from movable area so that it can be migrated.
  *  It returns NULL if the block was unreadable.
  */
 struct buffer_head *
 __bread(struct block_device *bdev, sector_t block, unsigned size)
 {
-   struct buffer_head *bh = __getblk(bdev, block, size);
+   return __bread_gfp(bdev, block, size, __GFP_MOVABLE);
+}
+EXPORT_SYMBOL(__bread);
+
+/**
+ *  __bread_gfp() - reads a specified block and returns the bh
+ *  @bdev: the block_device to read from
+ *  @block: number of block
+ *  @size: size (in bytes) to read
+ *  @gfp: page allocation flag
+ *
+ *  Reads a specified block, and returns buffer head that contains it.
+ *  The page cache can be allocated from non-movable area
+ *  not to prevent page migration if you set gfp to zero.
+ *  It returns NULL if the block was unreadable.
+ */
+struct buffer_head *
+__bread_gfp(struct block_device *bdev, sector_t block,
+  unsigned size, gfp_t gfp)
+{
+   struct buffer_head *bh = __getblk_gfp(bdev, block, size, gfp);

if (likely(bh) && !buffer_uptodate(bh))
bh = __bread_slow(bh);
return bh;
 }
-EXPORT_SYMBOL(__bread);
+EXPORT_SYMBOL(__bread_gfp);

 /*
  * invalidate_bh_lrus() is cal

[PATCHv2 0/3] new APIs to allocate buffer-cache with user specific flag

[Gioh Kim]

Hello,

This patch try to solve problem that a long-lasting page caches of
ext4 superblock and journaling of superblock disturb page migration.

I've been testing CMA feature on my ARM-based platform
and found that two page caches cannot be migrated.
They are page caches of superblock of ext4 filesystem and its journaling data.

Current ext4 reads superblock with sb_bread() that allocates page
from movable area. But the problem is that ext4 hold the page until
it is unmounted. If root filesystem is ext4 the page cannot be migrated forever.
And also the journaling data for the superblock cannot be migreated.

I introduce a new API that allocates page cache with specific flag passed by an 
argument.
The API user can set flag to zero if the user wants to allocate page cache from 
non-movable area.

It is useful for ext4/ext3 and others that want to hold page cache for a long 
time.

I have 3 patchs:

1. Patch 1/3: introduce a new API that create page cache with allocation flag
2. Patch 2/3: have ext4 use the new API to read superblock
3. Patch 3/3: have jbd/jbd2 use the new API to make journaling of superblock

This patchset is based on linux-next-20140814.

Thanks a lot.

Gioh Kim (3):
 fs/buffer.c: allocate buffer cache with user specific flag
 ext4: allocate buffer-cache for superblock in non-movable area
 jbd-jbd2-allocate-buffer-cache-for-superblock-inode-.patch

 fs/buffer.c |   52 +---
 fs/ext4/super.c |6 ++---
 fs/jbd/journal.c|2 -
 fs/jbd2/journal.c   |2 -
 include/linux/buffer_head.h |   12 +-
 5 files changed, 51 insertions(+), 23 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 5/17] arcmsr: bugfix - return status of abort command

[Ching Huang]

From: Ching Huang 

This patch fixed the wrong return status of abort command.

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2014-08-08 19:35:46.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2014-08-08 19:36:00.0 +0800
@@ -2476,7 +2476,7 @@ static int arcmsr_polling_hba_ccbdone(st
}
arcmsr_cdb = (struct ARCMSR_CDB *)(acb->vir2phy_offset + 
(flag_ccb << 5));
ccb = container_of(arcmsr_cdb, struct CommandControlBlock, 
arcmsr_cdb);
-   poll_ccb_done = (ccb == poll_ccb) ? 1:0;
+   poll_ccb_done |= (ccb == poll_ccb) ? 1 : 0;
if ((ccb->acb != acb) || (ccb->startdone != ARCMSR_CCB_START)) {
if ((ccb->startdone == ARCMSR_CCB_ABORTED) || (ccb == 
poll_ccb)) {
printk(KERN_NOTICE "arcmsr%d: scsi id = %d lun 
= %d ccb = '0x%p'"
@@ -2540,7 +2540,7 @@ static int arcmsr_polling_hbb_ccbdone(st
/* check if command done with no error*/
arcmsr_cdb = (struct ARCMSR_CDB *)(acb->vir2phy_offset + 
(flag_ccb << 5));
ccb = container_of(arcmsr_cdb, struct CommandControlBlock, 
arcmsr_cdb);
-   poll_ccb_done = (ccb == poll_ccb) ? 1:0;
+   poll_ccb_done |= (ccb == poll_ccb) ? 1 : 0;
if ((ccb->acb != acb) || (ccb->startdone != ARCMSR_CCB_START)) {
if ((ccb->startdone == ARCMSR_CCB_ABORTED) || (ccb == 
poll_ccb)) {
printk(KERN_NOTICE "arcmsr%d: scsi id = %d lun 
= %d ccb = '0x%p'"
@@ -2596,7 +2596,7 @@ polling_hbc_ccb_retry:
ccb_cdb_phy = (flag_ccb & 0xFFF0);
arcmsr_cdb = (struct ARCMSR_CDB *)(acb->vir2phy_offset + 
ccb_cdb_phy);/*frame must be 32 bytes aligned*/
pCCB = container_of(arcmsr_cdb, struct CommandControlBlock, 
arcmsr_cdb);
-   poll_ccb_done = (pCCB == poll_ccb) ? 1 : 0;
+   poll_ccb_done |= (pCCB == poll_ccb) ? 1 : 0;
/* check ifcommand done with no error*/
if ((pCCB->acb != acb) || (pCCB->startdone != 
ARCMSR_CCB_START)) {
if (pCCB->startdone == ARCMSR_CCB_ABORTED) {
@@ -3198,6 +3198,8 @@ static int arcmsr_abort(struct scsi_cmnd
(struct AdapterControlBlock *)cmd->device->host->hostdata;
int i = 0;
int rtn = FAILED;
+   uint32_t intmask_org;
+
printk(KERN_NOTICE
"arcmsr%d: abort device command of scsi id = %d lun = %d \n",
acb->host->host_no, cmd->device->id, (u32)cmd->device->lun);
@@ -3209,9 +3211,12 @@ static int arcmsr_abort(struct scsi_cmnd
** we need to handle it as soon as possible and exit

*/
-   if (!atomic_read(&acb->ccboutstandingcount))
+   if (!atomic_read(&acb->ccboutstandingcount)) {
+   acb->acb_flags &= ~ACB_F_ABORT;
return rtn;
+   }
 
+   intmask_org = arcmsr_disable_outbound_ints(acb);
for (i = 0; i < ARCMSR_MAX_FREECCB_NUM; i++) {
struct CommandControlBlock *ccb = acb->pccb_pool[i];
if (ccb->startdone == ARCMSR_CCB_START && ccb->pcmd == cmd) {
@@ -3221,6 +3226,7 @@ static int arcmsr_abort(struct scsi_cmnd
}
}
acb->acb_flags &= ~ACB_F_ABORT;
+   arcmsr_enable_outbound_ints(acb, intmask_org);
return rtn;
 }
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ipc: always handle a new value of auto_msgmni

[Andrew Vagin]

On Sat, Aug 16, 2014 at 10:29:16PM +0200, Manfred Spraul wrote:
> Hi Andrew,
> 
> On 08/14/2014 03:34 PM, Andrew Vagin wrote:
> >On Thu, Aug 14, 2014 at 11:37:45AM +0200, Manfred Spraul wrote:
> >>Hi Andrey,
> >>
> >>[...]
> >>What do you use auto_msgmni for?
> >We disable it to check that criu restores a value of the msgmni sysctl 
> >correctly.
> >
> >https://github.com/xemul/criu/blob/master/test/zdtm/live/static/ipc_namespace.c
> Thanks for the link, if I see it right, my patch would break your code:
> 
> http://marc.info/?l=linux-kernel&m=140782863804950
> 
> It removes auto_msgmni - and
> What do you think, should I leave auto_msgmni as a stale variable, perhaps
> with a pr_info() that it doesn't have any effect?

Yes, you should. For example "criu restore" will start failing, if you remove
auto_msgmni.
> 
> 
> --
> Manfred
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 4/17] arcmsr: limit max. number of SCSI command request

[Ching Huang]

From: Ching Huang 

This patch limits the max. number of SCSI command request to avoid command 
overflow.

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h  2014-05-06 15:24:06.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h  2014-05-06 15:22:36.0 +0800
@@ -45,11 +45,12 @@
 #include 
 struct device_attribute;
 /*The limit of outstanding scsi command that firmware can handle*/
-#define ARCMSR_MAX_OUTSTANDING_CMD 
256
 #ifdef CONFIG_XEN
#define ARCMSR_MAX_FREECCB_NUM  160
+#define ARCMSR_MAX_OUTSTANDING_CMD 155
 #else
#define ARCMSR_MAX_FREECCB_NUM  320
+#define ARCMSR_MAX_OUTSTANDING_CMD 255
 #endif
 #define ARCMSR_DRIVER_VERSION  "v1.30.00.04-20140428"
 #define ARCMSR_SCSI_INITIATOR_ID   
255
@@ -598,6 +599,7 @@ struct AdapterControlBlock
#define FW_DEADLOCK 0x0010
atomic_trq_map_token;
atomic_tante_token_value;
+   uint32_tmaxOutstanding;
int msix_vector_count;
 };/* HW_DEVICE_EXTENSION */
 /*
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2014-08-08 19:03:48.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2014-08-08 19:35:46.0 +0800
@@ -134,7 +134,7 @@ static struct scsi_host_template arcmsr_
.eh_bus_reset_handler   = arcmsr_bus_reset,
.bios_param = arcmsr_bios_param,
.change_queue_depth = arcmsr_adjust_disk_queue_depth,
-   .can_queue  = ARCMSR_MAX_FREECCB_NUM,
+   .can_queue  = ARCMSR_MAX_OUTSTANDING_CMD,
.this_id= ARCMSR_SCSI_INITIATOR_ID,
.sg_tablesize   = ARCMSR_DEFAULT_SG_ENTRIES, 
.max_sectors= ARCMSR_MAX_XFER_SECTORS_C, 
@@ -693,7 +693,7 @@ static int arcmsr_probe(struct pci_dev *
host->max_lun = ARCMSR_MAX_TARGETLUN;
host->max_id = ARCMSR_MAX_TARGETID; /*16:8*/
host->max_cmd_len = 16; /*this is issue of 
64bit LBA ,over 2T byte*/
-   host->can_queue = ARCMSR_MAX_FREECCB_NUM;   /* max simultaneous 
cmds */ 
+   host->can_queue = ARCMSR_MAX_OUTSTANDING_CMD;   /* max simultaneous 
cmds */ 
host->cmd_per_lun = ARCMSR_MAX_CMD_PERLUN;  
host->this_id = ARCMSR_SCSI_INITIATOR_ID;
host->unique_id = (bus << 8) | dev_fun;
@@ -2215,9 +2215,6 @@ static int arcmsr_queue_command_lck(stru
arcmsr_handle_virtual_command(acb, cmd);
return 0;
}
-   if (atomic_read(&acb->ccboutstandingcount) >=
-   ARCMSR_MAX_OUTSTANDING_CMD)
-   return SCSI_MLQUEUE_HOST_BUSY;
ccb = arcmsr_get_freeccb(acb);
if (!ccb)
return SCSI_MLQUEUE_HOST_BUSY;
@@ -2427,12 +2424,27 @@ static bool arcmsr_get_hbc_config(struct
 }
 static bool arcmsr_get_firmware_spec(struct AdapterControlBlock *acb)
 {
-   if (acb->adapter_type == ACB_ADAPTER_TYPE_A)
-   return arcmsr_get_hba_config(acb);
-   else if (acb->adapter_type == ACB_ADAPTER_TYPE_B)
-   return arcmsr_get_hbb_config(acb);
+   bool rtn = false;
+
+   switch (acb->adapter_type) {
+   case ACB_ADAPTER_TYPE_A:
+   rtn = arcmsr_get_hba_config(acb);
+   break;
+   case ACB_ADAPTER_TYPE_B:
+   rtn = arcmsr_get_hbb_config(acb);
+   break;
+   case ACB_ADAPTER_TYPE_C:
+   rtn = arcmsr_get_hbc_config(acb);
+   break;
+   default:
+   break;
+   }
+   if(acb->firm_numbers_queue > ARCMSR_MAX_OUTSTANDING_CMD)
+   acb->maxOutstanding = ARCMSR_MAX_OUTSTANDING_CMD;
else
-   return arcmsr_get_hbc_config(acb);
+   acb->maxOutstanding = acb->firm_numbers_queue - 1;
+   acb->host->can_queue = acb->maxOutstanding;
+   return rtn;
 }
 
 static int arcmsr_polling_hba_ccbdone(struct AdapterControlBlock *acb,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [f2fs-dev] [PATCH 08/13 v2] f2fs: do checkpoint at f2fs_put_super

[Chao Yu]

Hi Jaegeuk,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Saturday, August 16, 2014 5:58 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH 08/13 v2] f2fs: do checkpoint at f2fs_put_super
> 
> Change log from v1:
>  o relocate F2FS_SET_SB_DIRT to avoid unnecessary checkpoints

In umount, we will encounter memory leak as we may skip releasing dirty inode
when IO error occurred in cp. Why not just invoking release_dirty_inode directly
in f2fs_put_super?

Thanks,
Yu

> 
> The generic_shutdown_super calls sync_filesystem, evict_inode, and then
> f2fs_put_super. In f2fs_evict_inode, we remain some dirty inode information
> so we should release them at f2fs_put_super.
> 
> But normally, it's more reasonable to set its superblock as dirty when
> evict_inode is called.
> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/checkpoint.c | 1 +
>  fs/f2fs/super.c  | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> index 7e1c13b..01e1796 100644
> --- a/fs/f2fs/checkpoint.c
> +++ b/fs/f2fs/checkpoint.c
> @@ -330,6 +330,7 @@ void add_dirty_inode(struct f2fs_sb_info *sbi, nid_t ino, 
> int type)
>  {
>   /* add new dirty ino entry into list */
>   __add_ino_entry(sbi, ino, type);
> + F2FS_SET_SB_DIRT(sbi);
>  }
> 
>  void remove_dirty_inode(struct f2fs_sb_info *sbi, nid_t ino, int type)
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 633315a..60e3554 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -432,7 +432,7 @@ static void f2fs_put_super(struct super_block *sb)
>   stop_gc_thread(sbi);
> 
>   /* We don't need to do checkpoint when it's clean */
> - if (sbi->s_dirty && get_pages(sbi, F2FS_DIRTY_NODES))
> + if (sbi->s_dirty)
>   write_checkpoint(sbi, true);
> 
>   iput(sbi->node_inode);
> --
> 1.8.5.2 (Apple Git-48)
> 
> 
> 
> --
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] zd1211rw: replace ZD_ASSERT with lockdep_assert_held()

[Sharma, Sanjeev]

Ping for review the patch.

thanks,

Sanjeev Sharma
-Original Message-
From: Sanjeev Sharma [mailto:sanjeev_sha...@mentor.com] 
Sent: Tuesday, August 12, 2014 12:36 PM
To: d...@gentoo.org; k...@deine-taler.de
Cc: linvi...@tuxdriver.com; linux-wirel...@vger.kernel.org; 
net...@vger.kernel.org; linux-kernel@vger.kernel.org; Sharma, Sanjeev; Sharma, 
Sanjeev
Subject: [PATCH] zd1211rw: replace ZD_ASSERT with lockdep_assert_held()

on some architecture spin_is_locked() always return false in uniprocessor 
configuration and therefore it would be advise to replace with 
lockdep_assert_held().

Signed-off-by: Sanjeev Sharma 
---
 drivers/net/wireless/zd1211rw/zd_mac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/zd1211rw/zd_mac.c 
b/drivers/net/wireless/zd1211rw/zd_mac.c
index e7af261..72c0bc2 100644
--- a/drivers/net/wireless/zd1211rw/zd_mac.c
+++ b/drivers/net/wireless/zd1211rw/zd_mac.c
@@ -235,7 +235,7 @@ void zd_mac_clear(struct zd_mac *mac)  {
flush_workqueue(zd_workqueue);
zd_chip_clear(&mac->chip);
-   ZD_ASSERT(!spin_is_locked(&mac->lock));
+   lockdep_assert_held(!spin_is_locked(&mac->lock));
ZD_MEMCLEAR(mac, sizeof(struct zd_mac));  }
 
--
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] sgi-xp: Do not use BUG_ON(!spin_is_locked())

[Sharma, Sanjeev]

Hello Robin,

Who will merge the change in linux-next tree.

Regards
Sanjeev Sharma

-Original Message-
From: Sanjeev Sharma [mailto:sanjeev_sha...@mentor.com] 
Sent: Tuesday, August 12, 2014 1:05 PM
To: c...@sgi.com; robinmh...@gmail.com
Cc: linux-kernel@vger.kernel.org; Sharma, Sanjeev; Sharma, Sanjeev
Subject: [PATCH] sgi-xp: Do not use BUG_ON(!spin_is_locked())

on some architecture spin_is_locked() always return false in uniprocessor 
configuration and can therefore not be used with BUG_ON.it would be advise to 
replace with lockdep_assert_held().

Signed-off-by: Sanjeev Sharma 
---
 drivers/misc/sgi-xp/xpc_channel.c | 6 +++---
 drivers/misc/sgi-xp/xpc_sn2.c | 2 +-
 drivers/misc/sgi-xp/xpc_uv.c  | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/misc/sgi-xp/xpc_channel.c 
b/drivers/misc/sgi-xp/xpc_channel.c
index 128d561..240fe5a 100644
--- a/drivers/misc/sgi-xp/xpc_channel.c
+++ b/drivers/misc/sgi-xp/xpc_channel.c
@@ -28,7 +28,7 @@ xpc_process_connect(struct xpc_channel *ch, unsigned long 
*irq_flags)  {
enum xp_retval ret;
 
-   DBUG_ON(!spin_is_locked(&ch->lock));
+   lockdep_assert_held(!spin_is_locked(&ch->lock));
 
if (!(ch->flags & XPC_C_OPENREQUEST) ||
!(ch->flags & XPC_C_ROPENREQUEST)) { @@ -82,7 +82,7 @@ 
xpc_process_disconnect(struct xpc_channel *ch, unsigned long *irq_flags)
struct xpc_partition *part = &xpc_partitions[ch->partid];
u32 channel_was_connected = (ch->flags & XPC_C_WASCONNECTED);
 
-   DBUG_ON(!spin_is_locked(&ch->lock));
+   lockdep_assert_held(!spin_is_locked(&ch->lock));
 
if (!(ch->flags & XPC_C_DISCONNECTING))
return;
@@ -758,7 +758,7 @@ xpc_disconnect_channel(const int line, struct xpc_channel 
*ch,  {
u32 channel_was_connected = (ch->flags & XPC_C_CONNECTED);
 
-   DBUG_ON(!spin_is_locked(&ch->lock));
+   lockdep_assert_held(!spin_is_locked(&ch->lock));
 
if (ch->flags & (XPC_C_DISCONNECTING | XPC_C_DISCONNECTED))
return;
diff --git a/drivers/misc/sgi-xp/xpc_sn2.c b/drivers/misc/sgi-xp/xpc_sn2.c 
index 7d71c04..f90ee26 100644
--- a/drivers/misc/sgi-xp/xpc_sn2.c
+++ b/drivers/misc/sgi-xp/xpc_sn2.c
@@ -1674,7 +1674,7 @@ xpc_teardown_msg_structures_sn2(struct xpc_channel *ch)  {
struct xpc_channel_sn2 *ch_sn2 = &ch->sn.sn2;
 
-   DBUG_ON(!spin_is_locked(&ch->lock));
+   lockdep_assert_held(!spin_is_locked(&ch->lock));
 
ch_sn2->remote_msgqueue_pa = 0;
 
diff --git a/drivers/misc/sgi-xp/xpc_uv.c b/drivers/misc/sgi-xp/xpc_uv.c index 
95c8944..a349940 100644
--- a/drivers/misc/sgi-xp/xpc_uv.c
+++ b/drivers/misc/sgi-xp/xpc_uv.c
@@ -1183,7 +1183,7 @@ xpc_teardown_msg_structures_uv(struct xpc_channel *ch)  {
struct xpc_channel_uv *ch_uv = &ch->sn.uv;
 
-   DBUG_ON(!spin_is_locked(&ch->lock));
+   lockdep_assert_held(!spin_is_locked(&ch->lock));
 
kfree(ch_uv->cached_notify_gru_mq_desc);
ch_uv->cached_notify_gru_mq_desc = NULL;
--
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Ignore the [PATCH v4 4/17]

[Ching Huang]

Please ignore the patch [PATCH v4 4/17], I will resend the patch [PATCH v3 
4/17].

Regards,
Ching Huang 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

[Sharma, Sanjeev]

Hi Greg,

Any feedback on this patch ?

Regards
Sanjeev Sharma

-Original Message-
From: Sharma, Sanjeev 
Sent: Tuesday, August 12, 2014 12:07 PM
To: 'Hans de Goede'
Cc: gre...@linuxfoundation.org; kra...@redhat.com; 
mdharm-...@one-eyed-alien.net; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org; linux-s...@vger.kernel.org
Subject: RE: [PATCH v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

Yes I have incorporated review comment from Greg.

Regards
Sanjeev Sharma

-Original Message-
From: Hans de Goede [mailto:hdego...@redhat.com]
Sent: Tuesday, August 12, 2014 11:59 AM
To: Sharma, Sanjeev
Cc: gre...@linuxfoundation.org; kra...@redhat.com; 
mdharm-...@one-eyed-alien.net; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org; linux-s...@vger.kernel.org
Subject: Re: [PATCH v3] uas: replace WARN_ON_ONCE() with lockdep_assert_held()

Hi,

On 08/12/2014 08:40 AM, Sanjeev Sharma wrote:
> on some architecture spin_is_locked() always return false in 
> uniprocessor configuration and therefore it would be advise to replace 
> with lockdep_assert_held().
> 
> Signed-off-by: Sanjeev Sharma 
> ---
> Changes in v3:
>  incorporated review comment suggested by Greg

Thanks, this is still:

Acked-by: Hans de Goede 

Regards,

Hans

> 
>  drivers/usb/storage/uas.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c 
> index 3f42785..05b2d8e 100644
> --- a/drivers/usb/storage/uas.c
> +++ b/drivers/usb/storage/uas.c
> @@ -154,7 +154,7 @@ static void uas_mark_cmd_dead(struct uas_dev_info 
> *devinfo,
>   struct scsi_cmnd *cmnd = container_of(scp, struct scsi_cmnd, SCp);
>  
>   uas_log_cmd_state(cmnd, caller);
> - WARN_ON_ONCE(!spin_is_locked(&devinfo->lock));
> + lockdep_assert_held(&devinfo->lock);
>   WARN_ON_ONCE(cmdinfo->state & COMMAND_ABORTED);
>   cmdinfo->state |= COMMAND_ABORTED;
>   cmdinfo->state &= ~IS_IN_WORK_LIST;
> @@ -181,7 +181,7 @@ static void uas_add_work(struct uas_cmd_info *cmdinfo)
>   struct scsi_cmnd *cmnd = container_of(scp, struct scsi_cmnd, SCp);
>   struct uas_dev_info *devinfo = cmnd->device->hostdata;
>  
> - WARN_ON_ONCE(!spin_is_locked(&devinfo->lock));
> + lockdep_assert_held(&devinfo->lock);
>   cmdinfo->state |= IS_IN_WORK_LIST;
>   schedule_work(&devinfo->work);
>  }
> @@ -283,7 +283,7 @@ static int uas_try_complete(struct scsi_cmnd *cmnd, const 
> char *caller)
>   struct uas_cmd_info *cmdinfo = (void *)&cmnd->SCp;
>   struct uas_dev_info *devinfo = (void *)cmnd->device->hostdata;
>  
> - WARN_ON_ONCE(!spin_is_locked(&devinfo->lock));
> + lockdep_assert_held(&devinfo->lock);
>   if (cmdinfo->state & (COMMAND_INFLIGHT |
> DATA_IN_URB_INFLIGHT |
> DATA_OUT_URB_INFLIGHT |
> @@ -622,7 +622,7 @@ static int uas_submit_urbs(struct scsi_cmnd *cmnd,
>   struct urb *urb;
>   int err;
>  
> - WARN_ON_ONCE(!spin_is_locked(&devinfo->lock));
> + lockdep_assert_held(&devinfo->lock);
>   if (cmdinfo->state & SUBMIT_STATUS_URB) {
>   urb = uas_submit_sense_urb(cmnd, gfp, cmdinfo->stream);
>   if (!urb)
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 4/17] arcmsr: limit max. number of SCSI command request

[Ching Huang]

From: Ching Huang 

This patch limits the max. number of SCSI commmand request to avoid command 
overflow.

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h  2014-05-06 15:24:06.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h  2014-05-06 15:22:36.0 +0800
@@ -45,11 +45,12 @@
 #include 
 struct device_attribute;
 /*The limit of outstanding scsi command that firmware can handle*/
-#define ARCMSR_MAX_OUTSTANDING_CMD 
256
 #ifdef CONFIG_XEN
#define ARCMSR_MAX_FREECCB_NUM  160
+#define ARCMSR_MAX_OUTSTANDING_CMD 155
 #else
#define ARCMSR_MAX_FREECCB_NUM  320
+#define ARCMSR_MAX_OUTSTANDING_CMD 255
 #endif
 #define ARCMSR_DRIVER_VERSION  "v1.30.00.04-20140428"
 #define ARCMSR_SCSI_INITIATOR_ID   
255
@@ -598,6 +599,7 @@ struct AdapterControlBlock
#define FW_DEADLOCK 0x0010
atomic_trq_map_token;
atomic_tante_token_value;
+   uint32_tmaxOutstanding;
int msix_vector_count;
 };/* HW_DEVICE_EXTENSION */
 /*
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2014-08-08 19:03:48.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2014-08-08 19:35:46.0 +0800
@@ -134,7 +134,7 @@ static struct scsi_host_template arcmsr_
.eh_bus_reset_handler   = arcmsr_bus_reset,
.bios_param = arcmsr_bios_param,
.change_queue_depth = arcmsr_adjust_disk_queue_depth,
-   .can_queue  = ARCMSR_MAX_FREECCB_NUM,
+   .can_queue  = ARCMSR_MAX_OUTSTANDING_CMD,
.this_id= ARCMSR_SCSI_INITIATOR_ID,
.sg_tablesize   = ARCMSR_DEFAULT_SG_ENTRIES, 
.max_sectors= ARCMSR_MAX_XFER_SECTORS_C, 
@@ -693,7 +693,7 @@ static int arcmsr_probe(struct pci_dev *
host->max_lun = ARCMSR_MAX_TARGETLUN;
host->max_id = ARCMSR_MAX_TARGETID; /*16:8*/
host->max_cmd_len = 16; /*this is issue of 
64bit LBA ,over 2T byte*/
-   host->can_queue = ARCMSR_MAX_FREECCB_NUM;   /* max simultaneous 
cmds */ 
+   host->can_queue = ARCMSR_MAX_OUTSTANDING_CMD;   /* max simultaneous 
cmds */ 
host->cmd_per_lun = ARCMSR_MAX_CMD_PERLUN;  
host->this_id = ARCMSR_SCSI_INITIATOR_ID;
host->unique_id = (bus << 8) | dev_fun;
@@ -2215,9 +2215,6 @@ static int arcmsr_queue_command_lck(stru
arcmsr_handle_virtual_command(acb, cmd);
return 0;
}
-   if (atomic_read(&acb->ccboutstandingcount) >=
-   ARCMSR_MAX_OUTSTANDING_CMD)
-   return SCSI_MLQUEUE_HOST_BUSY;
ccb = arcmsr_get_freeccb(acb);
if (!ccb)
return SCSI_MLQUEUE_HOST_BUSY;
@@ -2427,12 +2424,27 @@ static bool arcmsr_get_hbc_config(struct
 }
 static bool arcmsr_get_firmware_spec(struct AdapterControlBlock *acb)
 {
-   if (acb->adapter_type == ACB_ADAPTER_TYPE_A)
-   return arcmsr_get_hba_config(acb);
-   else if (acb->adapter_type == ACB_ADAPTER_TYPE_B)
-   return arcmsr_get_hbb_config(acb);
+   bool rtn = false;
+
+   switch (acb->adapter_type) {
+   case ACB_ADAPTER_TYPE_A:
+   rtn = arcmsr_get_hba_config(acb);
+   break;
+   case ACB_ADAPTER_TYPE_B:
+   rtn = arcmsr_get_hbb_config(acb);
+   break;
+   case ACB_ADAPTER_TYPE_C:
+   rtn = arcmsr_get_hbc_config(acb);
+   break;
+   default:
+   break;
+   }
+   if(acb->firm_numbers_queue > ARCMSR_MAX_OUTSTANDING_CMD)
+   acb->maxOutstanding = ARCMSR_MAX_OUTSTANDING_CMD;
else
-   return arcmsr_get_hbc_config(acb);
+   acb->maxOutstanding = acb->firm_numbers_queue - 1;
+   acb->host->can_queue = acb->maxOutstanding;
+   return rtn;
 }
 
 static int arcmsr_polling_hba_ccbdone(struct AdapterControlBlock *acb,


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 3/17] arcmsr: Add code to support hibernation

[Ching Huang]

From: Ching Huang 

This patch adds code to support system hibernation.

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2014-08-01 17:54:46.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2014-08-08 19:03:48.0 +0800
@@ -89,11 +89,15 @@ static int arcmsr_bios_param(struct scsi
 static int arcmsr_queue_command(struct Scsi_Host *h, struct scsi_cmnd *cmd);
 static int arcmsr_probe(struct pci_dev *pdev,
const struct pci_device_id *id);
+static int arcmsr_suspend(struct pci_dev *pdev, pm_message_t state);
+static int arcmsr_resume(struct pci_dev *pdev);
 static void arcmsr_remove(struct pci_dev *pdev);
 static void arcmsr_shutdown(struct pci_dev *pdev);
 static void arcmsr_iop_init(struct AdapterControlBlock *acb);
 static void arcmsr_free_ccb_pool(struct AdapterControlBlock *acb);
 static u32 arcmsr_disable_outbound_ints(struct AdapterControlBlock *acb);
+static void arcmsr_enable_outbound_ints(struct AdapterControlBlock *acb,
+   u32 intmask_org);
 static void arcmsr_stop_adapter_bgrb(struct AdapterControlBlock *acb);
 static void arcmsr_flush_hba_cache(struct AdapterControlBlock *acb);
 static void arcmsr_flush_hbb_cache(struct AdapterControlBlock *acb);
@@ -167,6 +171,8 @@ static struct pci_driver arcmsr_pci_driv
.id_table   = arcmsr_device_id_table,
.probe  = arcmsr_probe,
.remove = arcmsr_remove,
+   .suspend= arcmsr_suspend,
+   .resume = arcmsr_resume,
.shutdown   = arcmsr_shutdown,
 };
 /*
@@ -772,6 +778,76 @@ static void arcmsr_free_irq(struct pci_d
free_irq(pdev->irq, acb);
 }
 
+static int arcmsr_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+   uint32_t intmask_org;
+   struct Scsi_Host *host = pci_get_drvdata(pdev);
+   struct AdapterControlBlock *acb =
+   (struct AdapterControlBlock *)host->hostdata;
+
+   intmask_org = arcmsr_disable_outbound_ints(acb);
+   arcmsr_free_irq(pdev, acb);
+   del_timer_sync(&acb->eternal_timer);
+   flush_work(&acb->arcmsr_do_message_isr_bh);
+   arcmsr_stop_adapter_bgrb(acb);
+   arcmsr_flush_adapter_cache(acb);
+   pci_set_drvdata(pdev, host);
+   pci_save_state(pdev);
+   pci_disable_device(pdev);
+   pci_set_power_state(pdev, pci_choose_state(pdev, state));
+   return 0;
+}
+
+static int arcmsr_resume(struct pci_dev *pdev)
+{
+   int error;
+   struct Scsi_Host *host = pci_get_drvdata(pdev);
+   struct AdapterControlBlock *acb =
+   (struct AdapterControlBlock *)host->hostdata;
+
+   pci_set_power_state(pdev, PCI_D0);
+   pci_enable_wake(pdev, PCI_D0, 0);
+   pci_restore_state(pdev);
+   if (pci_enable_device(pdev)) {
+   pr_warn("%s: pci_enable_device error\n", __func__);
+   return -ENODEV;
+   }
+   error = pci_set_dma_mask(pdev, DMA_BIT_MASK(64));
+   if (error) {
+   error = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
+   if (error) {
+   pr_warn("scsi%d: No suitable DMA mask available\n",
+  host->host_no);
+   goto controller_unregister;
+   }
+   }
+   pci_set_master(pdev);
+   if (arcmsr_request_irq(pdev, acb) == FAILED)
+   goto controller_stop;
+   arcmsr_iop_init(acb);
+   INIT_WORK(&acb->arcmsr_do_message_isr_bh, arcmsr_message_isr_bh_fn);
+   atomic_set(&acb->rq_map_token, 16);
+   atomic_set(&acb->ante_token_value, 16);
+   acb->fw_flag = FW_NORMAL;
+   init_timer(&acb->eternal_timer);
+   acb->eternal_timer.expires = jiffies + msecs_to_jiffies(6 * HZ);
+   acb->eternal_timer.data = (unsigned long) acb;
+   acb->eternal_timer.function = &arcmsr_request_device_map;
+   add_timer(&acb->eternal_timer);
+   return 0;
+controller_stop:
+   arcmsr_stop_adapter_bgrb(acb);
+   arcmsr_flush_adapter_cache(acb);
+controller_unregister:
+   scsi_remove_host(host);
+   arcmsr_free_ccb_pool(acb);
+   arcmsr_unmap_pciregion(acb);
+   pci_release_regions(pdev);
+   scsi_host_put(host);
+   pci_disable_device(pdev);
+   return -ENODEV;
+}
+
 static uint8_t arcmsr_abort_hba_allcmd(struct AdapterControlBlock *acb)
 {
struct MessageUnit_A __iomem *reg = acb->pmuA;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 2/17] arcmsr: Add code to support MSI-X, MSI interrupt

[Ching Huang]

From: Ching Huang 

This patch adds code to support MSI, MSI-X interrupt.

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h  2014-04-28 16:02:46.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h  2014-05-06 15:24:36.0 +0800
@@ -64,6 +64,7 @@ struct device_attribute;
 #define ARCMSR_MAX_HBB_POSTQUEUE   
264
 #define ARCMSR_MAX_XFER_LEN
0x26000 /* 152K */
 #define ARCMSR_CDB_SG_PAGE_LENGTH  
256 
+#define ARCMST_NUM_MSIX_VECTORS4
 #ifndef PCI_DEVICE_ID_ARECA_1880
 #define PCI_DEVICE_ID_ARECA_1880 0x1880
  #endif
@@ -508,6 +509,7 @@ struct AdapterControlBlock
struct pci_dev *pdev;
struct Scsi_Host *  host;
unsigned long   vir2phy_offset;
+   struct msix_entry   entries[ARCMST_NUM_MSIX_VECTORS];
/* Offset is used in making arc cdb physical to virtual calculations */
uint32_toutbound_int_enable;
uint32_tcdb_phyaddr_hi32;
@@ -544,6 +546,8 @@ struct AdapterControlBlock
/* iop init */
#define ACB_F_ABORT 0x0200
#define ACB_F_FIRMWARE_TRAP 0x0400
+   #define ACB_F_MSI_ENABLED   0x1000
+   #define ACB_F_MSIX_ENABLED  0x2000
struct CommandControlBlock *
pccb_pool[ARCMSR_MAX_FREECCB_NUM];
/* used for memory free */
struct list_headccb_free_list;
@@ -594,6 +598,7 @@ struct AdapterControlBlock
#define FW_DEADLOCK 0x0010
atomic_trq_map_token;
atomic_tante_token_value;
+   int msix_vector_count;
 };/* HW_DEVICE_EXTENSION */
 /*
 ***
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2014-08-01 11:02:44.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2014-08-01 17:54:46.0 +0800
@@ -603,6 +603,56 @@ static void arcmsr_message_isr_bh_fn(str
}
 }
 
+static int
+arcmsr_request_irq(struct pci_dev *pdev, struct AdapterControlBlock *acb)
+{
+   int i, j, r;
+   struct msix_entry entries[ARCMST_NUM_MSIX_VECTORS];
+
+   for (i = 0; i < ARCMST_NUM_MSIX_VECTORS; i++)
+   entries[i].entry = i;
+   r = pci_enable_msix_range(pdev, entries, 1, ARCMST_NUM_MSIX_VECTORS);
+   if (r < 0)
+   goto msi_int;
+   acb->msix_vector_count = r;
+   for (i = 0; i < r; i++) {
+   if (request_irq(entries[i].vector,
+   arcmsr_do_interrupt, 0, "arcmsr", acb)) {
+   pr_warn("arcmsr%d: request_irq =%d failed!\n",
+   acb->host->host_no, entries[i].vector);
+   for (j = 0 ; j < i ; j++)
+   free_irq(entries[j].vector, acb);
+   pci_disable_msix(pdev);
+   goto msi_int;
+   }
+   acb->entries[i] = entries[i];
+   }
+   acb->acb_flags |= ACB_F_MSIX_ENABLED;
+   pr_info("arcmsr%d: msi-x enabled\n", acb->host->host_no);
+   return SUCCESS;
+msi_int:
+   if (pci_enable_msi_exact(pdev, 1) < 0)
+   goto legacy_int;
+   if (request_irq(pdev->irq, arcmsr_do_interrupt,
+   IRQF_SHARED, "arcmsr", acb)) {
+   pr_warn("arcmsr%d: request_irq =%d failed!\n",
+   acb->host->host_no, pdev->irq);
+   pci_disable_msi(pdev);
+   goto legacy_int;
+   }
+   acb->acb_flags |= ACB_F_MSI_ENABLED;
+   pr_info("arcmsr%d: msi enabled\n", acb->host->host_no);
+   return SUCCESS;
+legacy_int:
+   if (request_irq(pdev->irq, arcmsr_do_interrupt,
+   IRQF_SHARED, "arcmsr", acb)) {
+   pr_warn("arcmsr%d: request_irq = %d failed!\n",
+   acb->host->host_no, pdev->irq);
+   return FAILED;
+   }
+   return SUCCESS;
+}
+
 static int arcmsr_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 {
struct Scsi_Host *host;
@@ -667,16 +717,13 @@ static int arcmsr_probe(struct pci_dev *
if(error){
goto free_hbb_mu;
}
-   arcmsr_iop_init(acb);
error = scsi_add_host(host, &pdev->dev);
if(error){
goto RAID_controller_stop;
}
-   error = request_irq(pdev->irq, arcmsr_do_interrupt, IRQF_SHARED, 
"arcmsr", acb);
-   if(error){
+   if (arcmsr_request_irq(pdev, acb) == FAILED)
goto scsi_host_remove;
-   }
-   

Re: [PATCH] perf, tools: Add PERF_PID

[Namhyung Kim]

Hi Andi,

On Wed, 13 Aug 2014 14:12:17 -0700, Andi Kleen wrote:
> From: Andi Kleen 
>
> It's currently difficult to filter out perf itself using a filter.
> This can give cascading effects during IO tracing when the IO
> perf does itself causes more trace output.
>
> The best way to filter is to use the pid. But it's difficult to get the pid
> of perf without using hacks.
>
> Add a PERF_PID meta variable to the perf filter that contains the current pid.
>
> With this patch the following works
>
> % perf record -e syscalls:sys_enter_write -a --filter 'common_pid != 
> PERF_PID' ...
>
> This won't work for more complex perf pipe lines with multiple processes,
> but at least solves the problem nicely for a single perf.
>
> Signed-off-by: Andi Kleen 

I like the idea, so with comments below fixed:

Acked-by: Namhyung Kim 

Thanks,
Namhyung


[SNIP]
> + /* Assume a pid has not more than 8 characters */
> + pid = strstr(last->filter, "PERF_PID");
> + if (pid) {
> + char buf[9];
> + snprintf(buf, 9, "%08d", getpid());

Why do you add zero-paddings?  I guess it'd confuse the parser as if
it's an octal digits.  What about just using "%8d"?  It seems the parser
ignores whitespaces between tokens..


> + memcpy(pid, buf, 8);
> + }
> + fprintf(stderr, "filter |%s|\n", last->filter);

Isn't it a debug message?

Thanks,
Namhyung


>   return 0;
>  }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] mem-hotplug: fix boot failed in case all the nodes are hotpluggable

[Xishi Qiu]

If all the nodes are marked hotpluggable flag, alloc node data will fail.
Because __next_mem_range_rev() will skip the hotpluggable memory regions.
numa_clear_kernel_node_hotplug() is called after alloc node data.

numa_init()
...
ret = init_func();  // this will mark hotpluggable flag from SRAT
...
memblock_set_bottom_up(false);
...
ret = numa_register_memblks(&numa_meminfo);  // this will alloc node 
data(pglist_data) 
...
numa_clear_kernel_node_hotplug();  // in case all the nodes are 
hotpluggable
...

numa_register_memblks()
setup_node_data()
memblock_find_in_range_node()
__memblock_find_range_top_down()
for_each_mem_range_rev()
__next_mem_range_rev()

This patch moves numa_clear_kernel_node_hotplug() into numa_register_memblks(),
clear kernel node hotpluggable flag before alloc node data, then alloc node data
won't fail even all the nodes are hotpluggable.

Signed-off-by: Xishi Qiu 
---
 arch/x86/mm/numa.c |   88 ++--
 1 files changed, 44 insertions(+), 44 deletions(-)

diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index a32b706..f7ebd97 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -478,6 +478,41 @@ static bool __init numa_meminfo_cover_memory(const struct 
numa_meminfo *mi)
return true;
 }
 
+static void __init numa_clear_kernel_node_hotplug(void)
+{
+   int i, nid;
+   nodemask_t numa_kernel_nodes = NODE_MASK_NONE;
+   unsigned long start, end;
+   struct memblock_region *r;
+
+   /*
+* At this time, all memory regions reserved by memblock are
+* used by the kernel. Set the nid in memblock.reserved will
+* mark out all the nodes the kernel resides in.
+*/
+   for (i = 0; i < numa_meminfo.nr_blks; i++) {
+   struct numa_memblk *mb = &numa_meminfo.blk[i];
+   memblock_set_node(mb->start, mb->end - mb->start,
+ &memblock.reserved, mb->nid);
+   }
+
+   /* Mark all kernel nodes. */
+   for_each_memblock(reserved, r)
+   node_set(r->nid, numa_kernel_nodes);
+
+   /* Clear MEMBLOCK_HOTPLUG flag for memory in kernel nodes. */
+   for (i = 0; i < numa_meminfo.nr_blks; i++) {
+   nid = numa_meminfo.blk[i].nid;
+   if (!node_isset(nid, numa_kernel_nodes))
+   continue;
+
+   start = numa_meminfo.blk[i].start;
+   end = numa_meminfo.blk[i].end;
+
+   memblock_clear_hotplug(start, end - start);
+   }
+}
+
 static int __init numa_register_memblks(struct numa_meminfo *mi)
 {
unsigned long uninitialized_var(pfn_align);
@@ -496,6 +531,15 @@ static int __init numa_register_memblks(struct 
numa_meminfo *mi)
}
 
/*
+* At very early time, the kernel have to use some memory such as
+* loading the kernel image. We cannot prevent this anyway. So any
+* node the kernel resides in should be un-hotpluggable.
+*
+* And when we come here, alloc node data won't fail.
+*/
+   numa_clear_kernel_node_hotplug();
+
+   /*
 * If sections array is gonna be used for pfn -> nid mapping, check
 * whether its granularity is fine enough.
 */
@@ -554,41 +598,6 @@ static void __init numa_init_array(void)
}
 }
 
-static void __init numa_clear_kernel_node_hotplug(void)
-{
-   int i, nid;
-   nodemask_t numa_kernel_nodes = NODE_MASK_NONE;
-   unsigned long start, end;
-   struct memblock_region *r;
-
-   /*
-* At this time, all memory regions reserved by memblock are
-* used by the kernel. Set the nid in memblock.reserved will
-* mark out all the nodes the kernel resides in.
-*/
-   for (i = 0; i < numa_meminfo.nr_blks; i++) {
-   struct numa_memblk *mb = &numa_meminfo.blk[i];
-   memblock_set_node(mb->start, mb->end - mb->start,
- &memblock.reserved, mb->nid);
-   }
-
-   /* Mark all kernel nodes. */
-   for_each_memblock(reserved, r)
-   node_set(r->nid, numa_kernel_nodes);
-
-   /* Clear MEMBLOCK_HOTPLUG flag for memory in kernel nodes. */
-   for (i = 0; i < numa_meminfo.nr_blks; i++) {
-   nid = numa_meminfo.blk[i].nid;
-   if (!node_isset(nid, numa_kernel_nodes))
-   continue;
-
-   start = numa_meminfo.blk[i].start;
-   end = numa_meminfo.blk[i].end;
-
-   memblock_clear_hotplug(start, end - start);
-   }
-}
-
 static int __init numa_init(int (*init_func)(void))
 {
int i;
@@ -643,15 +652,6 @@ static int __init numa_init(int (*init_func)(void))
}
numa_init_array();
 
-   /*
-* At 

[PATCH v3 1/17] arcmsr: Revised interrupt service routine relate function to fix bug

[Ching Huang]

From: Ching Huang 

This patch rewrite the interrupt service routine relate function to fix command 
timeout when controller has very heavy loading.

Signed-off-by: Ching Huang 
---

diff -uprN a/drivers/scsi/arcmsr/arcmsr.h b/drivers/scsi/arcmsr/arcmsr.h
--- a/drivers/scsi/arcmsr/arcmsr.h  2014-07-30 10:33:02.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr.h  2014-04-28 16:02:46.0 +0800
@@ -51,7 +51,7 @@ struct device_attribute;
 #else
#define ARCMSR_MAX_FREECCB_NUM  320
 #endif
-#define ARCMSR_DRIVER_VERSION   "Driver Version 1.20.00.15 
2010/08/05"
+#define ARCMSR_DRIVER_VERSION  "v1.30.00.04-20140428"
 #define ARCMSR_SCSI_INITIATOR_ID   
255
 #define ARCMSR_MAX_XFER_SECTORS
512
 #define ARCMSR_MAX_XFER_SECTORS_B  
4096
diff -uprN a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
--- a/drivers/scsi/arcmsr/arcmsr_hba.c  2014-07-30 10:32:28.0 +0800
+++ b/drivers/scsi/arcmsr/arcmsr_hba.c  2014-08-01 11:02:44.0 +0800
@@ -1441,14 +1441,15 @@ static void arcmsr_hba_doorbell_isr(stru
uint32_t outbound_doorbell;
struct MessageUnit_A __iomem *reg = acb->pmuA;
outbound_doorbell = readl(®->outbound_doorbell);
-   writel(outbound_doorbell, ®->outbound_doorbell);
-   if (outbound_doorbell & ARCMSR_OUTBOUND_IOP331_DATA_WRITE_OK) {
-   arcmsr_iop2drv_data_wrote_handle(acb);
-   }
-
-   if (outbound_doorbell & ARCMSR_OUTBOUND_IOP331_DATA_READ_OK) {
-   arcmsr_iop2drv_data_read_handle(acb);
-   }
+   do {
+   writel(outbound_doorbell, ®->outbound_doorbell);
+   if (outbound_doorbell & ARCMSR_OUTBOUND_IOP331_DATA_WRITE_OK)
+   arcmsr_iop2drv_data_wrote_handle(acb);
+   if (outbound_doorbell & ARCMSR_OUTBOUND_IOP331_DATA_READ_OK)
+   arcmsr_iop2drv_data_read_handle(acb);
+   outbound_doorbell = readl(®->outbound_doorbell);
+   } while (outbound_doorbell & (ARCMSR_OUTBOUND_IOP331_DATA_WRITE_OK
+   | ARCMSR_OUTBOUND_IOP331_DATA_READ_OK));
 }
 static void arcmsr_hbc_doorbell_isr(struct AdapterControlBlock *pACB)
 {
@@ -1462,17 +1463,19 @@ static void arcmsr_hbc_doorbell_isr(stru
***
*/
outbound_doorbell = readl(®->outbound_doorbell);
-   writel(outbound_doorbell, ®->outbound_doorbell_clear);/*clear 
interrupt*/
-   if (outbound_doorbell & ARCMSR_HBCMU_IOP2DRV_DATA_WRITE_OK) {
-   arcmsr_iop2drv_data_wrote_handle(pACB);
-   }
-   if (outbound_doorbell & ARCMSR_HBCMU_IOP2DRV_DATA_READ_OK) {
-   arcmsr_iop2drv_data_read_handle(pACB);
-   }
-   if (outbound_doorbell & ARCMSR_HBCMU_IOP2DRV_MESSAGE_CMD_DONE) {
-   arcmsr_hbc_message_isr(pACB);/* messenger of "driver to iop 
commands" */
-   }
-   return;
+   do {
+   writel(outbound_doorbell, ®->outbound_doorbell_clear);
+   readl(®->outbound_doorbell_clear);
+   if (outbound_doorbell & ARCMSR_HBCMU_IOP2DRV_DATA_WRITE_OK)
+   arcmsr_iop2drv_data_wrote_handle(pACB);
+   if (outbound_doorbell & ARCMSR_HBCMU_IOP2DRV_DATA_READ_OK)
+   arcmsr_iop2drv_data_read_handle(pACB);
+   if (outbound_doorbell & ARCMSR_HBCMU_IOP2DRV_MESSAGE_CMD_DONE)
+   arcmsr_hbc_message_isr(pACB);
+   outbound_doorbell = readl(®->outbound_doorbell);
+   } while (outbound_doorbell & (ARCMSR_HBCMU_IOP2DRV_DATA_WRITE_OK
+   | ARCMSR_HBCMU_IOP2DRV_DATA_READ_OK
+   | ARCMSR_HBCMU_IOP2DRV_MESSAGE_CMD_DONE));
 }
 static void arcmsr_hba_postqueue_isr(struct AdapterControlBlock *acb)
 {
@@ -1521,21 +1524,22 @@ static void arcmsr_hbc_postqueue_isr(str
/* areca cdb command done */
/* Use correct offset and size for syncing */
 
-   while (readl(&phbcmu->host_int_status) &
-   ARCMSR_HBCMU_OUTBOUND_POSTQUEUE_ISR){
-   /* check if command done with no error*/
-   flag_ccb = readl(&phbcmu->outbound_queueport_low);
-   ccb_cdb_phy = (flag_ccb & 0xFFF0);/*frame must be 32 bytes aligned*/
-   arcmsr_cdb = (struct ARCMSR_CDB *)(acb->vir2phy_offset + ccb_cdb_phy);
-   ccb = container_of(arcmsr_cdb, struct CommandControlBlock, arcmsr_cdb);
-   error = (flag_ccb & ARCMSR_CCBREPLY_FLAG_ERROR_MODE1) ? true : false;
-   /* check if command done with no error */
-   arcmsr_drain_donequeue(acb, ccb, error);
-   if (throttling == ARCMSR_HBC_ISR_THROTTLING_LEVEL) {
-   writel(ARCMSR_HBCMU_DRV2IOP_POSTQUEUE_THROTTLING, 
&phbcmu->inbound_doorbell);
-   break;
-   }
-   throttling++;
+   while ((flag_ccb = readl(&phbcmu->outbound_q

Re: [PATCH 1/5] KVM: vmx: fix ept reserved bits for 1-GByte page

[Paolo Bonzini]

Il 19/08/2014 04:17, Wanpeng Li ha scritto:
>>> >> -if (level == 1 || (level == 2 && (spte & (1ULL << 7 
>>> >> {
>>> >> +if (level == 1 || ((level == 3 || level == 2)
>>> >> +&& (spte & (1ULL << 7 {
>> >
>> >This condition can be simplified by checking the return value of 
>> >ept_rsvd_mask.
>> >If it includes 0x38, this is a large page.

Oops, a "not" was missing. If it includes 0x38, this is _not_ a large
page (it is a page directory / page directory pointer / PML4).

>> Otherwise it is a leaf page and
>> you can go down the "if".
> As you know, 5:3 bits which used for EPT MT are not reserved bits, so 
> I fail to understand why check the return value of ept_rsvd_mask and 
> it's a large page if includes 0x38. Could you eplain in more details? ;-)

A non-leaf page will always have 0x38 in the ept_rsvd_mask.  A leaf page
will never have 0x38 in the ept_rsvd_mask.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/4] xhci: Introduce xhci_init_driver()

[Yoshihiro Shimoda]

Hi,

(2014/08/19 1:12), Andrew Bresticker wrote:
> Since the struct hc_driver is mostly the same across the xhci-pci,
> xhci-plat, and the upcoming xhci-tegra driver, introduce the function
> xhci_init_driver() which will populate the hc_driver with the default
> xHCI operations.  The caller must supply a setup function which will
> be used as the hc_driver's reset callback.
> 
> Note that xhci-plat also overrides the default ->start() callback so
> that it can do rcar-specific initialization.
> 
> Signed-off-by: Andrew Bresticker 
> ---
> Changes from v1:
>  - rebased on changes introduced by xhci-rcar driver
< snip >
> @@ -300,6 +249,8 @@ MODULE_ALIAS("platform:xhci-hcd");
>  
>  int xhci_register_plat(void)
>  {
> + xhci_init_driver(&xhci_plat_hc_driver, xhci_plat_setup);
> + xhci_plat_hc_drver.start = xhci_plat_start;

Thank you for the care of xhci-rcar driver.
However, this "xhci_plat_hc_drver" should be "xhci_plat_hc_driver".

After I modified it by myself, I could build the xhci-plat-hcd.ko in my 
environment.

Best regards,
Yoshihiro Shimoda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] perf top: Handle 'z' key for toggle zeroing samples in TUI

[Namhyung Kim]

On Wed, 13 Aug 2014 22:47:43 +0200, Stephane Eranian wrote:
> On Wed, Aug 13, 2014 at 10:37 PM, Arnaldo Carvalho de Melo
>  wrote:
>>
>> Em Wed, Aug 13, 2014 at 01:07:30AM +0200, Stephane Eranian escreveu:
>> > On Tue, Aug 12, 2014 at 10:16 AM, Namhyung Kim  wrote:
>> > > The perf top TUI lacks 'z' key support to toggle sample zeroing.
>> > > Add it.
>> > >
>> > Works for me.
>> > Tested-by: Stephane Eranian 
>>
>> One thing that can be improved: Make it trigger a refresh in the right
>> after 'z' is pressed.
>>
>> Also, this toggles the zeroing before each sample, it would be nice to
>> have a visual cue that this is in effect, probably in the first line in
>> the screen, perhaps on the far right, something like [z] when this is in
>> effect and nothing when not.
>>
> I agree. Had to run a test on the side to verify that it was actually doing
> the right thing.
>
>>
>> Right now the way to figure this out is to observe the number of
>> samples, if it increases monotonically, zeroing before refresh is not in
>> effect, if it goes from a high number to a smaller or vice versa,
>> zeroing is in effect :-)
>>
>> Anyway, applied, people wanting this feature can figure this out, what I
>> suggested is just polishing.
>>
> We need to visual cue.

Got it.  Will add [z] on the header line.

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/2] usb: gadget: Add xilinx usb2 device support

[sundeep subbaraya]

Hi,

On Tue, Jul 22, 2014 at 3:32 PM, Varka Bhadram  wrote:
> On 07/22/2014 02:38 PM, Subbaraya Sundeep Bhatta wrote:
>>
>> +#include 
>> +#include 
>> +#include 
>> +#include "gadget_chips.h"
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>
>
> Normally we will put the includes in alphabetical because it looks good
> and readable.
>
> But we have to include the local headers separately after all the main
> includes...
> #include 
> #include 
> 
> #include 
>
> #include "gadget_chips.h"
>
> (...)
>
Ok
>
>>
>> +   switch (udc->setupseqtx) {
>> +   case STATUS_PHASE:
>> +   switch (udc->setup.bRequest) {
>> +   case USB_REQ_SET_ADDRESS:
>> +   /* Set the address of the device.*/
>> +   udc->write_fn(udc->base_address,
>> +   XUSB_ADDRESS_OFFSET,
>> +   udc->setup.wValue);
>
>
> Should match open parenthesis
not necessary, as per coding style spaces should not be used --
Outside of comments, documentation and except in Kconfig, spaces are never
used for indentation.

>
> udc->write_fn(udc->base_address,
>   XUSB_ADDRESS_OFFSET,
>
>   udc->setup.wValue);
>
>
>> +   break;
>> +   case USB_REQ_SET_FEATURE:
>> +   if (udc->setup.bRequestType ==
>> +   USB_RECIP_DEVICE) {
>> +   if (udc->setup.wValue ==
>> +   USB_DEVICE_TEST_MODE)
>> +   udc->write_fn(udc->base_address,
>> +
>> XUSB_TESTMODE_OFFSET,
>> +   test_mode);
>
>
> Dto
not necessary
>
>
>> +   }
>> +   break;
>> +   }
>> +   req->usb_req.actual = req->usb_req.length;
>> +   xudc_done(ep0, req, 0);
>> +   break;
>> +   case DATA_PHASE:
>> +   if (!bytes_to_tx) {
>> +   /*
>> +* We're done with data transfer, next
>> +* will be zero length OUT with data toggle of
>> +* 1. Setup data_toggle.
>> +*/
>> +   epcfgreg = udc->read_fn(udc->base_address +
>> +   ep0->offset);
>> +   epcfgreg |= XUSB_EP_CFG_DATA_TOGGLE_MASK;
>> +   udc->write_fn(udc->base_address, ep0->offset,
>> epcfgreg);
>> +   udc->setupseqtx = STATUS_PHASE;
>> +   } else {
>> +   length = count = min_t(u32, bytes_to_tx,
>> +   EP0_MAX_PACKET);
>> +   /* Copy the data to be transmitted into the DPRAM.
>> */
>> +   ep0rambase = (u8 __force *) (udc->base_address +
>> +   (ep0->rambase << 2));
>> +
>> +   buffer = req->usb_req.buf + req->usb_req.actual;
>> +   req->usb_req.actual = req->usb_req.actual +
>> length;
>> +   memcpy((void *)ep0rambase, buffer, length);
>> +   }
>> +   udc->write_fn(udc->base_address, XUSB_EP_BUF0COUNT_OFFSET,
>> +   count);
>> +   udc->write_fn(udc->base_address, XUSB_BUFFREADY_OFFSET,
>> 1);
>> +   break;
>> +   default:
>> +   break;
>> +   }
>> +}
>> +
>> +/**
>> + * xudc_ctrl_ep_handler - Endpoint 0 interrupt handler.
>> + * @udc: pointer to the udc structure.
>> + * @intrstatus:It's the mask value for the interrupt sources on
>> endpoint 0.
>> + *
>> + * Processes the commands received during enumeration phase.
>> + */
>> +static void xudc_ctrl_ep_handler(struct xusb_udc *udc, u32 intrstatus)
>> +{
>> +
>> +   if (intrstatus & XUSB_STATUS_SETUP_PACKET_MASK) {
>> +   xudc_handle_setup(udc);
>> +   } else {
>> +   if (intrstatus & XUSB_STATUS_FIFO_BUFF_RDY_MASK)
>> +   xudc_ep0_out(udc);
>> +   else if (intrstatus & XUSB_STATUS_FIFO_BUFF_FREE_MASK)
>> +   xudc_ep0_in(udc);
>> +   }
>> +}
>> +
>> +/**
>> + * xudc_nonctrl_ep_handler - Non control endpoint interrupt handler.
>> + * @udc: pointer to the udc structure.
>> + * @epnum: End point number for which the interrupt is to be processed
>> + * @intrstatus:mask value for interrupt sources of endpoints
>> other
>> + * than endpoint 0.
>> + *
>> + * Processes the buffer completion interrupts.
>> + */
>> +static void xudc_nonctrl_ep_handler(struct xusb_udc *udc, u8 epnum,
>> +   u32 intrstatus)
>
>
> Should match open parenthesis:
not necessary
>
>
> sta

Re: [PATCH 00/29] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem

[Marek Szyprowski]

Hello,

On 2014-08-19 01:32, Joerg Roedel wrote:

On Tue, Aug 05, 2014 at 12:47:28PM +0200, Marek Szyprowski wrote:

  .../devicetree/bindings/iommu/samsung,sysmmu.txt   |  93 ++-
  Documentation/power/notifiers.txt  |  14 +
  arch/arm/boot/dts/exynos4.dtsi | 118 
  arch/arm/boot/dts/exynos4210.dtsi  |  23 +
  arch/arm/boot/dts/exynos4x12.dtsi  |  82 +++
  arch/arm/include/asm/dma-iommu.h   |  36 ++
  arch/arm/mach-exynos/pm_domains.c  |  12 +-
  arch/arm/mach-integrator/impd1.c   |   2 +-
  arch/arm/mm/dma-mapping.c  |  47 ++
  drivers/base/bus.c |   4 +-
  drivers/base/dd.c  |  10 +-
  drivers/base/platform.c|   2 +-
  drivers/base/power/domain.c|  70 ++-
  drivers/clk/samsung/clk-exynos4.c  |   1 +
  drivers/gpu/drm/exynos/exynos_drm_fimc.c   |   1 +
  drivers/gpu/drm/exynos/exynos_drm_fimd.c   |  26 +-
  drivers/gpu/drm/exynos/exynos_drm_g2d.c|   1 +
  drivers/gpu/drm/exynos/exynos_drm_gsc.c|   1 +
  drivers/gpu/drm/exynos/exynos_drm_rotator.c|   1 +
  drivers/gpu/drm/exynos/exynos_mixer.c  |   1 +
  drivers/iommu/exynos-iommu.c   | 663 +
  drivers/iommu/iommu.c  |   3 +
  drivers/media/platform/s5p-mfc/s5p_mfc.c   | 107 ++--
  drivers/pci/host/pci-mvebu.c   |   2 +-
  drivers/pci/host/pci-rcar-gen2.c   |   2 +-
  drivers/pci/host/pci-tegra.c   |   2 +-
  drivers/pci/host/pcie-rcar.c   |   2 +-
  drivers/soc/tegra/pmc.c|   2 +-
  include/dt-bindings/clock/exynos4.h|  10 +-
  include/linux/device.h |  12 +-
  include/linux/iommu.h  |   1 +
  include/linux/pm.h |   2 +
  include/linux/pm_domain.h  |  19 +
  33 files changed, 1016 insertions(+), 356 deletions(-)

This touches a lot of non-iommu stuff. What is your strategy on getting
this in, do you plan to get the non-iommu changes merged first or do you
want to collect the respective Acks and merge this all through one tree?


Those patches are posted as one patchset mainly to demonstrate how to get
everything to work together. I also posted this as a single patch series
to get some feedback from other iommu developers, especially all those
involved in the generic iommu dt bindings.

For merging, I will split them into smaller series and try to get
respective acks.

Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH 1/2] perf top: Fix -z option behavior

[Namhyung Kim]

On Wed, 13 Aug 2014 17:27:56 -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Aug 12, 2014 at 05:16:05PM +0900, Namhyung Kim escreveu:
>> The current -z option does almost nothing.  It doesn't zero the
>> existing samples so that we can see profiles of exited process after
>> last refresh.  It seems it only affects annotation.
>> 
>> This patch clears existing entries before processing if -z option is
>> given.  For this original decaying logic also moved before processing.
>
> So, this is two things bolted into one, i.e. it is not stated here why
> decaying needs to be done before resorting. I bet its because since
> we're zeroing everything, no need to decay anything, right?

Exactly.

>
> Stating more clearly what is the intent and the reason for changes helps
> reviewing.

Yep, will do better next time.

>
> Anyway, will add a note about that and apply the change.

Thank you!

>
> Also, the delete entries thing could zero total stats in struct hists,
> which is not a problem currently, because, IIRC, the collapse/resort
> logic will do that when it rotates the hists, but if we ever want to
> just delete events and then add a bunch of events without resorting, we
> will end up with bogus stats that will have the sum of the old events
> stats with the new ones.

Right.  I'll send the fix.

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 03/13] perf annotate: Move session handling out of __cmd_annotate()

[Namhyung Kim]

On Wed, 13 Aug 2014 13:48:22 +0200, Jiri Olsa wrote:
> On Tue, Aug 12, 2014 at 03:40:35PM +0900, Namhyung Kim wrote:
>> +annotate.session = perf_session__new(&file, false, &annotate.tool);
>> +if (annotate.session == NULL)
>> +return -ENOMEM;
>
> I know you're just moving code, but perf_session__new could
> fail for more reasons than just ENOMEM, which is the most
> unlikely case ;-) -1 is probably better option here

Okay, will change as a separate fix later.

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Oops: 17 SMP ARM (v3.16-rc2)

[Iain Paton]

On 17/08/14 22:46, Fabio Estevam wrote:
> Iain,
> 
> On Sun, Aug 17, 2014 at 6:34 PM, Iain Paton  wrote:
>> On 15/08/14 06:42, Mattis Lorentzon wrote:
>>
>>> We mostly run SSH with benchmarks using NFS, it can probably be
>>> triggered by using only SSH with the following loop:
>>>
>>> # while : ; do ssh arm-card date; done
>>
>> Mattis,
>>
>> What sort of time does it take for you to see a problem?
>>
>> I've been running the above for nearly two days on 3.16.0 on a board
>> with fec interrupts routed through gpio_6 and haven't seen a hint of
>> a problem.
> 
> Thanks for testing.
> 
> Which mx6 board have you used on this test?

It's currently pointed at a RIoTboard (atheros phy) but I'm happy to 
try it against both a Sabre-Lite and a Wandboard B1, all running the 
same kernel binary, as well. 

I'm interested enough in why different people get different results 
with this that I'll put some time towards testing to try to help 
narrow down the cause.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] PM / sleep: Asynchronous threads for dpm_complete

[xiaoming wang]

In analogy with commits 5af84b82701a and 97df8c12995,
using asynchronous threads can improve the overall
resume time significantly.

This patch is for dpm_complete phase.

Signed-off-by: Chuansheng Liu 
Signed-off-by: xiaoming wang 
---
 drivers/base/power/main.c |   38 ++
 1 files changed, 34 insertions(+), 4 deletions(-)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index f9fe1b3..00c4bf1 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -889,14 +889,15 @@ void dpm_resume(pm_message_t state)
  * @dev: Device to handle.
  * @state: PM transition of the system being carried out.
  */
-static void device_complete(struct device *dev, pm_message_t state)
+static void device_complete(struct device *dev, pm_message_t state, bool async)
 {
void (*callback)(struct device *) = NULL;
char *info = NULL;
 
if (dev->power.syscore)
-   return;
+   goto Complete;
 
+   dpm_wait(dev->parent, async);
device_lock(dev);
 
if (dev->pm_domain) {
@@ -928,6 +929,17 @@ static void device_complete(struct device *dev, 
pm_message_t state)
device_unlock(dev);
 
pm_runtime_put(dev);
+
+Complete:
+   complete_all(&dev->power.completion);
+}
+
+static void async_complete(void *data, async_cookie_t cookie)
+{
+   struct device *dev = (struct device *)data;
+
+   device_complete(dev, pm_transition, true);
+   put_device(dev);
 }
 
 /**
@@ -940,27 +952,45 @@ static void device_complete(struct device *dev, 
pm_message_t state)
 void dpm_complete(pm_message_t state)
 {
struct list_head list;
+   struct device *dev;
 
trace_suspend_resume(TPS("dpm_complete"), state.event, true);
might_sleep();
 
INIT_LIST_HEAD(&list);
mutex_lock(&dpm_list_mtx);
+   pm_transition = state;
+
+   /*
+ * Advanced the async threads upfront,
+ * in case the starting of async threads is
+ * delayed by non-async resuming devices.
+ */
+   list_for_each_entry(dev, &dpm_prepared_list, power.entry) {
+   reinit_completion(dev->power.completion);
+   if (is_async(dev)) {
+   get_device(dev);
+   async_schedule(async_complete, dev);
+   }
+   }
+
while (!list_empty(&dpm_prepared_list)) {
-   struct device *dev = to_device(dpm_prepared_list.prev);
+   dev = to_device(dpm_prepared_list.prev);
 
get_device(dev);
dev->power.is_prepared = false;
list_move(&dev->power.entry, &list);
mutex_unlock(&dpm_list_mtx);
 
-   device_complete(dev, state);
+   if (!is_async(dev))
+   device_complete(dev, state);
 
mutex_lock(&dpm_list_mtx);
put_device(dev);
}
list_splice(&list, &dpm_list);
mutex_unlock(&dpm_list_mtx);
+   async_synchronize_full();
trace_suspend_resume(TPS("dpm_complete"), state.event, false);
 }
 
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] PM / sleep: Asynchronous threads for dpm_prepare

[xiaoming wang]

In analogy with commits 5af84b82701a and 97df8c12995,
using asynchronous threads can improve the overall
suspend time significantly.

This patch is for dpm_prepare phase.

Signed-off-by: Chuansheng Liu 
Signed-off-by: xiaoming wang 
---
 drivers/base/power/main.c |   57 +
 1 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index b67d9ae..f9fe1b3 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -1531,15 +1531,24 @@ int dpm_suspend(pm_message_t state)
  * Execute the ->prepare() callback(s) for given device.  No new children of 
the
  * device may be registered after this function has returned.
  */
-static int device_prepare(struct device *dev, pm_message_t state)
+static int __device_prepare(struct device *dev, pm_message_t state, bool async)
 {
int (*callback)(struct device *) = NULL;
char *info = NULL;
int ret = 0;
 
+   if (async_error)
+   goto Complete;
+
+   if (pm_wakeup_pending()) {
+   async_error = -EBUSY;
+   goto Complete;
+   }
+
if (dev->power.syscore)
-   return 0;
+   goto Complete;
 
+   dpm_wait_for_children(dev, async);
/*
 * If a device's parent goes into runtime suspend at the wrong time,
 * it won't be possible to resume the device.  To prevent this we
@@ -1582,7 +1591,7 @@ static int device_prepare(struct device *dev, 
pm_message_t state)
if (ret < 0) {
suspend_report_result(callback, ret);
pm_runtime_put(dev);
-   return ret;
+   goto Complete;
}
/*
 * A positive return value from ->prepare() means "this device appears
@@ -1594,9 +1603,40 @@ static int device_prepare(struct device *dev, 
pm_message_t state)
spin_lock_irq(&dev->power.lock);
dev->power.direct_complete = ret > 0 && state.event == PM_EVENT_SUSPEND;
spin_unlock_irq(&dev->power.lock);
-   return 0;
+
+Complete:
+   complete_all(&dev->power.completion);
+   if (ret)
+   async_error = ret;
+
+   return ret;
+}
+
+static void async_prepare(void *data, async_cookie_t cookie)
+{
+   struct device *dev = (struct device *)data;
+   int error;
+
+   error = __device_prepare(dev, pm_transition, true);
+   if (error) {
+   dpm_save_failed_dev(dev_name(dev));
+   pm_dev_err(dev, pm_transition, " async", error);
+   }
+   put_device(dev);
+}
+
+static int device_prepare(struct device *dev)
+{
+   reinit_completion(dev->power.completion);
+   if (pm_async_enabled && dev->power.async_suspend) {
+   get_device(dev);
+   async_schedule(async_prepare, dev);
+   return 0;
+   }
+   return __device_prepare(dev, pm_transition, false);
 }
 
+
 /**
  * dpm_prepare - Prepare all non-sysdev devices for a system PM transition.
  * @state: PM transition of the system being carried out.
@@ -1611,13 +1651,15 @@ int dpm_prepare(pm_message_t state)
might_sleep();
 
mutex_lock(&dpm_list_mtx);
+   pm_transition = state;
+   async_error = 0;
while (!list_empty(&dpm_list)) {
struct device *dev = to_device(dpm_list.next);
 
get_device(dev);
mutex_unlock(&dpm_list_mtx);
 
-   error = device_prepare(dev, state);
+   error = device_prepare(dev);
 
mutex_lock(&dpm_list_mtx);
if (error) {
@@ -1636,8 +1678,13 @@ int dpm_prepare(pm_message_t state)
if (!list_empty(&dev->power.entry))
list_move_tail(&dev->power.entry, &dpm_prepared_list);
put_device(dev);
+   if (async_error)
+   break;
}
mutex_unlock(&dpm_list_mtx);
+   async_synchronize_full();
+   if (!error)
+   error = async_error;
trace_suspend_resume(TPS("dpm_prepare"), state.event, false);
return error;
 }
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 13/15] cpufreq: Add cpufreq driver for Tegra124

[Viresh Kumar]

On 19 August 2014 09:03, Tuomas Tynkkynen  wrote:
> From: Tuomas Tynkkynen 
>
> Add a new cpufreq driver for Tegra124. Instead of using the PLLX as
> the CPU clocksource, switch immediately to the DFLL. It allows the use
> of higher clock rates, and will automatically scale the CPU voltage as
> well. Besides the CPU clocksource switch, we let the cpufreq-cpu0 driver
> for all the cpufreq operations.
>
> This driver also relies on the DFLL driver to fill the OPP table for the
> CPU0 device, so that the cpufreq-cpu0 driver knows what frequencies to
> use.
>
> Signed-off-by: Tuomas Tynkkynen 
> ---
> v3:
>  - separate Kconfig entry

Gud..

>  - use 'select GENERIC_CPUFREQ_CPU0', not depends

Bad :(

It *has* to be a depends here, its not optional. That was outcome of the
chat we had last time, if I remember it well..

>  - support unbinding of the platform device
>  - allocate a state structure instead of globals
>  - use of_match_machine()
>  - various style nits fixed
> ---

You don't need to add these --- here, just add a blank line and git
will take care of things for you :)

>  drivers/cpufreq/Kconfig.arm|   8 ++
>  drivers/cpufreq/Makefile   |   1 +
>  drivers/cpufreq/tegra124-cpufreq.c | 206 
> +
>  3 files changed, 215 insertions(+)
>  create mode 100644 drivers/cpufreq/tegra124-cpufreq.c
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 3795a16..07bfed1 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -247,3 +247,11 @@ config ARM_TEGRA20_CPUFREQ
> default y
> help
>   This adds the CPUFreq driver support for Tegra20 SOCs.
> +
> +config ARM_TEGRA124_CPUFREQ
> +   bool "Tegra124 CPUFreq support"
> +   depends on ARCH_TEGRA
> +   select GENERIC_CPUFREQ_CPU0

So it will become: depends on ARCH_TEGRA && GENERIC_CPUFREQ_CPU0

> +static int tegra124_cpufreq_probe(struct platform_device *pdev)
> +{

> +   priv->vdd_cpu_reg = regulator_get(get_cpu_device(0), "vdd-cpu");

get_cpu_device() can fail as well, and so you may want to check its return
value as well..

> +static int __init tegra_cpufreq_init(void)
> +{
> +   int ret;
> +   struct platform_device *pdev;
> +
> +   if (!of_match_machine(soc_of_matches))
> +   return -ENODEV;

You may want to add a comment here on why you chose to add another layer
of platform device/driver.. i.e. to catch -EPROBE_DEFER from clk-APIs..

> +   ret = platform_driver_register(&tegra124_cpufreq_platdrv);
> +   if (ret)
> +   return ret;
> +
> +   pdev = platform_device_register_simple("cpufreq-tegra124", -1, NULL, 
> 0);
> +   if (IS_ERR(pdev)) {
> +   platform_driver_unregister(&tegra124_cpufreq_platdrv);
> +   return PTR_ERR(pdev);
> +   }
> +
> +   return 0;
> +}
> +module_init(tegra_cpufreq_init);
> +
> +MODULE_AUTHOR("Tuomas Tynkkynen ");
> +MODULE_DESCRIPTION("cpufreq driver for NVIDIA Tegra124");
> +MODULE_LICENSE("GPL v2");
> --
> 1.8.1.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number

[Xiao Guangrong]

On 08/19/2014 01:40 PM, David Matlack wrote:
> On Mon, Aug 18, 2014 at 10:19 PM, Xiao Guangrong
>  wrote:
>> On 08/19/2014 01:00 PM, David Matlack wrote:
>>> On Mon, Aug 18, 2014 at 9:41 PM, Xiao Guangrong
>>>  wrote:
 On 08/19/2014 12:31 PM, David Matlack wrote:
> The single line patch I suggested was only intended to fix the "forever
> incorrectly exit mmio".

 My patch also fixes this case and that does not doubly increase the
 number. I think this is the better one.
>>>
>>> I prefer doubly increasing the generation for this reason: the updated 
>>> boolean
>>> requires extra code on the "client-side" to check if there's an update in
>>> progress. And that makes it easy to get wrong. In fact, your patch
>>> forgot to check the updated bit in mark_mmio_spte(). Doubly increasing the
>>> generation requires no "client-side" code to work.
>>
>> No, the updated patch is used to fix case 2 which i draw the scenario in
>> the last mail. I mean the original patch in this patchset which just
>> increase the number after srcu-sync.
>>
>> Then could you tell me that your approach can do but my original patch can 
>> not?
> 
> It avoids publishing new memslots with an old generation number attached to
> them (even if it only lasts for a short period of time). 

I can not see the problem if that happen, could you please draw the scenario?

> Do you have a reason
> why you don't want to doubly increase the generation?

That more easily causes the number wrap-around.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] perf callchain: Prune misleading callchains for self entries

[Namhyung Kim]

Hi Jiri,

On Mon, 18 Aug 2014 13:31:47 +0200, Jiri Olsa wrote:
> On Sat, Aug 16, 2014 at 11:26:31AM +0900, Namhyung Kim wrote:
>
> SNIP
>
>> > 
>> > hum, where is it callee/caller mixed?  with following example:
>> > 
>> > ---
>> > void c(void)
>> > {
>> > }
>> > 
>> > void b(void)
>> > {
>> > c();
>> > }
>> > 
>> > void a(void)
>> > {
>> > b();
>> > }
>> > 
>> > int main(void)
>> > {
>> > while(1) {
>> > a();
>> > b();
>> > c();
>> > }
>> > }
>> > ---
>> > 
>> > for 'c' the current code will display:
>> > 
>> > -   43.74%43.74%  tt [.] c 
>> >▒
>> >- __libc_start_main 
>> >▒
>> >   - 86.33% main
>> >▒
>> >67.08% c
>> >▒
>> >  - 32.91% a
>> >▒
>> >   99.44% c 
>> >▒
>> > - 0.56% b  
>> >▒
>> >  c 
>> >▒
>> > 13.67% c   
>> >▒
>> > 
>> > and with this patch:
>> > 
>> > -   43.74%43.74%  tt [.] c 
>> >▒
>> >  c 
>> >▒
>> > 
>> > 
>> > The 'c' callchain is still in caller order. IMO we should
>> > keep whole callchain here.
>> 
>> The problem is not in pure self entry (that has self overhead = children
>> overhead) and pure cumulative entry (self overhead = 0).  It's in mixed
>> entries, please see last two examples in the description 0/3.
>
> right, but it still affects pure entries as well
> anyway, let's see the mixed entry
>
> for 'a' the current code will display:
> -   31.97%17.16%  tt  [.] a   
>  ▒
>- __libc_start_main
>  ◆
> 81.08% a  
>  ▒
>   - 18.92% main   
>  ▒
>a  
>  ▒
>- a
>  ▒
> 85.05% c  
>  ▒
>   - 14.91% b  
>  ▒
>100.00% c  
>  ▒
>
> and with this patch:
> -   31.97%17.16%  tt  [.] a   
>  ▒
>- a
>  ▒
> 85.05% c  
>  ▒
>   - 14.91% b  
>  ▒
>100.00% c  
>  ▒
>
> so we'll miss the 'self' callchain of 'a' symbol
>
> if we want to avoid the confusion about 2 different callchains, how
> about marking them with 'self' and 'children' tags, instead of removing
> one of them, like:
>
> for 'a' the current code will display:
> -   31.97%17.16%  tt  [.] a   
>  ▒
>- [self]
>  __libc_start_main
>  ◆
> 81.08% a

Re: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

[Li, ZhenHua]

I found there are more data need to be cleared for the dump kernel.
So please ignore this patch, I will send out another one.

Thanks
Zhenhua

On 08/19/2014 07:59 AM, Li, Zhen-Hua wrote:

My debugging result is this:

1. Clear the old root entry table, dump kernel will choose another
  memory region for root entry.
2. Do NOT clear the old root entry, when dump kernel initializing
the iommu data structure, it  will allocate memory for root entry,
this is different from the old address.

If not clear old entry , the error message appears before dump kernel
finishes the iommu init works, and also appears in other places(before
device inits).

If I clear the old root entry, the error message disappears before iommu
init work finish, but still appears in other places.

-Original Message-
From: Li, Zhen-Hua
Sent: Tuesday, August 19, 2014 7:48 AM
To: Li, Zhen-Hua; Joerg Roedel
Cc: David Woodhouse; io...@lists.linux-foundation.org; 
linux-kernel@vger.kernel.org
Subject: RE: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

When the dump kernel boots, it will initialize iommu again, and the root entry 
will be allocted
in another memory region.

That means, no matter kernel clears the old root entry table or not,  the dump 
kernel will use
another memory region when iommu initializing.

-Original Message-
From: Li, Zhen-Hua
Sent: Tuesday, August 19, 2014 7:27 AM
To: 'Joerg Roedel'
Cc: David Woodhouse; io...@lists.linux-foundation.org; 
linux-kernel@vger.kernel.org
Subject: RE: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

: [fault reason 01] Present bit in root entry is clear
It appears when iommu initializing in the kdump kernel.

-Original Message-
From: Joerg Roedel [mailto:j...@8bytes.org]
Sent: Tuesday, August 19, 2014 7:23 AM
To: Li, Zhen-Hua
Cc: David Woodhouse; io...@lists.linux-foundation.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] iommu/vt-d : clear old root entry for dump kernel

On Mon, Aug 18, 2014 at 11:01:56PM +, Li, Zhen-Hua wrote:

There is a bug when Linux running on an HP large system:
when kdump kernel runs, the hardware is still using the old
root entry. This causes error message when iommu not finished initialization.

What error message are you seeing? When the kdump kernel boots the iommu
should be still enabled from the old kernel with the old root-entry. So
any in-flight DMA initiated from the old kernel can still pass and there
should be no error messages.

When you clear the root-entry that in-flight DMA might go to another
random location in system memory or just fail, no?


Joerg



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] builddeb: put the dbg files into the correct directory

[Darrick J. Wong]

Since the conversion of objtree to use relative pathnames (commit
7e1c04779e, "kbuild: Use relative path for $(objtree)"), the debug
info files have been ending up in /debian/dbgtmp/ in the regular
linux-image package instead of the debug files package.  Fix up the
paths so that the debug files end up in the -dbg package.

Signed-off-by: Darrick J. Wong 
---
 scripts/package/builddeb |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 5707466..0456322 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -153,15 +153,16 @@ if grep -q '^CONFIG_MODULES=y' $KCONFIG_CONFIG ; then
fi
if [ -n "$BUILD_DEBUG" ] ; then
(
+   old_dir="$(pwd)"
cd $tmpdir
for module in $(find lib/modules/ -name *.ko); do
-   mkdir -p $(dirname 
$dbg_dir/usr/lib/debug/$module)
+   mkdir -p $(dirname 
$old_dir/$dbg_dir/usr/lib/debug/$module)
# only keep debug symbols in the debug file
-   $OBJCOPY --only-keep-debug $module 
$dbg_dir/usr/lib/debug/$module
+   $OBJCOPY --only-keep-debug $module 
$old_dir/$dbg_dir/usr/lib/debug/$module
# strip original module from debug symbols
$OBJCOPY --strip-debug $module
# then add a link to those
-   $OBJCOPY 
--add-gnu-debuglink=$dbg_dir/usr/lib/debug/$module $module
+   $OBJCOPY 
--add-gnu-debuglink=$old_dir/$dbg_dir/usr/lib/debug/$module $module
done
)
fi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] zram: add num_discards for discarded pages stat

[Chao Yu]

> -Original Message-
> From: owner-linux...@kvack.org [mailto:owner-linux...@kvack.org] On Behalf Of 
> Sergey
> Senozhatsky
> Sent: Friday, August 15, 2014 2:12 PM
> To: Chao Yu
> Cc: minc...@kernel.org; linux-kernel@vger.kernel.org; linux...@kvack.org; 
> ngu...@vflare.org;
> 'Jerome Marchand'; 'Sergey Senozhatsky'; 'Andrew Morton'
> Subject: Re: [PATCH] zram: add num_discards for discarded pages stat
> 
> On (08/15/14 11:27), Chao Yu wrote:
> > Now we have supported handling discard request which is sended by 
> > filesystem,
> > but no interface could be used to show information of discard.
> > This patch adds num_discards to stat discarded pages, then export it to 
> > sysfs
> > for displaying.
> >
> 
> a side question: we account discarded pages via slot free notify in
> notify_free and via req_discard in num_discards. how about accounting
> both of them in num_discards? because, after all, they account a number
> of discarded pages (zram_free_page()). or there any particular reason we
> want to distinguish.

Yeah, I agree with you as I have no such reason unless there are our users'
explicitly requirement for showing notify_free/num_discards separately later.

How do you think of sending another patch to merge these two counts?

One more thing is that I am missing to update document of zram, sorry about
that, let me update it in v2.

Thanks,
Yu

> 
>   -ss
> 
> > Signed-off-by: Chao Yu 
> > ---
> >  Documentation/ABI/testing/sysfs-block-zram | 10 ++
> >  drivers/block/zram/zram_drv.c  |  3 +++
> >  drivers/block/zram/zram_drv.h  |  1 +
> >  3 files changed, 14 insertions(+)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-block-zram
> b/Documentation/ABI/testing/sysfs-block-zram
> > index 70ec992..fa8936e 100644
> > --- a/Documentation/ABI/testing/sysfs-block-zram
> > +++ b/Documentation/ABI/testing/sysfs-block-zram
> > @@ -57,6 +57,16 @@ Description:
> > The failed_writes file is read-only and specifies the number of
> > failed writes happened on this device.
> >
> > +
> > +What:  /sys/block/zram/num_discards
> > +Date:  August 2014
> > +Contact:   Chao Yu 
> > +Description:
> > +   The num_discards file is read-only and specifies the number of
> > +   physical blocks which are discarded by this device. These blocks
> > +   are included in discard request which is sended by filesystem as
> > +   the blocks are no longer used.
> > +
> >  What:  /sys/block/zram/max_comp_streams
> >  Date:  February 2014
> >  Contact:   Sergey Senozhatsky 
> > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > index d00831c..904e7a5 100644
> > --- a/drivers/block/zram/zram_drv.c
> > +++ b/drivers/block/zram/zram_drv.c
> > @@ -606,6 +606,7 @@ static void zram_bio_discard(struct zram *zram, u32 
> > index,
> > bit_spin_lock(ZRAM_ACCESS, &meta->table[index].value);
> > zram_free_page(zram, index);
> > bit_spin_unlock(ZRAM_ACCESS, &meta->table[index].value);
> > +   atomic64_inc(&zram->stats.num_discards);
> > index++;
> > n -= PAGE_SIZE;
> > }
> > @@ -866,6 +867,7 @@ ZRAM_ATTR_RO(num_reads);
> >  ZRAM_ATTR_RO(num_writes);
> >  ZRAM_ATTR_RO(failed_reads);
> >  ZRAM_ATTR_RO(failed_writes);
> > +ZRAM_ATTR_RO(num_discards);
> >  ZRAM_ATTR_RO(invalid_io);
> >  ZRAM_ATTR_RO(notify_free);
> >  ZRAM_ATTR_RO(zero_pages);
> > @@ -879,6 +881,7 @@ static struct attribute *zram_disk_attrs[] = {
> > &dev_attr_num_writes.attr,
> > &dev_attr_failed_reads.attr,
> > &dev_attr_failed_writes.attr,
> > +   &dev_attr_num_discards.attr,
> > &dev_attr_invalid_io.attr,
> > &dev_attr_notify_free.attr,
> > &dev_attr_zero_pages.attr,
> > diff --git a/drivers/block/zram/zram_drv.h b/drivers/block/zram/zram_drv.h
> > index e0f725c..2994aaf 100644
> > --- a/drivers/block/zram/zram_drv.h
> > +++ b/drivers/block/zram/zram_drv.h
> > @@ -86,6 +86,7 @@ struct zram_stats {
> > atomic64_t num_writes;  /* --do-- */
> > atomic64_t failed_reads;/* can happen when memory is too low */
> > atomic64_t failed_writes;   /* can happen when memory is too low */
> > +   atomic64_t num_discards;/* no. of discarded pages */
> > atomic64_t invalid_io;  /* non-page-aligned I/O requests */
> > atomic64_t notify_free; /* no. of swap slot free notifications */
> > atomic64_t zero_pages;  /* no. of zero filled pages */
> > --
> > 2.0.1.474.g72c7794
> >
> >
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 

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

Re: [RFC PATCH 2/9] ACPI: Document ACPI device specific properties

[Darren Hart]

On Mon, Aug 18, 2014 at 11:54:29AM +0100, Mark Rutland wrote:
> Hi Mika,
> 
> While I am very much in favour of having a structured way of describing
> device specific data in ACPI I am very concerned by the idea of assuming
> (a false) equivalence with DT. More on that below.

Hi Mark,

The equivalence is intended in the sense that we should be able to represent any
of the existing schemas with the same properties in ACPI as in DT.

...

> > +An example device where we might need properties is a GPIO keys device.
> > +In addition to the GpioIo/GpioInt resources the driver needs to know how
> > +to map each GpioIo resource to the corresponding Linux input event.
> > +
> > +To solve this we add the following ACPI device properties from the
> > +gpio-keys schema:
> > +
> > +   Device (KEYS) {
> > +   Name (_DSD, Package () {
> > +   ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > +   Package () {
> > +   Package () {"poll-interval", 100},
> > +   Package () {"autorepeat", 1}
> > +   }
> > +   })
> > +
> > +   Device (BTN0) {
> > +   Name (_DSD, Package () {
> > +   
> > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > +   Package () {
> > +   Package () {"linux,code", 105},
> > +   Package () {"linux,input-type", 1},
> 
> The leakage of Linux implementation details into DTBs is bad enough. I
> would really not like to see this kind of thing in ACPI tables.
> 
> Leaking this into HW description of any sort completely rids said
> description of any OS independence, and it's usually short-sighted,
> nonsensical, or ill-defined (what does 'autorepeat' actually mean?).
> 
> I am very worried by the prospect of _DSD making it harder rather than
> easier for an arbitrary OS to use ACPI data due to assumptions being
> made about (a particular revision of) a particular OS.

This is perhaps not the best example to include in the documentation. A guiding
principle has been to only represent in the DSD that which is an actual property
of the hardware.

It is also a goal of the mechanism to enable ACPI systems to reuse the 200+
existing OF-aware drivers in the kernel today. If those schemas are
ill-conceived, we should work to improve the schemas.

On the point of OS-independence, while I agree that using something like the USB
keycodes here would be better, the namespacing employed in these properties
makes it possible to use the same DSD for muliple OSes as another OS could add
it's own keycode, for example, without conflict. Again, that is really an issue
with the schemas, not the _DSD mechanism itself.

Perhaps we should use a different example in the documentation as I would agree
this is not a model schema.

> > +Of course the device driver then needs to iterate over these devices but
> > +it can be done easily via the ->children field of the companion ACPI
> > +device. This will be demonstrated later on in the document.
> > +
> > +If there is an existing Device Tree binding for a device, it is expected
> > +that the same bindings are used with ACPI properties, so that the driver
> > +dealing with the device needs only minor modifications if any.
> 
> For simple devices like a UART which just has a "clock-frequency"
> property in DT, importing both the concept of the property and the key
> name itself is a sensible approach.
> 
> However, I do not think this makes sense as a general design rule. ACPI
> and DT already have different idioms for describing certain things (e.g.
> GPIOs, interrupts) and care needs to be taken to distinguish simple
> device-specific properties from class-specific properties or implied
> linkages between devices.

I believe we have GPIO handled well in this series. In DT terms, ACPI is the
controller, providing a list of GpioIO|GpioInt resources in the CRS of the
referenced object. Arguments are Resource Index, Pin Index, Polarity. The rest
of the properties are handled via the GpioIO|GpioInt resources in the _CRS.

> 
> The "#clock-cells" and "#pwm-cells" _DSD examples in ACPI 5.1 are
> complete nonsense. They import an idiom from DT into ACPI without

Yeah... coming up with good examples for a generic mechanism which are both
descriptive and universally unobjectionable. Good point. We might be able to
improve this via an errata update. What would you recommend?

> considering the surrounding context (cells, lack of typing, phandles,

How are the phandles not covered via the ACPI namespace references?

The point on cells is a good one, and I believe some of this can be mitigated by
providing subsystem specific accessors as we have for GPIO, for example.

> etc). As an example, I worry that why it may be trivial to map pinctrl
> bindings into ACPI _DSD, there is no clear way that the

RE: [PATCH] regmap: fix of_regmap_get_endian()

[li.xi...@freescale.com]

Hi,

I found this patch has some confliction with the Mark's newest Remgap-Tree's
origin/topic/dt-endian branch.

Javier Martinez has already fix some of these.

Thanks,

BRs
Xiubo



> -Original Message-
> From: Thierry Reding [mailto:thierry.red...@gmail.com]
> Sent: Tuesday, August 19, 2014 1:22 PM
> To: Stephen Warren
> Cc: Mark Brown; Thierry Reding; linux-kernel@vger.kernel.org; linux-
> n...@vger.kernel.org; Stephen Warren; Xiubo Li-B47053
> Subject: Re: [PATCH] regmap: fix of_regmap_get_endian()
> 
> On Mon, Aug 18, 2014 at 04:14:04PM -0600, Stephen Warren wrote:
> > From: Stephen Warren 
> >
> > Commit d647c199510c ("regmap: add DT endianness binding support") has
> > some issues. Specifically, if config->reg_format_endian is not explicitly
> > set, it will be zero, i.e. REGMAP_ENDIAN_DEFAULT. The switch statement
> > that looks up the *endian from DT for the type==REGMAP_ENDIAN_VAL case
> > doesn't change *endian in the type==REGMAP_ENDIAN_REG case. However, the
> > test immediately following, compares *endian against REGMAP_ENDIAN_NATIVE,
> > and if not equal, returns *endian as is. This ends up returning
> > REGMAP_ENDIAN_DEFAULT, which the calling code does not expect, eventually
> > leading to e.g.:
> >
> > Unable to handle kernel NULL pointer dereference at virtual address 0024
> > ...
> > [] (regcache_cache_only) from []
> (tegra30_ahub_probe+0x1b8/0x430)
> > [] (tegra30_ahub_probe) from []
> (platform_drv_probe+0x2c/0x5c)
> > [] (platform_drv_probe) from []
> (driver_probe_device+0x10c/0x22c)
> > [] (driver_probe_device) from []
> (__driver_attach+0x8c/0x90)
> >
> > This patch solves this by:
> > * When looking up the endianness from DT, don't change *endian at all if
> >   there is no DT property; leave it set to REGMAP_ENDIAN_DEFAULT so the
> >   code falls through to other data sources in the same way as before.
> >   Now, the "unspecified" case acts the same for both REGMAP_ENDIAN_REG and
> >   REGMAP_ENDIAN_VAL.
> > * After potentially looking up the endianness from DT, check *endian
> >   against REGMAP_ENDIAN_DEFAULT instead of REGMAP_ENDIAN_NATIVE to avoid
> >   returning unexpected values.
> >
> > Also, clean up the code a bit:
> >
> > * Make the comments briefer, and only refer to the specific action taken
> >   at their location. This makes most of the comments independent of DT,
> >   and easier to follow.
> > * Restore the overall default of REGMAP_ENDIAN_BIG if none of the config,
> >   DT, or the bus specify any endianness. Since all busses specify an
> >   endianness now, this makes no difference, but I saw no justification in
> >   the patch description for changing the default default.
> > * s/of_regmap_get_endian/regmap_get_endian/ since the function isn't DT-
> >   specific, even if the reason it was originally added was to add some
> >   DT-specific features.
> >
> > Reported-by: Thierry Reding 
> > Fixes: d647c199510c ("regmap: add DT endianness binding support")
> > Cc: Xiubo Li 
> > Signed-off-by: Stephen Warren 
> > ---
> >  drivers/base/regmap/regmap.c | 58 ++---
> ---
> >  1 file changed, 18 insertions(+), 40 deletions(-)
> 
> Thanks for fixing this, Stephen.
> 
> Tested-by: Thierry Reding 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number

[David Matlack]

On Mon, Aug 18, 2014 at 10:19 PM, Xiao Guangrong
 wrote:
> On 08/19/2014 01:00 PM, David Matlack wrote:
>> On Mon, Aug 18, 2014 at 9:41 PM, Xiao Guangrong
>>  wrote:
>>> On 08/19/2014 12:31 PM, David Matlack wrote:
 The single line patch I suggested was only intended to fix the "forever
 incorrectly exit mmio".
>>>
>>> My patch also fixes this case and that does not doubly increase the
>>> number. I think this is the better one.
>>
>> I prefer doubly increasing the generation for this reason: the updated 
>> boolean
>> requires extra code on the "client-side" to check if there's an update in
>> progress. And that makes it easy to get wrong. In fact, your patch
>> forgot to check the updated bit in mark_mmio_spte(). Doubly increasing the
>> generation requires no "client-side" code to work.
>
> No, the updated patch is used to fix case 2 which i draw the scenario in
> the last mail. I mean the original patch in this patchset which just
> increase the number after srcu-sync.
>
> Then could you tell me that your approach can do but my original patch can 
> not?

It avoids publishing new memslots with an old generation number attached to
them (even if it only lasts for a short period of time). Do you have a reason
why you don't want to doubly increase the generation?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] tty: serial: serial_core.c: printk replacement

[Sudip Mukherjee]

>
> Hi, that will not work either, as there is put_device(tty_dev) before
> you use tty_dev.
>
> --
> js
> suse labs
>
Hi,
i missed that. I put my test message to test tty_dev immediately after
tty_dev was initialized and so never got the error when the port was
suspended.
Will change it to pr_err and resend the patch for you to review.

Thanks
Sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Question]: redundant interrupts for broadcast timer

[Leo Yan]

hi,

We observed the redundant interrupts for broadcast timer, so want to 
confirm here firstly; pls see below flow:


1. Thread_A starts a hrtimer with 100ms timeout, and then thread_A will 
remove from the runqueue to sleep;
2. The CPU which thread_A runs on will enter idle and call notify 
CLOCK_EVT_NOTIFY_BROADCAST_ENTER, so the CPU will shutdown its local 
timer and set broadcast timer's next event with delta for 100ms;
3. After 70ms later, the CPU is waken up by other peripheral's interrupt 
and thread_A will be waken up as well; thread_A will cancel the hrtimer 
at this point, kernel will remove the timer event from the event queue 
but it will not disable broadcast timer;
4. So after 30ms later, the broadcast timer interrupt will be triggered 
even though the timer has been cancelled by s/w in step 3.


With current timer framework, is upper behaviour expected? Or maybe we 
miss something so that introduce such kind issue?


And i'm interesting now if have some idea to optimize such issue, very 
appreciate for suggestion and comment.


Thanks,
Leo Yan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PANIC: ata_qc_new_init crashes at boot

[Dan Williams]

On Mon, Aug 18, 2014 at 2:21 PM, Tejun Heo  wrote:
> Hello,
>
> Sorry about the delay.  Cc'ing Dan.
>
> On Wed, Aug 06, 2014 at 02:02:47PM -0400, Nick Krause wrote:
>> On Wed, Jul 23, 2014 at 4:39 AM, Peter Zijlstra  wrote:
>> > On Tue, Jul 22, 2014 at 03:48:02PM -0400, Peter Hurley wrote:
>> >> [ +cc Tejun ]
>> >>
>> >> On 07/22/2014 03:26 PM, Jesse Brandeburg wrote:
>> >> > This is a repeatable panic, happens every boot (and prevents starting 
>> >> > my system)
>> >> >
>> >> > [8.732993] sd 6:0:1:0: [sdb] Attached SCSI disk
>> >> > [8.733857]  sda: sda1 sda2 sda3
>> >> > [8.734318] sd 6:0:0:0: [sda] Attached SCSI disk
>> >> > [8.737943] BUG: unable to handle kernel NULL pointer dereference at 
>> >> > 0058
>> >> > [8.737947] IP: [] ata_qc_new_init+0x188/0x1b0
>> >
>> > I too have this problem on one of my machines. Let me know if there's
>> > anything you need.
>
> Are you still seeing this on every boot?  ISTR this getting fixed but
> I could be confused.  Dan, the original thread is
>
>   
> http://lkml.kernel.org/g/CAEuXFEy5=0xkqpiwqnigbpi5ehszq5f_u7sj0t2bho_1lqe...@mail.gmail.com
>

This is the last I heard:

http://marc.info/?l=linux-ide&m=140630768020241&w=2

But I never saw a follow up.

Hmmm, commit 1a112d10f03e libata: introduce ata_host->n_tags to avoid
oops on SAS controllers

...doesn't fix this?  Jesse reported positive results here:

http://marc.info/?l=linux-ide&m=140624094731542&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] doc: dt/bindings: input: introduce palmas power button description

[Dmitry Torokhov]

On Mon, Aug 18, 2014 at 03:13:29PM -0500, Nishanth Menon wrote:
> Many palmas family of PMICs have support for interrupt based power
> button. This allows the device to notify the processor of external
> push button events over the shared palmas interrupt.
> 
> Document the hardware support for the same.
> 
> Signed-off-by: Nishanth Menon 
> ---
>  .../bindings/input/ti,palmas-pwrbutton.txt |   32 
> 
>  1 file changed, 32 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
> 
> diff --git a/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt 
> b/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
> new file mode 100644
> index 000..6a89bcd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/ti,palmas-pwrbutton.txt
> @@ -0,0 +1,32 @@
> +Texas Instruments Palmas family power button module
> +
> +This module is part of the Palmas family of PMICs. For more details
> +about the whole chip see:
> +Documentation/devicetree/bindings/mfd/palmas.txt.
> +
> +This module provides a simple power button event via an Interrupt.
> +
> +Required properties:
> +- compatible: should be one of the following
> +   - "ti,palmas-pwrbutton": For Palmas compatible power on button
> +- interrupt-parent: Parent interrupt device, must be handle of palmas node.
> +- interrupts: Interrupt number of power button submodule on device.
> +
> +Optional Properties:
> +
> +- ti,palmas-long-press-seconds: Duration in seconds which the power
> +  button should be kept pressed for Palmas to power off automatically.
> +  NOTE: This depends on OTP support and POWERHOLD signal configuration
> +  on platform.

Only a few values are valid for this property, I think you should mention that.

> +
> +Example:
> +
> +&palmas {
> + palmas_pwr_button: pwrbutton {
> + compatible = "ti,palmas-pwrbutton";
> + interrupt-parent = <&tps659038>;
> + interrupts = <1 IRQ_TYPE_NONE>;

Why none? Can we specify appropriate trigger here instead of hard-coding in the
driver?

> + wakeup-source;

What handles this attribute? I do not see it handled in the driver.

> + ti,palmas-long-press-seconds = <12>;
> + };
> +};
> -- 
> 1.7.9.5
> 

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Input: misc: introduce palmas-pwrbutton

[Dmitry Torokhov]

Hi NIshanth,

On Mon, Aug 18, 2014 at 03:13:30PM -0500, Nishanth Menon wrote:
> Many palmas family of PMICs have support for interrupt based power
> button. This allows the device to notify the processor of external
> push button events over the shared palmas interrupt. However, this
> event is generated only during a "press" operation. Software is
> supposed to poll(sigh!) for detecting a release event.
> 
> The PMIC also supports ability to power off independent of the
> software decisions when the button is pressed for a long duration if
> the PMIC is appropriately configured on the platform.
> 
> Even though the function is similar to twl4030_pwrbutton, it is
> substantially different in operation to belong to a new driver of it's
> own.
> 
> Based on original work done by Girish S Ghongdemath 
> 
> Signed-off-by: Nishanth Menon 
> ---
>  drivers/input/misc/Kconfig|   10 ++
>  drivers/input/misc/Makefile   |1 +
>  drivers/input/misc/palmas-pwrbutton.c |  314 
> +
>  3 files changed, 325 insertions(+)
>  create mode 100644 drivers/input/misc/palmas-pwrbutton.c
> 
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 2ff4425..0224dcf 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -451,6 +451,16 @@ config HP_SDC_RTC
> Say Y here if you want to support the built-in real time clock
> of the HP SDC controller.
>  
> +config INPUT_PALMAS_PWRBUTTON
> + tristate "Palmas Power button Driver"
> + depends on MFD_PALMAS
> + help
> +   Say Y here if you want to enable power key reporting via the
> +   Palmas family of PMICs.
> +
> +   To compile this driver as a module, choose M here. The module will
> +   be called palmas_pwrbutton.
> +
>  config INPUT_PCF50633_PMU
>   tristate "PCF50633 PMU events"
>   depends on MFD_PCF50633
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index 4955ad3..e3d5efb 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -40,6 +40,7 @@ obj-$(CONFIG_INPUT_MAX8997_HAPTIC)  += max8997_haptic.o
>  obj-$(CONFIG_INPUT_MC13783_PWRBUTTON)+= mc13783-pwrbutton.o
>  obj-$(CONFIG_INPUT_MMA8450)  += mma8450.o
>  obj-$(CONFIG_INPUT_MPU3050)  += mpu3050.o
> +obj-$(CONFIG_INPUT_PALMAS_PWRBUTTON) += palmas-pwrbutton.o
>  obj-$(CONFIG_INPUT_PCAP) += pcap_keys.o
>  obj-$(CONFIG_INPUT_PCF50633_PMU) += pcf50633-input.o
>  obj-$(CONFIG_INPUT_PCF8574)  += pcf8574_keypad.o
> diff --git a/drivers/input/misc/palmas-pwrbutton.c 
> b/drivers/input/misc/palmas-pwrbutton.c
> new file mode 100644
> index 000..35f3d68
> --- /dev/null
> +++ b/drivers/input/misc/palmas-pwrbutton.c
> @@ -0,0 +1,314 @@
> +/*
> + * Texas Instruments' Palmas Power Button Input Driver
> + *
> + * Copyright (C) 2012-2014 Texas Instruments Incorporated - 
> http://www.ti.com/
> + *   Girish S Ghongdemath
> + *   Nishanth Menon
> + *
> + * 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.
> + *
> + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> + * kind, whether express or implied; without even the implied warranty
> + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PALMAS_LPK_TIME_MASK 0x0c
> +#define PALMAS_PWR_KEY_PRESS 0x01
> +#define PALMAS_PWR_KEY_Q_TIME_MS 20
> +
> +/**
> + * struct palmas_pwron - Palmas power on data
> + * @palmas:  pointer to palmas device
> + * @input_dev:   pointer to input device
> + * @irq: irq that we are hooked on to
> + * @input_work:  work for detecting release of key
> + * @current_state:   key current state
> + * @key_recheck_ms:  duration for recheck of key (in milli-seconds)
> + */
> +struct palmas_pwron {
> + struct palmas *palmas;
> + struct input_dev *input_dev;
> + int irq;
> + struct delayed_work input_work;
> + int current_state;
> + u32 key_recheck_ms;
> +};
> +
> +/**
> + * struct palmas_pwron_config - configuration of palmas power on
> + * @long_press_time_val: value for long press h/w shutdown event
> + */
> +struct palmas_pwron_config {
> + u8 long_press_time_val;
> +};
> +
> +/**
> + * palmas_get_pwr_state() - read button state
> + * @pwron: pointer to pwron struct
> + */
> +static int palmas_get_pwr_state(struct palmas_pwron *pwron)
> +{
> + struct input_dev *input_dev = pwron->input_dev;
> + struct device *dev = input_dev->dev.parent;
> + unsigned int reg = 0;
> + int ret;
> +
> + ret = palmas_read(pwron->palmas, PALMAS_INTERRUPT_BA

Re: [PATCH] regmap: fix of_regmap_get_endian()

[Thierry Reding]

On Mon, Aug 18, 2014 at 04:14:04PM -0600, Stephen Warren wrote:
> From: Stephen Warren 
> 
> Commit d647c199510c ("regmap: add DT endianness binding support") has
> some issues. Specifically, if config->reg_format_endian is not explicitly
> set, it will be zero, i.e. REGMAP_ENDIAN_DEFAULT. The switch statement
> that looks up the *endian from DT for the type==REGMAP_ENDIAN_VAL case
> doesn't change *endian in the type==REGMAP_ENDIAN_REG case. However, the
> test immediately following, compares *endian against REGMAP_ENDIAN_NATIVE,
> and if not equal, returns *endian as is. This ends up returning
> REGMAP_ENDIAN_DEFAULT, which the calling code does not expect, eventually
> leading to e.g.:
> 
> Unable to handle kernel NULL pointer dereference at virtual address 0024
> ...
> [] (regcache_cache_only) from [] 
> (tegra30_ahub_probe+0x1b8/0x430)
> [] (tegra30_ahub_probe) from [] 
> (platform_drv_probe+0x2c/0x5c)
> [] (platform_drv_probe) from [] 
> (driver_probe_device+0x10c/0x22c)
> [] (driver_probe_device) from [] 
> (__driver_attach+0x8c/0x90)
> 
> This patch solves this by:
> * When looking up the endianness from DT, don't change *endian at all if
>   there is no DT property; leave it set to REGMAP_ENDIAN_DEFAULT so the
>   code falls through to other data sources in the same way as before.
>   Now, the "unspecified" case acts the same for both REGMAP_ENDIAN_REG and
>   REGMAP_ENDIAN_VAL.
> * After potentially looking up the endianness from DT, check *endian
>   against REGMAP_ENDIAN_DEFAULT instead of REGMAP_ENDIAN_NATIVE to avoid
>   returning unexpected values.
> 
> Also, clean up the code a bit:
> 
> * Make the comments briefer, and only refer to the specific action taken
>   at their location. This makes most of the comments independent of DT,
>   and easier to follow.
> * Restore the overall default of REGMAP_ENDIAN_BIG if none of the config,
>   DT, or the bus specify any endianness. Since all busses specify an
>   endianness now, this makes no difference, but I saw no justification in
>   the patch description for changing the default default.
> * s/of_regmap_get_endian/regmap_get_endian/ since the function isn't DT-
>   specific, even if the reason it was originally added was to add some
>   DT-specific features.
> 
> Reported-by: Thierry Reding 
> Fixes: d647c199510c ("regmap: add DT endianness binding support")
> Cc: Xiubo Li 
> Signed-off-by: Stephen Warren 
> ---
>  drivers/base/regmap/regmap.c | 58 
> ++--
>  1 file changed, 18 insertions(+), 40 deletions(-)

Thanks for fixing this, Stephen.

Tested-by: Thierry Reding 


pgp2QcQpV9mbJ.pgp
Description: PGP signature

Re: [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number

[Xiao Guangrong]

On 08/19/2014 01:00 PM, David Matlack wrote:
> On Mon, Aug 18, 2014 at 9:41 PM, Xiao Guangrong
>  wrote:
>> On 08/19/2014 12:31 PM, David Matlack wrote:
>>> But it looks like you basically said the same thing earlier, so I think
>>> we're on the same page.
>>>
>>
>> Yes, that is what i try to explain in previous mails. :(
> 
> I'm glad we understand each other now! Sorry again for my confusion.

Yup, me too. :)

> 
>>> The single line patch I suggested was only intended to fix the "forever
>>> incorrectly exit mmio".
>>
>> My patch also fixes this case and that does not doubly increase the
>> number. I think this is the better one.
> 
> I prefer doubly increasing the generation for this reason: the updated boolean
> requires extra code on the "client-side" to check if there's an update in
> progress. And that makes it easy to get wrong. In fact, your patch
> forgot to check the updated bit in mark_mmio_spte(). Doubly increasing the
> generation requires no "client-side" code to work.

No, the updated patch is used to fix case 2 which i draw the scenario in
the last mail. I mean the original patch in this patchset which just
increase the number after srcu-sync.

Then could you tell me that your approach can do but my original patch can not?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 1/4] net: allow large number of rx queues

[Pankaj Gupta]

> Hello.
> 
> On 08/18/2014 05:37 PM, Pankaj Gupta wrote:
> 
> > netif_alloc_rx_queues() uses kcalloc() to allocate memory
> > for "struct netdev_queue *_rx" array.
> > If we are doing large rx queue allocation kcalloc() might
> > fail, so this patch does a fallback to vzalloc().
> > Similar implementation is done for tx queue allocation in
> > netif_alloc_netdev_queues().
> 
> > We avoid failure of high order memory allocation
> > with the help of vzalloc(), this allows us to do large
> > rx and tx queue allocation which in turn helps us to
> > increase the number of queues in tun.
> 
> > As vmalloc() adds overhead on a critical network path,
> > __GFP_REPEAT flag is used with kzalloc() to do this fallback
> > only when really needed.
> 
> > Signed-off-by: Pankaj Gupta 
> > Reviewed-by: Michael S. Tsirkin 
> > Reviewed-by: David Gibson 
> > ---
> >   net/core/dev.c | 20 +---
> >   1 file changed, 13 insertions(+), 7 deletions(-)
> 
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 1c15b18..a455a02 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -5942,17 +5942,24 @@ void netif_stacked_transfer_operstate(const struct
> > net_device *rootdev,
> >   EXPORT_SYMBOL(netif_stacked_transfer_operstate);
> >
> >   #ifdef CONFIG_SYSFS
> > +static void netif_free_rx_queues(struct net_device *dev)
> > +{
> > +   kvfree(dev->_rx);
> > +}
> > +
> >   static int netif_alloc_rx_queues(struct net_device *dev)
> >   {
> > unsigned int i, count = dev->num_rx_queues;
> > struct netdev_rx_queue *rx;
> > -
> > +   size_t sz = count * sizeof(*rx);
> 
>Please keep an empty line after declarations.
 Yes, I will add it. Thanks
> 
> > BUG_ON(count < 1);
> >
> 
> WBR, Sergei
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] mmc: dw_mmc: move rockchip related code to a separate file

[Jaehoon Chung]

Acked-by: Jaehoon Chung 

Best Regards,
Jaehoon Chung

On 08/19/2014 01:36 PM, Addy Ke wrote:
> To support HS200 and UHS-1, we need add a big hunk of code,
> as shown in the following patches. So a separate file for
> rockchip SOCs is suitable.
> 
> Signed-off-by: Addy Ke 
> ---
> Changes in v2:
> - Kconfig: depend on ARCH_ROCKCHIP, suggested by Bartlomiej Zolnierkiewicz
> - Kconfig: depend on OF, suggested by Doug Anderson
> - Not change suspend/resume code, suggested by Doug Anderson
> - If pdev->dev.of_node is NULL, then return -ENODEV, suggested by Heiko 
> Stübner
> 
>  drivers/mmc/host/Kconfig   |   9 +++
>  drivers/mmc/host/Makefile  |   1 +
>  drivers/mmc/host/dw_mmc-pltfm.c|  57 
>  drivers/mmc/host/dw_mmc-rockchip.c | 136 
> +
>  4 files changed, 146 insertions(+), 57 deletions(-)
>  create mode 100644 drivers/mmc/host/dw_mmc-rockchip.c
> 
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index a565254..f6095f6 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -621,6 +621,15 @@ config MMC_DW_PCI
>  
> If unsure, say N.
>  
> +config MMC_DW_ROCKCHIP
> + tristate "Rockchip specific extensions for Synopsys DW Memory Card 
> Interface"
> + depends on MMC_DW && ARCH_ROCKCHIP && OF
> + select MMC_DW_PLTFM
> + help
> +   This selects support for Rockchip SoC specific extensions to the
> +   Synopsys DesignWare Memory Card Interface driver. Select this option
> +   for platforms based on RK3066, RK3188 and RK3288 SoC's.
> +
>  config MMC_SH_MMCIF
>   tristate "SuperH Internal MMCIF support"
>   depends on MMC_BLOCK
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index 7f81ddf..5fce465 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -45,6 +45,7 @@ obj-$(CONFIG_MMC_DW_PLTFM)  += dw_mmc-pltfm.o
>  obj-$(CONFIG_MMC_DW_EXYNOS)  += dw_mmc-exynos.o
>  obj-$(CONFIG_MMC_DW_K3)  += dw_mmc-k3.o
>  obj-$(CONFIG_MMC_DW_PCI) += dw_mmc-pci.o
> +obj-$(CONFIG_MMC_DW_ROCKCHIP)+= dw_mmc-rockchip.o
>  obj-$(CONFIG_MMC_SH_MMCIF)   += sh_mmcif.o
>  obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o
>  obj-$(CONFIG_MMC_VUB300) += vub300.o
> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
> index b547f7a..0c56c41 100644
> --- a/drivers/mmc/host/dw_mmc-pltfm.c
> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
> @@ -26,64 +26,11 @@
>  #include "dw_mmc.h"
>  #include "dw_mmc-pltfm.h"
>  
> -#define RK3288_CLKGEN_DIV2
> -
>  static void dw_mci_pltfm_prepare_command(struct dw_mci *host, u32 *cmdr)
>  {
>   *cmdr |= SDMMC_CMD_USE_HOLD_REG;
>  }
>  
> -static int dw_mci_rk3288_setup_clock(struct dw_mci *host)
> -{
> - host->bus_hz /= RK3288_CLKGEN_DIV;
> -
> - return 0;
> -}
> -
> -static void dw_mci_rk3288_set_ios(struct dw_mci *host, struct mmc_ios *ios)
> -{
> - int ret;
> - unsigned int cclkin;
> - u32 bus_hz;
> -
> - /*
> -  * cclkin: source clock of mmc controller.
> -  * bus_hz: card interface clock generated by CLKGEN.
> -  * bus_hz = cclkin / RK3288_CLKGEN_DIV;
> -  * ios->clock = (div == 0) ? bus_hz : (bus_hz / (2 * div))
> -  *
> -  * Note: div can only be 0 or 1
> -  *   if DDR50 8bit mode(only emmc work in 8bit mode),
> -  *   div must be set 1
> -  */
> - if ((ios->bus_width == MMC_BUS_WIDTH_8) &&
> - (ios->timing == MMC_TIMING_MMC_DDR52))
> - cclkin = 2 * ios->clock * RK3288_CLKGEN_DIV;
> - else
> - cclkin = ios->clock * RK3288_CLKGEN_DIV;
> -
> - ret = clk_set_rate(host->ciu_clk, cclkin);
> - if (ret)
> - dev_warn(host->dev, "failed to set rate %uHz\n", ios->clock);
> -
> - bus_hz = clk_get_rate(host->ciu_clk) / RK3288_CLKGEN_DIV;
> - if (bus_hz != host->bus_hz) {
> - host->bus_hz = bus_hz;
> - /* force dw_mci_setup_bus() */
> - host->current_speed = 0;
> - }
> -}
> -
> -static const struct dw_mci_drv_data rk2928_drv_data = {
> - .prepare_command= dw_mci_pltfm_prepare_command,
> -};
> -
> -static const struct dw_mci_drv_data rk3288_drv_data = {
> - .prepare_command= dw_mci_pltfm_prepare_command,
> - .set_ios= dw_mci_rk3288_set_ios,
> - .setup_clock= dw_mci_rk3288_setup_clock,
> -};
> -
>  static const struct dw_mci_drv_data socfpga_drv_data = {
>   .prepare_command= dw_mci_pltfm_prepare_command,
>  };
> @@ -144,10 +91,6 @@ EXPORT_SYMBOL_GPL(dw_mci_pltfm_pmops);
>  
>  static const struct of_device_id dw_mci_pltfm_match[] = {
>   { .compatible = "snps,dw-mshc", },
> - { .compatible = "rockchip,rk2928-dw-mshc",
> - .data = &rk2928_drv_data },
> - { .compatible = "rockchip,rk3288-dw-mshc",
> - .data = &rk3288_drv_data },
>   { .compatible = "altr,socfpga-dw-mshc",
>   .data = &so

Re: [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number

[David Matlack]

On Mon, Aug 18, 2014 at 9:41 PM, Xiao Guangrong
 wrote:
> On 08/19/2014 12:31 PM, David Matlack wrote:
>> But it looks like you basically said the same thing earlier, so I think
>> we're on the same page.
>>
>
> Yes, that is what i try to explain in previous mails. :(

I'm glad we understand each other now! Sorry again for my confusion.

>> The single line patch I suggested was only intended to fix the "forever
>> incorrectly exit mmio".
>
> My patch also fixes this case and that does not doubly increase the
> number. I think this is the better one.

I prefer doubly increasing the generation for this reason: the updated boolean
requires extra code on the "client-side" to check if there's an update in
progress. And that makes it easy to get wrong. In fact, your patch
forgot to check the updated bit in mark_mmio_spte(). Doubly increasing the
generation requires no "client-side" code to work.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[mm] f7b5d647946: -3.0% dbench.throughput-MB/sec

[Fengguang Wu]

Hi Mel,

We noticed a minor dbench throughput regression on commit
f7b5d647946aae1647bf5cd26c16b3a793c1ac49 ("mm: page_alloc: abort fair
zone allocation policy when remotes nodes are encountered").

testcase: ivb44/dbench/100%

bb0b6dffa2ccfbd  f7b5d647946aae1647bf5cd26
---  -
 25692 ± 0%  -3.0%  24913 ± 0%  dbench.throughput-MB/sec
   6974259 ± 6% -12.1%6127616 ± 0%  meminfo.DirectMap2M
 18.43 ± 0%  -4.6%  17.59 ± 0%  turbostat.RAM_W
  9302 ± 0%  -3.6%   8965 ± 1%  time.user_time
   1425791 ± 1%  -2.0%1396598 ± 0%  time.involuntary_context_switches

Disclaimer:
Results have been estimated based on internal Intel analysis and are provided
for informational purposes only. Any difference in system hardware or software
design or configuration may affect actual performance.

Thanks,
Fengguang
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu10/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu11/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu12/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu13/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu14/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu15/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu16/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu17/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu18/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu19/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu20/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu21/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu22/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu23/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu24/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu25/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu26/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu27/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu28/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu29/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu30/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu31/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu32/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu33/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu34/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu35/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu36/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu37/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu38/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu39/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu4/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu40/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu41/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu42/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu43/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu44/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu45/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu46/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu47/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu5/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu6/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu7/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu8/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu9/cpufreq/scaling_governor
dbench 48 -c /usr/share/dbench/client.txt

Re: [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number

[Xiao Guangrong]

On 08/19/2014 12:31 PM, David Matlack wrote:
> On Mon, Aug 18, 2014 at 8:50 PM, Xiao Guangrong
>  wrote:
>> On 08/19/2014 05:15 AM, David Matlack wrote:
>>> On Mon, Aug 18, 2014 at 12:56 PM, Xiao Guangrong
>>>  wrote:
 @@ -287,9 +293,15 @@ static bool set_mmio_spte(struct kvm *kvm, u64 
 *sptep, gfn_t gfn,

  static bool check_mmio_spte(struct kvm *kvm, u64 spte)
  {
 +   struct kvm_memslots *slots = kvm_memslots(kvm);
 unsigned int kvm_gen, spte_gen;

 -   kvm_gen = kvm_current_mmio_generation(kvm);
 +   if (slots->updated)
 +   return false;
 +
 +   smp_rmb();
 +
 +   kvm_gen = __kvm_current_mmio_generation(slots);
 spte_gen = get_mmio_spte_generation(spte);

>>>
>>> What does this fix? Case 2 can still happen. (Case 2 is unavoidable unless 
>>> we
>>> block during memslot updates, which I don't think we should :).
>>
>> This exactly fixes case 2, slots->updated just acts as the "low bit"
>> but avoid generation number wrap-around and trick handling of the number.
>> More details please see below.
>>
>>>
 trace_check_mmio_spte(spte, kvm_gen, spte_gen);
 diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
 index 4b6c01b..1d4e78f 100644
 --- a/virt/kvm/kvm_main.c
 +++ b/virt/kvm/kvm_main.c
 @@ -96,7 +96,7 @@ static void hardware_disable_all(void);

  static void kvm_io_bus_destroy(struct kvm_io_bus *bus);
  static void update_memslots(struct kvm_memslots *slots,
 -   struct kvm_memory_slot *new, u64 
 last_generation);
 +   struct kvm_memory_slot *new);

  static void kvm_release_pfn_dirty(pfn_t pfn);
  static void mark_page_dirty_in_slot(struct kvm *kvm,
 @@ -685,8 +685,7 @@ static void sort_memslots(struct kvm_memslots *slots)
  }

  static void update_memslots(struct kvm_memslots *slots,
 -   struct kvm_memory_slot *new,
 -   u64 last_generation)
 +   struct kvm_memory_slot *new)
  {
 if (new) {
 int id = new->id;
 @@ -697,8 +696,6 @@ static void update_memslots(struct kvm_memslots *slots,
 if (new->npages != npages)
 sort_memslots(slots);
 }
 -
 -   slots->generation = last_generation + 1;
  }

  static int check_memory_region_flags(struct kvm_userspace_memory_region 
 *mem)
 @@ -720,10 +717,17 @@ static struct kvm_memslots 
 *install_new_memslots(struct kvm *kvm,
  {
 struct kvm_memslots *old_memslots = kvm->memslots;

 -   update_memslots(slots, new, kvm->memslots->generation);
 +   /* ensure generation number is always increased. */
 +   slots->updated = true;
 +   slots->generation = old_memslots->generation;
 +   update_memslots(slots, new);
 rcu_assign_pointer(kvm->memslots, slots);
 synchronize_srcu_expedited(&kvm->srcu);

 +   slots->generation++;
 +   smp_wmb();
 +   slots->updated = false;
 +
 kvm_arch_memslots_updated(kvm);

 return old_memslots;

>>>
>>> This is effectively the same as the first approach.
>>>
>>> I just realized how simple Paolo's idea is. I think it can be a one line
>>> patch (without comments):
>>>
>>> [...]
>>> update_memslots(slots, new, kvm->memslots->generation);
>>> rcu_assign_pointer(kvm->memslots, slots);
>>> synchronize_srcu_expedited(&kvm->srcu);
>>> +   slots->generation++;
>>>
>>> kvm_arch_memslots_updated(kvm);
>>> [...]
>>
>> Really? Unfortunately no. :)
>>
>> See this scenario:
>>
>> CPU 0  CPU 1
>> ioctl registering a new memslot which
>> contains GPA:
>>page-fault handler:
>>  see it'a mmio access on GPA;
>>
>>  assign the new memslots with generation number increased
>>  cache the generation-number into spte;
>>  fix the access and comeback to guest;
>> SRCU-sync
>>  page-fault again and check the spte is a valid 
>> mmio-spte(*)
>> generation-number++;
>> return to userspace;
>>  do mmio-emulation and inject mmio-exit;
>>
>> !!! userspace receives a unexpected mmio-exit, that is case 2 i exactly
>> said in the last mail.
>>
>>
>> Note in the step *, my approach detects the invalid generation-number which
>> will invalidate the mmio spte properly .
> 
> Sorry I didn't explain myself very well: Since we can get a single wrong
> mmio exit no matter what, it has to be handled in userspace. So my point
> was, it doesn't really help to fix that one very specific way that it can
> happen, because it can just happen in oth

[GIT PULL] PCI changes for v3.17 (part 3)

[Bjorn Helgaas]

Hi Linus,

I screwed up.  I intended these changes for v3.17, and I put them in my
'next' branch just before leaving on vacation, but I forgot to include them
in my merge window pull request when I returned.  They're low-risk, so I'm
sending them to you now (late), but the world won't end if they wait until
v3.18.

The main reason to include them would be to support the TI DRA7xx.

Bjorn


The following changes since commit 792688fde431b4fdb2cf10a6f7589a8176b6b14a:

  Merge branches 'pci/host-generic', 'pci/host-mvebu', 'pci/host-rcar', 
'pci/host-tegra', 'pci/msi', 'pci/misc', 'pci/resource' and 
'pci/virtualization' into next (2014-07-16 17:09:47 -0600)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
tags/pci-v3.17-changes-3

for you to fetch changes up to 981c191778a4f92bc82456205a444d522843a630:

  Merge branches 'pci/host-designware', 'pci/host-mvebu' and 'pci/host-tegra' 
into next (2014-07-22 17:55:50 -0600)


PCI changes for v3.17 (part 3):

  Marvell MVEBU
- Remove ARCH_KIRKWOOD dependency (Andrew Lunn)

  NVIDIA Tegra
- Add debugfs support (Thierry Reding)

  Synopsys DesignWare
- Look for configuration space in 'reg', not 'ranges' (Kishon Vijay Abraham 
I)
- Program ATU with untranslated address (Kishon Vijay Abraham I)
- Add config access-related pcie_host_ops for v3.65 hardware (Murali 
Karicheri)
- Add MSI-related pcie_host_ops for v3.65 hardware (Murali Karicheri)

  TI DRA7xx
- Add TI DR7xx PCIe driver (Kishon Vijay Abraham I)


Andrew Lunn (1):
  PCI: mvebu: Remove ARCH_KIRKWOOD dependency

Bjorn Helgaas (1):
  Merge branches 'pci/host-designware', 'pci/host-mvebu' and 
'pci/host-tegra' into next

Kishon Vijay Abraham I (3):
  PCI: designware: Look for configuration space in 'reg', not 'ranges'
  PCI: designware: Program ATU with untranslated address
  PCI: dra7xx: Add TI DRA7xx PCIe driver

Murali Karicheri (2):
  PCI: designware: Add config access-related pcie_host_ops for v3.65 
hardware
  PCI: designware: Add MSI-related pcie_host_ops for v3.65 hardware

Thierry Reding (1):
  PCI: tegra: Add debugfs support

 .../devicetree/bindings/pci/designware-pcie.txt|   4 +
 Documentation/devicetree/bindings/pci/ti-pci.txt   |  59 +++
 MAINTAINERS|   8 +
 drivers/pci/host/Kconfig   |  11 +-
 drivers/pci/host/Makefile  |   1 +
 drivers/pci/host/pci-dra7xx.c  | 458 +
 drivers/pci/host/pci-tegra.c   | 118 ++
 drivers/pci/host/pcie-designware.c | 134 --
 drivers/pci/host/pcie-designware.h |  11 +
 9 files changed, 771 insertions(+), 33 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/ti-pci.txt
 create mode 100644 drivers/pci/host/pci-dra7xx.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] mmc: dw_mmc: move rockchip related code to a separate file

[Addy Ke]

To support HS200 and UHS-1, we need add a big hunk of code,
as shown in the following patches. So a separate file for
rockchip SOCs is suitable.

Signed-off-by: Addy Ke 
---
Changes in v2:
- Kconfig: depend on ARCH_ROCKCHIP, suggested by Bartlomiej Zolnierkiewicz
- Kconfig: depend on OF, suggested by Doug Anderson
- Not change suspend/resume code, suggested by Doug Anderson
- If pdev->dev.of_node is NULL, then return -ENODEV, suggested by Heiko Stübner

 drivers/mmc/host/Kconfig   |   9 +++
 drivers/mmc/host/Makefile  |   1 +
 drivers/mmc/host/dw_mmc-pltfm.c|  57 
 drivers/mmc/host/dw_mmc-rockchip.c | 136 +
 4 files changed, 146 insertions(+), 57 deletions(-)
 create mode 100644 drivers/mmc/host/dw_mmc-rockchip.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index a565254..f6095f6 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -621,6 +621,15 @@ config MMC_DW_PCI
 
  If unsure, say N.
 
+config MMC_DW_ROCKCHIP
+   tristate "Rockchip specific extensions for Synopsys DW Memory Card 
Interface"
+   depends on MMC_DW && ARCH_ROCKCHIP && OF
+   select MMC_DW_PLTFM
+   help
+ This selects support for Rockchip SoC specific extensions to the
+ Synopsys DesignWare Memory Card Interface driver. Select this option
+ for platforms based on RK3066, RK3188 and RK3288 SoC's.
+
 config MMC_SH_MMCIF
tristate "SuperH Internal MMCIF support"
depends on MMC_BLOCK
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 7f81ddf..5fce465 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_MMC_DW_PLTFM)+= dw_mmc-pltfm.o
 obj-$(CONFIG_MMC_DW_EXYNOS)+= dw_mmc-exynos.o
 obj-$(CONFIG_MMC_DW_K3)+= dw_mmc-k3.o
 obj-$(CONFIG_MMC_DW_PCI)   += dw_mmc-pci.o
+obj-$(CONFIG_MMC_DW_ROCKCHIP)  += dw_mmc-rockchip.o
 obj-$(CONFIG_MMC_SH_MMCIF) += sh_mmcif.o
 obj-$(CONFIG_MMC_JZ4740)   += jz4740_mmc.o
 obj-$(CONFIG_MMC_VUB300)   += vub300.o
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index b547f7a..0c56c41 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -26,64 +26,11 @@
 #include "dw_mmc.h"
 #include "dw_mmc-pltfm.h"
 
-#define RK3288_CLKGEN_DIV  2
-
 static void dw_mci_pltfm_prepare_command(struct dw_mci *host, u32 *cmdr)
 {
*cmdr |= SDMMC_CMD_USE_HOLD_REG;
 }
 
-static int dw_mci_rk3288_setup_clock(struct dw_mci *host)
-{
-   host->bus_hz /= RK3288_CLKGEN_DIV;
-
-   return 0;
-}
-
-static void dw_mci_rk3288_set_ios(struct dw_mci *host, struct mmc_ios *ios)
-{
-   int ret;
-   unsigned int cclkin;
-   u32 bus_hz;
-
-   /*
-* cclkin: source clock of mmc controller.
-* bus_hz: card interface clock generated by CLKGEN.
-* bus_hz = cclkin / RK3288_CLKGEN_DIV;
-* ios->clock = (div == 0) ? bus_hz : (bus_hz / (2 * div))
-*
-* Note: div can only be 0 or 1
-*   if DDR50 8bit mode(only emmc work in 8bit mode),
-*   div must be set 1
-*/
-   if ((ios->bus_width == MMC_BUS_WIDTH_8) &&
-   (ios->timing == MMC_TIMING_MMC_DDR52))
-   cclkin = 2 * ios->clock * RK3288_CLKGEN_DIV;
-   else
-   cclkin = ios->clock * RK3288_CLKGEN_DIV;
-
-   ret = clk_set_rate(host->ciu_clk, cclkin);
-   if (ret)
-   dev_warn(host->dev, "failed to set rate %uHz\n", ios->clock);
-
-   bus_hz = clk_get_rate(host->ciu_clk) / RK3288_CLKGEN_DIV;
-   if (bus_hz != host->bus_hz) {
-   host->bus_hz = bus_hz;
-   /* force dw_mci_setup_bus() */
-   host->current_speed = 0;
-   }
-}
-
-static const struct dw_mci_drv_data rk2928_drv_data = {
-   .prepare_command= dw_mci_pltfm_prepare_command,
-};
-
-static const struct dw_mci_drv_data rk3288_drv_data = {
-   .prepare_command= dw_mci_pltfm_prepare_command,
-   .set_ios= dw_mci_rk3288_set_ios,
-   .setup_clock= dw_mci_rk3288_setup_clock,
-};
-
 static const struct dw_mci_drv_data socfpga_drv_data = {
.prepare_command= dw_mci_pltfm_prepare_command,
 };
@@ -144,10 +91,6 @@ EXPORT_SYMBOL_GPL(dw_mci_pltfm_pmops);
 
 static const struct of_device_id dw_mci_pltfm_match[] = {
{ .compatible = "snps,dw-mshc", },
-   { .compatible = "rockchip,rk2928-dw-mshc",
-   .data = &rk2928_drv_data },
-   { .compatible = "rockchip,rk3288-dw-mshc",
-   .data = &rk3288_drv_data },
{ .compatible = "altr,socfpga-dw-mshc",
.data = &socfpga_drv_data },
{},
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c 
b/drivers/mmc/host/dw_mmc-rockchip.c
new file mode 100644
index 000..f0c2cb1
--- /dev/null
+++ b/drivers/mmc/host/dw_mmc-rockchip.c
@@ -0,0 +1,136 @@
+/*
+ * Copyrig

Re: [PATCH v3 03/15] clk: tegra: Add closed loop support for the DFLL

[Vince Hsu]

Hi,

On 08/19/2014 11:33 AM, Tuomas Tynkkynen wrote:

From: Tuomas Tynkkynen 

With closed loop support, the clock rate of the DFLL can be adjusted.

The oscillator itself in the DFLL is a free-running oscillator whose
rate is directly determined the supply voltage. However, the DFLL
module contains logic to compare the DFLL output rate to a fixed
reference clock (51 MHz) and make a decision to either lower or raise
the DFLL supply voltage. The DFLL module can then autonomously change
the supply voltage by communicating with an off-chip PMIC via either I2C
or PWM signals. This driver currently supports only I2C.

Signed-off-by: Tuomas Tynkkynen 

---
v3: Fix incorrect order of arguments to dfll_scale_dvco_rate
---
  drivers/clk/tegra/clk-dfll.c | 656 ++-
  1 file changed, 653 insertions(+), 3 deletions(-)

...

+
+/**
+ * dfll_init_out_if - prepare DFLL-to-PMIC interface
+ * @td: DFLL instance
+ *
+ * During DFLL driver initialization or resume from context loss,
+ * disable the I2C command output to the PMIC, set safe voltage and
+ * output limits, and disable and clear limit interrupts.
+ */
+static void dfll_init_out_if(struct tegra_dfll *td)
+{
+   u32 val;
+
+   td->lut_min = 0;
+   td->lut_max = td->i2c_lut_size - 1;
+   td->lut_safe = td->lut_min + 1;
+
+   dfll_i2c_writel(td, 0, DFLL_OUTPUT_CFG);
+   val = (td->lut_safe << DFLL_OUTPUT_CFG_SAFE_SHIFT) |
+   (td->lut_max << DFLL_OUTPUT_CFG_MAX_SHIFT) |
+   (td->lut_min << DFLL_OUTPUT_CFG_MIN_SHIFT);
+   dfll_writel(td, val, DFLL_OUTPUT_CFG);
+   dfll_wmb(td);
Sorry that I forgot to mention this in v2's comment. Could you squash 
the change below in this patch? And actually it's pretty easy to misuse 
the dfll read/write/wmb functions. We might want to have some generic 
functions for these, and let the generic functions handle the offset to 
different register blocks.


commit 4a1fdd54141b4f8f9425d54cdad13c42763e6186
Author: Vince Hsu 
Date:   Thu Aug 14 18:19:20 2014 +0800

clk: tegra: use the correct write funtion for DFLL_OUTPUT_CFG

Signed-off-by: Vince Hsu 

diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
index 9b3eded6b880..71e4b256ea0d 100644
--- a/drivers/clk/tegra/clk-dfll.c
+++ b/drivers/clk/tegra/clk-dfll.c
@@ -645,7 +645,7 @@ static void dfll_init_out_if(struct tegra_dfll *td)
val = (td->lut_safe << DFLL_OUTPUT_CFG_SAFE_SHIFT) |
(td->lut_max << DFLL_OUTPUT_CFG_MAX_SHIFT) |
(td->lut_min << DFLL_OUTPUT_CFG_MIN_SHIFT);
-   dfll_writel(td, val, DFLL_OUTPUT_CFG);
+   dfll_i2c_writel(td, val, DFLL_OUTPUT_CFG);
-dfll_wmb(td);
+dfll_i2c_wmb(td);

dfll_writel(td, 0, DFLL_OUTPUT_FORCE);
@@ -1146,7 +1146,8 @@ static int attr_registers_show(struct seq_file *s, 
void *data)

seq_puts(s, "CONTROL REGISTERS:\n");
for (offs = 0; offs <= DFLL_MONITOR_DATA; offs += 4)
seq_printf(s, "[0x%02x] = 0x%08x\n", offs,
-  dfll_readl(td, offs));
+   offs == DFLL_OUTPUT_CFG ? 
dfll_i2c_readl(td, offs) :

+   dfll_readl(td, offs));

seq_puts(s, "\nI2C and INTR REGISTERS:\n");
for (offs = DFLL_I2C_CFG; offs <= DFLL_I2C_STS; offs += 4)



Thanks,
Vince

















--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[mm] 3484b2de949: -56.2% vm-scalability.throughput, +9.3% turbostat.Pkg_W

[Fengguang Wu]

Hi Mel,

We noticed the below vm-scalability performance/power regressions on
commit 3484b2de9499df23c4604a513b36f96326ae81ad ("mm: rearrange zone
fields into read-only, page alloc, statistics and page reclaim lines").

24b7e5819ad5cbe  3484b2de9499df23c4604a513  testbox/testcase/testparams
---  -  ---
 %stddev%change   %stddev
\  | /
  9.95 ± 2% +69.1%  16.83 ± 5%  
brickland3/vm-scalability/300s-lru-file-mmap-read
  2.32 ± 6%+229.4%   7.63 ± 5%  
brickland3/vm-scalability/300s-lru-file-readonce
 12.27 ± 3% +99.4%  24.46 ± 5%  TOTAL vm-scalability.stddev

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  13882598 ± 0% -35.8%8915310 ± 1%  
brickland3/vm-scalability/300s-lru-file-mmap-read
  36379953 ± 1% -64.0%   13093373 ± 0%  
brickland3/vm-scalability/300s-lru-file-readonce
  50262551 ± 0% -56.2%   22008683 ± 0%  TOTAL vm-scalability.throughput

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  1138 ±46% -94.7% 60 ±23%  
brickland3/vm-scalability/300s-lru-file-mmap-read
  1138 ±46% -94.7% 60 ±23%  TOTAL proc-vmstat.compact_success

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  0.95 ±20% -87.5%   0.12 ±12%  
brickland3/vm-scalability/300s-lru-file-readonce
  0.95 ±20% -87.5%   0.12 ±12%  TOTAL 
perf-profile.cpu-cycles.read_hpet.ktime_get.clockevents_program_event.tick_program_event.hrtimer_interrupt

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  1.40 ±17% -96.1%   0.05 ±27%  
brickland3/vm-scalability/300s-lru-file-mmap-read
  2.70 ±36% -95.0%   0.13 ± 8%  
brickland3/vm-scalability/300s-lru-file-readonce
  4.10 ±29% -95.4%   0.19 ±14%  TOTAL 
perf-profile.cpu-cycles._raw_spin_lock_irqsave.pagevec_lru_move_fn.__lru_cache_add.lru_cache_add.add_to_page_cache_lru

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  1.46 ±12% -89.1%   0.16 ±18%  
brickland3/vm-scalability/300s-lru-file-readonce
  1.46 ±12% -89.1%   0.16 ±18%  TOTAL 
perf-profile.cpu-cycles.read_hpet.ktime_get.tick_sched_timer.__run_hrtimer.hrtimer_interrupt

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  1.18 ±23% -82.5%   0.21 ±22%  
brickland3/vm-scalability/300s-lru-file-readonce
  1.18 ±23% -82.5%   0.21 ±22%  TOTAL 
perf-profile.cpu-cycles.read_hpet.ktime_get_update_offsets_now.hrtimer_interrupt.local_apic_timer_interrupt.smp_apic_timer_interrupt

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
   763 ±31% -84.5%118 ±11%  
brickland3/vm-scalability/300s-lru-file-mmap-read
   763 ±31% -84.5%118 ±11%  TOTAL 
proc-vmstat.kswapd_low_wmark_hit_quickly

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  1.59 ±12% -85.1%   0.24 ±19%  
brickland3/vm-scalability/300s-lru-file-mmap-read
  1.59 ±12% -85.1%   0.24 ±19%  TOTAL 
perf-profile.cpu-cycles.get_page_from_freelist.__alloc_pages_nodemask.alloc_pages_current.__page_cache_alloc.__do_page_cache_readahead

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
 19972 ±45% -71.3%   5725 ±16%  
brickland3/vm-scalability/300s-lru-file-mmap-read
 19972 ±45% -71.3%   5725 ±16%  TOTAL proc-vmstat.pgmigrate_success

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
   543 ±28% -62.1%205 ±14%  
brickland3/vm-scalability/300s-lru-file-mmap-read
47 ±16%+828.5%443 ± 7%  
brickland3/vm-scalability/300s-lru-file-readonce
   590 ±27% +10.0%649 ± 9%  TOTAL 
proc-vmstat.kswapd_high_wmark_hit_quickly

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
518176 ± 5%-100.0%  0 ± 0%  
brickland3/vm-scalability/300s-lru-file-mmap-read
687557 ± 0% -53.8% 317522 ± 2%  
brickland3/vm-scalability/300s-lru-file-readonce
   1205734 ± 2% -73.7% 317522 ± 2%  TOTAL 
numa-vmstat.node1.workingset_nodereclaim

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  -  
  2.61 ± 5% -52.7%   1.24 ±25%  
brickland3/vm-scalability/300s-lru-file-mmap-read
  1.29 ±10% -91.0%   0.12 ±15%  
brickland3/vm-scalability/300s-lru-file-readonce
  3.91 ± 7% -65.4%   1.35 ±24%  TOTAL 
perf-profile.cpu-cycles.read_hpet.ktime_get.sched_clock_tick.scheduler_tick.update_process_times

24b7e5819ad5cbe  3484b2de9499df23c4604a513  
---  --

Re: [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number

[David Matlack]

On Mon, Aug 18, 2014 at 8:50 PM, Xiao Guangrong
 wrote:
> On 08/19/2014 05:15 AM, David Matlack wrote:
>> On Mon, Aug 18, 2014 at 12:56 PM, Xiao Guangrong
>>  wrote:
>>> @@ -287,9 +293,15 @@ static bool set_mmio_spte(struct kvm *kvm, u64 *sptep, 
>>> gfn_t gfn,
>>>
>>>  static bool check_mmio_spte(struct kvm *kvm, u64 spte)
>>>  {
>>> +   struct kvm_memslots *slots = kvm_memslots(kvm);
>>> unsigned int kvm_gen, spte_gen;
>>>
>>> -   kvm_gen = kvm_current_mmio_generation(kvm);
>>> +   if (slots->updated)
>>> +   return false;
>>> +
>>> +   smp_rmb();
>>> +
>>> +   kvm_gen = __kvm_current_mmio_generation(slots);
>>> spte_gen = get_mmio_spte_generation(spte);
>>>
>>
>> What does this fix? Case 2 can still happen. (Case 2 is unavoidable unless we
>> block during memslot updates, which I don't think we should :).
>
> This exactly fixes case 2, slots->updated just acts as the "low bit"
> but avoid generation number wrap-around and trick handling of the number.
> More details please see below.
>
>>
>>> trace_check_mmio_spte(spte, kvm_gen, spte_gen);
>>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>>> index 4b6c01b..1d4e78f 100644
>>> --- a/virt/kvm/kvm_main.c
>>> +++ b/virt/kvm/kvm_main.c
>>> @@ -96,7 +96,7 @@ static void hardware_disable_all(void);
>>>
>>>  static void kvm_io_bus_destroy(struct kvm_io_bus *bus);
>>>  static void update_memslots(struct kvm_memslots *slots,
>>> -   struct kvm_memory_slot *new, u64 
>>> last_generation);
>>> +   struct kvm_memory_slot *new);
>>>
>>>  static void kvm_release_pfn_dirty(pfn_t pfn);
>>>  static void mark_page_dirty_in_slot(struct kvm *kvm,
>>> @@ -685,8 +685,7 @@ static void sort_memslots(struct kvm_memslots *slots)
>>>  }
>>>
>>>  static void update_memslots(struct kvm_memslots *slots,
>>> -   struct kvm_memory_slot *new,
>>> -   u64 last_generation)
>>> +   struct kvm_memory_slot *new)
>>>  {
>>> if (new) {
>>> int id = new->id;
>>> @@ -697,8 +696,6 @@ static void update_memslots(struct kvm_memslots *slots,
>>> if (new->npages != npages)
>>> sort_memslots(slots);
>>> }
>>> -
>>> -   slots->generation = last_generation + 1;
>>>  }
>>>
>>>  static int check_memory_region_flags(struct kvm_userspace_memory_region 
>>> *mem)
>>> @@ -720,10 +717,17 @@ static struct kvm_memslots 
>>> *install_new_memslots(struct kvm *kvm,
>>>  {
>>> struct kvm_memslots *old_memslots = kvm->memslots;
>>>
>>> -   update_memslots(slots, new, kvm->memslots->generation);
>>> +   /* ensure generation number is always increased. */
>>> +   slots->updated = true;
>>> +   slots->generation = old_memslots->generation;
>>> +   update_memslots(slots, new);
>>> rcu_assign_pointer(kvm->memslots, slots);
>>> synchronize_srcu_expedited(&kvm->srcu);
>>>
>>> +   slots->generation++;
>>> +   smp_wmb();
>>> +   slots->updated = false;
>>> +
>>> kvm_arch_memslots_updated(kvm);
>>>
>>> return old_memslots;
>>>
>>
>> This is effectively the same as the first approach.
>>
>> I just realized how simple Paolo's idea is. I think it can be a one line
>> patch (without comments):
>>
>> [...]
>> update_memslots(slots, new, kvm->memslots->generation);
>> rcu_assign_pointer(kvm->memslots, slots);
>> synchronize_srcu_expedited(&kvm->srcu);
>> +   slots->generation++;
>>
>> kvm_arch_memslots_updated(kvm);
>> [...]
>
> Really? Unfortunately no. :)
>
> See this scenario:
>
> CPU 0  CPU 1
> ioctl registering a new memslot which
> contains GPA:
>page-fault handler:
>  see it'a mmio access on GPA;
>
>  assign the new memslots with generation number increased
>  cache the generation-number into spte;
>  fix the access and comeback to guest;
> SRCU-sync
>  page-fault again and check the spte is a valid 
> mmio-spte(*)
> generation-number++;
> return to userspace;
>  do mmio-emulation and inject mmio-exit;
>
> !!! userspace receives a unexpected mmio-exit, that is case 2 i exactly
> said in the last mail.
>
>
> Note in the step *, my approach detects the invalid generation-number which
> will invalidate the mmio spte properly .

Sorry I didn't explain myself very well: Since we can get a single wrong
mmio exit no matter what, it has to be handled in userspace. So my point
was, it doesn't really help to fix that one very specific way that it can
happen, because it can just happen in other ways. (E.g. update memslots
occurs after is_noslot_pfn() and before mmio exit).

But it looks like you basically said the same thing earlier, so I think
we're on the same page.

The singl

[PATCH v3 0/17] arcmsr: change note since v13 or v2

[Ching Huang]

Change note:
1,5,7~17/17 since v1.3 are not change.
2,3,4/17 since v2 are not change.

6/17 since v2:
1. pre-define adapter_type value in private data of pci_device_id.
2. remove the arcmsr_define_adapter_type function.

Ching Huang 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[writeback] 952648324b9: xfstests.xfs.026.fail

[Fengguang Wu]

Hi Jan,

We find more xfstests changes on "writeback: Per-sb dirty tracking".

008 seems improved, the others are regressions.
063 failure is not 100% reproducible.

df3be46bdbab23e  952648324b969f3fc22d3a2a7  
---  -  
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.026.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.027.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.061.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.281.fail
 0   +Inf%  0 ±200%  TOTAL xfstests.xfs.063.fail
 0 ±489%-100.0%  0 ± 0%  TOTAL xfstests.xfs.008.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.056.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.059.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.060.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.266.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.282.fail
 0   +Inf%  1 ± 0%  TOTAL xfstests.xfs.283.fail

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/3] init / kthread: add module_long_probe_init() and module_long_probe_exit()

[Luis R. Rodriguez]

On Mon, Aug 18, 2014 at 10:19 AM, Oleg Nesterov  wrote:
> And, again, I do not really know which version is better.

In Chicago right now -- feedback was it seems the that generally
splitting up probe from init might be good in the end, if we do this
we won't need a work around for drivers that wait until our
grandmothers die on probe, but we certainly will then be penalizing
drivers who's init does take over 30 seconds. I'm waiting to see an
alternative version of the solution provided as an example on the
other thread, maybe it will fix my keyboard issue :)

 Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH tip/core/rcu 1/2] rcu: Parallelize and economize NOCB kthread wakeups

[Paul E. McKenney]

On Mon, Aug 18, 2014 at 11:23:45PM +0530, Amit Shah wrote:
> On (Fri) 15 Aug 2014 [08:04:05], Paul E. McKenney wrote:
> > On Fri, Aug 15, 2014 at 10:54:11AM +0530, Amit Shah wrote:
> > > On (Wed) 13 Aug 2014 [06:00:49], Paul E. McKenney wrote:
> > > > On Wed, Aug 13, 2014 at 11:14:39AM +0530, Amit Shah wrote:
> > > > > On (Tue) 12 Aug 2014 [14:41:51], Paul E. McKenney wrote:
> > > > > > On Tue, Aug 12, 2014 at 02:39:36PM -0700, Paul E. McKenney wrote:
> > > > > > > On Tue, Aug 12, 2014 at 09:06:21AM -0700, Paul E. McKenney wrote:
> > > > > > > > On Tue, Aug 12, 2014 at 11:03:21AM +0530, Amit Shah wrote:
> > > > > > > 
> > > > > > > [ . . . ]
> > > > > > > 
> > > > > > > > > I know of only virtio-console doing this (via userspace only,
> > > > > > > > > though).
> > > > > > > > 
> > > > > > > > As in userspace within the guest?  That would not work.  The 
> > > > > > > > userspace
> > > > > > > > that the qemu is running in might.  There is a way to extract 
> > > > > > > > ftrace info
> > > > > > > > from crash dumps, so one approach would be "sendkey 
> > > > > > > > alt-sysrq-c", then
> > > > > > > > pull the buffer from the resulting dump.  For all I know, there 
> > > > > > > > might also
> > > > > > > > be some script that uses the qemu "x" command to get at the 
> > > > > > > > ftrace buffer.
> > > > > > > > 
> > > > > > > > Again, I cannot reproduce this, and I have been through the 
> > > > > > > > code several
> > > > > > > > times over the past few days, and am not seeing it.  I could 
> > > > > > > > start
> > > > > > > > sending you random diagnostic patches, but it would be much 
> > > > > > > > better if
> > > > > > > > we could get the trace data from the failure.
> > > > > 
> > > > > I think the only recourse I now have is to dump the guest state from
> > > > > qemu, and attempt to find the ftrace buffers by poking pages and
> > > > > finding some ftrace-like struct... and then dumping the buffers.
> > > > 
> > > > The data exists in the qemu guest state, so it would be good to have
> > > > it one way or another.  My current (perhaps self-serving) guess is that
> > > > you have come up with a way to trick qemu into dropping IPIs.
> > > 
> > > I didn't get around to doing this yet; will get to it next week.
> > > 
> > > In the meantime, I tried this on RHEL6 (with RHEL6 qemu and gcc and
> > > seabios), and that exhibits the problem similarly with my .config.
> > 
> > And I am running my tests successfully on an x86_64 system running
> > Ubuntu 12.04.  Some testing on 14.04 seems to require booting with
> > acpi=off, leading to my perhaps self-serving guess above.
> 
> It looks like Ubuntu 12.04 has a choice of multiple kernels.  Which
> one are you running?

3.2.0-67-generic-pae and 3.13.0-30-generic for the host.

> Also, is there a chance you could try this on a RHEL6 box?

The odds are low over the next few days.  I am adding nastier rcutorture
testing, however.  It would still be very good to get debug information
from your setup.  One approach would be to convert the trace function
calls into printk(), if that would help.

Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: slub/debugobjects: lockup when freeing memory

[Paul E. McKenney]

On Mon, Aug 18, 2014 at 10:44:34PM -0500, Christoph Lameter wrote:
> On Mon, 18 Aug 2014, Paul E. McKenney wrote:
> 
> > > > So call rcu activates the object, but the object has no reference in
> > > > the debug objects code so the fixup code is called which inits the
> > > > object and allocates a reference 
> > >
> > > So we need to init the object in the page struct before the __call_rcu?
> >
> > And the needed APIs are now in mainline:
> >
> > void init_rcu_head(struct rcu_head *head);
> > void destroy_rcu_head(struct rcu_head *head);
> >
> > Over to you, Christoph!  ;-)
> 
> The field we are using for the rcu head serves other purposes before
> the free action. We cannot init the field at slab creation as we
> thought since it is used for the queueing of slabs on the partial, free
> and full lists. The kmem_cache information is not available when doing
> the freeing so we must force the allocation of reserve fields and the
> use of the reserved areas for rcu on all kmem_caches.

Yow!  I am glad I didn't try doing this myself!

> I made this conditional on CONFIG_RCU_XYZ. This needs to be the actual
> Debug options that will require allocations when initializing rcu heads.
> 
> Also note that the allocations in the rcu head initialization must be
> restricted to non RCU slabs otherwise the recursion may not terminate.
> 
> 
> Subject RFC: Allow allocations on initializing rcu fields in slub.
> 
> Signed-off-by: Christoph Lameter 
> 
> Index: linux/mm/slub.c
> ===
> --- linux.orig/mm/slub.c
> +++ linux/mm/slub.c
> @@ -1308,6 +1308,41 @@ static inline struct page *alloc_slab_pa
>   return page;
>  }
> 
> +#ifdef CONFIG_RCU_DEBUG_XYZ

If you make CONFIG_RCU_DEBUG_XYZ instead be CONFIG_DEBUG_OBJECTS_RCU_HEAD,
then it will automatically show up when it needs to.

The rest looks plausible, for whatever that is worth.

Thanx, Paul

> +/*
> + * We may have to do alloations during the initialization of the
> + * debug portion of the rcu structure for a slab. It must therefore
> + * be separately allocated and initized on allocation.
> + * We cannot overload the lru field in the page struct at all.
> + */
> +#define need_reserve_slab_rcu 1
> +#else
> +/*
> + * Overload the lru field in struct page if it fits.
> + * Should struct rcu_head grow due to debugging fields etc then
> + * additional space will be allocated from the end of the slab to
> + * store the rcu_head.
> + */
> +#define need_reserve_slab_rcu
> \
> + (sizeof(((struct page *)NULL)->lru) < sizeof(struct rcu_head))
> +#endif
> +
> +static struct rcu_head *get_rcu_head(struct kmem_cache *s, struct page *page)
> +{
> + if (need_reserve_slab_rcu) {
> + int order = compound_order(page);
> + int offset = (PAGE_SIZE << order) - s->reserved;
> +
> + VM_BUG_ON(s->reserved != sizeof(struct rcu_head));
> + return page_address(page) + offset;
> + } else {
> + /*
> +  * RCU free overloads the RCU head over the LRU
> +  */
> + return (void *)&page->lru;
> + }
> +}
> +
>  static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int 
> node)
>  {
>   struct page *page;
> @@ -1357,6 +1392,21 @@ static struct page *allocate_slab(struct
>   kmemcheck_mark_unallocated_pages(page, pages);
>   }
> 
> +#ifdef CONFIG_RCU_DEBUG_XYZ
> + if (unlikely(s->flags & SLAB_DESTROY_BY_RCU) && page)
> + /*
> +  * Initialize rcu_head and potentially do other
> +  * allocations. Note that this is still a recursive
> +  * call into the allocator which may recurse endlessly
> +  * if the same kmem_cache is used for allocation here.
> +  *
> +  * So in order to be safe the slab caches used
> +  * in init_rcu_head must be restricted to be of the
> +  * non rcu kind only.
> +  */
> + init_rcu_head(get_rcu_head(s, page));
> +#endif
> +
>   if (flags & __GFP_WAIT)
>   local_irq_disable();
>   if (!page)
> @@ -1452,13 +1502,13 @@ static void __free_slab(struct kmem_cach
>   memcg_uncharge_slab(s, order);
>  }
> 
> -#define need_reserve_slab_rcu
> \
> - (sizeof(((struct page *)NULL)->lru) < sizeof(struct rcu_head))
> -
>  static void rcu_free_slab(struct rcu_head *h)
>  {
>   struct page *page;
> 
> +#ifdef CONFIG_RCU_DEBUG_XYZ
> + destroy_rcu_head(h);
> +#endif
>   if (need_reserve_slab_rcu)
>   page = virt_to_head_page(h);
>   else
> @@ -1469,24 +1519,9 @@ static void rcu_free_slab(struct rcu_hea
> 
>  static void free_slab(struct kmem_cache *s, struct page *page)
>  {
> - if (unlikely(s->flags & SLAB_DESTROY_BY_RCU)) {
> - 

Re: [PATCH v2 05/18] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Hanjun Guo]

On 2014-8-18 22:27, Catalin Marinas wrote:
> On Mon, Aug 04, 2014 at 04:28:12PM +0100, Hanjun Guo wrote:
>> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
>> the former signals to the OS that the hardware is PSCI compliant.
> 
> Actually it signals that the firmware is PSCI compliant. The hardware
> doesn't care much.

Right, I will update it.

> 
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 6400312..6e04868 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -19,6 +19,18 @@ extern int acpi_disabled;
>>  extern int acpi_noirq;
>>  extern int acpi_pci_disabled;
>>  
>> +/* 1 to indicate PSCI 0.2+ is implemented */
>> +static inline bool acpi_psci_present(void)
>> +{
>> +return !!(acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT);
>> +}
>> +
>> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>> +static inline bool acpi_psci_use_hvc(void)
>> +{
>> +return !!(acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC);
>> +}
> 
> Do we actually need !! here? Shouldn't the compiler figure out
> conversion to bool automatically?

I thought !! will explicitly show that it's a bool value and
improve the readability of the code, but I'm ok to remove !!
here.

> 
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index 9cf9127..69a315d 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -11,6 +11,8 @@
>>   *  published by the Free Software Foundation.
>>   */
>>  
>> +#define pr_fmt(fmt) "ACPI: " fmt
>> +
>>  #include 
>>  #include 
>>  #include 
>> @@ -47,6 +49,26 @@ void __init __acpi_unmap_table(char *map, unsigned long 
>> size)
>>  early_memunmap(map, size);
>>  }
>>  
>> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
>> +{
>> +struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> +
>> +/*
>> + * Revision in table header is the FADT Major version,
>> + * and there is a minor version of FADT which was introduced
>> + * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
>> + * to get arm boot flags, or we will disable ACPI.
>> + */
>> +if (table->revision < 5 || fadt->minor_revision < 1) {
> 
> If we ever get revision 6.0, this would trigger.

Yes, good catch, actually I already fixed that in my local git repo,

+   if (table->revision > 5 ||
+   (table->revision == 5 && fadt->minor_revision >= 1)) {
+   return 0;
+   } else {
+   pr_info("FADT revision is %d.%d, no PSCI support, should be 5.1
or higher\n",
+   table->revision, fadt->minor_revision);
+   disable_acpi();
+   return -EINVAL;
+   }

> 
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index 85c6326..dfc4e4f3 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -395,6 +395,8 @@ void __init setup_arch(char **cmdline_p)
>>  efi_idmap_init();
>>  
>>  cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>> +acpi_boot_init();
>> +
>>  unflatten_device_tree();
> 
> Unless that's changed in a subsequent patch, do we still need to call
> unflatten_device_tree() if ACPI was successful?

No, we don't. in [PATCH v2 16/18], we will not call unflatten_device_tree()
if ACPI is successful. Since the CONFIG_ACPI is not enabled for ARM64 (will
enable it in the last patch), so acpi_boot_init() is a stub empty function
here.

> 
>>  psci_init();
> 
> I would also rename this to something like psci_dt_init() and move the
> acpi_disabled check here rather than in the callee.

thanks for the suggestion, I will update my patch :)

Thanks
Hanjun


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] KVM: fix cache stale memslot info with correct mmio generation number

[Xiao Guangrong]

On 08/19/2014 05:15 AM, David Matlack wrote:
> On Mon, Aug 18, 2014 at 12:56 PM, Xiao Guangrong
>  wrote:
>> @@ -287,9 +293,15 @@ static bool set_mmio_spte(struct kvm *kvm, u64 *sptep, 
>> gfn_t gfn,
>>
>>  static bool check_mmio_spte(struct kvm *kvm, u64 spte)
>>  {
>> +   struct kvm_memslots *slots = kvm_memslots(kvm);
>> unsigned int kvm_gen, spte_gen;
>>
>> -   kvm_gen = kvm_current_mmio_generation(kvm);
>> +   if (slots->updated)
>> +   return false;
>> +
>> +   smp_rmb();
>> +
>> +   kvm_gen = __kvm_current_mmio_generation(slots);
>> spte_gen = get_mmio_spte_generation(spte);
>>
> 
> What does this fix? Case 2 can still happen. (Case 2 is unavoidable unless we
> block during memslot updates, which I don't think we should :).

This exactly fixes case 2, slots->updated just acts as the "low bit"
but avoid generation number wrap-around and trick handling of the number.
More details please see below.

> 
>> trace_check_mmio_spte(spte, kvm_gen, spte_gen);
>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
>> index 4b6c01b..1d4e78f 100644
>> --- a/virt/kvm/kvm_main.c
>> +++ b/virt/kvm/kvm_main.c
>> @@ -96,7 +96,7 @@ static void hardware_disable_all(void);
>>
>>  static void kvm_io_bus_destroy(struct kvm_io_bus *bus);
>>  static void update_memslots(struct kvm_memslots *slots,
>> -   struct kvm_memory_slot *new, u64 
>> last_generation);
>> +   struct kvm_memory_slot *new);
>>
>>  static void kvm_release_pfn_dirty(pfn_t pfn);
>>  static void mark_page_dirty_in_slot(struct kvm *kvm,
>> @@ -685,8 +685,7 @@ static void sort_memslots(struct kvm_memslots *slots)
>>  }
>>
>>  static void update_memslots(struct kvm_memslots *slots,
>> -   struct kvm_memory_slot *new,
>> -   u64 last_generation)
>> +   struct kvm_memory_slot *new)
>>  {
>> if (new) {
>> int id = new->id;
>> @@ -697,8 +696,6 @@ static void update_memslots(struct kvm_memslots *slots,
>> if (new->npages != npages)
>> sort_memslots(slots);
>> }
>> -
>> -   slots->generation = last_generation + 1;
>>  }
>>
>>  static int check_memory_region_flags(struct kvm_userspace_memory_region 
>> *mem)
>> @@ -720,10 +717,17 @@ static struct kvm_memslots 
>> *install_new_memslots(struct kvm *kvm,
>>  {
>> struct kvm_memslots *old_memslots = kvm->memslots;
>>
>> -   update_memslots(slots, new, kvm->memslots->generation);
>> +   /* ensure generation number is always increased. */
>> +   slots->updated = true;
>> +   slots->generation = old_memslots->generation;
>> +   update_memslots(slots, new);
>> rcu_assign_pointer(kvm->memslots, slots);
>> synchronize_srcu_expedited(&kvm->srcu);
>>
>> +   slots->generation++;
>> +   smp_wmb();
>> +   slots->updated = false;
>> +
>> kvm_arch_memslots_updated(kvm);
>>
>> return old_memslots;
>>
> 
> This is effectively the same as the first approach.
> 
> I just realized how simple Paolo's idea is. I think it can be a one line
> patch (without comments):
> 
> [...]
> update_memslots(slots, new, kvm->memslots->generation);
> rcu_assign_pointer(kvm->memslots, slots);
> synchronize_srcu_expedited(&kvm->srcu);
> +   slots->generation++;
> 
> kvm_arch_memslots_updated(kvm);
> [...]

Really? Unfortunately no. :)

See this scenario:

CPU 0  CPU 1
ioctl registering a new memslot which
contains GPA:
   page-fault handler:
 see it'a mmio access on GPA;

 assign the new memslots with generation number increased
 cache the generation-number into spte;
 fix the access and comeback to guest;
SRCU-sync
 page-fault again and check the spte is a valid 
mmio-spte(*)
generation-number++;
return to userspace;
 do mmio-emulation and inject mmio-exit;

!!! userspace receives a unexpected mmio-exit, that is case 2 i exactly
said in the last mail.


Note in the step *, my approach detects the invalid generation-number which
will invalidate the mmio spte properly .

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 12/15] cpufreq: tegra: Rename tegra-cpufreq to tegra20-cpufreq

[Viresh Kumar]

On 19 August 2014 09:03, Tuomas Tynkkynen  wrote:
> From: Tuomas Tynkkynen 
>
> The Tegra124 will use a different driver for frequency scaling, so
> rename the old driver (which handles only Tegra20) appropriately.
>
> Signed-off-by: Tuomas Tynkkynen 
> ---
> v3: New patch
> ---
>  drivers/cpufreq/Kconfig.arm| 6 +++---
>  drivers/cpufreq/Makefile   | 2 +-
>  drivers/cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} | 0
>  3 files changed, 4 insertions(+), 4 deletions(-)
>  rename drivers/cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} (100%)

Acked-by: Viresh Kumar 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 09/15] ARM: tegra: Add the DFLL to Tegra124 device tree

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

The DFLL clocksource is a separate IP block from the usual
clock-and-reset controller, so it gets its own device tree node.

Signed-off-by: Tuomas Tynkkynen 
---
 arch/arm/boot/dts/tegra124.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 03916ef..8ff4332 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -544,6 +544,28 @@
status = "disabled";
};
 
+   dfll: dfll@0,7011 {
+   compatible = "nvidia,tegra124-dfll";
+   reg = <0 0x7011 0 0x100>, /* DFLL control */
+ <0 0x7011 0 0x100>, /* I2C output control */
+ <0 0x70110100 0 0x100>, /* Integrated I2C controller */
+ <0 0x70110200 0 0x100>; /* Look-up table RAM */
+   interrupts = ;
+   clocks = <&tegra_car TEGRA124_CLK_DFLL_SOC>,
+<&tegra_car TEGRA124_CLK_DFLL_REF>,
+<&tegra_car TEGRA124_CLK_I2C5>;
+   clock-names = "soc", "ref", "i2c";
+   #clock-cells = <0>;
+   clock-output-names = "dfllCPU_out";
+   nvidia,sample-rate = <12500>;
+   nvidia,droop-ctrl = <0x0f00>;
+   nvidia,force-mode = <1>;
+   nvidia,cf = <10>;
+   nvidia,ci = <0>;
+   nvidia,cg = <2>;
+   status = "disabled";
+   };
+
ahub@0,7030 {
compatible = "nvidia,tegra124-ahub";
reg = <0x0 0x7030 0x0 0x200>,
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 04/15] clk: tegra: Add functions for parsing CVB tables

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

Tegra CVB tables encode the relationship between operating voltage
and optimal frequency as a function of the so-called speedo value.
The speedo value is written to the on-chip fuses at the factory,
which allows the voltage-frequency operating points to be calculated
on an per-chip basis.

Add utility functions to parse the Tegra-specific tables and export the
voltage-frequency pairs to the generic OPP framework for other drivers
to use.

Signed-off-by: Tuomas Tynkkynen 
---
 arch/arm/mach-tegra/Kconfig |   1 +
 drivers/clk/tegra/cvb.c | 133 
 drivers/clk/tegra/cvb.h |  67 ++
 3 files changed, 201 insertions(+)
 create mode 100644 drivers/clk/tegra/cvb.c
 create mode 100644 drivers/clk/tegra/cvb.h

diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 0953996..0d5832f 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -7,6 +7,7 @@ menuconfig ARCH_TEGRA
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD if SMP
select PINCTRL
+   select PM_OPP
select ARCH_HAS_RESET_CONTROLLER
select RESET_CONTROLLER
select SOC_BUS
diff --git a/drivers/clk/tegra/cvb.c b/drivers/clk/tegra/cvb.c
new file mode 100644
index 000..69c74ee
--- /dev/null
+++ b/drivers/clk/tegra/cvb.c
@@ -0,0 +1,133 @@
+/*
+ * Utility functions for parsing Tegra CVB voltage tables
+ *
+ * Copyright (C) 2012-2014 NVIDIA Corporation.  All rights reserved.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+#include 
+#include 
+#include 
+
+#include "cvb.h"
+
+/* cvb_mv = ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0) */
+static inline int get_cvb_voltage(int speedo, int s_scale,
+ const struct cvb_coefficients *cvb)
+{
+   int mv;
+
+   /* apply only speedo scale: output mv = cvb_mv * v_scale */
+   mv = DIV_ROUND_CLOSEST(cvb->c2 * speedo, s_scale);
+   mv = DIV_ROUND_CLOSEST((mv + cvb->c1) * speedo, s_scale) + cvb->c0;
+   return mv;
+}
+
+static int round_cvb_voltage(int mv, int v_scale,
+const struct rail_alignment *align)
+{
+   /* combined: apply voltage scale and round to cvb alignment step */
+   int uv;
+   int step = (align->step_uv ? : 1000) * v_scale;
+   int offset = align->offset_uv * v_scale;
+
+   uv = max(mv * 1000, offset) - offset;
+   uv = DIV_ROUND_UP(uv, step) * align->step_uv + align->offset_uv;
+   return uv / 1000;
+}
+
+enum {
+   DOWN,
+   UP
+};
+
+static int round_voltage(int mv, const struct rail_alignment *align, int up)
+{
+   if (align->step_uv) {
+   int uv;
+
+   uv = max(mv * 1000, align->offset_uv) - align->offset_uv;
+   uv = (uv + (up ? align->step_uv - 1 : 0)) / align->step_uv;
+   return (uv * align->step_uv + align->offset_uv) / 1000;
+   }
+   return mv;
+}
+
+static int build_opp_table(const struct cvb_table *d,
+  int speedo_value,
+  unsigned long max_freq,
+  struct device *opp_dev)
+{
+   int i, ret, dfll_mv, min_mv, max_mv;
+   const struct cvb_table_freq_entry *table = NULL;
+   const struct rail_alignment *align = &d->alignment;
+
+   min_mv = round_voltage(d->min_millivolts, align, UP);
+   max_mv = round_voltage(d->max_millivolts, align, DOWN);
+
+   for (i = 0; i < MAX_DVFS_FREQS; i++) {
+   table = &d->cvb_table[i];
+   if (!table->freq || (table->freq > max_freq))
+   break;
+
+   dfll_mv = get_cvb_voltage(
+   speedo_value, d->speedo_scale, &table->coefficients);
+   dfll_mv = round_cvb_voltage(dfll_mv, d->voltage_scale, align);
+   dfll_mv = clamp(dfll_mv, min_mv, max_mv);
+
+   ret = dev_pm_opp_add(opp_dev, table->freq, dfll_mv * 1000);
+   if (ret)
+   return ret;
+   }
+
+   return 0;
+}
+
+/**
+ * tegra_cvb_build_opp_table - build OPP table from Tegra CVB tables
+ * @cvb_tables: array of CVB tables
+ * @sz: size of the previously mentioned array
+ * @process_id: process id of the HW module
+ * @speedo_id: speedo id of the HW module
+ * @speedo_value: speedo value of the HW module
+ * @max_rate: highest safe clock rate
+ * @opp_dev: the struct device * for which the OPP table is built
+ *
+ * On Tegra, a CVB table encodes the relationship between operating voltage
+ * and safe

[PATCH v3 01/15] clk: tegra: Add binding for the Tegra124 DFLL clocksource

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

The DFLL is the main clocksource for the fast CPU cluster on Tegra124
and also provides automatic CPU rail voltage scaling as well. The DFLL
is a separate IP block from the usual Tegra124 clock-and-reset
controller, so it gets its own node in the device tree.

Signed-off-by: Tuomas Tynkkynen 
---
 .../bindings/clock/nvidia,tegra124-dfll.txt| 69 ++
 1 file changed, 69 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt

diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt 
b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
new file mode 100644
index 000..54c62ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
@@ -0,0 +1,69 @@
+NVIDIA Tegra124 DFLL FCPU clocksource
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The DFLL IP block on Tegra is a root clocksource designed for clocking
+the fast CPU cluster. It consists of a free-running voltage controlled
+oscillator connected to the CPU voltage rail (VDD_CPU), and a closed loop
+control module that will automatically adjust the VDD_CPU voltage by
+communicating with an off-chip PMIC either via an I2C bus or via PWM signals.
+
+Required properties:
+- compatible : should be "nvidia,tegra124-dfll-fcpu"
+- reg : Defines the following set of registers, in the order listed:
+- registers for the DFLL control logic.
+- registers for the I2C output logic.
+- registers for the integrated I2C master controller.
+- look-up table RAM for voltage register values.
+- interrupts: Should contain the DFLL block interrupt.
+- clocks: Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+  - soc: Clock source for the DFLL control logic.
+  - ref: The closed loop reference clock
+  - i2c: Clock source for the integrated I2C master.
+- #clock-cells: Must be 0.
+- clock-output-names: Name of the clock output.
+- vdd-cpu-supply: Regulator for the CPU voltage rail that the DFLL
+  hardware will start controlling.
+
+Required properties for the control loop parameters:
+- nvidia,sample-rate: Sample rate of the DFLL control loop.
+- nvidia,droop-ctrl: See the register CL_DVFS_DROOP_CTRL in the TRM.
+- nvidia,force-mode: See the field DFLL_PARAMS_FORCE_MODE in the TRM.
+- nvidia,cf: Numeric value, see the field DFLL_PARAMS_CF_PARAM in the TRM.
+- nvidia,ci: Numeric value, see the field DFLL_PARAMS_CI_PARAM in the TRM.
+- nvidia,cg: Numeric value, see the field DFLL_PARAMS_CG_PARAM in the TRM.
+- nvidia,cg-scale: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the 
TRM.
+
+Required properties for I2C mode:
+- nvidia,i2c-fs-rate: I2C transfer rate, if using FS mode.
+
+Example:
+
+dfll@0,7011 {
+compatible = "nvidia,tegra124-dfll";
+reg = <0 0x7011 0 0x100>, /* DFLL control */
+  <0 0x7011 0 0x100>, /* I2C output control */
+  <0 0x70110100 0 0x100>, /* Integrated I2C controller */
+  <0 0x70110200 0 0x100>; /* Look-up table RAM */
+interrupts = ;
+clocks = <&tegra_car TEGRA124_CLK_DFLL_SOC>,
+ <&tegra_car TEGRA124_CLK_DFLL_REF>,
+ <&tegra_car TEGRA124_CLK_I2C5>;
+clock-names = "soc", "ref", "i2c";
+#clock-cells = <0>;
+clock-output-names = "dfllCPU_out";
+vdd-cpu-supply = <&vdd_cpu>;
+status = "okay";
+
+nvidia,sample-rate = <12500>;
+nvidia,droop-ctrl = <0x0f00>;
+nvidia,force-mode = <1>;
+nvidia,cf = <10>;
+nvidia,ci = <0>;
+nvidia,cg = <2>;
+
+nvidia,i2c-fs-rate = <40>;
+};
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: slub/debugobjects: lockup when freeing memory

[Christoph Lameter]

On Mon, 18 Aug 2014, Paul E. McKenney wrote:

> > > So call rcu activates the object, but the object has no reference in
> > > the debug objects code so the fixup code is called which inits the
> > > object and allocates a reference 
> >
> > So we need to init the object in the page struct before the __call_rcu?
>
> And the needed APIs are now in mainline:
>
>   void init_rcu_head(struct rcu_head *head);
>   void destroy_rcu_head(struct rcu_head *head);
>
> Over to you, Christoph!  ;-)

The field we are using for the rcu head serves other purposes before
the free action. We cannot init the field at slab creation as we
thought since it is used for the queueing of slabs on the partial, free
and full lists. The kmem_cache information is not available when doing
the freeing so we must force the allocation of reserve fields and the
use of the reserved areas for rcu on all kmem_caches.

I made this conditional on CONFIG_RCU_XYZ. This needs to be the actual
Debug options that will require allocations when initializing rcu heads.

Also note that the allocations in the rcu head initialization must be
restricted to non RCU slabs otherwise the recursion may not terminate.


Subject RFC: Allow allocations on initializing rcu fields in slub.

Signed-off-by: Christoph Lameter 

Index: linux/mm/slub.c
===
--- linux.orig/mm/slub.c
+++ linux/mm/slub.c
@@ -1308,6 +1308,41 @@ static inline struct page *alloc_slab_pa
return page;
 }

+#ifdef CONFIG_RCU_DEBUG_XYZ
+/*
+ * We may have to do alloations during the initialization of the
+ * debug portion of the rcu structure for a slab. It must therefore
+ * be separately allocated and initized on allocation.
+ * We cannot overload the lru field in the page struct at all.
+ */
+#define need_reserve_slab_rcu 1
+#else
+/*
+ * Overload the lru field in struct page if it fits.
+ * Should struct rcu_head grow due to debugging fields etc then
+ * additional space will be allocated from the end of the slab to
+ * store the rcu_head.
+ */
+#define need_reserve_slab_rcu  \
+   (sizeof(((struct page *)NULL)->lru) < sizeof(struct rcu_head))
+#endif
+
+static struct rcu_head *get_rcu_head(struct kmem_cache *s, struct page *page)
+{
+   if (need_reserve_slab_rcu) {
+   int order = compound_order(page);
+   int offset = (PAGE_SIZE << order) - s->reserved;
+
+   VM_BUG_ON(s->reserved != sizeof(struct rcu_head));
+   return page_address(page) + offset;
+   } else {
+   /*
+* RCU free overloads the RCU head over the LRU
+*/
+   return (void *)&page->lru;
+   }
+}
+
 static struct page *allocate_slab(struct kmem_cache *s, gfp_t flags, int node)
 {
struct page *page;
@@ -1357,6 +1392,21 @@ static struct page *allocate_slab(struct
kmemcheck_mark_unallocated_pages(page, pages);
}

+#ifdef CONFIG_RCU_DEBUG_XYZ
+   if (unlikely(s->flags & SLAB_DESTROY_BY_RCU) && page)
+   /*
+* Initialize rcu_head and potentially do other
+* allocations. Note that this is still a recursive
+* call into the allocator which may recurse endlessly
+* if the same kmem_cache is used for allocation here.
+*
+* So in order to be safe the slab caches used
+* in init_rcu_head must be restricted to be of the
+* non rcu kind only.
+*/
+   init_rcu_head(get_rcu_head(s, page));
+#endif
+
if (flags & __GFP_WAIT)
local_irq_disable();
if (!page)
@@ -1452,13 +1502,13 @@ static void __free_slab(struct kmem_cach
memcg_uncharge_slab(s, order);
 }

-#define need_reserve_slab_rcu  \
-   (sizeof(((struct page *)NULL)->lru) < sizeof(struct rcu_head))
-
 static void rcu_free_slab(struct rcu_head *h)
 {
struct page *page;

+#ifdef CONFIG_RCU_DEBUG_XYZ
+   destroy_rcu_head(h);
+#endif
if (need_reserve_slab_rcu)
page = virt_to_head_page(h);
else
@@ -1469,24 +1519,9 @@ static void rcu_free_slab(struct rcu_hea

 static void free_slab(struct kmem_cache *s, struct page *page)
 {
-   if (unlikely(s->flags & SLAB_DESTROY_BY_RCU)) {
-   struct rcu_head *head;
-
-   if (need_reserve_slab_rcu) {
-   int order = compound_order(page);
-   int offset = (PAGE_SIZE << order) - s->reserved;
-
-   VM_BUG_ON(s->reserved != sizeof(*head));
-   head = page_address(page) + offset;
-   } else {
-   /*
-* RCU free overloads the RCU head over the LRU
-*/
-   head = (void *)&page->lru;
- 

[PATCH v3 10/15] ARM: tegra: Enable the DFLL on the Jetson TK1

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

Add the board-specific properties of the DFLL for the Jetson TK1 board.
On this board, the DFLL will take control of the sd0 regulator on the
on-board AS3722 PMIC.

Signed-off-by: Tuomas Tynkkynen 
---
 arch/arm/boot/dts/tegra124-jetson-tk1.dts | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts 
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 624b0fb..0c30450 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1453,7 +1453,7 @@
vin-ldo9-10-supply = <&vdd_5v0_sys>;
vin-ldo11-supply = <&vdd_3v3_run>;
 
-   sd0 {
+   vdd_cpu: sd0 {
regulator-name = "+VDD_CPU_AP";
regulator-min-microvolt = <70>;
regulator-max-microvolt = <140>;
@@ -1662,6 +1662,12 @@
non-removable;
};
 
+   dfll@0,7011 {
+   status = "okay";
+   vdd-cpu-supply = <&vdd_cpu>;
+   nvidia,i2c-fs-rate = <40>;
+   };
+
ahub@0,7030 {
i2s@0,70301100 {
status = "okay";
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 06/15] clk: tegra: Add Tegra124 DFLL clocksource platform driver

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

Add basic platform driver support for the fast CPU cluster DFLL
clocksource found on Tegra124 SoCs. This small driver selects the
appropriate Tegra124-specific characterization data and integration
code. It relies on the DFLL common code to do most of the work.

Signed-off-by: Tuomas Tynkkynen 
---
v3: changed some accidental commas at end-of-statement to semicolons
---
 drivers/clk/tegra/Makefile |   2 +
 drivers/clk/tegra/clk-tegra124-dfll-fcpu.c | 165 +
 2 files changed, 167 insertions(+)
 create mode 100644 drivers/clk/tegra/clk-tegra124-dfll-fcpu.c

diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index 47320ca..2f87188 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -16,3 +16,5 @@ obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += clk-tegra20.o
 obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += clk-tegra30.o
 obj-$(CONFIG_ARCH_TEGRA_114_SOC)   += clk-tegra114.o
 obj-$(CONFIG_ARCH_TEGRA_124_SOC)   += clk-tegra124.o
+obj-$(CONFIG_ARCH_TEGRA_124_SOC)   += clk-tegra124-dfll-fcpu.o
+obj-y  += cvb.o
diff --git a/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c 
b/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
new file mode 100644
index 000..13d2fae
--- /dev/null
+++ b/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
@@ -0,0 +1,165 @@
+/*
+ * Tegra124 DFLL FCPU clock source driver
+ *
+ * Copyright (C) 2012-2014 NVIDIA Corporation.  All rights reserved.
+ *
+ * Aleksandr Frid 
+ * Paul Walmsley 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk.h"
+#include "clk-dfll.h"
+#include "cvb.h"
+
+/* Maximum CPU frequency, indexed by CPU speedo id */
+static const unsigned long cpu_max_freq_table[] = {
+   [0] = 201450UL,
+   [1] = 232050UL,
+   [2] = 211650UL,
+   [3] = 252450UL,
+};
+
+static const struct cvb_table tegra124_cpu_cvb_tables[] = {
+   {
+   .speedo_id = -1,
+   .process_id = -1,
+   .min_millivolts = 900,
+   .max_millivolts = 1260,
+   .alignment = {
+   .step_uv = 1, /* 10mV */
+   },
+   .speedo_scale = 100,
+   .voltage_scale = 1000,
+   .cvb_table = {
+   {20400UL,   {1112619, -29295, 402} },
+   {30600UL,   {1150460, -30585, 402} },
+   {40800UL,   {1190122, -31865, 402} },
+   {51000UL,   {1231606, -33155, 402} },
+   {61200UL,   {1274912, -34435, 402} },
+   {71400UL,   {1320040, -35725, 402} },
+   {81600UL,   {1366990, -37005, 402} },
+   {91800UL,   {1415762, -38295, 402} },
+   {102000UL,  {1466355, -39575, 402} },
+   {112200UL,  {1518771, -40865, 402} },
+   {122400UL,  {1573009, -42145, 402} },
+   {132600UL,  {1629068, -43435, 402} },
+   {142800UL,  {1686950, -44715, 402} },
+   {153000UL,  {1746653, -46005, 402} },
+   {163200UL,  {1808179, -47285, 402} },
+   {173400UL,  {1871526, -48575, 402} },
+   {183600UL,  {1936696, -49855, 402} },
+   {193800UL,  {2003687, -51145, 402} },
+   {201450UL,  {2054787, -52095, 402} },
+   {211650UL,  {2124957, -53385, 402} },
+   {221850UL,  {2196950, -54665, 402} },
+   {232050UL,  {2270765, -55955, 402} },
+   {242250UL,  {2346401, -57235, 402} },
+   {252450UL,  {2437299, -58535, 402} },
+   {0, {  0,  0,   0} },
+   },
+   .cpu_dfll_data = {
+   .tune0_low = 0x005020ff,
+   .tune0_high = 0x005040ff,
+   .tune1 = 0x0060,
+   }
+   },
+};
+
+static struct tegra_dfll_soc_data soc;
+
+static int tegra124_dfll_fcpu_probe(struct platform_device *pdev)
+{
+   return tegra_dfll_register(pdev, &soc);
+}
+
+static struct of_device_id tegra124_dfll_fcpu_of_match[] = {
+   { .compatible = "nvidia,tegra124-dfll", },

[PATCH v3 03/15] clk: tegra: Add closed loop support for the DFLL

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

With closed loop support, the clock rate of the DFLL can be adjusted.

The oscillator itself in the DFLL is a free-running oscillator whose
rate is directly determined the supply voltage. However, the DFLL
module contains logic to compare the DFLL output rate to a fixed
reference clock (51 MHz) and make a decision to either lower or raise
the DFLL supply voltage. The DFLL module can then autonomously change
the supply voltage by communicating with an off-chip PMIC via either I2C
or PWM signals. This driver currently supports only I2C.

Signed-off-by: Tuomas Tynkkynen 

---
v3: Fix incorrect order of arguments to dfll_scale_dvco_rate
---
 drivers/clk/tegra/clk-dfll.c | 656 ++-
 1 file changed, 653 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
index f60ef54..d11ab43f 100644
--- a/drivers/clk/tegra/clk-dfll.c
+++ b/drivers/clk/tegra/clk-dfll.c
@@ -205,12 +205,16 @@
  */
 #define REF_CLOCK_RATE 5100UL
 
+#define DVCO_RATE_TO_MULT(rate, ref_rate)  ((rate) / ((ref_rate) / 2))
+#define MULT_TO_DVCO_RATE(mult, ref_rate)  ((mult) * ((ref_rate) / 2))
 
 /**
  * enum dfll_ctrl_mode - DFLL hardware operating mode
  * @DFLL_UNINITIALIZED: (uninitialized state - not in hardware bitfield)
  * @DFLL_DISABLED: DFLL not generating an output clock
  * @DFLL_OPEN_LOOP: DVCO running, but DFLL not adjusting voltage
+ * @DFLL_CLOSED_LOOP: DVCO running, and DFLL adjusting voltage to match
+ *   the requested rate
  *
  * The integer corresponding to the last two states, minus one, is
  * written to the DFLL hardware to change operating modes.
@@ -219,6 +223,7 @@ enum dfll_ctrl_mode {
DFLL_UNINITIALIZED = 0,
DFLL_DISABLED = 1,
DFLL_OPEN_LOOP = 2,
+   DFLL_CLOSED_LOOP = 3,
 };
 
 /**
@@ -236,6 +241,22 @@ enum dfll_tune_range {
DFLL_TUNE_LOW = 1,
 };
 
+/**
+ * struct dfll_rate_req - target DFLL rate request data
+ * @rate: target frequency, after the postscaling
+ * @dvco_target_rate: target frequency, after the postscaling
+ * @lut_index: LUT index at which voltage the dvco_target_rate will be reached
+ * @mult_bits: value to program to the MULT bits of the DFLL_FREQ_REQ register
+ * @scale_bits: value to program to the SCALE bits of the DFLL_FREQ_REQ 
register
+ */
+struct dfll_rate_req {
+   unsigned long rate;
+   unsigned long dvco_target_rate;
+   int lut_index;
+   u8 mult_bits;
+   u8 scale_bits;
+};
+
 struct tegra_dfll {
struct device   *dev;
struct tegra_dfll_soc_data  *soc;
@@ -259,9 +280,26 @@ struct tegra_dfll {
struct dentry   *debugfs_dir;
struct clk_hw   dfll_clk_hw;
const char  *output_clock_name;
+   struct dfll_rate_reqlast_req;
 
/* Parameters from DT */
u32 droop_ctrl;
+   u32 sample_rate;
+   u32 force_mode;
+   u32 cf;
+   u32 ci;
+   u32 cg;
+   boolcg_scale;
+
+   /* I2C interface parameters */
+   u32 i2c_fs_rate;
+   u32 i2c_reg;
+   u32 i2c_slave_addr;
+
+   /* i2c_lut array entries are regulator framework selectors */
+   unsignedi2c_lut[MAX_DFLL_VOLTAGES];
+   int i2c_lut_size;
+   u8  lut_min, lut_max, lut_safe;
 };
 
 #define clk_hw_to_dfll(_hw) container_of(_hw, struct tegra_dfll, dfll_clk_hw)
@@ -271,6 +309,7 @@ static const char * const mode_name[] = {
[DFLL_UNINITIALIZED] = "uninitialized",
[DFLL_DISABLED] = "disabled",
[DFLL_OPEN_LOOP] = "open_loop",
+   [DFLL_CLOSED_LOOP] = "closed_loop",
 };
 
 /*
@@ -494,6 +533,282 @@ static void dfll_set_mode(struct tegra_dfll *td,
 }
 
 /*
+ * DFLL-to-I2C controller interface
+ */
+
+/**
+ * dfll_i2c_set_output_enabled - enable/disable I2C PMIC voltage requests
+ * @td: DFLL instance
+ * @enable: whether to enable or disable the I2C voltage requests
+ *
+ * Set the master enable control for I2C control value updates. If disabled,
+ * then I2C control messages are inhibited, regardless of the DFLL mode.
+ */
+static int dfll_i2c_set_output_enabled(struct tegra_dfll *td, bool enable)
+{
+   u32 val;
+
+   val = dfll_i2c_readl(td, DFLL_OUTPUT_CFG);
+
+   if (enable)
+   val |= DFLL_OUTPUT_CFG_I2C_ENABLE;
+   else
+   val &= ~DFLL_OUTPUT_CFG_I2C_ENABLE;
+
+   dfll_i2c_writel(td, val, DFLL_OUTPUT_CFG);
+   dfll_i2c_wmb(td);
+
+   return 0;
+}
+
+/**
+ * dfll_load_lut - load the voltage lookup table
+ * @td: struct 

[PATCH v3 00/15] Tegra124 CL-DVFS / DFLL clocksource, plus cpufreq

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

v3 changes:
- Fix incorrect order of arguments to dfll_scale_dvco_rate
- Fix accidental commas at end-of-statement to semicolons
- Some cpufreq changes:
- rename cpufreq-tegra to cpufreq-tegra20
- have separate Kconfig entries for Tegra20/Tegra124 support
- use 'select GENERIC_CPUFREQ_CPU0', not depends
- support unbinding of the platform device
- requires adding the vdd_cpu regulator to the DT so
  the old voltage can be restored when switching to PLLX
- allocate a state structure instead of globals
- use of_match_machine()
- various style nits fixed

The cpufreq part is dependant on the of_match_machine() series.

Original cover letter:

This series implements the DFLL/CL-DVFS clock source for the fast CPU
cluster on Tegra124, and a cpufreq driver that uses the DFLL for
clocking the CPU. Most of this is based on Paul Walmsley's public patch
set from December 2013, which is available at
http://comments.gmane.org/gmane.linux.ports.tegra/15273

The DFLL clock hardware is a voltage-controlled oscillator plus
control logic that compares the generated output clock with a
51 MHz reference clock, and can make decisions to either lower
or raise the DFLL voltage to keep the output rate close to the
software-requested rate. The voltage changes are done by
communicating with an off-chip PMIC via either I2C or PWM.
As the DFLL oscillator is powered via the CPU rail, using
the DFLL as the CPU clocksource also gives us dynamic CPU
voltage scaling.

This series has been tested on the Jetson TK1 (Rev C). Porting this to
the Venice2 should be simple, though do note that it does not have
active cooling.

Thanks,
Tuomas


Paul Walmsley (1):
  clk: tegra: Add DFLL DVCO reset control for Tegra124

Tuomas Tynkkynen (14):
  clk: tegra: Add binding for the Tegra124 DFLL clocksource
  clk: tegra: Add library for the DFLL clock source (open-loop mode)
  clk: tegra: Add closed loop support for the DFLL
  clk: tegra: Add functions for parsing CVB tables
  clk: tegra: Add Tegra124 DFLL clocksource platform driver
  clk: tegra: Save/restore CCLKG_BURST_POLICY on suspend
  clk: tegra: Add the DFLL as a possible parent of the cclk_g clock
  ARM: tegra: Add the DFLL to Tegra124 device tree
  ARM: tegra: Enable the DFLL on the Jetson TK1
  cpufreq: tegra124: Add device tree bindings
  cpufreq: tegra: Rename tegra-cpufreq to tegra20-cpufreq
  cpufreq: Add cpufreq driver for Tegra124
  ARM: tegra: Add entries for cpufreq on Tegra124
  ARM: tegra: Add CPU regulator to the Jetson TK1 device tree

 .../bindings/clock/nvidia,tegra124-dfll.txt|   69 +
 .../bindings/cpufreq/tegra124-cpufreq.txt  |   44 +
 arch/arm/boot/dts/tegra124-jetson-tk1.dts  |   12 +-
 arch/arm/boot/dts/tegra124.dtsi|   33 +-
 arch/arm/mach-tegra/Kconfig|1 +
 drivers/clk/tegra/Makefile |3 +
 drivers/clk/tegra/clk-dfll.c   | 1735 
 drivers/clk/tegra/clk-dfll.h   |   55 +
 drivers/clk/tegra/clk-tegra-super-gen4.c   |4 +-
 drivers/clk/tegra/clk-tegra124-dfll-fcpu.c |  165 ++
 drivers/clk/tegra/clk-tegra124.c   |   61 +
 drivers/clk/tegra/clk.h|3 +
 drivers/clk/tegra/cvb.c|  133 ++
 drivers/clk/tegra/cvb.h|   67 +
 drivers/cpufreq/Kconfig.arm|   14 +-
 drivers/cpufreq/Makefile   |3 +-
 drivers/cpufreq/tegra124-cpufreq.c |  206 +++
 .../cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} |0
 18 files changed, 2601 insertions(+), 7 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt
 create mode 100644 drivers/clk/tegra/clk-dfll.c
 create mode 100644 drivers/clk/tegra/clk-dfll.h
 create mode 100644 drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
 create mode 100644 drivers/clk/tegra/cvb.c
 create mode 100644 drivers/clk/tegra/cvb.h
 create mode 100644 drivers/cpufreq/tegra124-cpufreq.c
 rename drivers/cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} (100%)

-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 12/15] cpufreq: tegra: Rename tegra-cpufreq to tegra20-cpufreq

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

The Tegra124 will use a different driver for frequency scaling, so
rename the old driver (which handles only Tegra20) appropriately.

Signed-off-by: Tuomas Tynkkynen 
---
v3: New patch
---
 drivers/cpufreq/Kconfig.arm| 6 +++---
 drivers/cpufreq/Makefile   | 2 +-
 drivers/cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} | 0
 3 files changed, 4 insertions(+), 4 deletions(-)
 rename drivers/cpufreq/{tegra-cpufreq.c => tegra20-cpufreq.c} (100%)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 7364a53..3795a16 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -241,9 +241,9 @@ config ARM_SPEAR_CPUFREQ
help
  This adds the CPUFreq driver support for SPEAr SOCs.
 
-config ARM_TEGRA_CPUFREQ
-   bool "TEGRA CPUFreq support"
+config ARM_TEGRA20_CPUFREQ
+   bool "Tegra20 CPUFreq support"
depends on ARCH_TEGRA
default y
help
- This adds the CPUFreq driver support for TEGRA SOCs.
+ This adds the CPUFreq driver support for Tegra20 SOCs.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index db6d9a2..428451a 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -75,7 +75,7 @@ obj-$(CONFIG_ARM_S5PV210_CPUFREQ) += s5pv210-cpufreq.o
 obj-$(CONFIG_ARM_SA1100_CPUFREQ)   += sa1100-cpufreq.o
 obj-$(CONFIG_ARM_SA1110_CPUFREQ)   += sa1110-cpufreq.o
 obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
-obj-$(CONFIG_ARM_TEGRA_CPUFREQ)+= tegra-cpufreq.o
+obj-$(CONFIG_ARM_TEGRA20_CPUFREQ)  += tegra20-cpufreq.o
 obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
 
 
##
diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra20-cpufreq.c
similarity index 100%
rename from drivers/cpufreq/tegra-cpufreq.c
rename to drivers/cpufreq/tegra20-cpufreq.c
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 05/15] clk: tegra: Add DFLL DVCO reset control for Tegra124

[Tuomas Tynkkynen]

From: Paul Walmsley 

The DVCO present in the DFLL IP block has a separate reset line,
exposed via the CAR IP block.  This reset line is asserted upon SoC
reset.  Unless something (such as the DFLL driver) deasserts this
line, the DVCO will not oscillate, although reads and writes to the
DFLL IP block will complete.

Thanks to Aleksandr Frid  for identifying this and
saving hours of debugging time.

Signed-off-by: Paul Walmsley 
[ttynkkynen: ported to tegra124 from tegra114]
Signed-off-by: Tuomas Tynkkynen 
---
 drivers/clk/tegra/clk-tegra124.c | 47 
 drivers/clk/tegra/clk.h  |  3 +++
 2 files changed, 50 insertions(+)

diff --git a/drivers/clk/tegra/clk-tegra124.c b/drivers/clk/tegra/clk-tegra124.c
index 9525c68..cc81eab 100644
--- a/drivers/clk/tegra/clk-tegra124.c
+++ b/drivers/clk/tegra/clk-tegra124.c
@@ -31,6 +31,9 @@
 #define CLK_SOURCE_CSITE 0x1d4
 #define CLK_SOURCE_EMC 0x19c
 
+#define RST_DFLL_DVCO  0x2f4
+#define DVFS_DFLL_RESET_SHIFT  0
+
 #define PLLC_BASE 0x80
 #define PLLC_OUT 0x84
 #define PLLC_MISC2 0x88
@@ -1386,6 +1389,50 @@ static void __init tegra124_clock_apply_init_table(void)
tegra_init_from_table(init_table, clks, TEGRA124_CLK_CLK_MAX);
 }
 
+/**
+ * tegra124_car_barrier - wait for pending writes to the CAR to complete
+ *
+ * Wait for any outstanding writes to the CAR MMIO space from this CPU
+ * to complete before continuing execution.  No return value.
+ */
+static void tegra124_car_barrier(void)
+{
+   readl_relaxed(clk_base + RST_DFLL_DVCO);
+}
+
+/**
+ * tegra124_clock_assert_dfll_dvco_reset - assert the DFLL's DVCO reset
+ *
+ * Assert the reset line of the DFLL's DVCO.  No return value.
+ */
+void tegra124_clock_assert_dfll_dvco_reset(void)
+{
+   u32 v;
+
+   v = readl_relaxed(clk_base + RST_DFLL_DVCO);
+   v |= (1 << DVFS_DFLL_RESET_SHIFT);
+   writel_relaxed(v, clk_base + RST_DFLL_DVCO);
+   tegra124_car_barrier();
+}
+EXPORT_SYMBOL(tegra124_clock_assert_dfll_dvco_reset);
+
+/**
+ * tegra124_clock_deassert_dfll_dvco_reset - deassert the DFLL's DVCO reset
+ *
+ * Deassert the reset line of the DFLL's DVCO, allowing the DVCO to
+ * operate.  No return value.
+ */
+void tegra124_clock_deassert_dfll_dvco_reset(void)
+{
+   u32 v;
+
+   v = readl_relaxed(clk_base + RST_DFLL_DVCO);
+   v &= ~(1 << DVFS_DFLL_RESET_SHIFT);
+   writel_relaxed(v, clk_base + RST_DFLL_DVCO);
+   tegra124_car_barrier();
+}
+EXPORT_SYMBOL(tegra124_clock_deassert_dfll_dvco_reset);
+
 static void __init tegra124_clock_init(struct device_node *np)
 {
struct device_node *node;
diff --git a/drivers/clk/tegra/clk.h b/drivers/clk/tegra/clk.h
index 16ec8d6..4b3f3d0 100644
--- a/drivers/clk/tegra/clk.h
+++ b/drivers/clk/tegra/clk.h
@@ -627,6 +627,9 @@ void tegra114_clock_tune_cpu_trimmers_init(void);
 void tegra114_clock_assert_dfll_dvco_reset(void);
 void tegra114_clock_deassert_dfll_dvco_reset(void);
 
+void tegra124_clock_assert_dfll_dvco_reset(void);
+void tegra124_clock_deassert_dfll_dvco_reset(void);
+
 typedef void (*tegra_clk_apply_init_table_func)(void);
 extern tegra_clk_apply_init_table_func tegra_clk_apply_init_table;
 
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 15/15] ARM: tegra: Add CPU regulator to the Jetson TK1 device tree

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

Add the CPU voltage regulator for the cpufreq driver.

Signed-off-by: Tuomas Tynkkynen 
---
v3: New patch
---
 arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts 
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 0c30450..4be7c82 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1858,3 +1858,7 @@
clock-names = "pll_a", "pll_a_out0", "mclk";
};
 };
+
+&cpu0 {
+   vdd-cpu-supply = <&vdd_cpu>;
+};
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 02/15] clk: tegra: Add library for the DFLL clock source (open-loop mode)

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

Add shared code to support the Tegra DFLL clocksource in open-loop
mode. This root clocksource is present on the Tegra124 SoCs. The
DFLL is the intended primary clock source for the fast CPU cluster.

This code is very closely based on a patch by Paul Walmsley from
December (http://comments.gmane.org/gmane.linux.ports.tegra/15273),
which in turn comes from the internal driver by originally created
by Aleksandr Frid .

Subsequent patches will add support for closed loop mode and drivers
for the Tegra124 fast CPU cluster DFLL devices, which rely on this
code.

Signed-off-by: Paul Walmsley 
Signed-off-by: Tuomas Tynkkynen 
---
v3: Fix incorrect order of arguments to dfll_scale_dvco_rate call
---
 drivers/clk/tegra/Makefile   |1 +
 drivers/clk/tegra/clk-dfll.c | 1085 ++
 drivers/clk/tegra/clk-dfll.h |   55 +++
 3 files changed, 1141 insertions(+)
 create mode 100644 drivers/clk/tegra/clk-dfll.c
 create mode 100644 drivers/clk/tegra/clk-dfll.h

diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
index f7dfb72..47320ca 100644
--- a/drivers/clk/tegra/Makefile
+++ b/drivers/clk/tegra/Makefile
@@ -1,5 +1,6 @@
 obj-y  += clk.o
 obj-y  += clk-audio-sync.o
+obj-y  += clk-dfll.o
 obj-y  += clk-divider.o
 obj-y  += clk-periph.o
 obj-y  += clk-periph-gate.o
diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
new file mode 100644
index 000..f60ef54
--- /dev/null
+++ b/drivers/clk/tegra/clk-dfll.c
@@ -0,0 +1,1085 @@
+/*
+ * clk-dfll.c - Tegra DFLL clock source common code
+ *
+ * Copyright (C) 2012-2014 NVIDIA Corporation. All rights reserved.
+ *
+ * Aleksandr Frid 
+ * Paul Walmsley 
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * This library is for the DVCO and DFLL IP blocks on the Tegra124
+ * SoC. These IP blocks together are also known at NVIDIA as
+ * "CL-DVFS". To try to avoid confusion, this code refers to them
+ * collectively as the "DFLL."
+ *
+ * The DFLL is a root clocksource which tolerates some amount of
+ * supply voltage noise. Tegra124 uses it to clock the fast CPU
+ * complex when the target CPU speed is above a particular rate. The
+ * DFLL can be operated in either open-loop mode or closed-loop mode.
+ * In open-loop mode, the DFLL generates an output clock appropriate
+ * to the supply voltage. In closed-loop mode, when configured with a
+ * target frequency, the DFLL minimizes supply voltage while
+ * delivering an average frequency equal to the target.
+ *
+ * Devices clocked by the DFLL must be able to tolerate frequency
+ * variation. In the case of the CPU, it's important to note that the
+ * CPU cycle time will vary. This has implications for
+ * performance-measurement code and any code that relies on the CPU
+ * cycle time to delay for a certain length of time.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "clk-dfll.h"
+
+/*
+ * DFLL control registers - access via dfll_{readl,writel}
+ */
+
+/* DFLL_CTRL: DFLL control register */
+#define DFLL_CTRL  0x00
+#define DFLL_CTRL_MODE_MASK0x03
+
+/* DFLL_CONFIG: DFLL sample rate control */
+#define DFLL_CONFIG0x04
+#define DFLL_CONFIG_DIV_MASK   0xff
+#define DFLL_CONFIG_DIV_PRESCALE   32
+
+/* DFLL_PARAMS: tuning coefficients for closed loop integrator */
+#define DFLL_PARAMS0x08
+#define DFLL_PARAMS_CG_SCALE   (0x1 << 24)
+#define DFLL_PARAMS_FORCE_MODE_SHIFT   22
+#define DFLL_PARAMS_FORCE_MODE_MASK(0x3 << DFLL_PARAMS_FORCE_MODE_SHIFT)
+#define DFLL_PARAMS_CF_PARAM_SHIFT 16
+#define DFLL_PARAMS_CF_PARAM_MASK  (0x3f << DFLL_PARAMS_CF_PARAM_SHIFT)
+#define DFLL_PARAMS_CI_PARAM_SHIFT 8
+#define DFLL_PARAMS_CI_PARAM_MASK  (0x7 << DFLL_PARAMS_CI_PARAM_SHIFT)
+#define DFLL_PARAMS_CG_PARAM_SHIFT 0
+#define DFLL_PARAMS_CG_PARAM_MASK  (0xff << DFLL_PARAMS_CG_PARAM_SHIFT)
+
+/* DFLL_TUNE0: delay line configuration register 0 */
+#define DFLL_TUNE0 0x0c
+
+/* DFLL_TUNE1: delay line configuration register 1 */
+#define DFLL_TUNE1 0x10
+
+/* DFLL_FREQ_REQ: target DFLL frequency control */
+#define DFLL_FREQ_REQ  0x14
+#define DFLL_FREQ_REQ_FORCE_ENA

[PATCH v3 08/15] clk: tegra: Add the DFLL as a possible parent of the cclk_g clock

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

The DFLL clocksource was missing from the list of possible parents for
the fast CPU cluster. Add it to the list.

Signed-off-by: Tuomas Tynkkynen 
---
 drivers/clk/tegra/clk-tegra-super-gen4.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/tegra/clk-tegra-super-gen4.c 
b/drivers/clk/tegra/clk-tegra-super-gen4.c
index feb3201..f1f4410 100644
--- a/drivers/clk/tegra/clk-tegra-super-gen4.c
+++ b/drivers/clk/tegra/clk-tegra-super-gen4.c
@@ -44,7 +44,9 @@ static const char *sclk_parents[] = { "clk_m", "pll_c_out1", 
"pll_p_out4",
 
 static const char *cclk_g_parents[] = { "clk_m", "pll_c", "clk_32k", "pll_m",
"pll_p", "pll_p_out4", "unused",
-   "unused", "pll_x" };
+   "unused", "pll_x", "unused", "unused",
+   "unused", "unused", "unused", "unused",
+   "dfllCPU_out" };
 
 static const char *cclk_lp_parents[] = { "clk_m", "pll_c", "clk_32k", "pll_m",
 "pll_p", "pll_p_out4", "unused",
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 13/15] cpufreq: Add cpufreq driver for Tegra124

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

Add a new cpufreq driver for Tegra124. Instead of using the PLLX as
the CPU clocksource, switch immediately to the DFLL. It allows the use
of higher clock rates, and will automatically scale the CPU voltage as
well. Besides the CPU clocksource switch, we let the cpufreq-cpu0 driver
for all the cpufreq operations.

This driver also relies on the DFLL driver to fill the OPP table for the
CPU0 device, so that the cpufreq-cpu0 driver knows what frequencies to
use.

Signed-off-by: Tuomas Tynkkynen 
---
v3:
 - separate Kconfig entry
 - use 'select GENERIC_CPUFREQ_CPU0', not depends
 - support unbinding of the platform device
 - allocate a state structure instead of globals
 - use of_match_machine()
 - various style nits fixed
---
 drivers/cpufreq/Kconfig.arm|   8 ++
 drivers/cpufreq/Makefile   |   1 +
 drivers/cpufreq/tegra124-cpufreq.c | 206 +
 3 files changed, 215 insertions(+)
 create mode 100644 drivers/cpufreq/tegra124-cpufreq.c

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 3795a16..07bfed1 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -247,3 +247,11 @@ config ARM_TEGRA20_CPUFREQ
default y
help
  This adds the CPUFreq driver support for Tegra20 SOCs.
+
+config ARM_TEGRA124_CPUFREQ
+   bool "Tegra124 CPUFreq support"
+   depends on ARCH_TEGRA
+   select GENERIC_CPUFREQ_CPU0
+   default y
+   help
+ This adds the CPUFreq driver support for Tegra124 SOCs.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 428451a..25b4f53 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_ARM_SA1100_CPUFREQ)  += sa1100-cpufreq.o
 obj-$(CONFIG_ARM_SA1110_CPUFREQ)   += sa1110-cpufreq.o
 obj-$(CONFIG_ARM_SPEAR_CPUFREQ)+= spear-cpufreq.o
 obj-$(CONFIG_ARM_TEGRA20_CPUFREQ)  += tegra20-cpufreq.o
+obj-$(CONFIG_ARM_TEGRA124_CPUFREQ) += tegra124-cpufreq.o
 obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
 
 
##
diff --git a/drivers/cpufreq/tegra124-cpufreq.c 
b/drivers/cpufreq/tegra124-cpufreq.c
new file mode 100644
index 000..5748baa
--- /dev/null
+++ b/drivers/cpufreq/tegra124-cpufreq.c
@@ -0,0 +1,206 @@
+/*
+ * Tegra 124 cpufreq driver
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#define pr_fmt(fmt)KBUILD_MODNAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct tegra124_cpufreq_priv {
+   struct regulator *vdd_cpu_reg;
+   struct clk *cpu_clk;
+   struct clk *pllp_clk;
+   struct clk *pllx_clk;
+   struct clk *dfll_clk;
+   struct platform_device *cpufreq_cpu0_pdev;
+};
+
+static int tegra124_cpu_switch_to_dfll(struct tegra124_cpufreq_priv *priv)
+{
+   struct clk *orig_parent;
+   int ret;
+
+   ret = clk_set_rate(priv->dfll_clk, clk_get_rate(priv->cpu_clk));
+   if (ret)
+   return ret;
+
+   orig_parent = clk_get_parent(priv->cpu_clk);
+   clk_set_parent(priv->cpu_clk, priv->pllp_clk);
+
+   ret = clk_prepare_enable(priv->dfll_clk);
+   if (ret)
+   goto out;
+
+   clk_set_parent(priv->cpu_clk, priv->dfll_clk);
+
+   return 0;
+
+out:
+   clk_set_parent(priv->cpu_clk, orig_parent);
+
+   return ret;
+}
+
+static void tegra124_cpu_switch_to_pllx(struct tegra124_cpufreq_priv *priv)
+{
+   clk_set_parent(priv->cpu_clk, priv->pllp_clk);
+   clk_disable_unprepare(priv->dfll_clk);
+   regulator_sync_voltage(priv->vdd_cpu_reg);
+   clk_set_parent(priv->cpu_clk, priv->pllx_clk);
+}
+
+static int tegra124_cpufreq_probe(struct platform_device *pdev)
+{
+   struct tegra124_cpufreq_priv *priv;
+   struct device_node *np;
+   struct platform_device_info cpufreq_cpu0_devinfo = {};
+   int ret;
+
+   priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   np = of_cpu_device_node_get(0);
+   if (!np)
+   return -ENODEV;
+
+   priv->vdd_cpu_reg = regulator_get(get_cpu_device(0), "vdd-cpu");
+   if (IS_ERR(priv->vdd_cpu_reg)) {
+   ret = PTR_ERR(priv->vdd_cpu_reg);
+   goto out_put_np;
+   }
+
+   priv->cpu_clk = of_clk_get_by_name(np, "cpu_g");
+   if (IS_ERR(priv->cpu_clk)) {
+ 

[PATCH v3 11/15] cpufreq: tegra124: Add device tree bindings

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

The cpufreq driver for Tegra124 will be a different one than the old
Tegra20 cpufreq driver (tegra-cpufreq), which does not use the device
tree.

Signed-off-by: Tuomas Tynkkynen 
---
v3: vdd-cpu-supply property added
---
 .../bindings/cpufreq/tegra124-cpufreq.txt  | 44 ++
 1 file changed, 44 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt

diff --git a/Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt 
b/Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt
new file mode 100644
index 000..b1669fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt
@@ -0,0 +1,44 @@
+Tegra124 CPU frequency scaling driver bindings
+--
+
+Both required and optional properties listed below must be defined
+under node /cpus/cpu@0.
+
+Required properties:
+- clocks: Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+  - cpu_g: Clock mux for the fast CPU cluster.
+  - cpu_lp: Clock mux for the low-power CPU cluster.
+  - pll_x: Fast PLL clocksource.
+  - pll_p: Auxiliary PLL used during fast PLL rate changes.
+  - dfll: Fast DFLL clocksource that also automatically scales CPU voltage.
+- vdd-cpu-supply: Regulator for CPU voltage
+
+Optional properties:
+- clock-latency: Specify the possible maximum transition latency for clock,
+  in unit of nanoseconds.
+
+Example:
+
+cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a15";
+   reg = <0>;
+
+   clocks = <&tegra_car TEGRA124_CLK_CCLK_G>,
+<&tegra_car TEGRA124_CLK_CCLK_LP>,
+<&tegra_car TEGRA124_CLK_PLL_X>,
+<&tegra_car TEGRA124_CLK_PLL_P>,
+<&dfll>;
+   clock-names = "cpu_g", "cpu_lp", "pll_x", "pll_p", "dfll";
+   clock-latency = <30>;
+   vdd-cpu-supply: <&vdd_cpu>;
+   };
+
+   <...>
+};
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 07/15] clk: tegra: Save/restore CCLKG_BURST_POLICY on suspend

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

Save and restore this register since the LP1 restore assembly routines
fiddle with it. Otherwise the CPU would keep running on PLLX after
resume from suspend even when DFLL was the original clocksource.

Signed-off-by: Tuomas Tynkkynen 
---
 drivers/clk/tegra/clk-tegra124.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/clk/tegra/clk-tegra124.c b/drivers/clk/tegra/clk-tegra124.c
index cc81eab..4b12ddc 100644
--- a/drivers/clk/tegra/clk-tegra124.c
+++ b/drivers/clk/tegra/clk-tegra124.c
@@ -89,6 +89,8 @@
 #define PMC_PLLM_WB0_OVERRIDE 0x1dc
 #define PMC_PLLM_WB0_OVERRIDE_2 0x2b0
 
+#define CCLKG_BURST_POLICY 0x368
+
 #define UTMIP_PLL_CFG2 0x488
 #define UTMIP_PLL_CFG2_STABLE_COUNT(x) (((x) & 0x) << 6)
 #define UTMIP_PLL_CFG2_ACTIVE_DLY_COUNT(x) (((x) & 0x3f) << 18)
@@ -121,6 +123,8 @@
 #ifdef CONFIG_PM_SLEEP
 static struct cpu_clk_suspend_context {
u32 clk_csite_src;
+   u32 cclkg_burst;
+   u32 cclkg_divider;
 } tegra124_cpu_clk_sctx;
 #endif
 
@@ -1318,12 +1322,22 @@ static void tegra124_cpu_clock_suspend(void)
tegra124_cpu_clk_sctx.clk_csite_src =
readl(clk_base + CLK_SOURCE_CSITE);
writel(3 << 30, clk_base + CLK_SOURCE_CSITE);
+
+   tegra124_cpu_clk_sctx.cclkg_burst =
+   readl(clk_base + CCLKG_BURST_POLICY);
+   tegra124_cpu_clk_sctx.cclkg_divider =
+   readl(clk_base + CCLKG_BURST_POLICY + 4);
 }
 
 static void tegra124_cpu_clock_resume(void)
 {
writel(tegra124_cpu_clk_sctx.clk_csite_src,
clk_base + CLK_SOURCE_CSITE);
+
+   writel(tegra124_cpu_clk_sctx.cclkg_burst,
+   clk_base + CCLKG_BURST_POLICY);
+   writel(tegra124_cpu_clk_sctx.cclkg_divider,
+   clk_base + CCLKG_BURST_POLICY + 4);
 }
 #endif
 
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 14/15] ARM: tegra: Add entries for cpufreq on Tegra124

[Tuomas Tynkkynen]

From: Tuomas Tynkkynen 

The Tegra124 cpufreq driver relies on certain clocks being present
in the /cpus/cpu@0 node.

Signed-off-by: Tuomas Tynkkynen 
---
 arch/arm/boot/dts/tegra124.dtsi | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index 8ff4332..17f2382 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -782,10 +782,19 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   cpu@0 {
+   cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0>;
+
+   clocks = <&tegra_car TEGRA124_CLK_CCLK_G>,
+<&tegra_car TEGRA124_CLK_CCLK_LP>,
+<&tegra_car TEGRA124_CLK_PLL_X>,
+<&tegra_car TEGRA124_CLK_PLL_P>,
+<&dfll>;
+   clock-names = "cpu_g", "cpu_lp", "pll_x", "pll_p", 
"dfll";
+   /* FIXME: what's the actual transition time? */
+   clock-latency = <30>;
};
 
cpu@1 {
-- 
1.8.1.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] arm: Do not overwrite __machine_arch_type

[Peng Fan]

If using DT_MACHINE_START when enabled CONFIG_OF, the nr of mdesc is ~0.
The value of __machine_arch_type is passsed from bootloader using reigster
r1, and assigned in head-common.S. Remove this line to avoid overwrite it.

Signed-off-by: Peng Fan 
---
 arch/arm/kernel/devtree.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 11c54de..3a04486 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -243,8 +243,5 @@ const struct machine_desc * __init 
setup_machine_fdt(unsigned int dt_phys)
 
early_init_dt_scan_nodes();
 
-   /* Change machine number to match the mdesc we're using */
-   __machine_arch_type = mdesc->nr;
-
return mdesc;
 }
-- 
1.8.4


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: AGENCY FOR SHIPPING AND CUSTOM BROKER

[RAIN]

Dear Sir,
Good day!
 
This is Rain Mao from Shenzhen Top Way International Forwarding Co.,Ltd in 
China. 

We interest & expect to establish the cooperation relationship with your esteem 
company.

This is the first letter you recieve from me.Could you please help me to 
forward my contact
to the person whom manage the shipment?
So that  I could share the lastest rates from China to AUSTRIALIA, Thanks! 
 
Our competitive advantages :
l  FCL&LCL freight china to all over the world. 
l  DHL,UPS,FEDEX courier door to door price 30% discount to worldwide
l  Door to door sea freight cargo.
l  Free samples & small orders consolidation service.
l  15 days free warehousing.
 
Any question and instruction will be highly appreciated.
Let's talk more about the details.

Thanks&Best regards
 
Ms.Rain 
Shenzhen Top Way International Forwarding Co., Ltd
MOBILE & WHATSAPP:+86-13528787227
TEL:+86-755-89367755-802
Email:r...@topwayfreight.com
Skype:rain-blestocean
QQ:840626628
website: topwayfreight.com
http://hkkingway.en.alibaba.com

Re: Static build of libtraceevent failing on ubuntu13 x86_64

[Namhyung Kim]

Hi Arnaldo,

On Wed, 13 Aug 2014 19:54:38 -0300, Arnaldo Carvalho de Melo wrote:
> Hi guys,
>
>   Have you ever stumbled on this?
>
>   It is the only target breaking when I do a test build of perf + 
> libtraceevent
> on several distros/arches, the command is:
>
> $ make -C tools/perf build-test
>
> Distro is ubuntu12
>
> acme@ubuntu13:~/git/linux$ cat /etc/debian_version 
> wheezy/sid
> acme@ubuntu13:~/git/linux$ uname -a
> Linux ubuntu13 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06 UTC 2014 
> x86_64 x86_64 x86_64 GNU/Linux
>
> - Arnaldo
>
> - make_static: cd . && make -f Makefile DESTDIR=/tmp/tmp.18qUa2nzwd 
> LDFLAGS=-static
> cd . && make -f Makefile DESTDIR=/tmp/tmp.18qUa2nzwd LDFLAGS=-static
[SNIP]
>   LINK perf
> /home/acme/git/linux/tools/lib/traceevent/libtraceevent.a(event-plugin.o): In 
> function `load_plugin':
> /home/acme/git/linux/tools/lib/traceevent/event-plugin.c:256: warning: Using 
> 'dlopen' in statically linked applications requires at runtime the shared 
> libraries from the glibc version used for linking

Hmm.. this one is actually related to the libtraceevent.  It seems glibc
(and libdl) emits warnings if a static build try to link to the libdl
functions (for obvious reason) and/or nss functions (which might use
libdl).

I found this article [1] but couldn't find how can suppress them.  But
as it's for loading plugins at runtime, we can disable the plugin
support for static builds if we really nervous about the warnings.


[1] http://www.airs.com/blog/archives/54



> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libaudit.a(libaudit.o):
>  In function `audit_rule_fieldpair_data':
> (.text+0x191b): warning: Using 'getgrnam' in statically linked applications 
> requires at runtime the shared libraries from the glibc version used for 
> linking
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/libaudit.a(libaudit.o):
>  In function `audit_rule_fieldpair_data':
> (.text+0x1978): warning: Using 'getpwnam' in statically linked applications 
> requires at runtime the shared libraries from the glibc version used for 
> linking
> libperf.a(target.o): In function `target__parse_uid':
> /home/acme/git/linux/tools/perf/util/target.c:79: warning: Using 'getpwnam_r' 
> in statically linked applications requires at runtime the shared libraries 
> from the glibc version used for linking
> /home/acme/git/linux/tools/perf/util/target.c:91: warning: Using 'getpwuid_r' 
> in statically linked applications requires at runtime the shared libraries 
> from the glibc version used for linking
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libnuma.a(affinity.o): In 
> function `affinity_ip':
> (.text+0x765): warning: Using 'getaddrinfo' in statically linked applications 
> requires at runtime the shared libraries from the glibc version used for 
> linking

Likewise.


> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libbfd.a(compress.o): In 
> function `bfd_compress_section_contents':
> /build/buildd/binutils-2.23.52.20130913/builddir-single/bfd/../../bfd/compress.c:100:
>  undefined reference to `compressBound'
> /build/buildd/binutils-2.23.52.20130913/builddir-single/bfd/../../bfd/compress.c:106:
>  undefined reference to `compress'
> /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libbfd.a(compress.o): In 
> function `decompress_contents':
> /build/buildd/binutils-2.23.52.20130913/builddir-single/bfd/../../bfd/compress.c:49:
>  undefined reference to `inflateInit_'
> /build/buildd/binutils-2.23.52.20130913/builddir-single/bfd/../../bfd/compress.c:56:
>  undefined reference to `inflate'
> /build/buildd/binutils-2.23.52.20130913/builddir-single/bfd/../../bfd/compress.c:59:
>  undefined reference to `inflateReset'
> /build/buildd/binutils-2.23.52.20130913/builddir-single/bfd/../../bfd/compress.c:61:
>  undefined reference to `inflateEnd'

This one is different and seems like linking with libbfd but without zlib?

Thanks,
Namhyung


> collect2: error: ld returned 1 exit status
> make[3]: *** [perf] Error 1
> make[2]: *** [all] Error 2
>   test: test -x ./perf
> make[1]: *** [make_static] Error 1
> make: *** [build-test] Error 2
> make: Leaving directory `/home/acme/git/linux/tools/perf'
>
> real  14m52.077s
> user  39m36.668s
> sys   6m27.970s
> acme@ubuntu13:~/git/linux$ 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] fs: Initialize mountpoint list head in new_mountpoint()

[Murilo Opsfelder Araujo]

The commit 89f7ca1af15bdfe7a6aed343032a84af2a69f736 makes next-20140818
to panic because mountpoint list head was not initialized.  Initializing
it with NULL fixes the problem.

commit 89f7ca1af15bdfe7a6aed343032a84af2a69f736
Author: Eric W. Biederman 
Date:   Sun Sep 22 19:37:01 2013 -0700

vfs: Keep a list of mounts on a mount point

To spot any possible problems call BUG if a mountpoint
is put when it's list of mounts is not empty.

AV: use hlist instead of list_head

Signed-off-by: Murilo Opsfelder Araujo 
---
 fs/namespace.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/namespace.c b/fs/namespace.c
index 1a2bbef..1a00bac 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -736,6 +736,7 @@ static struct mountpoint *new_mountpoint(struct dentry 
*dentry)
return ERR_PTR(ret);
}
 
+   INIT_HLIST_HEAD(&mp->m_list);
mp->m_dentry = dentry;
mp->m_count = 1;
hlist_add_head(&mp->m_hash, chain);
-- 
2.1.0.rc2.234.ge4c5f60

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mtd: nand: stm_nand_bch: add new driver

[Brian Norris]

On Fri, Aug 01, 2014 at 10:27:25AM +0100, Lee Jones wrote:
> On Thu, 31 Jul 2014, Brian Norris wrote:
> > On Thu, Jul 31, 2014 at 05:47:09PM +0100, Lee Jones wrote:
> > > > >  arch/arm/boot/dts/stih41x-b2020.dtsi   |   40 +
> > > > 
> > > > This will need refreshed and sent as a separate patch, to go through the
> > > > appropriate ARM tree.
> > > 
> > > As above.
> > 
> > OK, if you're really planning to send a final git pull request, you'll
> > need to have this in a separate branch for them to take, then.
> 
> Of course.  Same goes with the DTS(I) changes.

PSA: make sure your patches will bisect if you're going to send so many.
I don't want to have to copy-and-paste my build results again.

> > > > (Related: Coverity caught a whole bunch of these type of bugs in the MTD
> > > > test modules. I have fixes queued up that I meant to test and submit
> > > > soon.)
> > > 
> > > I will attempt to play around with Coverity.
> > 
> > Good luck :) Coverity isn't always the easiest to get running
> > individually. You might have better luck (once your stuff is merged)
> 
> Sorry merged where?

To Linus's tree. Presumably that's what you're sending your patches to
me for? :)

Dave Jones runs a Coverity instance against mainline.

> > checking out the free service offered for open source projects through
> > github. There's a project instance set up for mainline:
> > 
> >   https://scan.coverity.com/projects/128?tab=overview
> 
> Thanks.  I'll have a play.
> 
> > > > > +/*
> > > > > + * Detect an erased page, tolerating and correcting up to a 
> > > > > specified number of
> > > > > + * bits at '0'.  (For many devices, it is now deemed within spec for 
> > > > > an erased
> > > > > + * page to include a number of bits at '0', either as a result of 
> > > > > read-disturb
> > > > > + * behaviour or 'stuck-at-zero' failures.)  Returns the number of 
> > > > > corrected
> > > > > + * bits, or a '-1' if we have exceeded the maximum number of bits at 
> > > > > '0' (likely
> > > > > + * to be a genuine uncorrectable ECC error).  In the latter case, 
> > > > > the data must
> > > > > + * be returned unmodified, in accordance with the MTD API.
> > > > > + */
> > > > > +static int check_erased_page(uint8_t *data, uint32_t page_size, int 
> > > > > max_zeros)
> > > > 
> > > > Another "check erased page" implementation? Sigh... it would be nice if
> > > > we could agree on a common implementation to share. My last attempt was
> > > > unsuccessful, since some drivers have some very odd requirements.
> > > > 
> > > > > +{
> > > > > + uint8_t *b = data;
> > > > > + int zeros = 0;
> > > > > + int i;
> > > > > +
> > > > > + for (i = 0; i < page_size; i++) {
> > > > > + zeros += hweight8(~*b++);
> > > > > + if (zeros > max_zeros)
> > > > > + return -1;
> > > > > + }
> > > > > +
> > > > > + if (zeros)
> > > > > + memset(data, 0xff, page_size);
> > > > 
> > > > It seems like you're not considering the spare area at all. What if this
> > > > is a mostly-blank page, with ECC data, but most of the bitflips are in
> > > > the spare area? Then you will "correct" this page to all 0xFF, not
> > > > noticing that this was really not a blank page at all.
> > > 
> > > I could really use Angus' advice on this one.  Although, I fear he may
> > > have disappeared into the cosmos.  If I remember correctly (I'm
> > > getting rusty on this now), this controller doesn't allow access to
> > > the spare area easily.  I think it's all handled automatically
> > > i.e. without intervention.
> > 
> > That's tough. It's pretty hard to support NAND without *any* access to
> > spare area.
> 
> I think we _can_ do it, via the second (Flex) interface, but it appears
> to be readonly and we only do so when initially scanning/building the
> BBTs.

Does your driver pass the MTD tests? (drivers/mtd/tests/)

> I'm not sure I follow your example precisely.  When you say that most
> of the bitflips are in the spare area, do you mean that there's usable
> data in there?

What I mean is that because ALL [*] data (in- and out-of-band) is used
by the error correction algorithm, then you need to use all of that data
when determining that a page is erased, not just the data that you see
in-band.

Consider this: you program a page with all 0xFF data, except for a
single byte of data. Then suppose your page experiences too many
bitflips in the spare area. When you try to read this page back, you
will experience an ECC error, and fall back to "checking for an erased
page." But if this algorithm only looks at the in-band data, it may see
mostly-0xFF, with fewer than 8 bits that are low. Because it ignored all
of the ECC parity data stored OOB, then your algorithm might falsely
declare your page "erased," when in fact it held data and is instead
truly uncorrectable.

This kind of subtle error might lead to silent corruption.

I haven't exactly seen this in practice, since most MTD users

[PATCH v2] ARM: dts: Add sdio0 and sdio1 to the rk3288

[Addy Ke]

This patch requires that 
land in order to compile.

Signed-off-by: Addy Ke 
---
Changes in v2:
- repost patch to match what's in Heiko's "wip/v3.18-next/dts" tree
  for the other dwmmc controllers
- add "cd" and "int" line, suggested by Doug Anderson
- fix up sdio1 configuration error 

 arch/arm/boot/dts/rk3288.dtsi | 86 +++
 1 file changed, 86 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 36be7bb..91576ae 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -88,6 +88,26 @@
status = "disabled";
};
 
+   sdio0: dwmmc@ff0d {
+   compatible = "rockchip,rk3288-dw-mshc";
+   clocks = <&cru HCLK_SDIO0>, <&cru SCLK_SDIO0>;
+   clock-names = "biu", "ciu";
+   fifo-depth = <0x100>;
+   interrupts = ;
+   reg = <0xff0d 0x4000>;
+   status = "disabled";
+   };
+
+   sdio1: dwmmc@ff0e {
+   compatible = "rockchip,rk3288-dw-mshc";
+   clocks = <&cru HCLK_SDIO1>, <&cru SCLK_SDIO1>;
+   clock-names = "biu", "ciu";
+   fifo-depth = <0x100>;
+   interrupts = ;
+   reg = <0xff0e 0x4000>;
+   status = "disabled";
+   };
+
emmc: dwmmc@ff0f {
compatible = "rockchip,rk3288-dw-mshc";
clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>;
@@ -508,6 +528,72 @@
};
};
 
+   sdio0 {
+   sdio0_clk: sdio0-clk {
+   rockchip,pins = <4 25 RK_FUNC_1 
&pcfg_pull_none>;
+   };
+
+   sdio0_cmd: sdio0-cmd {
+   rockchip,pins = <4 24 RK_FUNC_1 &pcfg_pull_up>;
+   };
+
+   sdio0_cd: sdio0-cd {
+   rockchip,pins = <4 26 RK_FUNC_1 &pcfg_pull_up>;
+   };
+
+   sdio0_pwr: sdio0-pwr {
+   rockchip,pins = <4 28 RK_FUNC_1 &pcfg_pull_up>;
+   };
+
+   sdio0_int: sdio0-int {
+   rockchip,pins = <4 30 RK_FUNC_1 &pcfg_pull_up>;
+   };
+
+   sdio0_bus1: sdio0-bus1 {
+   rockchip,pins = <4 20 RK_FUNC_1 &pcfg_pull_up>;
+   };
+
+   sdio0_bus4: sdio0-bus4 {
+   rockchip,pins = <4 20 RK_FUNC_1 &pcfg_pull_up>,
+   <4 21 RK_FUNC_1 &pcfg_pull_up>,
+   <4 22 RK_FUNC_1 &pcfg_pull_up>,
+   <4 23 RK_FUNC_1 &pcfg_pull_up>;
+   };
+   };
+
+   sdio1 {
+   sdio1_clk: sdio1-clk {
+   rockchip,pins = <4 7 RK_FUNC_4 &pcfg_pull_none>;
+   };
+
+   sdio1_cmd: sdio1-cmd {
+   rockchip,pins = <4 6 RK_FUNC_4 &pcfg_pull_up>;
+   };
+
+   sdio1_cd: sdio1-cd {
+   rockchip,pins = <3 28 RK_FUNC_4 &pcfg_pull_up>;
+   };
+
+   sdio1_pwr: sdio1-pwr {
+   rockchip,pins = <4 9 RK_FUNC_4 &pcfg_pull_up>;
+   };
+
+   sdio1_int: sdio1-int {
+   rockchip,pins = <3 31 RK_FUNC_4 &pcfg_pull_up>;
+   };
+
+   sdio1_bus1: sdio1-bus1 {
+   rockchip,pins = <3 24 RK_FUNC_4 &pcfg_pull_up>;
+   };
+
+   sdio1_bus4: sdio1-bus4 {
+   rockchip,pins = <3 24 RK_FUNC_4 &pcfg_pull_up>,
+   <3 25 RK_FUNC_4 &pcfg_pull_up>,
+   <3 26 RK_FUNC_4 &pcfg_pull_up>,
+   <3 27 RK_FUNC_4 &pcfg_pull_up>;
+   };
+   };
+
emmc {
emmc_clk: emmc-clk {
rockchip,pins = <3 18 RK_FUNC_2 
&pcfg_pull_none>;
-- 
1.8.3.2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i8k: Don't revert affinity in i8k_smm

[Guenter Roeck]

On Tue, Aug 19, 2014 at 09:19:55AM +1000, Con Kolivas wrote:
> As a followup to this discussion:
> 
> On Tue, 15 Jul 2014 08:01:13 PM Sam Asadi wrote:
> > Commit f36fdb9f0266 (i8k: Force SMM to run on CPU 0) adds support
> > for multi-core CPUs to the driver. Unfortunately, that causes it
> > to fail loading if compiled without SMP support, at least on
> > 32 bit kernels. Kernel log shows "i8k: unable to get SMM Dell
> > signature", and function i8k_smm is found to return -EINVAL.
> > 
> > Testing revealed that the culprit is the missing return value check
> > of set_cpus_allowed_ptr.
> 
> It appears that the original commit f36fdb9f0266 changes the affinity for the 
> duration of i8k_smm function and then unconditionally reverts the affinity to 
> the old cpu mask regardless of whether the function succeeds or fails. As 
> this 
> must run on CPU 0 at all times it does not make sense to revert the affinity 
> at 
> the end of the function. Proposed patch attached.
> 
Sorry, I must have missed the rest of the discussion. What problem is this patch
supposed to fix ? Or, in other words, is there a problem with the current code ?
I also don't really understand the argument above. Why does it not make sense to
revert to the original affinity ? After all, only the SMM call must run on CPU
0. Why does it not make sense to let the rest of the code run on another CPU ?

Thanks,
Guenter

> Signed-off-by: Con Kolivas 
> 
> ---
>  drivers/char/i8k.c |6 --
>  1 file changed, 6 deletions(-)
> 
> Index: linux-3.16-ck1/drivers/char/i8k.c
> ===
> --- linux-3.16-ck1.orig/drivers/char/i8k.c2014-08-12 14:07:49.0 
> +1000
> +++ linux-3.16-ck1/drivers/char/i8k.c 2014-08-19 09:09:57.939056696 +1000
> @@ -132,12 +132,8 @@ static int i8k_smm(struct smm_regs *regs
>  {
>   int rc;
>   int eax = regs->eax;
> - cpumask_var_t old_mask;
>  
>   /* SMM requires CPU 0 */
> - if (!alloc_cpumask_var(&old_mask, GFP_KERNEL))
> - return -ENOMEM;
> - cpumask_copy(old_mask, ¤t->cpus_allowed);
>   rc = set_cpus_allowed_ptr(current, cpumask_of(0));
>   if (rc)
>   goto out;
> @@ -203,8 +199,6 @@ static int i8k_smm(struct smm_regs *regs
>   rc = -EINVAL;
>  
>  out:
> - set_cpus_allowed_ptr(current, old_mask);
> - free_cpumask_var(old_mask);
>   return rc;
>  }
>  
> 
> -- 
> -ck
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 1/2] PM: Print pending wakeup IRQ preventing suspend to dmesg

[Todd Poynor]

On Fri, Aug 1, 2014 at 9:30 AM, Amit Pundir  wrote:
> From: Todd Poynor 
>
> Currently when a pending wakeup irq stops suspend, it can be difficult
> to determine why suspend was prevented and which IRQ was actually
> responsible.
>
> In order to help debug these situations, this patch prints the IRQ
> number and action name of that pending wakeup irq which prevents suspend.
> This patch comes from the Android patch set, where its been used to debug
> suspend problems.

This info is sometimes useful to debugging Android suspend / battery
life problems, such as to detect a driver that is failing to service
or clear a wakeup interrupt condition.

In general, we intend to fold reporting of suspend abort reasons
(wakeup IRQ pending, wakelock grabbed, task refusing to freeze...)
into the wakeup reason reporting API to userspace previously discussed
on the linux-pm list (and also revive discussion of how to rework that
for mainline acceptance soon).

Thanks,


Todd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] KVM: vmx: fix ept reserved bits for 1-GByte page

[Wanpeng Li]

Hi Paolo,
On Mon, Aug 18, 2014 at 12:18:59PM +0200, Paolo Bonzini wrote:
>Il 18/08/2014 11:50, Wanpeng Li ha scritto:
>> EPT misconfig handler in kvm will check which reason lead to EPT 
>> misconfiguration after vmexit. One of the reasons is that an EPT 
>> paging-structure entry is configured with settings reserved for 
>> future functionality. However, the handler can't identify if 
>> paging-structure entry of reserved bits for 1-GByte page are 
>> configured, since PDPTE which point to 1-GByte page will reserve 
>> bits 29:12 instead of bits 7:3 which are reserved for PDPTE that 
>> references an EPT Page Directory. This patch fix it by reserve 
>> bits 29:12 for 1-GByte page. 
>> 
>> Signed-off-by: Wanpeng Li 
>> ---
>>  arch/x86/kvm/vmx.c | 14 ++
>>  1 file changed, 10 insertions(+), 4 deletions(-)
>> 
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index bfe11cf..71cbee5 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -5521,9 +5521,14 @@ static u64 ept_rsvd_mask(u64 spte, int level)
>>  for (i = 51; i > boot_cpu_data.x86_phys_bits; i--)
>>  mask |= (1ULL << i);
>>  
>> -if (level > 2)
>> -/* bits 7:3 reserved */
>> -mask |= 0xf8;
>> +if (level > 2) {
>
>level can be 4 here.  You have to return 0xf8 for level == 4.
>
>The same "if" statement then can cover both 2MB and 1GB pages, like
>
>if (spte & (1ULL << 7))
>/* 1GB/2MB page, bits 29:12 or 20:12 reserved 
> respectively */
>mask |= (PAGE_SIZE << ((level - 1) * 9)) - PAGE_SIZE;
>else
>/* bits 6:3 reserved */
>mask |= 0x78;
>
>> -if (level == 1 || (level == 2 && (spte & (1ULL << 7 {
>> +if (level == 1 || ((level == 3 || level == 2)
>> +&& (spte & (1ULL << 7 {
>
>This condition can be simplified by checking the return value of ept_rsvd_mask.
>If it includes 0x38, this is a large page.  Otherwise it is a leaf page and
>you can go down the "if".

As you know, 5:3 bits which used for EPT MT are not reserved bits, so 
I fail to understand why check the return value of ept_rsvd_mask and 
it's a large page if includes 0x38. Could you eplain in more details? ;-)

Regards,
Wanpeng Li 

>
>Paolo
>
>>  u64 ept_mem_type = (spte & 0x38) >> 3;
>>  
>>  if (ept_mem_type == 2 || ept_mem_type == 3 ||
>> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH 2/2] PM: Suspend: Print wall time at suspend entry and exit

[Todd Poynor]

> Existing printk timestamps in a dmesg only log suspend activities
> (e.g. filesystem syncs, freezing/unfreezing tasks etc) while the
> system has already started to enter/exit the suspend state. Sometimes
> it is handy to have suspend entry/exit overhead information while
> debugging suspend issues. This patch print markers with wall
> timestamps at suspend Entry and Exit in the kernel log. These
> timestamps can be used to compute how long the system spent in
> low-power suspend state plus the entry/exit overhead.
>
> This patch comes from the Android patch set, where its been used to
> help diagnose battery life problems in various Android-based devices.

Thanks Amit.  For this patch, we're actually moving away from
primarily analyzing the kernel log of suspend times, instead logging
this info via userspace.  Android is now using the wakeup_count
suspend interface (previously autosleep was employed), allowing
userspace to be informed whenever suspend is entered and resumed.  The
Android batterystats service logs timestamps for these, along with the
wakeup reason info previously discussed on the linux-pm list.  But it
still is occasionally useful to see the suspend times when debugging
problems based on the kernel log.


Todd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] earlyprintk: re-enable earlyprintk calling early_param

[Keun-O Park]

FYI only if you missed my previous 2 replies which didn't reach the
mailing list.
Thanks.



On Mon, Aug 18, 2014 at 12:13 PM, Sahara  wrote:
>
> 2014년 08월 16일 03:34, Rusty Russell 쓴 글:
>
>> kpark3...@gmail.com writes:
>>>
>>> From: Sahara 
>>>
>>> Although there are many obs_kernel_param and its names are
>>> earlyprintk and also EARLY_PRINTK is also enabled, we could not
>>> see the early_printk output properly until now. This patch
>>> considers earlycon as well as earlyprintk.
>>
>> Hmm, the initial "earlycon" hack slipped in when I wasn't looking.
>> I don't think we should extend it.
>>
>> Why not make the thing(s) you want early_param()s?
>>
>> Cheers,
>> Rusty.
>
> The earlycon and the earlyprintk are scattered and used in many
> architectures.
> It looks earlycon just could be a subset of earlyprintk.
> The earlycon is for uart specific, while the earlyprintk is to support vga,
> efi, xen, serial, and so on. Especially ARM uses earlyprintk in many places.
> And, I am not sure if this is a good chance to replace all the earlyprintk
> with the earlycon. As of now, it's fair for both earlycon and earlyprintk.
> Or perhaps removing case#2, see in my previous email to Andrew Morton, is
> better?, so users be forced to specify earlycon and earlyprintk in cmdline
> if they want to see early_printk() output.
>
> Thanks.
>
> Best Regards,
> Sahara.
>
>
>>
>>> --- a/init/main.c
>>> +++ b/init/main.c
>>> @@ -426,7 +426,8 @@ static int __init do_early_param(char *param, char
>>> *val, const char *unused)
>>> for (p = __setup_start; p < __setup_end; p++) {
>>> if ((p->early && parameq(param, p->str)) ||
>>> (strcmp(param, "console") == 0 &&
>>> -strcmp(p->str, "earlycon") == 0)
>>> +((strcmp(p->str, "earlycon") == 0) ||
>>> +(strcmp(p->str, "earlyprintk") == 0)))
>>> ) {
>>> if (p->setup_func(val) != 0)
>>> pr_warn("Malformed early option '%s'\n",
>>> param);
>>> --
>>> 1.7.9.5
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mtd: nand: stm_nand_bch: add new driver

[Brian Norris]

On Wed, Aug 06, 2014 at 02:32:18AM +0530, pe...@pek-sem.com wrote:
> On Tuesday 05 August 2014 07:53 PM, Lee Jones wrote:
> >On Thu, 03 Jul 2014, Gupta, Pekon wrote:
> + /* Load last page of block */
> + offs = (loff_t)block << chip->phys_erase_shift;
> + offs += mtd->erasesize - mtd->writesize;
> + if (bch_read_page(nandi, offs, buf) < 0) {
> >>
> >>*Important*: You shouldn't call internal functions directly here..
> >>Instead use chip->_read() OR mtd-read() that will:

I'm not sure exactly what you're saying in the above line (chip->_read()
is not a function, and and mtd-read() is syntactically incorrect),
but...

You most certainly do *not* want to call mtd->_read() directly (or any
of the callbacks prefixed with underscores). That is one of the main
purposes of:

commit 3c3c10bba1e4ccb75b41442e45c1a072f6cded19
Author: Artem Bityutskiy 
Date:   Mon Jan 30 14:58:32 2012 +0200

mtd: add leading underscore to all mtd functions

> >>- keep this code independent of ECC modes added in your driver
> >>in future.
> >>- implicitly handle updating mtd->ecc_stat (like ecc_failed,
> >>bits_corrected).
> >>- implicitly take care of address alignments checks and offset
> >>calculations.
> >>
> >> >>bch_read_page())
> >
> >Yourself and Brian seem to disagree on this point.  Which is correct?

I think you've worked out a decent solution in your latest series, but
a few of the guiding principles:

 * BBT code can rely on generic NAND implementation details (e.g.,
   chip->options), but it can also act as an MTD user (i.e., use the
   mtd_*() APIs)

 * It should not rely on details of the particular NAND driver (e.g.,
   calling your ST bch_read_page())

 * Look at similar code and try to follow its pattern where it makes
   sense. So while nand_bbt.c is not a shining example in all regards, I
   think it does OK in terms of some of the key points of layering.

> + /* Is block already considered bad? (will also catch
> invalid offsets) */
> + ret = mtd_block_isbad(mtd, offs);
> >>>
> >>>You're violating some of the layering here; the low-level driver
> >>>probably shouldn't be calling the high-level mtd_*() APIs. On
> >>>a similar
> >>>note, I'm not 100% confident that the nand_base/nand_bbt
> >>>separation is
> >>>written cleanly enough for easy maintenance of your nand_base
> >>>+ ST BBT
> >>>code in parallel. I might need a second look at that, and I think
> >>>modularizing your BBT code to a separate file could help ease
> >>>this a
> >>>little.
> >
> >... here is the converse argument.

I think I clarified this one; I misspoke about the mtd_*() APIs.

> I think somewhere in earlier comments, Brian also supported
> to use high-level function like mtd_read(). Also, nand_bbt.c
> itself uses 'mtd_read(), mtd_read_oob() and mtd_write_oob()
> at many places. So I'll let Brain decide here.
> But having low-level function will add redundant code for
> re-checking and aligning the addresses boundaries to block
> and page/sector sizes.

Not all checks are redundant. It's redundant to have the direct
descendant doing the same checks that the parent does, like:

  mtd_read() (checks boundaries)
  |_ mtd->_read() (e.g., nand_read())

So nand_read() and nand_do_read_ops() don't need the checking.

But for a BBT implementation, it can help to make sure that its
page/block/etc. arithmetic fits the right bounds when it ends up
deciding to scan a block.

Now, it still may be easy to prove that the checks are
redundant/unnecessary for correctly-written code, but if the layering
makes sense, then it still may be a better choice to simply use the
high-level, self-checking API than to try to dig deeper. For instance,
I'm pretty sure UBI does some checks to make sure it's not reading off
the end of an MTD, but it still calls mtd_read() because it's The Right
Thing (TM).

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v15 7/7] mm: Don't split THP page when syscall is called

[Rik van Riel]

On 08/17/2014 08:17 PM, Minchan Kim wrote:

We don't need to split THP page when MADV_FREE syscall is
called. It could be done when VM decide really frees it so
we could avoid unnecessary THP split.

Cc: Andrea Arcangeli 
Acked-by: Kirill A. Shutemov 
Signed-off-by: Minchan Kim 


Acked-by: Rik van Riel 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v15 2/7] x86: add pmd_[dirty|mkclean] for THP

[Rik van Riel]

On 08/17/2014 08:17 PM, Minchan Kim wrote:

MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
overwrite of the contents since MADV_FREE syscall is called for
THP page.

This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
support.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Acked-by: Zhang Yanfei 
Acked-by: Kirill A. Shutemov 
Signed-off-by: Minchan Kim 


Acked-by: Rik van Riel 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 7/8] mtd: nand: stm_nand_bch: add support for ST's BCH NAND controller

[Brian Norris]

On Mon, Aug 18, 2014 at 11:31:58AM +0100, Lee Jones wrote:
...
> +/* Derive Hamming-FLEX timing register values from 'nand_sdr_timings' data */
> +static void flex_calc_timing_registers(const struct nand_sdr_timings *spec,
> +int tCLK, int relax,
> +uint32_t *ctl_timing,
> +uint32_t *wen_timing,
> +uint32_t *ren_timing)
> +{
> + int tMAX_HOLD;
> + int n_ctl_setup;
> + int n_ctl_hold;
> + int n_ctl_wb;
> +
> + int tMAX_WEN_OFF;
> + int n_wen_on;
> + int n_wen_off;
> +
> + int tMAX_REN_OFF;
> + int n_ren_on;
> + int n_ren_off;
> +
> + /*
> +  * CTL_TIMING
> +  */
> +
> + /*  - SETUP */
> + n_ctl_setup = (PICO_TO_MILI(spec->tCLS_min - spec->tWP_min)
> ++ tCLK - 1)/tCLK;

Can you add spaces around the '/'? It helps readability. (This is
repeated throughout.)

> + if (n_ctl_setup < 1)
> + n_ctl_setup = 1;
> + n_ctl_setup += relax;

It's been discussed that many drivers probably want a simplified version
of struct nand_sdr_timings where some of these computations are done
already. As we haven't developed such a simplification yet, I'm fine
taking your computations as-is. If nothing else, they serve as a
reference for a later simplification. (Just FYI.)

> +
> + /*  - HOLD */
> + tMAX_HOLD = spec->tCLH_min;
> + if (spec->tCH_min > tMAX_HOLD)
> + tMAX_HOLD = spec->tCH_min;
> + if (spec->tALH_min > tMAX_HOLD)
> + tMAX_HOLD = spec->tALH_min;
> + if (spec->tDH_min > tMAX_HOLD)
> + tMAX_HOLD = spec->tDH_min;
> + n_ctl_hold = (PICO_TO_MILI(tMAX_HOLD) + tCLK - 1)/tCLK + relax;
> +
> + /*  - CE_deassert_hold = 0 */
> +
> + /*  - WE_high_to_RBn_low */
> + n_ctl_wb = (PICO_TO_MILI(spec->tWB_max) + tCLK - 1)/tCLK;
> +
> + *ctl_timing = ((n_ctl_setup & 0xff) |
> +(n_ctl_hold & 0xff) << 8 |
> +(n_ctl_wb & 0xff) << 24);
> +
> + /*
> +  * WEN_TIMING
> +  */
> +
> + /*  - ON */
> + n_wen_on = (PICO_TO_MILI(spec->tWH_min) + tCLK - 1)/tCLK + relax;
> +
> + /*  - OFF */
> + tMAX_WEN_OFF = spec->tWC_min - spec->tWH_min;
> + if (spec->tWP_min > tMAX_WEN_OFF)
> + tMAX_WEN_OFF = spec->tWP_min;
> + n_wen_off = (PICO_TO_MILI(tMAX_WEN_OFF) + tCLK - 1)/tCLK + relax;
> +
> + *wen_timing = ((n_wen_on & 0xff) |
> +(n_wen_off & 0xff) << 8);
> +
> + /*
> +  * REN_TIMING
> +  */
> +
> + /*  - ON */
> + n_ren_on = (PICO_TO_MILI(spec->tREH_min) + tCLK - 1)/tCLK + relax;
> +
> + /*  - OFF */
> + tMAX_REN_OFF = spec->tRC_min - spec->tREH_min;
> + if (spec->tRP_min > tMAX_REN_OFF)
> + tMAX_REN_OFF = spec->tRP_min;
> + if (spec->tREA_max > tMAX_REN_OFF)
> + tMAX_REN_OFF = spec->tREA_max;
> + n_ren_off = (PICO_TO_MILI(tMAX_REN_OFF) + tCLK - 1)/tCLK + 1 + relax;
> +
> + *ren_timing = ((n_ren_on & 0xff) |
> +(n_ren_off & 0xff) << 8);
> +}
> +
> +/* Derive BCH timing register values from 'nand_sdr_timings' data */
> +static void bch_calc_timing_registers(const struct nand_sdr_timings *spec,
> +   int tCLK, int relax,
> +   uint32_t *ctl_timing,
> +   uint32_t *wen_timing,
> +   uint32_t *ren_timing)
> +{
> + int tMAX_HOLD;
> + int n_ctl_setup;
> + int n_ctl_hold;
> + int n_ctl_wb;
> +
> + int n_wen_on;
> + int n_wen_off;
> + int wen_half_on;
> + int wen_half_off;
> +
> + int tMAX_REN_ON;
> + int tMAX_CS_DEASSERT;
> + int n_d_latch;
> + int n_telqv;
> + int n_ren_on;
> + int n_ren_off;
> +
> + /*
> +  * CTL_TIMING
> +  */
> +
> + /*  - SETUP */
> + if (spec->tCLS_min > spec->tWP_min)
> + n_ctl_setup = (PICO_TO_MILI(spec->tCLS_min - spec->tWP_min)
> ++ tCLK - 1)/tCLK;
> + else
> + n_ctl_setup = 0;
> + n_ctl_setup += relax;
> +
> + /*  - HOLD */
> + tMAX_HOLD = spec->tCLH_min;
> + if (spec->tCH_min > tMAX_HOLD)
> + tMAX_HOLD = spec->tCH_min;
> + if (spec->tALH_min > tMAX_HOLD)
> + tMAX_HOLD = spec->tALH_min;
> + if (spec->tDH_min > tMAX_HOLD)
> + tMAX_HOLD = spec->tDH_min;
> + n_ctl_hold = (PICO_TO_MILI(tMAX_HOLD) + tCLK - 1)/tCLK + relax;
> + /*  - CE_deassert_hold = 0 */
> +
> + /*  - WE_high_to_RBn_low */
> + n_ctl_wb = (PICO_TO_MILI(spec->tWB_max) + tCLK - 1)/tCLK;
> +
> + *ctl_timing = ((n_ctl_setup & 0xff) |
> +(n_ctl_hold & 0xff) << 8 |
> +(n_ctl_wb & 0xff) << 24);
> +
> + /*
> +  * WEN_TIMING
> +  */
> +
> + 

Re: [alsa-devel] [PATCH v3 2/2] mfd: arizona: Update DT binding to support INn_MODE init_data

[Inha Song]

Hi, Charles.
Thanks for your review.

On Mon, 18 Aug 2014 15:29:45 +0100
Charles Keepax  wrote:

> On Mon, Aug 18, 2014 at 08:00:09PM +0900, Inha Song wrote:
> > This patch update DT binding to support INn_MODE init_data. Each
> > input signal path can be configurated either as a Analogue or
> > Digital using the INn_MODE registers.
> > 
> > Signed-off-by: Inha Song 
> > ---
> >  Documentation/devicetree/bindings/mfd/arizona.txt | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt 
> > b/Documentation/devicetree/bindings/mfd/arizona.txt
> > index 5c7e723..0064b21 100644
> > --- a/Documentation/devicetree/bindings/mfd/arizona.txt
> > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt
> > @@ -42,6 +42,14 @@ Optional properties:
> >  the chip default will be used.  If present exactly five values must
> >  be specified.
> >  
> > +  - wlf,inmode : A list of INn_MODE register values, where n is the number
> > +of input signals. Each input signal path can be configurated either as 
> > a
> > +Analogue or Digital using the INn_MODE registers. If absent, INn_MODE
> 
> I would replace the second sentence here with something like
> "Valid values are 0 (Differential), 1 (Single-ended) and 2 (Digital
> Microphone)."
> 

OK, I will fix it like this:

- wlf,inmode : A list of INn_MODE register values, where n is the number
  of input signals. Valid values are 0 (Differential), 1 (Single-ended) and
  2 (Digital Microphone). If absent, INn_MODE registers.

Best regards,
Inha Song.

> Thanks,
> Charles
> 
> > +registers set to 0 by default. If present, values must be specified 
> > less
> > +than or equal to the number of input singals. If values less than the
> > +number of input signals, elements that has not been specifed are set 
> > to 0
> > +by default.
> > +
> >- DCVDD-supply, MICVDD-supply : Power supplies, only need to be 
> > specified if
> >  they are being externally supplied. As covered in
> >  Documentation/devicetree/bindings/regulator/regulator.txt
> > -- 
> > 2.0.0.390.gcb682f8
> > 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] memory-hotplug: add sysfs zones_online_to attribute

[Zhang Zhen]

On 2014/8/19 5:48, David Rientjes wrote:
> On Wed, 13 Aug 2014, Zhang Zhen wrote:
> 
>> Currently memory-hotplug has two limits:
>> 1. If the memory block is in ZONE_NORMAL, you can change it to
>> ZONE_MOVABLE, but this memory block must be adjacent to ZONE_MOVABLE.
>> 2. If the memory block is in ZONE_MOVABLE, you can change it to
>> ZONE_NORMAL, but this memory block must be adjacent to ZONE_NORMAL.
>>
>> With this patch, we can easy to know a memory block can be onlined to
>> which zone, and don't need to know the above two limits.
>>
>> Updated the related Documentation.
>>
>> Change v1 -> v2:
>> - optimize the implementation following Dave Hansen's suggestion
>>
>> Signed-off-by: Zhang Zhen 
> 
> linux-next build failure:
> 
> drivers/built-in.o: In function `show_zones_online_to':
> memory.c:(.text+0x13ee09): undefined reference to `test_pages_in_a_zone'
> 
The function implementation in mm/memory_hotplug.c is only built if
CONFIG_MEMORY_HOTREMOVE is enabled.

A fix has been proposed.
http://ozlabs.org/~akpm/mmots/broken-out/memory-hotplug-add-sysfs-zones_online_to-attribute-fix-2.patch

Thanks!
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 02/12] PCI: OF: Parse and map the IRQ when adding the PCI device.

[Wei Yang]

On Mon, Aug 18, 2014 at 03:25:50PM +0100, Catalin Marinas wrote:
>...
>> Well, it will become necessary as old code gets dismantled and converted 
>> towards
>> this patchset. To give you an example that I'm familiar with, for arch/arm 
>> the
>> host bridge drivers have moved into drivers/pci/host, but they still 
>> depend/use
>> the bios32 infrastructure that takes care of setting up the irq. When they 
>> switch
>> to my version they would have to go and debug the "irq not being assigned" 
>> issue
>> and it is quite likely that some of the people doing the conversion will 
>> complain
>> about my code rather than understanding the issue. What I'm trying to do is 
>> to
>> make switching to my patchset as painless as possible, with a cleanup to 
>> remove
>> redundant operations coming after the switchover.
>
>While the goal is fine, until we see a common pattern for what needs to
>go into pcibios_add_device() I think we should have an arm64-specific
>implementation (and probably an arm32 specific one as well). I can see
>powerpc uses it for setting the DMA ops. Would we have a similar need on
>arm64 to choose between coherent and non-coherent dma_ops?

Liviu,

I have the same feeling with Catalin. An arm64-specific implementation of
pcibios_add_device() would be better.

No more other concerns from my side.

>
>Also at some point we'll get ACPI support, so I'm not sure what we do
>with assigning the dev->irq here but definitely of_* functions won't
>work.
>
>-- 
>Catalin

-- 
Richard Yang
Help you, Help me

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/5] softlockup: make detector be aware of task switch of processes hogging cpu

[Chai Wen]

On 08/19/2014 04:38 AM, Don Zickus wrote:

> On Mon, Aug 18, 2014 at 09:02:00PM +0200, Ingo Molnar wrote:
>>
>> * Don Zickus  wrote:
>>
>> So I agree with the motivation of this improvement, but 
>> is this implementation namespace-safe?
>
> What namespace are you worried about colliding with?  I 
> thought softlockup_ would provide the safety??  Maybe I 
> am missing something obvious. :-(

 I meant PID namespaces - a PID in itself isn't guaranteed 
 to be unique across the system.
>>>
>>> Ah, I don't think we thought about that.  Is there a better 
>>> way to do this?  Is there a domain id or something that can 
>>> be OR'd with the pid?
>>
>> What is always unique is the task pointer itself. We use pids 
>> when we interface with user-space - but we don't really do that 
>> here, right?
> 
> No, I don't believe so.  Ok, so saving 'current' and comparing that should
> be enough, correct?
> 


I am not sure of the safety about using pid here with namespace.
But as to the pointer of process, is there a chance that we got a 'historical'
address saved in the 'softlockup_warn_pid(or address)_saved' and the current
hogging process happened to get the same task pointer address?
If it never happens, I think the comparing of address is ok.

thanks
chai wen

> Cheers,
> Don
> .
> 



-- 
Regards

Chai Wen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/8] mtd: nand: Support for new DT NAND driver

[Brian Norris]

On Mon, Aug 18, 2014 at 11:31:51AM +0100, Lee Jones wrote:
> I believe all of your queries have either been answered or addressed
> and I am hoping this will be the last submission. :)

Sorry, no. I can't review code that doesn't compile, so I'm only now
getting to some of the review.

> This is v2 of the squashed submission.  v1 had a small typo which
> prevented the BBT code from being truly configurable.  This has now
> been rectified and build tested with and without MTD_NAND_STM_BCH_BBT
> support.

>From smatch:

  drivers/mtd/nand/stm_nand_bch.c:1556 stm_nand_bch_probe() error: we 
previously assumed 'bank' could be null (see line 1482) [smatch]

>From GCC (extra warnings):

  drivers/mtd/nand/stm_nand_dt.c:39:21: warning: no previous prototype for 
'stm_of_get_partitions_node' [-Wmissing-prototypes]
  drivers/mtd/nand/stm_nand_dt.c:68:5: warning: no previous prototype for 
'stm_of_get_nand_banks' [-Wmissing-prototypes]

Looks like you forgot to include .

And your code is not bisectable. I think patch 7 and 8 should be
reordered (with some tweaks, perhaps):

Bisectability test results for configuration 
"arm-multi_v7_defconfig,arm,arm-unknown-linux-gnueabi-"

Failed to build patch #7: 5936df30f5e1 mtd: nand: stm_nand_bch: add support for 
ST's BCH NAND controller
Configuration: "arm-multi_v7_defconfig, architecture arm".


In file included from include/linux/ftrace.h:20:0,
 from include/linux/perf_event.h:47,
 from kernel/sys.c:16:
arch/arm/include/asm/ftrace.h:48:21: warning: no previous prototype for 
'return_address' [-Wmissing-prototypes]
In file included from include/linux/ftrace.h:20:0,
 from include/linux/perf_event.h:47,
 from include/linux/ftrace_event.h:9,
 from kernel/module.c:21:
arch/arm/include/asm/ftrace.h:48:21: warning: no previous prototype for 
'return_address' [-Wmissing-prototypes]
kernel/module.c: In function 'add_usage_links':
kernel/module.c:1512:6: warning: variable 'nowarn' set but not used 
[-Wunused-but-set-variable]
drivers/mtd/nand/stm_nand_bch.c:26:36: fatal error: linux/mtd/stm_nand_bbt.h: 
No such file or directory
compilation terminated.
make[4]: *** [drivers/mtd/nand/stm_nand_bch.o] Error 1

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/