Re: [PATCH 1/1] Cpufreq: Keep cpufreq sysfs nodes across S2RAM/S2DISK when using intel_pstate driver.

[Lan Tianyu]

Sorry later response and just back from vacation.

On 2014年09月29日 16:20, Viresh Kumar wrote:
> But this change is buggy.. Because you are updating 'cpufreq_suspended'
> before actually stopping the governor, any calls to __cpufreq_governor()
> will be converted to NO-operations because of this in __cpufreq_governor():
> 
> /* Don't start any governor operations if we are entering suspend */
> if (cpufreq_suspended)
> return 0;
> 
> And so the governor's will never stop :(
> 
> So you need to keep the above line where it was :)
> 

Yes, you are right. Thanks for fixing it.
-- 
Best regards
Tianyu Lan
--
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 v1] Arm64: ASLR: fix text randomization

[Arun Chandran]

Hi Mark,

On Tue, Oct 7, 2014 at 7:13 PM, Mark Rutland  wrote:
>
> On Tue, Oct 07, 2014 at 01:40:28PM +0100, Arun Chandran wrote:
> > This is due to incorrect definition of ELF_ET_DYN_BASE. It
> > introduces randomization for text even if user does a "echo 0 >
> > /proc/sys/kernel/randomize_va_space"
>
> Interesting.
>
> It looks like this was a copy of what powerpc and s390 do (authors
> Cc'd), and the generic support came later. powerpc gained support in
> 501cb16d3cfdcca9 (powerpc: Randomise PIEs), but the generic support was
> enabled later in e39f560239984c30 (fs: binfmt_elf: create Kconfig
> variable for PIE randomization).
>

I did not understand why they need a special architecture randomize_et_dyn()
function to handle the situation.

I have tested PIE on arm and x86 (which don't have a randomize_et_dyn()) and
it works as expected.

>
> The policy of disabling PIE randomization was added in a3defbe5c337dbc6
> (binfmt_elf: fix PIE execution with randomization disabled), after the
> powerpc implementation, but before the x86 implementation was made
> generic.

Thought about extending the policy(a3defbe5c337dbc6) to arm64 by doing

#
diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
index 01d3aab..401b1e8 100644
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -127,6 +127,7 @@ typedef struct user_fpsimd_state elf_fpregset_t;
  */
 extern unsigned long randomize_et_dyn(unsigned long base);
 #define ELF_ET_DYN_BASE(randomize_et_dyn(2 * TASK_SIZE_64 / 3))
+#define ARM64_ELF_ET_CONST_BASE(2 * TASK_SIZE_64 / 3)

 /*
  * When the program starts, a1 contains a pointer to a function to be
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 29d4869..5115f80 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -406,5 +406,8 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)

 unsigned long randomize_et_dyn(unsigned long base)
 {
-   return randomize_base(base);
+   if (current->flags & PF_RANDOMIZE)
+   return randomize_base(base);
+   else
+   return ARM64_ELF_ET_CONST_BASE;
 }
##

then discarded it after seeing the same thing works on x86 and arm.
In arm64(and in ppc and s390) why we need a special randomize_et_dyn()?

>
>
> I wasn't able to spot where the randomness came from in the
> ARCH_BINFMT_ELF_RANDOMIZE_PIE case, so it's not clear to me if the
> generic implementation behaves identically other than disabling
> randomization when told to via proc.

I also don't know from where it is coming; but it works on arm and x86 :)
>
>
> Assuming it behaves similarly enough, it looks like arm64, powerpc, and
> s390 should all be moved over.
>
> >
> > Signed-off-by: Arun Chandran 
> > ---
> > This can be tested using the code below
> >
> > #include 
> >
> > int main(int argc, char *argv)
> > {
> > printf("main = %p\n", main);
> > return 0;
> > }
> >
> > * compile it possition independently
> >   aarch64-linux-gnu-gcc -fPIE -pie aslr.c -o aslr
> >
> > * run it on the target
> >
> >   # ./aslr
> >   main = 0x7f87138950
> >   # ./aslr
> >   main = 0x7f94a10950
> >   # ./aslr
> >   main = 0x7f94fee950
> >   # ./aslr text
> >   main = 0x7f8cb72950
> >
> >   # echo 0 > /proc/sys/kernel/randomize_va_space
> >   # ./aslr text
> >   main = 0x555950
> >   # ./aslr
> >   main = 0x555950
> >   # ./aslr
> >   main = 0x555950
> >   # ./aslr
> >   main = 0x555950
>
> It would be worth pointing out that this is after your patch is applied.
> Before your patch I get randomized VAs even after writing 0 to
> randomize_va_spave.

Ok.

--Arun
--
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/

linux-next: Tree for Oct 8

[Stephen Rothwell]

Hi all,

Please do not add any material intended for v3.19 to you linux-next
included trees until after v3.18-rc1 has been released.

Changes since 20141007:

Non-merge commits (relative to Linus' tree): 9651
 8214 files changed, 378909 insertions(+), 275679 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.

Below is a summary of the state of the merge.

I am currently merging 227 trees (counting Linus' and 32 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (bfe01a5ba249 Linux 3.17)
Merging fixes/master (b94d525e58dc Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (ad684dce87fa ARM: 8179/1: kprobes-test: Fix compile 
error "bad immediate value for offset")
Merging m68k-current/for-linus (24cae7934cf1 m68k: Reformat 
arch/m68k/mm/hwtest.c)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of 
flash_block_list in rtas_flash)
Merging powerpc-merge-mpe/for-linus (7d59deb50aaf powerpc: Wire up 
sys_seccomp(), sys_getrandom() and sys_memfd_create())
Merging sparc/master (1cef94c36bd4 sparc64: Increase size of boot string to 
1024 bytes)
Merging net/master (c3a803e81713 Update Intel Ethernet Driver maintainers list)
Merging ipsec/master (b8c203b2d2fc xfrm: Generate queueing routes only from 
route lookup functions)
Merging sound-current/for-linus (897c329bcb22 ALSA: usb: caiaq: check for 
cdev->n_streams > 1)
Merging pci-current/for-linus (7cbeb9f90db8 PCI: pciehp: Fix pcie_wait_cmd() 
timeout)
Merging wireless/master (f8adaf0ae978 brcmfmac: Fix off by one bug in 
brcmf_count_20mhz_channels())
Merging driver-core.current/driver-core-linus (9e82bf014195 Linux 3.17-rc5)
Merging tty.current/tty-linus (9e82bf014195 Linux 3.17-rc5)
Merging usb.current/usb-linus (0f33be009b89 Linux 3.17-rc6)
Merging usb-gadget-fixes/fixes (0b93a4c838fa usb: dwc3: fix TRB completion when 
multiple TRBs are started)
Merging usb-serial-fixes/usb-linus (dee80ad12d2b USB: cp210x: add support for 
Seluxit USB dongle)
Merging staging.current/staging-linus (0f33be009b89 Linux 3.17-rc6)
Merging char-misc.current/char-misc-linus (9e82bf014195 Linux 3.17-rc5)
Merging input-current/for-linus (447a8b858e4b Merge branch 'next' into 
for-linus)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (be34c4ef693f crypto: sha - Handle unaligned 
input data in generic sha256 and sha512.)
Merging ide/master (a53dae49b2fe ide: use module_platform_driver())
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (e66c98c7a0ea of: Fix NULL 
dereference in selftest removal code)
Merging rr-fixes/fixes (f49819560f53 virtio-rng: skip reading when we start to 
remove the device)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch 
'for-joerg/arm-smmu/fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging kselftest-fixes/fixes (ce6a144a0d01 selftests/memfd: Run test on all 
architectures)
Merging drm-intel-fixes/for-linux-next-fixes (bfe01a5ba249 Linux 3.17)
Merging asm-generic/master (f3670394c29f Revert "x86/efi: Fixup GOT in all boot 
code paths&

Re: [PATCH 1/2] mmc: mxcmmc: fix race condition when dma finish a data transfer

[Sascha Hauer]

On Tue, Sep 30, 2014 at 04:59:37PM +0200, Matteo Facchinetti wrote:
> From: Matteo Facchinetti 
> 
> In accordance with the other drivers that using the dma engine,
> fix it, leaving *only* to dma driver the complete control to
> ending the read operation.
> 
> Removing STATUS_READ_OP_DONE event activation, has as effect
> to force mxcmci driver to handle the finish data transfer only
> by mxcmci dma callback.
> 
> Signed-off-by: Matteo Facchinetti 

I can't test this currently, but it looks sane to me and I assume you
invested quite some time to make sure the patch behaves correctly.

Acked-by: Sascha Hauer 

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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: implement rw_page operation of zram block device operation

[Minchan Kim]

Hello Karam,

On Mon, Oct 06, 2014 at 02:31:05PM +0900, karam@lge.com wrote:
> From: "karam.lee" 
> 
> Recently rw_page block device operation is added.
> This patch implements rw_page operation for zram block device so
> zram can process page sized I/O without bio.

It's a performance enhance patch? If you had, pz, inclulde the result
in the description.

> ---
> ---
>  drivers/block/zram/zram_drv.c |   60 
> +++--
>  1 file changed, 52 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 48eccb3..b76a5dc 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -368,7 +368,7 @@ static int zram_decompress_page(struct zram *zram, char 
> *mem, u32 index)
>  }
>  
>  static int zram_bvec_read(struct zram *zram, struct bio_vec *bvec,
> -   u32 index, int offset, struct bio *bio)
> +   u32 index, int offset)

Isn't it cleanup? Please, separate it into another patch.

>  {
>   int ret;
>   struct page *page;
> @@ -535,14 +535,13 @@ out:
>  }
>  
>  static int zram_bvec_rw(struct zram *zram, struct bio_vec *bvec, u32 index,
> - int offset, struct bio *bio)
> + int offset, int rw)
>  {
>   int ret;
> - int rw = bio_data_dir(bio);
>  
>   if (rw == READ) {
>   atomic64_inc(&zram->stats.num_reads);
> - ret = zram_bvec_read(zram, bvec, index, offset, bio);
> + ret = zram_bvec_read(zram, bvec, index, offset);
>   } else {
>   atomic64_inc(&zram->stats.num_writes);
>   ret = zram_bvec_write(zram, bvec, index, offset);
> @@ -718,7 +717,7 @@ out:
>  
>  static void __zram_make_request(struct zram *zram, struct bio *bio)
>  {
> - int offset;
> + int offset, rw;
>   u32 index;
>   struct bio_vec bvec;
>   struct bvec_iter iter;
> @@ -733,6 +732,7 @@ static void __zram_make_request(struct zram *zram, struct 
> bio *bio)
>   return;
>   }
>  
> + rw = bio_data_dir(bio);
>   bio_for_each_segment(bvec, bio, iter) {
>   int max_transfer_size = PAGE_SIZE - offset;
>  
> @@ -747,15 +747,15 @@ static void __zram_make_request(struct zram *zram, 
> struct bio *bio)
>   bv.bv_len = max_transfer_size;
>   bv.bv_offset = bvec.bv_offset;
>  
> - if (zram_bvec_rw(zram, &bv, index, offset, bio) < 0)
> + if (zram_bvec_rw(zram, &bv, index, offset, rw) < 0)
>   goto out;
>  
>   bv.bv_len = bvec.bv_len - max_transfer_size;
>   bv.bv_offset += max_transfer_size;
> - if (zram_bvec_rw(zram, &bv, index + 1, 0, bio) < 0)
> + if (zram_bvec_rw(zram, &bv, index + 1, 0, rw) < 0)
>   goto out;
>   } else
> - if (zram_bvec_rw(zram, &bvec, index, offset, bio) < 0)
> + if (zram_bvec_rw(zram, &bvec, index, offset, rw) < 0)
>   goto out;
>  
>   update_position(&index, &offset, &bvec);
> @@ -810,8 +810,52 @@ static void zram_slot_free_notify(struct block_device 
> *bdev,
>   atomic64_inc(&zram->stats.notify_free);
>  }
>  
> +static int zram_rw_page(struct block_device *bdev, sector_t sector,
> +struct page *page, int rw)
> +{
> + int offset, ret = 1;
> + u32 index;
> + u64 start, end, bound;
> + struct zram *zram;
> + struct bio_vec bv;
> +
> + zram = bdev->bd_disk->private_data;
> +
> + if (unlikely(sector&
> + (ZRAM_SECTOR_PER_LOGICAL_BLOCK - 1)))
> + goto out;
> +
> + start = sector;
> + end = start + (PAGE_SIZE >> SECTOR_SHIFT);
> + bound = zram->disksize >> SECTOR_SHIFT;
> + if (unlikely(start >= bound || end > bound || start > end))
> + goto out;

Please modify valid_io_request to used for your purpose and share it
with zram_make_request.

And please include Jerome because I'd like to confirm this patch in
partial_io system for just in case.

> +
> + down_read(&zram->init_lock);
> + if (unlikely(!init_done(zram))) {
> + ret = -ENOMEM;
> + goto out_unlock;
> + }
> +
> + index = sector >> SECTORS_PER_PAGE_SHIFT;
> + offset = sector & (SECTORS_PER_PAGE - 1) << SECTOR_SHIFT;
> +
> + bv.bv_page = page;
> + bv.bv_len = PAGE_SIZE;
> + bv.bv_offset = 0;
> +
> + ret = zram_bvec_rw(zram, &bv, index, offset, rw);
> + page_endio(page, rw, ret);
> +
> +out_unlock:
> + up_read(&zram->init_lock);
> +out:
> + return ret;
> +}
> +
>  static const struct block_device_operations zram_devops = {
>   .swap_slot_free_notify = zram_slot_free_notify,
> + .rw_page = zram_rw_page,
>   .owner = THIS_MODULE
>  };
>  
> -- 
> 1.7.9.5

Re: [PATCH 2/2] mmc: mxcmmc: fix the default value for available voltages into mxcmci_probe

[Sascha Hauer]

On Tue, Sep 30, 2014 at 04:59:38PM +0200, Matteo Facchinetti wrote:
> From: Matteo Facchinetti 
> 
> If available voltages are not given, mmc_regulator_get_supply() function
> returns 0 and mxcmmc driver doesn't set a value for ocr_avail mask.
> 
> In accordance with the comment in platform_data/mmc-mxcmmc.h,
> fix it, assuming MMC_VDD_32_33 | MMC_VDD_33_34 as default value.
> 
> Signed-off-by: Matteo Facchinetti 
> ---
>  drivers/mmc/host/mxcmmc.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c
> index 536a898..5350dc5 100644
> --- a/drivers/mmc/host/mxcmmc.c
> +++ b/drivers/mmc/host/mxcmmc.c
> @@ -1077,13 +1077,13 @@ static int mxcmci_probe(struct platform_device *pdev)
>   dat3_card_detect = true;
>  
>   ret = mmc_regulator_get_supply(mmc);

mmc_regulator_get_supply() sets mmc->ocr_avail based on the information
of the vmmc regulator if present...

> - if (ret) {
> - if (pdata && ret != -EPROBE_DEFER)
> - mmc->ocr_avail = pdata->ocr_avail ? :
> - MMC_VDD_32_33 | MMC_VDD_33_34;
> - else
> - goto out_free;
> - }
> + if (ret == -EPROBE_DEFER)
> + goto out_free;
> +
> + if (pdata && pdata->ocr_avail)
> + mmc->ocr_avail = pdata->ocr_avail;
> + else
> + mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;

... and here mmc->ocr_avail is overwritten unconditionally.

Unfortunately the return value of mmc_regulator_get_supply() doesn't
indicate if it was successful in setting a ocr_avail. So I think the best
you can do here is:

if (!mmc->ocr_avail) {
if (pdata && pdata->ocr_avail)
mmc->ocr_avail = pdata->ocr_avail;
else
mmc->ocr_avail = MMC_VDD_32_33 | MMC_VDD_33_34;
}

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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 v8 1/2] i2c: imx: add DMA support for freescale i2c driver

[Wolfram Sang]

On Wed, Oct 08, 2014 at 06:30:14AM +, Yao Yuan wrote:
> > -Original Message-
> > From: Wolfram Sang [mailto:w...@the-dreams.de]
> > Sent: Friday, October 03, 2014 3:55 PM
> > To: Yuan Yao-B46683
> > Cc: ma...@denx.de; l...@karo-electronics.de; mark.rutl...@arm.com; Duan
> > Fugang-B38611; shawn@linaro.org; linux-kernel@vger.kernel.org; linux-
> > arm-ker...@lists.infradead.org; linux-...@vger.kernel.org
> > Subject: Re: [PATCH v8 1/2] i2c: imx: add DMA support for freescale i2c
> > driver
> > > -#include 
> > > -#include 
> > > -#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > -#include 
> > >  #include 
> > > +#include 
> > >  #include 
> > > -#include 
> > > -#include 
> > > -#include 
> > > -#include 
> > > +#include 
> > > +#include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > > +#include 
> > > +#include 
> > > +#include 
> > 
> > This is a seperate patch.
> 
> [Yuan Yao] 
> Here I just adjust the order of the include file as alphabetical order.
> If it looks strange I can only add the include files about DMA.

It doesn't look strange, it makes sense to do that. However, this should
be a seperate patch.

a) sort includes
b) add the dma includes in the dma patch

> After DMA callback, I must wait until the last byte transfer completely.
> It's a very short time which less than 10us.
> By the way, how about use udelay(10) instead of schedule()?
> udelay(10) is waiting a appropriate time.
> schedule() is waiting too long for i2c but may be good for whole system.
> Can you give me some suggestion?

It doesn't matter much. Leave it as it is. If somebody wants to change
it, it can be patched.



signature.asc
Description: Digital signature

[PATCH] Input: mpr121: Switch to using managed resources

[Pramod Gurav]

This change switches to using devm_* managed resources APIs to
request the resources in probe to simplify probe error path and
module unloading and does away with remove function.

Cc: Dmitry Torokhov 
Cc: linux-in...@vger.kernel.org
Signed-off-by: Pramod Gurav 
---
 drivers/input/keyboard/mpr121_touchkey.c |   35 +++---
 1 file changed, 8 insertions(+), 27 deletions(-)

diff --git a/drivers/input/keyboard/mpr121_touchkey.c 
b/drivers/input/keyboard/mpr121_touchkey.c
index 009c822..49c578e 100644
--- a/drivers/input/keyboard/mpr121_touchkey.c
+++ b/drivers/input/keyboard/mpr121_touchkey.c
@@ -214,12 +214,12 @@ static int mpr_touchkey_probe(struct i2c_client *client,
return -EINVAL;
}
 
-   mpr121 = kzalloc(sizeof(struct mpr121_touchkey), GFP_KERNEL);
-   input_dev = input_allocate_device();
+   mpr121 = devm_kzalloc(&client->dev, sizeof(*mpr121),
+ GFP_KERNEL);
+   input_dev = devm_input_allocate_device(&client->dev);
if (!mpr121 || !input_dev) {
dev_err(&client->dev, "Failed to allocate memory\n");
-   error = -ENOMEM;
-   goto err_free_mem;
+   return -ENOMEM;
}
 
mpr121->client = client;
@@ -243,44 +243,26 @@ static int mpr_touchkey_probe(struct i2c_client *client,
error = mpr121_phys_init(pdata, mpr121, client);
if (error) {
dev_err(&client->dev, "Failed to init register\n");
-   goto err_free_mem;
+   return error;
}
 
-   error = request_threaded_irq(client->irq, NULL,
+   error = devm_request_threaded_irq(&client->dev, client->irq, NULL,
 mpr_touchkey_interrupt,
 IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
 client->dev.driver->name, mpr121);
if (error) {
dev_err(&client->dev, "Failed to register interrupt\n");
-   goto err_free_mem;
+   return error;
}
 
error = input_register_device(input_dev);
if (error)
-   goto err_free_irq;
+   return error;
 
i2c_set_clientdata(client, mpr121);
device_init_wakeup(&client->dev, pdata->wakeup);
 
return 0;
-
-err_free_irq:
-   free_irq(client->irq, mpr121);
-err_free_mem:
-   input_free_device(input_dev);
-   kfree(mpr121);
-   return error;
-}
-
-static int mpr_touchkey_remove(struct i2c_client *client)
-{
-   struct mpr121_touchkey *mpr121 = i2c_get_clientdata(client);
-
-   free_irq(client->irq, mpr121);
-   input_unregister_device(mpr121->input_dev);
-   kfree(mpr121);
-
-   return 0;
 }
 
 #ifdef CONFIG_PM_SLEEP
@@ -327,7 +309,6 @@ static struct i2c_driver mpr_touchkey_driver = {
},
.id_table   = mpr121_id,
.probe  = mpr_touchkey_probe,
-   .remove = mpr_touchkey_remove,
 };
 
 module_i2c_driver(mpr_touchkey_driver);
-- 
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/

[PATCH] sched/fair: Care divide error in update_task_scan_period()

[Yasuaki Ishimatsu]

While offling node by hot removing memory, the following divide error
occurs:

  divide error:  [#1] SMP
  [...]
  Call Trace:
   [...] handle_mm_fault
   [...] ? try_to_wake_up
   [...] ? wake_up_state
   [...] __do_page_fault
   [...] ? do_futex
   [...] ? put_prev_entity
   [...] ? __switch_to
   [...] do_page_fault
   [...] page_fault
  [...]
  RIP  [] task_numa_fault
   RSP 

The issue occurs as follows:
  1. When page fault occurs and page is allocated from node 1,
 task_struct->numa_faults_buffer_memory[] of node 1 is
 incremented and p->numa_faults_locality[] is also incremented
 as follows:

 o numa_faults_buffer_memory[]   o numa_faults_locality[]
  NR_NUMA_HINT_FAULT_TYPES
 |  0 | 1 |
 --  --
  node 0 |  0 | 0 |   remote |  0 |
  node 1 |  0 | 1 |   locale |  1 |
 --  --

  2. node 1 is offlined by hot removing memory.

  3. When page fault occurs, fault_types[] is calculated by using
 p->numa_faults_buffer_memory[] of all online nodes in
 task_numa_placement(). But node 1 was offline by step 2. So
 the fault_types[] is calculated by using only
 p->numa_faults_buffer_memory[] of node 0. So both of fault_types[]
 are set to 0.

  4. The values(0) of fault_types[] pass to update_task_scan_period().

  5. numa_faults_locality[1] is set to 1. So the following division is
 calculated.

static void update_task_scan_period(struct task_struct *p,
unsigned long shared, unsigned long private){
...
ratio = DIV_ROUND_UP(private * NUMA_PERIOD_SLOTS, (private + 
shared));
}

  6. But both of private and shared are set to 0. So divide error
 occurs here.

  The divide error is rare case because the trigger is node offline.
  By this patch, when both of private and shared are set to 0, diff
  is just set to 0, not calculating the division.

Signed-off-by: Yasuaki Ishimatsu 
---
 kernel/sched/fair.c | 30 +++---
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index bfa3c86..fb7dc3f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1496,18 +1496,26 @@ static void update_task_scan_period(struct task_struct 
*p,
slot = 1;
diff = slot * period_slot;
} else {
-   diff = -(NUMA_PERIOD_THRESHOLD - ratio) * period_slot;
+   if (unlikely((private + shared) == 0))
+   /*
+* This is a rare case. The trigger is node offline.
+*/
+   diff = 0;
+   else {
+   diff = -(NUMA_PERIOD_THRESHOLD - ratio) * period_slot;

-   /*
-* Scale scan rate increases based on sharing. There is an
-* inverse relationship between the degree of sharing and
-* the adjustment made to the scanning period. Broadly
-* speaking the intent is that there is little point
-* scanning faster if shared accesses dominate as it may
-* simply bounce migrations uselessly
-*/
-   ratio = DIV_ROUND_UP(private * NUMA_PERIOD_SLOTS, (private + 
shared));
-   diff = (diff * ratio) / NUMA_PERIOD_SLOTS;
+   /*
+* Scale scan rate increases based on sharing. There is
+* an inverse relationship between the degree of sharing
+* and the adjustment made to the scanning period.
+* Broadly speaking the intent is that there is little
+* point scanning faster if shared accesses dominate as
+* it may simply bounce migrations uselessly
+*/
+   ratio = DIV_ROUND_UP(private * NUMA_PERIOD_SLOTS,
+   (private + shared));
+   diff = (diff * ratio) / NUMA_PERIOD_SLOTS;
+   }
}

p->numa_scan_period = clamp(p->numa_scan_period + diff,
-- 
1.8.3.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] Input: lpc32xx-keys: Switch to using managed resources

[Pramod Gurav]

This change switches to using devm_* managed resources APIs to
request the resources in probe to simplify probe error path and
module unloading.

Cc: Dmitry Torokhov 
Cc: linux-in...@vger.kernel.org
Signed-off-by: Pramod Gurav 
---
 drivers/input/keyboard/lpc32xx-keys.c |   86 +
 1 file changed, 23 insertions(+), 63 deletions(-)

diff --git a/drivers/input/keyboard/lpc32xx-keys.c 
b/drivers/input/keyboard/lpc32xx-keys.c
index 8b1b013..6e244df 100644
--- a/drivers/input/keyboard/lpc32xx-keys.c
+++ b/drivers/input/keyboard/lpc32xx-keys.c
@@ -188,32 +188,27 @@ static int lpc32xx_kscan_probe(struct platform_device 
*pdev)
return -EINVAL;
}
 
-   kscandat = kzalloc(sizeof(struct lpc32xx_kscan_drv), GFP_KERNEL);
-   if (!kscandat) {
-   dev_err(&pdev->dev, "failed to allocate memory\n");
+   kscandat = devm_kzalloc(&pdev->dev, sizeof(*kscandat),
+   GFP_KERNEL);
+   if (!kscandat)
return -ENOMEM;
-   }
 
error = lpc32xx_parse_dt(&pdev->dev, kscandat);
if (error) {
dev_err(&pdev->dev, "failed to parse device tree\n");
-   goto err_free_mem;
+   return error;
}
 
keymap_size = sizeof(kscandat->keymap[0]) *
(kscandat->matrix_sz << kscandat->row_shift);
-   kscandat->keymap = kzalloc(keymap_size, GFP_KERNEL);
-   if (!kscandat->keymap) {
-   dev_err(&pdev->dev, "could not allocate memory for keymap\n");
-   error = -ENOMEM;
-   goto err_free_mem;
-   }
+   kscandat->keymap = devm_kzalloc(&pdev->dev, keymap_size, GFP_KERNEL);
+   if (!kscandat->keymap)
+   return -ENOMEM;
 
-   kscandat->input = input = input_allocate_device();
+   kscandat->input = input = devm_input_allocate_device(&pdev->dev);
if (!input) {
dev_err(&pdev->dev, "failed to allocate input device\n");
-   error = -ENOMEM;
-   goto err_free_keymap;
+   return -ENOMEM;
}
 
/* Setup key input */
@@ -234,39 +229,37 @@ static int lpc32xx_kscan_probe(struct platform_device 
*pdev)
   kscandat->keymap, kscandat->input);
if (error) {
dev_err(&pdev->dev, "failed to build keymap\n");
-   goto err_free_input;
+   return error;
}
 
input_set_drvdata(kscandat->input, kscandat);
 
-   kscandat->iores = request_mem_region(res->start, resource_size(res),
-pdev->name);
+   kscandat->iores = devm_request_mem_region(&pdev->dev, res->start,
+ resource_size(res),
+ pdev->name);
if (!kscandat->iores) {
dev_err(&pdev->dev, "failed to request I/O memory\n");
-   error = -EBUSY;
-   goto err_free_input;
+   return -EBUSY;
}
 
-   kscandat->kscan_base = ioremap(kscandat->iores->start,
+   kscandat->kscan_base = devm_ioremap(&pdev->dev, kscandat->iores->start,
   resource_size(kscandat->iores));
if (!kscandat->kscan_base) {
dev_err(&pdev->dev, "failed to remap I/O memory\n");
-   error = -EBUSY;
-   goto err_release_memregion;
+   return -EBUSY;
}
 
/* Get the key scanner clock */
-   kscandat->clk = clk_get(&pdev->dev, NULL);
+   kscandat->clk = devm_clk_get(&pdev->dev, NULL);
if (IS_ERR(kscandat->clk)) {
dev_err(&pdev->dev, "failed to get clock\n");
-   error = PTR_ERR(kscandat->clk);
-   goto err_unmap;
+   return PTR_ERR(kscandat->clk);
}
 
/* Configure the key scanner */
error = clk_prepare_enable(kscandat->clk);
if (error)
-   goto err_clk_put;
+   return error;
 
writel(kscandat->deb_clks, LPC32XX_KS_DEB(kscandat->kscan_base));
writel(kscandat->scan_delay, LPC32XX_KS_SCAN_CTL(kscandat->kscan_base));
@@ -277,52 +270,20 @@ static int lpc32xx_kscan_probe(struct platform_device 
*pdev)
writel(1, LPC32XX_KS_IRQ(kscandat->kscan_base));
clk_disable_unprepare(kscandat->clk);
 
-   error = request_irq(irq, lpc32xx_kscan_irq, 0, pdev->name, kscandat);
+   error = devm_request_irq(&pdev->dev, irq, lpc32xx_kscan_irq, 0,
+pdev->name, kscandat);
if (error) {
dev_err(&pdev->dev, "failed to request irq\n");
-   goto err_clk_put;
+   return error;
}
 
error = input_register_device(kscandat->input);
if (error) {
dev_err(&pdev->dev, "failed to register input device\n");
-   goto err_free

RE: [PATCH v8 1/2] i2c: imx: add DMA support for freescale i2c driver

[Yao Yuan]

> -Original Message-
> From: Wolfram Sang [mailto:w...@the-dreams.de]
> Sent: Friday, October 03, 2014 3:55 PM
> To: Yuan Yao-B46683
> Cc: ma...@denx.de; l...@karo-electronics.de; mark.rutl...@arm.com; Duan
> Fugang-B38611; shawn@linaro.org; linux-kernel@vger.kernel.org; linux-
> arm-ker...@lists.infradead.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH v8 1/2] i2c: imx: add DMA support for freescale i2c
> driver
> > -#include 
> > -#include 
> > -#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> > +#include 
> >  #include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> 
> This is a seperate patch.

[Yuan Yao] 
Here I just adjust the order of the include file as alphabetical order.
If it looks strange I can only add the include files about DMA.

> 
> 
> > +   while (1) {
> > +   temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
> > +   if (temp & I2SR_ICF)
> > +   break;
> > +   if (time_after(jiffies, orig_jiffies +
> > +   msecs_to_jiffies(IMX_I2C_DMA_TIMEOUT))) {
> > +   dev_dbg(dev, "<%s> Timeout\n", __func__);
> > +   return -ETIMEDOUT;
> > +   }
> > +   schedule();
> 
> That might have been asked before. Is there no interrupt for this?
> 

[Yuan Yao] No, there is no interrupt.
After DMA callback, I must wait until the last byte transfer completely.
It's a very short time which less than 10us.
By the way, how about use udelay(10) instead of schedule()?
udelay(10) is waiting a appropriate time.
schedule() is waiting too long for i2c but may be good for whole system.
Can you give me some suggestion?

Thanks for your review.

Best Regards,
Yuan Yao
--
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 RFC 2/2] cpufreq: arm_big_little: provide cpu capacity

[Mike Turquette]

Move the cpu capacity bits out of arch/arm/ and into the CPUfreq driver.
Not all ARM devices will use CPUfreq and it is unsafe to assume as such
in topology.c.

Instead, use the new capacity_ops introduced into CFS. If this code is
generic enough then it could be factored and shared via a header to make
it easier for other CPUfreq drivers to take advantage of it.

Signed-off-by: Mike Turquette 
---
This approach simply builds on top of Morten's series. I am not sure
that the per-cpu method is the best way to go in the future. And if so I
imagine that the CPUfreq core could provide everything except for the
cpu_eff part.

In general I think that the overlap between CPUfreq drivers and
arch/arm/kernel/topology.c is something that needs to addresssed soon,
as both pieces of code are re-inventing parts of each other.

 arch/arm/include/asm/topology.h  |  2 ++
 arch/arm/kernel/topology.c   | 42 ++---
 drivers/cpufreq/arm_big_little.c | 51 
 3 files changed, 55 insertions(+), 40 deletions(-)

diff --git a/arch/arm/include/asm/topology.h b/arch/arm/include/asm/topology.h
index 2fe85ff..3951232 100644
--- a/arch/arm/include/asm/topology.h
+++ b/arch/arm/include/asm/topology.h
@@ -14,6 +14,8 @@ struct cputopo_arm {
 };
 
 extern struct cputopo_arm cpu_topology[NR_CPUS];
+extern unsigned long max_raw_capacity;
+DECLARE_PER_CPU(unsigned long, cpu_raw_capacity);
 
 #define topology_physical_package_id(cpu)  (cpu_topology[cpu].socket_id)
 #define topology_core_id(cpu)  (cpu_topology[cpu].core_id)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 5f049ec..a2c9b5f 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -79,8 +79,8 @@ static unsigned long *__cpu_capacity;
 
 static unsigned long middle_capacity = 1;
 
-static unsigned long max_raw_capacity = 1;
-static DEFINE_PER_CPU(unsigned long, cpu_raw_capacity);
+unsigned long max_raw_capacity = 1;
+DEFINE_PER_CPU(unsigned long, cpu_raw_capacity);
 
 /*
  * Iterate all CPUs' descriptor in DT and compute the efficiency
@@ -175,44 +175,6 @@ static void update_cpu_capacity(unsigned int cpu)
cpu, arch_scale_freq_capacity(NULL, cpu));
 }
 
-/*
- * Scheduler load-tracking scale-invariance
- *
- * Provides the scheduler with a scale-invariance correction factor that
- * compensates for frequency scaling and micro-architecture differences between
- * cpus.
- */
-
-static DEFINE_PER_CPU(atomic_long_t, cpu_curr_freq);
-static DEFINE_PER_CPU(atomic_long_t, cpu_max_freq);
-
-/* cpufreq callback function setting current cpu frequency */
-void arch_scale_set_curr_freq(int cpu, unsigned long freq)
-{
-   atomic_long_set(&per_cpu(cpu_curr_freq, cpu), freq);
-}
-
-/* cpufreq callback function setting max cpu frequency */
-void arch_scale_set_max_freq(int cpu, unsigned long freq)
-{
-   atomic_long_set(&per_cpu(cpu_max_freq, cpu), freq);
-}
-
-unsigned long arch_scale_load_capacity(int cpu)
-{
-   unsigned long curr = atomic_long_read(&per_cpu(cpu_curr_freq, cpu));
-   unsigned long max = atomic_long_read(&per_cpu(cpu_max_freq, cpu));
-   unsigned long ret;
-
-   if (!max || !per_cpu(cpu_raw_capacity, cpu))
-   return SCHED_CAPACITY_SCALE;
-
-   ret = (curr * SCHED_CAPACITY_SCALE) / max;
-   ret = (ret * per_cpu(cpu_raw_capacity, cpu)) / max_raw_capacity;
-
-   return ret;
-}
-
 #else
 static inline void parse_dt_topology(void) {}
 static inline void update_cpu_capacity(unsigned int cpuid) {}
diff --git a/drivers/cpufreq/arm_big_little.c b/drivers/cpufreq/arm_big_little.c
index a46c223..5baffbd 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -31,7 +31,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
 
 #include "arm_big_little.h"
 
@@ -533,9 +536,52 @@ static struct notifier_block bL_switcher_notifier = {
.notifier_call = bL_cpufreq_switcher_notifier,
 };
 
+/*
+ * Scheduler load-tracking scale-invariance
+ *
+ * Provides the scheduler with a scale-invariance correction factor that
+ * compensates for frequency scaling and micro-architecture differences between
+ * cpus.
+ */
+
+static DEFINE_PER_CPU(atomic_long_t, cpu_curr_freq);
+static DEFINE_PER_CPU(atomic_long_t, cpu_max_freq);
+
+/* cpufreq callback function setting current cpu frequency */
+void arch_scale_set_curr_freq(int cpu, unsigned long freq)
+{
+   atomic_long_set(&per_cpu(cpu_curr_freq, cpu), freq);
+}
+
+/* cpufreq callback function setting max cpu frequency */
+void arch_scale_set_max_freq(int cpu, unsigned long freq)
+{
+   atomic_long_set(&per_cpu(cpu_max_freq, cpu), freq);
+}
+
+/*
+ * scale_load_capacity returns the current capacity for a given cpu, adjusted
+ * for micro-architectural differences and taking into accout cpu frequency
+ */
+unsigned long scale_load_capacity(int cpu)
+{
+   unsigned long curr = atomic_long_read(&per_c

[PATCH RFC 1/2] sched: cfs: introduce capacity_ops

[Mike Turquette]

The scheduler needs to know the current capacity of a cpu taking into
account micro-architectural differences as well as current cpu
frequency. The method for determining this may vary not only from
architecture to architecture, but also within differnt platforms of the
same architectures.

struct capacity_ops allows for a machine-specific backend to provide
this data. Access to the ops is protected by rcu_read_lock(). This is to
prevent a loadable module that provides capacity_ops callbacks from
pulling the rug out from under us while the scheduler is still using the
function.

A weak arch function used to be responsible for this, but that approach
is too limiting. For example various ARM SoCs may have wildly different
methods for determining the current cpu capacity. capacity_ops allows
many methods to be compiled into the kernel and then selects one at
run-time.

The default ops require no knowledge of hardware and do nothing. This
patch only includes .get_capacity, but future ops for updating and
setting the capacity in the works.

Signed-off-by: Mike Turquette 
---
Note that struct capacity_ops should have other members in it in the
future. I have an additional patch that I plan to post soon which adds
.eval_capacity as a way to for the scheduler to initiate a change in cpu
capacity (e.g. scale cpu frequency).

 include/linux/sched.h | 28 
 kernel/sched/fair.c   | 41 +++--
 2 files changed, 63 insertions(+), 6 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index fa0b121..4b69000 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -846,6 +846,34 @@ enum cpu_idle_type {
CPU_MAX_IDLE_TYPES
 };
 
+/**
+ * capacity_ops -  helpers for understanding and changing scalable cpu capacity
+ * @get_capacity:  returns current capacity of cpu, accounting for
+ *micro-architecture and frequency variability
+ *
+ * capacity_ops contains machine-specific callbacks for retreiving
+ * power-adjusted capacity and updating capacity on a set of cpus.
+ *
+ * The default ops do not interact with hardware.
+ *
+ * Using these ops requires holding rcu_read_lock() across the function call to
+ * protect against function pointers disappearing during use. This can happen
+ * if a loadable module provides the callbacks and is unloaded during execution
+ * of the callback.
+ *
+ * Updates to the ops (such as implementations based on a CPUfreq backend)
+ * requires acquring capacity_ops.lock during the change, followed by a call to
+ * synchronize_rcu().
+ */
+struct capacity_ops {
+   unsigned long (*get_capacity)(int cpu);
+   spinlock_t lock;
+};
+
+extern struct capacity_ops cfs_capacity_ops;
+
+unsigned long default_scale_load_capacity(int cpu);
+
 /*
  * Increase resolution of cpu_capacity calculations
  */
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 025bf3c..8124c7b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2264,8 +2264,6 @@ static u32 __compute_runnable_contrib(u64 n)
return contrib + runnable_avg_yN_sum[n];
 }
 
-unsigned long arch_scale_load_capacity(int cpu);
-
 /*
  * We can represent the historical contribution to runnable average as the
  * coefficients of a geometric series.  To do this we sub-divide our runnable
@@ -2302,7 +2300,7 @@ static __always_inline int 
__update_entity_runnable_avg(u64 now, int cpu,
u64 delta, periods;
u32 runnable_contrib;
int delta_w, decayed = 0;
-   u32 scale_cap = arch_scale_load_capacity(cpu);
+   u32 scale_cap = cfs_get_capacity(cpu);
 
delta = now - sa->last_runnable_update;
/*
@@ -5795,14 +5793,44 @@ unsigned long __weak arch_scale_smt_capacity(struct 
sched_domain *sd, int cpu)
return default_scale_smt_capacity(sd, cpu);
 }
 
-static unsigned long default_scale_load_capacity(int cpu)
+unsigned long default_scale_load_capacity(int cpu)
 {
return SCHED_CAPACITY_SCALE;
 }
 
-unsigned long __weak arch_scale_load_capacity(int cpu)
+struct capacity_ops cfs_capacity_ops = {
+   .get_capacity = default_scale_load_capacity,
+};
+
+static unsigned long cfs_get_capacity(int cpu)
 {
-   return default_scale_load_capacity(cpu);
+   unsigned long ret;
+
+   rcu_read_lock();
+   ret = cfs_capacity_ops.get_capacity(cpu);
+   rcu_read_unlock();
+
+   return ret;
+}
+
+/**
+ * set_default_capacity_ops - reset capacity ops to their default
+ * @eops - capacity_ops we are reseting
+ *
+ * Useful for loadable modules that supply custom capacity_ops callbacks.  When
+ * unloading these modules need to restore the originals before the custom
+ * callbacks disappear.
+ *
+ * FIXME - belongs in kernel/sched/core.c?
+ */
+void set_default_capacity_ops(struct capacity_ops *eops)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(&eops->lock, flags);
+   eops->get_capacity = default_scale_load_capacity;
+   spin_unlock_irqre

[PATCH RFC 0/2] introduce capacity_ops to CFS

[Mike Turquette]

The fair scheduler needs a method to retrieve the capacity of a cpu,
which may be derived from several platform-specific factors including
micro-architectural differences (e.g. big.LITTLE cpus), cpus with
different transistor types or process node properties (e.g. Nvidia
Tegra30 LP cpu) and cpu frequency (for cpus that dynamically scale clock
speed).

This info is inherently machine-specific and the first patch in this
series implements a new callback, .get_capacity as part of struct
capacity_ops. The default simply returns SCHED_CAPACITY_SCALE.

The second patch populates that callback with CPUfreq-based method for
machines using the arm_big_little CPUfreq driver. This can likely be
abstracted out a bit more to be generally useful to more CPUfreq drivers
but I wanted to gather feedback on the approach before going any
further.

Mike Turquette (2):
  sched: cfs: introduce capacity_ops
  cpufreq: arm_big_little: provide cpu capacity

 arch/arm/include/asm/topology.h  |  2 ++
 arch/arm/kernel/topology.c   | 42 ++---
 drivers/cpufreq/arm_big_little.c | 51 
 include/linux/sched.h| 28 ++
 kernel/sched/fair.c  | 41 +++-
 5 files changed, 118 insertions(+), 46 deletions(-)

-- 
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: [PATCH] target/file: fix inclusive vfs_fsync_range() end

[Nicholas A. Bellinger]

On Mon, 2014-10-06 at 16:40 -0700, Zach Brown wrote:
> Both of the file target's calls to vfs_fsync_range() got the end offset
> off by one.  The range is inclusive, not exclusive.  It would sync a bit
> more data than was required.
> 
> The sync path already tested the length of the range and fell back to
> LLONG_MAX so I copied that pattern in the rw path.
> 
> This is untested. I found the errors by inspection while following other
> code.
> 
> Signed-off-by: Zach Brown 
> ---
>  drivers/target/target_core_file.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/target/target_core_file.c 
> b/drivers/target/target_core_file.c
> index 7d6cdda..176588f 100644
> --- a/drivers/target/target_core_file.c
> +++ b/drivers/target/target_core_file.c
> @@ -415,7 +415,7 @@ fd_execute_sync_cache(struct se_cmd *cmd)
>   } else {
>   start = cmd->t_task_lba * dev->dev_attrib.block_size;
>   if (cmd->data_length)
> - end = start + cmd->data_length;
> + end = start + cmd->data_length - 1;
>   else
>   end = LLONG_MAX;
>   }
> @@ -680,7 +680,12 @@ fd_execute_rw(struct se_cmd *cmd, struct scatterlist 
> *sgl, u32 sgl_nents,
>   struct fd_dev *fd_dev = FD_DEV(dev);
>   loff_t start = cmd->t_task_lba *
>   dev->dev_attrib.block_size;
> - loff_t end = start + cmd->data_length;
> + loff_t end;
> +
> + if (cmd->data_length)
> + end = start + cmd->data_length - 1;
> + else
> + end = LLONG_MAX;
>  
>   vfs_fsync_range(fd_dev->fd_file, start, end, 1);
>   }

Nice catch Zach.  Applying to target-pending/for-next now.

Thank you,

--nab

--
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/7] cpufreq: Architecture specific callback for frequency changes

[Mike Turquette]

Quoting Morten Rasmussen (2014-09-22 09:24:02)
> Architectures that don't have any other means for tracking cpu frequency
> changes need a callback from cpufreq to implement a scaling factor to
> enable scale-invariant per-entity load-tracking in the scheduler.
> 
> To compute the scale invariance correction factor the architecture would
> need to know both the max frequency and the current frequency. This
> patch defines weak functions for setting both from cpufreq.
> 
> Related architecture specific functions use weak function definitions.
> The same approach is followed here.
> 
> These callbacks can be used to implement frequency scaling of cpu
> capacity later.
> 
> Signed-off-by: Morten Rasmussen 
> ---
>  drivers/cpufreq/cpufreq.c |   10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index d9fdedd..e911f6b 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -278,6 +278,10 @@ static inline void adjust_jiffies(unsigned long val, 
> struct cpufreq_freqs *ci)
>  }
>  #endif
>  
> +void __weak arch_scale_set_curr_freq(int cpu, unsigned long freq) {}
> +
> +void __weak arch_scale_set_max_freq(int cpu, unsigned long freq) {}

Hi Morten,

This approach assumes a single implementation for an architecture, which
probably will not scale across the myriad platforms we have merged in
mainline today. For ARM there could be any number of methods for
determining a cpus capacity, including use of CPUfreq or some other
platform-specific method.

I am vaguely aware of Intel-based platforms that do not implement ACPI,
so for that architecture I assume that an arch hook that assumes ACPI is
similarly restrictive.

I'll reply to this thread with a pair of patches that try to generalize
the functions you created in patches #2-4 of this series. I'm currently
hacking on a Chromebook 2 using the arm_big_little CPUfreq driver, so
you'll notice that is where I decided to implement the ops. Of course
those could be implemented in arch code, or some other driver.

Regards,
Mike

> +
>  static void __cpufreq_notify_transition(struct cpufreq_policy *policy,
> struct cpufreq_freqs *freqs, unsigned int state)
>  {
> @@ -315,6 +319,7 @@ static void __cpufreq_notify_transition(struct 
> cpufreq_policy *policy,
> pr_debug("FREQ: %lu - CPU: %lu\n",
>  (unsigned long)freqs->new, (unsigned 
> long)freqs->cpu);
> trace_cpu_frequency(freqs->new, freqs->cpu);
> +   arch_scale_set_curr_freq(freqs->cpu, freqs->new);
> srcu_notifier_call_chain(&cpufreq_transition_notifier_list,
> CPUFREQ_POSTCHANGE, freqs);
> if (likely(policy) && likely(policy->cpu == freqs->cpu))
> @@ -2135,7 +2140,7 @@ static int cpufreq_set_policy(struct cpufreq_policy 
> *policy,
> struct cpufreq_policy *new_policy)
>  {
> struct cpufreq_governor *old_gov;
> -   int ret;
> +   int ret, cpu;
>  
> pr_debug("setting new policy for CPU %u: %u - %u kHz\n",
>  new_policy->cpu, new_policy->min, new_policy->max);
> @@ -2173,6 +2178,9 @@ static int cpufreq_set_policy(struct cpufreq_policy 
> *policy,
> policy->min = new_policy->min;
> policy->max = new_policy->max;
>  
> +   for_each_cpu(cpu, policy->cpus)
> +   arch_scale_set_max_freq(cpu, policy->max);
> +
> pr_debug("new min and max freqs are %u - %u kHz\n",
>  policy->min, policy->max);
>  
> -- 
> 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/

[PATCH v3] Add LTC2941/LTC2943 Battery Gauge Driver

[Mike Looijmans]

Both the LTC2941 and LTC2943 measure battery capacity.
The LTC2943 is compatible with the LTC2941, it adds voltage and
temperature monitoring, and uses a slightly different conversion
formula for the charge counter.

To avoid confusion with e.g. the LTC2945, the driver is called
LTC2941 instead of LTC294X.

v2: Fix units of measurement: uV, uA and centidegrees.
v3: Correctly set configuration register. Allow negative values
for the sense resistor.

Signed-off-by: Mike Looijmans 
---
 drivers/power/Kconfig |7 +
 drivers/power/Makefile|1 +
 drivers/power/ltc2941-battery-gauge.c |  524 +
 3 files changed, 532 insertions(+)
 create mode 100644 drivers/power/ltc2941-battery-gauge.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 73cfcdf..bf3 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -382,6 +382,13 @@ config CHARGER_TPS65090
 Say Y here to enable support for battery charging with TPS65090
 PMIC chips.
 
+config BATTERY_GAUGE_LTC2941
+   tristate "LTC2941/LTC2943 Battery Gauge Driver"
+   depends on I2C
+   help
+Say Y here to include support for LTC2941 and LTC2943 Battery Gauge
+IC.
+
 config AB8500_BM
bool "AB8500 Battery Management Driver"
depends on AB8500_CORE && AB8500_GPADC
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index dfa8942..4f8e6c0 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_BATTERY_MAX17042)+= max17042_battery.o
 obj-$(CONFIG_BATTERY_Z2)   += z2_battery.o
 obj-$(CONFIG_BATTERY_S3C_ADC)  += s3c_adc_battery.o
 obj-$(CONFIG_BATTERY_TWL4030_MADC) += twl4030_madc_battery.o
+obj-$(CONFIG_BATTERY_GAUGE_LTC2941)+= ltc2941-battery-gauge.o
 obj-$(CONFIG_CHARGER_88PM860X) += 88pm860x_charger.o
 obj-$(CONFIG_CHARGER_PCF50633) += pcf50633-charger.o
 obj-$(CONFIG_BATTERY_JZ4740)   += jz4740-battery.o
diff --git a/drivers/power/ltc2941-battery-gauge.c 
b/drivers/power/ltc2941-battery-gauge.c
new file mode 100644
index 000..f0c387d
--- /dev/null
+++ b/drivers/power/ltc2941-battery-gauge.c
@@ -0,0 +1,524 @@
+/*
+ * I2C client/driver for the Linear Technology LTC2941 and LTC2943
+ * Battery Gas Gauge IC
+ *
+ * Copyright (C) 2014 Topic Embedded Systems
+ *
+ * Author: Auryn Verwegen
+ * Author: Mike Looijmans
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define I16_MSB(x) ((x >> 8) & 0xFF)
+#define I16_LSB(x) (x & 0xFF)
+
+#define LTC294X_WORK_DELAY 10  /* Update delay in seconds */
+
+#define LTC294X_MAX_VALUE  0x
+#define LTC294X_MID_SUPPLY 0x7FFF
+
+#define LTC2941_MAX_PRESCALER_EXP  7
+#define LTC2943_MAX_PRESCALER_EXP  6
+
+enum ltc294x_reg {
+   LTC294X_REG_STATUS  = 0x00,
+   LTC294X_REG_CONTROL = 0x01,
+   LTC294X_REG_ACC_CHARGE_MSB  = 0x02,
+   LTC294X_REG_ACC_CHARGE_LSB  = 0x03,
+   LTC294X_REG_THRESH_HIGH_MSB = 0x04,
+   LTC294X_REG_THRESH_HIGH_LSB = 0x05,
+   LTC294X_REG_THRESH_LOW_MSB  = 0x06,
+   LTC294X_REG_THRESH_LOW_LSB  = 0x07,
+   LTC294X_REG_VOLTAGE_MSB = 0x08,
+   LTC294X_REG_VOLTAGE_LSB = 0x09,
+   LTC294X_REG_CURRENT_MSB = 0x0E,
+   LTC294X_REG_CURRENT_LSB = 0x0F,
+   LTC294X_REG_TEMPERATURE_MSB = 0x14,
+   LTC294X_REG_TEMPERATURE_LSB = 0x15,
+} ;
+
+#define LTC2943_REG_CONTROL_MODE_MASK (BIT(7) | BIT(6))
+#define LTC2943_REG_CONTROL_MODE_SCAN BIT(7)
+#define LTC294X_REG_CONTROL_PRESCALER_MASK (BIT(5) | BIT(4) | BIT(3))
+#define LTC294X_REG_CONTROL_SHUTDOWN_MASK  (BIT(0))
+#define LTC294X_REG_CONTROL_PRESCALER_SET(x)   ((x << 3) & 
LTC294X_REG_CONTROL_PRESCALER_MASK)
+#define LTC294X_REG_CONTROL_ALCC_CONFIG_DISABLED   0
+
+#define LTC2941_NUM_REGS   0x08
+#define LTC2943_NUM_REGS   0x18
+
+struct ltc294x_info {
+   struct i2c_client *client;  /* I2C Client pointer */
+   struct power_supply supply; /* Supply pointer */
+   struct delayed_work work;   /* Work scheduler */
+   int num_regs; /* Number of registers (chip type) */
+   int id; /* Identifier of ltc294x chip */
+   int charge; /* Last charge register content */
+   int r_sense;/* mOhm */
+   int Qlsb;   /* nAh */
+};
+
+static DEFINE_IDR(ltc294x_id);
+static DEFINE_MUTEX(ltc294x_lock);
+
+static inline int convert_bin_to_uAh(
+   const struct ltc294x_info *info, int Q)
+{
+   int uAh;
+   uAh = ((Q * (info->Qlsb / 10))) / 100;
+   return uAh;
+}
+
+static inline int convert_uAh_to_bin(
+   const struct ltc294x_info *info, int uAh)
+{
+   int Q;
+   Q = (uAh * 100) / (info->Qlsb/10);
+   return (Q < LTC294X_MAX_VALUE) ? Q : LTC294X_MAX_VALUE;
+}
+
+static int ltc

Re: [PATCH v3] i2c: rk3x: adjust the LOW divison based on characteristics of SCL

[Doug Anderson]

Addy,

On Tue, Oct 7, 2014 at 8:50 PM, Addy Ke  wrote:
> As show in I2C specification:
> - Standard-mode: the minimum HIGH period of the scl clock is 4.0us
>  the minimum LOW period of the scl clock is 4.7us
> - Fast-mode: the minimum HIGH period of the scl clock is 0.6us
>  the minimum LOW period of the scl clock is 1.3us
>
> I have measured i2c SCL waveforms in fast-mode by oscilloscope
> on rk3288-pinky board. the LOW period of the scl clock is 1.3us.
> It is so critical that we must adjust LOW division to increase
> the LOW period of the scl clock.
>
> Thanks Doug for the suggestion about division formulas.
>
> Signed-off-by: Addy Ke 
> ---
> Changes in v2:
> - remove Fast-mode plus and HS-mode
> - use new formulas suggested by Doug
> Changes in V3:
> - use new formulas (sep 30) suggested by Doug
>
>  drivers/i2c/busses/i2c-rk3x.c | 135 
> +++---
>  1 file changed, 128 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> index b41d979..9612eba 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>
>  /* Register Map */
> @@ -428,18 +429,138 @@ out:
> return IRQ_HANDLED;
>  }
>
> +static void rk3x_i2c_calc_divs(unsigned long i2c_rate, unsigned long 
> scl_rate,
> +  unsigned long *div_low, unsigned long 
> *div_high)
> +{
> +   unsigned long min_low_ns, min_high_ns;
> +   unsigned long max_data_hold_ns;
> +   unsigned long data_hold_buffer_ns;
> +   unsigned long max_low_ns, min_total_ns;
> +
> +   unsigned long i2c_rate_khz, scl_rate_khz;
> +
> +   unsigned long min_low_div, min_high_div;
> +   unsigned long max_low_div;
> +
> +   unsigned long min_div_for_hold, min_total_div;
> +   unsigned long extra_div, extra_low_div, ideal_low_div;
> +
> +   /* Only support standard-mode and fast-mode */
> +   WARN_ON(scl_rate > 40);
> +
> +   /*
> +* min_low_ns:  The minimum number of ns we need to hold low
> +*  to meet i2c spec
> +* min_high_ns: The minimum number of ns we need to hold high
> +*  to meet i2c spec
> +* max_low_ns:  The maximum number of ns we can hold low
> +*  to meet i2c spec
> +*
> +* Note: max_low_ns should be (max data hold time * 2 - buffer)
> +*   This is because the i2c host on Rockchip holds the data line
> +*   for half the low time.
> +*/
> +   if (scl_rate <= 10) {
> +   min_low_ns = 4700;
> +   min_high_ns = 4000;
> +   max_data_hold_ns = 3450;
> +   data_hold_buffer_ns = 50;
> +   } else {
> +   min_low_ns = 1300;
> +   min_high_ns = 600;
> +   max_data_hold_ns = 900;
> +   data_hold_buffer_ns = 50;
> +   }
> +   max_low_ns = max_data_hold_ns * 2 - data_hold_buffer_ns;
> +   min_total_ns = min_low_ns + min_high_ns;
> +
> +   /* Adjust to avoid overflow */
> +   i2c_rate_khz = DIV_ROUND_UP(i2c_rate, 1000);
> +   scl_rate_khz = DIV_ROUND_UP(scl_rate, 1000);
> +
> +   /*
> +* We need the total div to be >= this number
> +* so we don't clock too fast.
> +*/
> +   min_total_div = DIV_ROUND_UP(i2c_rate_khz, scl_rate_khz * 8);
> +
> +   /* These are the min dividers needed for min hold times.*/

nit: a space before the "*" in the comment.

> +   min_low_div = DIV_ROUND_UP(i2c_rate_khz * min_low_ns, 8 * 100);
> +   min_high_div = DIV_ROUND_UP(i2c_rate_khz * min_high_ns, 8 * 100);
> +   min_div_for_hold = (min_low_div + min_high_div);
> +
> +   /*
> +* This is the maximum divider so we don't go over the max.
> +* We don't round up here (we round down) since this is a max.
> +*/
> +   max_low_div = i2c_rate_khz * max_low_ns / (8 * 100);
> +
> +   if (min_low_div > max_low_div)

It feels like we should print some sort of warning here.  Maybe WARN_ONCE?

> +   max_low_div = min_low_div;
> +
> +   if (min_div_for_hold > min_total_div) {
> +   /*
> +* Time needed to meet hold requirements is important.
> +* Just use that.
> +*/
> +   *div_low = min_low_div;
> +   *div_high = min_high_div;
> +   } else {
> +   /*
> +* We've got to distribute some time among the low and high
> +* so we don't run too fast.
> +*/
> +   extra_div = min_total_div - min_div_for_hold;
> +   /*
> +* We'll try to split things up perfectly evenly,
> +* biasing slightly towards having a higher div
> +* for low (spend more time low)

[GIT PULL] f2fs updates for v3.18

[Jaegeuk Kim]

Hi Linus,

This patch-set introduces a couple of new features such as large sector size,
FITRIM, and atomic/volatile writes.
Several patches enhance power-off recovery and checkpoint routines.
The fsck.f2fs starts to support fixing corrupted partitions with recovery hints
provided by this patch-set.

Thank you very much.

The following changes since commit 70c8038dd698b44daf7c8fc7e2eca142bec694c4:

  Merge tag 'for-f2fs-3.17-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs (2014-09-03 10:10:28 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git 
tags/f2fs-for-3.18

for you to fetch changes up to 02a1335f25a386db9afc68f8315162f862aac93f:

  f2fs: support volatile operations for transient data (2014-10-07 11:54:41 
-0700)


f2fs updates for v3.18

This series includes patches to:
 o retain some recovery information for fsck.f2fs
 o enhance checkpoint speed
 o enhance flush command management
 o bug fix for lseek
 o tune in-place-update policies
 o enhance roll-forward speed
 o revisit all the roll-forward and fsync rules
 o support large sector size
 o support FITRIM
 o support atomic and volatile writes

And several clean-ups and bug fixes are included.


Chao Yu (7):
  f2fs: remove unneeded sit_i in macro SIT_BLOCK_OFFSET/START_SEGNO
  f2fs: refactor flush_sit_entries codes for reducing SIT writes
  f2fs: fix to truncate blocks past EOF in ->setattr
  f2fs: support large sector size
  f2fs: skip punching hole in special condition
  f2fs: fix to clean previous mount option when remount_fs
  f2fs: fix to search whole dirty segmap when get_victim

Dan Carpenter (1):
  f2fs: potential shift wrapping buf in f2fs_trim_fs()

Gu Zheng (1):
  f2fs: use lock-less list(llist) to simplify the flush cmd management

Huang Ying (3):
  f2fs: avoid node page to be written twice in gc_node_segment
  f2fs: use nm_i->next_scan_nid as default for next_free_nid
  f2fs: fix a race condition in next_free_nid

Jaegeuk Kim (30):
  f2fs: introduce F2FS_I_SB, F2FS_M_SB, and F2FS_P_SB
  f2fs: retain inconsistency information to initiate fsck.f2fs
  f2fs: need fsck.f2fs when f2fs_bug_on is triggered
  f2fs: add BUG cases to initiate fsck.f2fs
  f2fs: handle bug cases by letting fsck.f2fs initiate
  f2fs: need fsck.f2fs if the recovery was failed
  f2fs: fix negative value for lseek offset
  f2fs: remove lengthy inode->i_ino
  f2fs: expand counting dirty pages in the inode page cache
  f2fs: give an option to enable in-place-updates during fsync to users
  f2fs: fix double lock for inode page during roll-foward recovery
  f2fs: use meta_inode cache to improve roll-forward speed
  f2fs: introduce a flag to represent each nat entry information
  f2fs: fix conditions to remain recovery information in f2fs_sync_file
  f2fs: fix roll-forward missing scenarios
  f2fs: do not skip latest inode information
  f2fs: remove redundant operation during roll-forward recovery
  f2fs: use MAX_BIO_BLOCKS(sbi)
  f2fs: update i_size when __allocate_data_block
  f2fs: change the ipu_policy option to enable combinations
  f2fs: use more free segments until SSR is activated
  f2fs: introduce cp_control structure
  f2fs: introduce FITRIM in f2fs_ioctl
  f2fs: refactor flush_nat_entries to remove costly reorganizing ops
  f2fs: check the use of macros on block counts and addresses
  f2fs: call f2fs_unlock_op after error was handled
  f2fs: clean up f2fs_ioctl functions
  f2fs: remove unused return value
  f2fs: support atomic writes
  f2fs: support volatile operations for transient data

 Documentation/ABI/testing/sysfs-fs-f2fs |   7 +
 Documentation/filesystems/f2fs.txt  |  13 +-
 fs/f2fs/checkpoint.c|  97 +++---
 fs/f2fs/data.c  |  69 +++--
 fs/f2fs/debug.c |  20 +-
 fs/f2fs/dir.c   |  19 +-
 fs/f2fs/f2fs.h  | 163 +++---
 fs/f2fs/file.c  | 257 
 fs/f2fs/gc.c|  26 +-
 fs/f2fs/inline.c|  20 +-
 fs/f2fs/inode.c |  37 ++-
 fs/f2fs/namei.c |  53 ++--
 fs/f2fs/node.c  | 460 ++--
 fs/f2fs/node.h  |  60 ++--
 fs/f2fs/recovery.c  | 191 +++-
 fs/f2fs/segment.c   | 520 +++-
 fs/f2fs/segment.h   | 160 ++
 fs/f2fs/super.c |  47 ++-
 fs/f2fs/xattr.c |   8 +-
 include/linux/f2fs_fs.h |   6 +-
 include/trace/

[GIT PULL] New Mailbox framework for 3.18

[Jassi Brar]

Hi Linus,

A framework for Mailbox controllers and clients have been cooking for
more than a year now. Everybody in the CC list had been copied on
patchset revisions and most of them have made sounds of approval,
though just one concrete Reviewed-by. The patchset has also been in
linux-next for a couple of weeks now and no conflict has been
reported. The framework has the backing of at least 5 platforms,
though I can't say if/when they upstream their drivers (some
businesses have 'changed').


The following changes since commit 9a50aaefc1b896e734bf7faf3d085f71a360ce97:

  Merge tag 'scsi-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi (2014-10-07
21:29:18 -0400)

are available in the git repository at:


  git://git.linaro.org/landing-teams/working/fujitsu/integration.git
mailbox-for-linus

for you to fetch changes up to 9f3e3cacb2ffdefe28c7cf490bf543e4dcb2770a:

  dt: mailbox: add generic bindings (2014-10-08 10:39:42 +0530)


Jassi Brar (3):
  mailbox: Introduce framework for mailbox
  doc: add documentation for mailbox framework
  dt: mailbox: add generic bindings

Suman Anna (1):
  mailbox: rename pl320-ipc specific mailbox.h

 .../devicetree/bindings/mailbox/mailbox.txt|  38 ++
 Documentation/mailbox.txt  | 122 ++
 MAINTAINERS|   8 +
 arch/arm/mach-highbank/highbank.c  |   2 +-
 drivers/cpufreq/highbank-cpufreq.c |   2 +-
 drivers/mailbox/Makefile   |   4 +
 drivers/mailbox/mailbox.c  | 465 +
 drivers/mailbox/pl320-ipc.c|   2 +-
 include/linux/mailbox_client.h |  46 ++
 include/linux/mailbox_controller.h | 133 ++
 include/linux/{mailbox.h => pl320-ipc.h}   |   0
 11 files changed, 819 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mailbox/mailbox.txt
 create mode 100644 Documentation/mailbox.txt
 create mode 100644 drivers/mailbox/mailbox.c
 create mode 100644 include/linux/mailbox_client.h
 create mode 100644 include/linux/mailbox_controller.h
 rename include/linux/{mailbox.h => pl320-ipc.h} (100%)


-- 
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106  -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
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: [v3,16/16] cxl: Add documentation for userspace APIs

[Michael Ellerman]

On Tue, 2014-07-10 at 10:48:22 UTC, Michael Neuling wrote:
> From: Ian Munsie 
> 
> This documentation gives an overview of the hardware architecture, userspace
> APIs via /dev/cxl/afu0.0 and the syfs files. It also adds a MAINTAINERS file

Elsewhere you talk about /dev/cxl/afuM.N, please be consistent.

> diff --git a/Documentation/ABI/testing/sysfs-class-cxl 
> b/Documentation/ABI/testing/sysfs-class-cxl
> new file mode 100644
> index 000..ca429fc
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-cxl
> @@ -0,0 +1,142 @@
> +Slave contexts (eg. /sys/class/cxl/afu0.0):

Don't slave contexts end with 's' ?

> +
> +What:/sys/class/cxl//irqs_max
> +Date:September 2014
> +Contact: Ian Munsie ,
> + Michael Neuling 

We just had to fix up a bunch of these for someone who left IBM. Would it be
better if they just pointed to linuxppc-dev ?

> +Description: read only
> + Maximum number of interrupts that can be requested by userspace.
> + The default on probe is the maximum that hardware can support
> + (eg. 2037). Write values will limit userspace applications to

I thought it was read only?

> + that many userspace interrupts. Must be >= irqs_min.

Decimal, hex?

> +What:/sys/class/cxl//irqs_min
> +Date:September 2014
> +Contact: Ian Munsie ,
> + Michael Neuling 
> +Description: read only
> + The minimum number of interrupts that userspace must request
> + on a CXL_START_WORK ioctl. Userspace may omit the
> + num_interrupts field in the START_WORK IOCTL to get this
> + minimum automatically.
> +
> +What:/sys/class/cxl//mmio_size
> +Date:September 2014
> +Contact: Ian Munsie ,
> + Michael Neuling 
> +Description: read only
> + Size of the MMIO space that may be mmaped by userspace.

Decimal, hex? Bytes, KB ?

> +What:/sys/class/cxl//models_supported
> +Date:September 2014
> +Contact: Ian Munsie ,
> + Michael Neuling 
> +Description: read only
> + List of the models this AFU supports.

So there can be more than one? How are multiple values separated?

> + Valid entries are: "dedicated_process" and "afu_directed"
> +
> +What:/sys/class/cxl//model
> +Date:September 2014
> +Contact: Ian Munsie ,
> + Michael Neuling 
> +Description: read/write
> + The current model the AFU is using. Will be one of the models
> + given in models_supported. Writing will change the model
> + provided that no user contexts are attached.
> +
> +
> +What:/sys/class/cxl//prefault_mode
> +Date:September 2014
> +Contact: Ian Munsie ,
> + Michael Neuling 
> +Description: read/write
> + Set the mode for prefaulting in segments into the segment table
> + when performing the START_WORK ioctl. Possible values:
> + none: No prefaulting (default)
> + wed: Treat the wed as an effective address and prefault 
> it
> + all: all segments this process currently maps

"this" process is not entirely clear. You mean "the process that calls 
START_WORK" ?


> +What:/sys/class/cxl//reset
> +Date:September 2014
> +Contact: Ian Munsie ,
> + Michael Neuling 
> +Description: write only
> + Reset the AFU.

How does this interact with the chardev API? Do my contexts go away or stop
working or anything?

> +What:/sys/class/cxl//api_version
> +Date:September 2014
> +Contact: Ian Munsie ,
> + Michael Neuling 
> +Description: read only
> + List the current version of the kernel/user API.

Show not List. Decimal, hex?

> +What:/sys/class/cxl//api_version_com
> +Date:September 2014
> +Contact: Ian Munsie ,
> + Michael Neuling 
> +Description: read only
> + List the lowest version the kernel/user API this
> + kernel is compatible with.

Show not List. Decimal, hex?

And needs to be clearer:

"The lowest version of the userspace API that this kernel supports."


> +Master contexts (eg. /sys/class/cxl/afu0.0m)
> +
> +What:/sys/class/cxl/m/mmio_size
> +Date:September 2014
> +Contact: Ian Munsie ,
> + Michael Neuling 
> +Description: read only
> + Size of the MMIO space that may be mmaped by userspace. This
> + includes all slave contexts space also.

Units.

> +What:/sys/class/cxl/m/pp_mmio_len
> +Date:September 2014
> +Contact: Ian Munsie ,
> + Michael Neuling 
> +Description: read only
> + Per Process MMIO space l

Re: High latency while CPU is under full load

[Mike Galbraith]

On Tue, 2014-10-07 at 21:28 +0200, Grozdan wrote: 
> Hi,
> 
> Basically, my problem is this:
> 
> I'm doing a lot of audio/video encoding on an AMD FX8350. The encoder
> process always runs at nice 10. Even so, my whole system feels very
> sluggish. Switching between different app windows and/or virtual
> desktops takes up usually 3-5 seconds giving the impression that there
> is not enough processing power. Browsing the web is also severely
> impacted.
> 
> I had to tune CFS in order to be (much) more responsive during an
> encoding session. This has worked out pretty well thus far, but it is
> my opinion that the user should *not* need to fiddle with buttons to
> make his system respond fluently even under high load. The below is
> what I had to do in order to get a snappy system during such load

You shouldn't have to do any CFS twiddling.

I kinda doubt it's the CPU scheduler, would be more inclined to suspect
mm/IO.  You could try the BFQ IO scheduler, that showed some promise on
my little box when doing hefty IO to my single speck of spinning rust.

If you want to try it, and can't find it, I can send you a quilt tarball
to plug into 3.16.4. 

> kernel.sched_nr_migrate = 64
> kernel.sched_latency_ns = 6500
> kernel.sched_wakeup_granularity_ns = 10

100us... that's a bad idea.

> kernel.sched_min_granularity_ns = 10

As is that, you'll likely be better off un-twiddling knobs.

> kernel.sched_migration_cost_ns = 700
> 
> I have tried 3 different kernels, including one compiled myself, but
> the results are the same
> Kernels I tried were: 3.11.10, 3.12 and 3.16.4 (self-compiled)
> 
> My system specs are as follows
> 
> CPU: AMD FX-8350 @ 4GHz
> RAM: 16GB DDR1333
> GPU: NVIDIA GTX 560 with NV blob driver

Not that I think NV is to blame, but you should probably try reproducing
the interactivity problem without that binary blob.  It's suspect just
for being a proprietary black hole, the perfect target to blame for all
your open source kernel woes ;-)

What are you encoding with what tools?  What does vmstat 1 look like
while box is working hard?  (With stock scheduler knobs I mean, and just
a few seconds)  Posting something easily reproducible (do this with that
tool) may help too.

-Mike

--
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 4/6] ARM: cygnus defconfig : Initial defconfig for Broadcom Cygnus SoC

[Scott Branden]

From: Jonathan Richardson 

Tested-by: Jonathan Richardson 
Reviewed-by: JD (Jiandong) Zheng 
Signed-off-by: Scott Branden 
---
 arch/arm/configs/bcm_cygnus_defconfig |  222 +
 1 file changed, 222 insertions(+)
 create mode 100644 arch/arm/configs/bcm_cygnus_defconfig

diff --git a/arch/arm/configs/bcm_cygnus_defconfig 
b/arch/arm/configs/bcm_cygnus_defconfig
new file mode 100644
index 000..d148f2d
--- /dev/null
+++ b/arch/arm/configs/bcm_cygnus_defconfig
@@ -0,0 +1,222 @@
+CONFIG_KERNEL_XZ=y
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+CONFIG_IRQ_DOMAIN_DEBUG=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=19
+CONFIG_CGROUPS=y
+CONFIG_CGROUP_FREEZER=y
+CONFIG_CGROUP_DEVICE=y
+CONFIG_CGROUP_CPUACCT=y
+CONFIG_RESOURCE_COUNTERS=y
+CONFIG_CGROUP_SCHED=y
+CONFIG_BLK_CGROUP=y
+CONFIG_NAMESPACES=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_ARCH_BCM=y
+CONFIG_ARCH_BCM_IPROC=y
+CONFIG_ARCH_BCM_CYGNUS=y
+CONFIG_ARM_THUMBEE=y
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+CONFIG_HIGHMEM=y
+# CONFIG_COMPACTION is not set
+# CONFIG_ATAGS is not set
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_CPU_IDLE=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+# CONFIG_SUSPEND is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_VERBOSE=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_MROUTE=y
+CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
+CONFIG_SYN_COOKIES=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_INET_DIAG is not set
+CONFIG_TCP_CONG_ADVANCED=y
+# CONFIG_TCP_CONG_BIC is not set
+# CONFIG_TCP_CONG_WESTWOOD is not set
+# CONFIG_TCP_CONG_HTCP is not set
+CONFIG_IPV6=y
+# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET6_XFRM_MODE_BEET is not set
+# CONFIG_IPV6_SIT is not set
+CONFIG_IPV6_MULTIPLE_TABLES=y
+CONFIG_IPV6_SUBTREES=y
+CONFIG_IPV6_MROUTE=y
+CONFIG_NETFILTER=y
+# CONFIG_BRIDGE_NETFILTER is not set
+CONFIG_NF_CONNTRACK=y
+# CONFIG_NF_CONNTRACK_PROCFS is not set
+CONFIG_NF_CONNTRACK_FTP=y
+CONFIG_NF_CONNTRACK_IPV4=y
+CONFIG_IP_NF_IPTABLES=y
+CONFIG_IP_NF_FILTER=y
+CONFIG_IP_NF_TARGET_REJECT=y
+CONFIG_IP_NF_NAT=y
+CONFIG_IP_NF_TARGET_MASQUERADE=y
+CONFIG_IP_NF_TARGET_REDIRECT=y
+CONFIG_IP_NF_MANGLE=y
+CONFIG_IP_NF_RAW=y
+CONFIG_NF_CONNTRACK_IPV6=y
+CONFIG_IP6_NF_IPTABLES=y
+CONFIG_IP6_NF_MATCH_AH=y
+CONFIG_IP6_NF_MATCH_EUI64=y
+CONFIG_IP6_NF_MATCH_FRAG=y
+CONFIG_IP6_NF_MATCH_OPTS=y
+CONFIG_IP6_NF_MATCH_IPV6HEADER=y
+CONFIG_IP6_NF_MATCH_MH=y
+CONFIG_IP6_NF_MATCH_RT=y
+CONFIG_IP6_NF_FILTER=y
+CONFIG_IP6_NF_TARGET_REJECT=y
+CONFIG_IP6_NF_MANGLE=y
+CONFIG_IP6_NF_RAW=y
+CONFIG_BRIDGE=y
+# CONFIG_BRIDGE_IGMP_SNOOPING is not set
+CONFIG_VLAN_8021Q=y
+CONFIG_NET_SCHED=y
+CONFIG_NET_SCH_FQ_CODEL=y
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_FIRMWARE_IN_KERNEL is not set
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_UBI=y
+# CONFIG_BLK_DEV is not set
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_NETDEVICES=y
+# CONFIG_NET_CADENCE is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+CONFIG_PHYLIB=y
+CONFIG_BROADCOM_PHY=y
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_KEYBOARD_ATKBD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_8250=y
+# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=2
+CONFIG_SERIAL_8250_RUNTIME_UARTS=2
+CONFIG_SERIAL_8250_DW=y
+CONFIG_SERIAL_OF_PLATFORM=y
+# CONFIG_HW_RANDOM is not set
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+# CONFIG_I2C_HELPER_AUTO is not set
+CONFIG_I2C_SMBUS=y
+CONFIG_SPI=y
+CONFIG_SPI_PL022=y
+CONFIG_SPI_SPIDEV=y
+CONFIG_GPIO_SYSFS=y
+# CONFIG_HWMON is not set
+CONFIG_WATCHDOG=y
+CONFIG_ARM_SP805_WATCHDOG=y
+CONFIG_FB=y
+CONFIG_FB_ARMCLCD=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+# CONFIG_LCD_CLASS_DEVICE is not set
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+# CONFIG_BACKLIGHT_GENERIC is not set
+CONFIG_BACKLIGHT_PWM=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_DYNAMIC_MINORS=y
+CONFIG_SND_VERBOSE_PRINTK=y
+CONFIG_SND_DEBUG=y
+CONFIG_

[PATCH 3/6] dt-bindings: Document Broadcom Cygnus SoC and clock driver

[Scott Branden]

From: Jonathan Richardson 

Reviewed-by: Arun Parameswaran 
Tested-by: Jonathan Richardson 
Reviewed-by: JD (Jiandong) Zheng 
Signed-off-by: Scott Branden 
---
 Documentation/devicetree/bindings/arm/cygnus.txt   |   12 ++
 .../devicetree/bindings/clock/clk-cygnus.txt   |  121 
 .../devicetree/bindings/clock/clk-iproc.txt|   48 
 3 files changed, 181 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/cygnus.txt
 create mode 100644 Documentation/devicetree/bindings/clock/clk-cygnus.txt
 create mode 100644 Documentation/devicetree/bindings/clock/clk-iproc.txt

diff --git a/Documentation/devicetree/bindings/arm/cygnus.txt 
b/Documentation/devicetree/bindings/arm/cygnus.txt
new file mode 100644
index 000..a210377
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cygnus.txt
@@ -0,0 +1,12 @@
+Broadcom Cygnus device tree bindings
+
+
+All Cygnus boards shall have the following properties:
+
+Required root node property:
+   - compatible = "brcm,cygnus";
+
+Boards variants shall have the following additional properties:
+
+Required root node property for the BCM911360_ENTPHN board:
+   - compatible = "brcm,bcm911360_entphn";
diff --git a/Documentation/devicetree/bindings/clock/clk-cygnus.txt 
b/Documentation/devicetree/bindings/clock/clk-cygnus.txt
new file mode 100644
index 000..7e03837
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-cygnus.txt
@@ -0,0 +1,121 @@
+Broadcom Cygnus Clock Controller
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+The Cygnus clock controller manages several PLL's and their channels, found 
only
+on the Cygnus chip. Clocks that are common to iProc can be found in the iProc
+clock controller. The controllers are split into a parent-child relationship
+where the parent is the PLL and the child controls the PLL's channels.
+
+All PLL's are derived from a 25MHz oscillator. The PLL's controlled are the
+GENPLL, LCPLL, the MIPI PLL. In addition, there are two clocks derived from
+GENPLL channel 0, and three that are derived directly from the oscillator.
+
+Required properties:
+- compatible: Must be one of the following:
+"brcm,cygnus-lcpll-clk" - Controls LCPLL.
+"brcm,cygnus-lcpll-ch" -  Controls LCPLL (parent) channels
+"brcm,cygnus-genpll-clk" - Controls parent GENPLL
+"brcm,cygnus-genpll-ch" - Controls GENPLL (parent) channels
+"brcm,cygnus-mipipll-clk" - Controls MIPI PLL
+"brcm,cygnus-mipipll-ch" - Controls parent MIPI PLL (parent) channels
+"brcm,cygnus-osc-derived" - Controls oscillator (parent) derived channels
+not controlled by any PLL.
+"brcm,cygnus-pll-derived" - Controls clocks derived from GENPLL channel 0.
+ These clocks have hard wired internal dividers and their clock rates
+ scale according to the GENPLL channel.
+
+- reg: First register is the base address of the PLL. Register 2 and 3 are
+  required by some clocks. They are the top clock gating control used to
+  enable/disable clocks (ch 1), and the CRMU PLL AON CONTROL register which
+  powers on PLL/LDO's (ch 2).
+
+- clocks: The input parent clock phandle for the clock. This is either a PLL,
+  oscillator, or GENPLL channel 0.
+
+- channel: The PLL channel that the clock belongs to. This is used for
+  "brcm,cygnus-lcpll-ch", "brcm,cygnus-genpll-ch", "brcm,cygnus-mipipll-ch",
+  "brcm,cygnus-osc-derived" only.
+
+- div: Used by "brcm,cygnus-pll-derived" to define the hard coded internal
+  divider value. Used by "brcm,cygnus-osc-derived" to specify the programmable
+  divider.
+
+- #clock-cells: From common clock binding; shall be set to 0.
+
+Examples:
+
+   osc: oscillator {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2500>;
+   };
+
+   lcpll: lcpll@0301d02c {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-lcpll-clk";
+   reg = <0x0301d02c 0x1c>;
+   clocks = <&osc>;
+   };
+
+   genpll: genpll@0301d000 {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-genpll-clk";
+   reg = <0x0301d000 0x2c>,
+ <0x180AA024 0x4>,
+ <0x0301C020 0x4>;
+   clocks = <&osc>;
+   };
+
+   axi21_clk: genpll_ch0@0301d000 {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-genpll-ch";
+   reg = <0x0301d000 0x2c>;
+   clocks = <&genpll>;
+   channel = <0>;
+   };
+
+   pcie_clk: lcpll_ch0@0301d02c {
+   compatible = "brcm,cygnus-lcpl

[PATCH 5/6] ARM: dts: Enable Broadcom Cygnus SoC

[Scott Branden]

From: Jonathan Richardson 

DT files to enable cygnus consisting of the enterprise phone board variant and
cygnus core configuration.

Reviewed-by: Ray Jui 
Reviewed-by: Arun Parameswaran 
Tested-by: Jonathan Richardson 
Reviewed-by: JD (Jiandong) Zheng 
Signed-off-by: Scott Branden 
---
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/bcm-cygnus.dtsi  |  349 
 arch/arm/boot/dts/bcm911360_entphn.dts |   22 ++
 3 files changed, 372 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm-cygnus.dtsi
 create mode 100644 arch/arm/boot/dts/bcm911360_entphn.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index b8c5cd3..b95d41d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -52,6 +52,7 @@ dtb-$(CONFIG_ARCH_AT91)   += sama5d36ek.dtb
 dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb
 dtb-$(CONFIG_ARCH_AXXIA) += axm5516-amarillo.dtb
 dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
+dtb-$(CONFIG_ARCH_BCM_CYGNUS) += bcm911360_entphn.dtb
 dtb-$(CONFIG_ARCH_BCM_5301X) += bcm4708-netgear-r6250.dtb
 dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm28155-ap.dtb \
bcm21664-garnet.dtb
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi 
b/arch/arm/boot/dts/bcm-cygnus.dtsi
new file mode 100644
index 000..81da0d8
--- /dev/null
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -0,0 +1,349 @@
+/*
+ * Copyright 2014 Broadcom Corporation.  All rights reserved.
+ *
+ * Unless you and Broadcom execute a separate written software license
+ * agreement governing use of this software, this software is licensed to you
+ * under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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 "skeleton.dtsi"
+
+/ {
+   compatible = "brcm,cygnus";
+   model = "Broadcom Cygnus SoC";
+   interrupt-parent = <&gic>;
+
+   aliases {
+   serial0 = &uart3;
+   serial1 = &uart0;
+   };
+
+   chosen {
+   bootargs = "console=ttyS0,115200 earlyprintk debug";
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "arm,cortex-a9";
+   next-level-cache = <&L2>;
+   reg = <0x0>;
+   };
+   };
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   osc: oscillator {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <2500>;
+   };
+
+   lcpll: lcpll@0301d02c {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-lcpll-clk";
+   reg = <0x0301d02c 0x1c>;
+   clocks = <&osc>;
+   };
+
+   genpll: genpll@0301d000 {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-genpll-clk";
+   reg = <0x0301d000 0x2c>,
+ <0x180AA024 0x4>,
+ <0x0301C020 0x4>;
+   clocks = <&osc>;
+   };
+
+   axi21_clk: genpll_ch0@0301d000 {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-genpll-ch";
+   reg = <0x0301d000 0x2c>;
+   clocks = <&genpll>;
+   channel = <0>;
+   };
+
+   clk_25MHz: genpll_ch1@0301d000 {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-genpll-ch";
+   reg = <0x0301d000 0x2c>;
+   clocks = <&genpll>;
+   channel = <1>;
+   };
+
+   sys_clk: genpll_ch2@0301d000 {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-genpll-ch";
+   reg = <0x0301d000 0x2c>;
+   clocks = <&genpll>;
+   channel = <2>;
+   };
+
+   ethernet_clk: genpll_ch3@0301d000 {
+   #clock-cells = <0>;
+   compatible = "brcm,cygnus-genpll-ch";
+   reg = <0x0301d000 0x2c>;
+   clocks = <&genpll>;
+   channel = <3>;
+   };
+
+   asiu_audio_clk: genpll_ch4@0301d000 {
+   #clock-cells = <0>;
+   compatible 

[PATCH 1/6] ARM: cygnus: Initial support for Broadcom Cygnus SoC

[Scott Branden]

From: Jonathan Richardson 

Adds initial support for the Cygnus SoC based on Broadcom’s iProc series.

Reviewed-by: Ray Jui 
Reviewed-by: Desmond Liu 
Reviewed-by: JD (Jiandong) Zheng 
Tested-by: Jonathan Richardson 
Signed-off-by: Scott Branden 
---
 arch/arm/mach-bcm/Kconfig  |   31 
 arch/arm/mach-bcm/Makefile |3 +
 arch/arm/mach-bcm/bcm_cygnus.c |  166 
 3 files changed, 200 insertions(+)
 create mode 100644 arch/arm/mach-bcm/bcm_cygnus.c

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index fc93800..2dd3f78 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -5,6 +5,37 @@ menuconfig ARCH_BCM
 
 if ARCH_BCM
 
+config ARCH_BCM_IPROC
+   bool "Broadcom ARMv7 iProc boards" if ARCH_MULTI_V7
+   select ARM_GIC
+   select CACHE_L2X0
+   select HAVE_ARM_TWD if LOCAL_TIMERS
+   select HAVE_CLK
+   select CLKSRC_OF
+   select CLKSRC_MMIO
+   select GENERIC_CLOCKEVENTS
+   select ARM_GLOBAL_TIMER
+   select ARCH_REQUIRE_GPIOLIB
+   select ARM_AMBA
+   select PINCTRL
+   select DEBUG_UART_8250
+   help
+ This enables support for systems based on Broadcom IPROC architected 
SoCs.
+ The IPROC complex contains one or more ARM CPUs along with common
+ core periperals. Application specific SoCs are created by adding a
+ uArchitecture containing peripherals outside of the IPROC complex.
+ Currently supported SoCs are Cygnus.
+
+menu "iProc SoC based Machine types"
+   depends on ARCH_BCM_IPROC
+
+   config ARCH_BCM_CYGNUS
+   bool "Support Broadcom Cygnus board"
+   select USB_ARCH_HAS_EHCI if USB_SUPPORT
+   help
+ Support for Broadcom Cygnus SoC.
+endmenu
+
 config ARCH_BCM_MOBILE
bool "Broadcom Mobile SoC Support" if ARCH_MULTI_V7
select ARCH_REQUIRE_GPIOLIB
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index b19a396..46e092a 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -10,6 +10,9 @@
 # of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 # GNU General Public License for more details.
 
+# Cygnus
+obj-$(CONFIG_ARCH_BCM_CYGNUS) +=  bcm_cygnus.o
+
 # BCM281XX
 obj-$(CONFIG_ARCH_BCM_281XX)   += board_bcm281xx.o
 
diff --git a/arch/arm/mach-bcm/bcm_cygnus.c b/arch/arm/mach-bcm/bcm_cygnus.c
new file mode 100644
index 000..8e430ed
--- /dev/null
+++ b/arch/arm/mach-bcm/bcm_cygnus.c
@@ -0,0 +1,166 @@
+/*
+ * Copyright 2014 Broadcom Corporation.  All rights reserved.
+ *
+ * Unless you and Broadcom execute a separate written software license
+ * agreement governing use of this software, this software is licensed to you
+ * under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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 
+
+#define CRMU_MAIL_BOX1  0x03024028
+#define CRMU_SOFT_RESET_CMD 0x
+
+/* CRU_RESET register */
+static void * __iomem crmu_mail_box1_reg;
+
+#ifdef CONFIG_NEON
+
+#define CRU_BASE  0x1800e000
+#define CRU_SIZE  0x34
+#define CRU_CONTROL_OFFSET0x0
+#define CRU_PWRDWN_EN_OFFSET  0x4
+#define CRU_PWRDWN_STATUS_OFFSET  0x8
+#define CRU_NEON0_HW_RESET  6
+#define CRU_CLAMP_ON_NEON0  20
+#define CRU_PWRONIN_NEON0   21
+#define CRU_PWRONOUT_NEON0  21
+#define CRU_PWROKIN_NEON0   22
+#define CRU_PWROKOUT_NEON0  22
+#define CRU_STATUS_DELAY_NS 500
+#define CRU_MAX_RETRY_COUNT 10
+#define CRU_RETRY_INTVL_US  1
+
+/* Power up the NEON/VFPv3 block. */
+static void bcm_cygnus_powerup_neon(void)
+{
+   void * __iomem cru_base = ioremap(CRU_BASE, CRU_SIZE);
+   u32 reg, i;
+
+   if (WARN_ON(!cru_base))
+   return;
+
+   /* De-assert the neon hardware block reset */
+   reg = readl(cru_base + CRU_CONTROL_OFFSET);
+   reg &= ~(1 << CRU_NEON0_HW_RESET);
+   writel(reg, cru_base + CRU_CONTROL_OFFSET);
+
+   /* Assert the power ON register bit */
+   reg = readl(cru_base + CRU_PWRDWN_EN_OFFSET);
+   reg |= (1 << CRU_PWRONIN_NEON0);
+   writel(reg, cru_base + CRU_PWRDWN_EN_OFFSET);
+
+   /*
+* Wait up to 10 usec in 1 usec increments for the
+* status register to acknowledge the power ON assert
+*/
+   for (i = 0; i < CRU_MAX_RETRY_COUNT; i++) {
+   reg = readl(cru_base + CRU_PWRDWN_STATUS_OFFSET);
+   if (reg & CRU_PWRONOUT_NEON0)
+   break;
+
+   udelay(CRU_RETRY_INTVL_US);
+   }
+
+   if (WARN_ON(i == CRU_MAX_

[PATCH 2/6] clk: Clock driver support for Broadcom Cygnus SoC

[Scott Branden]

From: Jonathan Richardson 

The iProc clock driver controls PLLs common across iProc chips. The
cygnus driver controls cygnus specific features and variations.

Reviewed-by: Ray Jui 
Tested-by: Jonathan Richardson 
Reviewed-by: JD (Jiandong) Zheng 
Signed-off-by: Scott Branden 
---
 drivers/clk/Makefile |1 +
 drivers/clk/bcm/Makefile |2 +
 drivers/clk/bcm/clk-cygnus.c | 1186 ++
 drivers/clk/bcm/clk-iproc.c  |  451 
 4 files changed, 1640 insertions(+)
 create mode 100644 drivers/clk/bcm/clk-cygnus.c
 create mode 100644 drivers/clk/bcm/clk-iproc.c

diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f537a0b..8ac0a31 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
 obj-$(CONFIG_COMMON_CLK_WM831X)+= clk-wm831x.o
 obj-$(CONFIG_COMMON_CLK_XGENE) += clk-xgene.o
 obj-$(CONFIG_COMMON_CLK_AT91)  += at91/
+obj-$(CONFIG_ARCH_BCM_IPROC)   += bcm/
 obj-$(CONFIG_ARCH_BCM_MOBILE)  += bcm/
 obj-$(CONFIG_ARCH_BERLIN)  += berlin/
 obj-$(CONFIG_ARCH_HI3xxx)  += hisilicon/
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index 6297d05..f803919 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -2,3 +2,5 @@ obj-$(CONFIG_CLK_BCM_KONA)  += clk-kona.o
 obj-$(CONFIG_CLK_BCM_KONA) += clk-kona-setup.o
 obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm281xx.o
 obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm21664.o
+obj-$(CONFIG_ARCH_BCM_IPROC)   += clk-iproc.o
+obj-$(CONFIG_ARCH_BCM_CYGNUS)  += clk-cygnus.o
diff --git a/drivers/clk/bcm/clk-cygnus.c b/drivers/clk/bcm/clk-cygnus.c
new file mode 100644
index 000..2a4f976
--- /dev/null
+++ b/drivers/clk/bcm/clk-cygnus.c
@@ -0,0 +1,1186 @@
+/*
+ * Copyright 2014 Broadcom Corporation.  All rights reserved.
+ *
+ * Unless you and Broadcom execute a separate written software license
+ * agreement governing use of this software, this software is licensed to you
+ * under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * 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 
+
+/*
+ * The CRU contains two similar PLLs: LCPLL and GENPLL,
+ * both with several output channels divided from the PLL
+ * output.
+ */
+
+#define CRU_LCPLL_CONTROL1_OFFSET  0x04
+#define CRU_LCPLL_STATUS_OFFSET0x18
+
+#define LCPLL0_PDIV_SHIFT   26
+#define LCPLL0_PDIV_MASK0xf
+#define LCPLL0_NDIV_SHIFT   16
+#define LCPLL0_NDIV_MASK0x3ff
+#define LCPLL_ENABLEB_CH_SHIFT  7
+#define LCPLL_ENABLEB_CH_MASK   0x3f
+#define LCPLL_MDIV_MASK 0xff
+#define LCPLL_STATUS_LOCK_SHIFT 12
+
+#define LCPLL0_CONTROL0_OFFSET  0x00
+#define LCPLL0_CONTROL1_OFFSET  0x04
+#define LCPLL0_CONTROL2_OFFSET  0x08
+#define LCPLL0_CONTROL3_OFFSET  0x0c
+
+#define GENPLL_CONTROL0_OFFSET 0x00
+#define GENPLL_CONTROL1_OFFSET 0x04
+#define GENPLL_CONTROL2_OFFSET 0x08
+#define GENPLL_CONTROL3_OFFSET 0x0c
+#define GENPLL_CONTROL4_OFFSET 0x10
+#define GENPLL_CONTROL5_OFFSET 0x14
+#define GENPLL_CONTROL6_OFFSET 0x18
+#define GENPLL_CONTROL7_OFFSET 0x1c
+#define GENPLL_CONTROL8_OFFSET 0x20
+#define GENPLL_CONTROL9_OFFSET 0x24
+#define GENPLL_STATUS_OFFSET   0x28
+
+#define GENPLL_ENABLEB_CH_SHIFT0x6
+#define GENPLL_ENABLEB_CH_MASK 0x3f
+
+#define GENPLL_STATUS_LOCK_SHIFT   12
+#define GENPLL_STATUS_LOCK_MASK1
+#define GENPLL_CONTROL4_NDIV_INT_SHIFT 20
+#define GENPLL_CONTROL4_NDIV_INT_MASK  0x3FF
+#define GENPLL_CONTROL4_NDIV_FRAC_SHIFT0
+#define GENPLL_CONTROL4_NDIV_FRAC_MASK 0xF
+#define GENPLL_CONTROL5_PDIV_SHIFT 0
+#define GENPLL_CONTROL5_PDIV_MASK  0xF
+#define GENPLL_MDIV_MASK   0xff
+
+#define MIPI_DSI_GENPLL_ENABLEB_CH_SHIFT   12
+#define NDIV_FRAC_DIVISOR  0x10
+
+#define ASIU_MIPI_GENPLL_PWRON_SHIFT  20
+#define ASIU_MIPI_GENPLL_PWRON_PLL_SHIFT  19
+#define ASIU_MIPI_GENPLL_PWRON_BG_SHIFT   18
+#define ASIU_MIPI_GENPLL_PWRON_LDO_SHIFT  17
+#define ASIU_MIPI_GENPLL_ISO_IN_SHIFT 16
+#define ASIU_AUDIO_GENPLL_PWRON_PLL_SHIFT 11
+#define ASIU_AUDIO_GENPLL_PWRON_BG_SHIFT  10
+#define ASIU_AUDIO_GENPLL_PWRON_LDO_SHIFT 9
+#define ASIU_AUDIO_GENPLL_ISO_IN  8
+
+#define CLK_RATE_NO_DIV   -1
+
+/*
+ * The clock framework may call recalc even if a clock is is unused, and
+ * therefore before being prepared/enabled. State checking is done for the
+ * MIPI PLL to prevent reading from a MIPI DSI register before the PLL is
+ * powered up because it will cause corruption (imprecise external ab

[PATCH 6/6] MAINTAINERS: Entry for Cygnus/iproc arm architecture and clock drivers

[Scott Branden]

From: Jonathan Richardson 

Acked-by: Jonathan Richardson 
Signed-off-by: Scott Branden 
---
 MAINTAINERS |   15 +++
 1 file changed, 15 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a12edf2..9024bac 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2071,6 +2071,21 @@ L:   linux-s...@vger.kernel.org
 S: Supported
 F: drivers/scsi/bnx2i/
 
+BROADCOM CYGNUS/IPROC ARM ARCHITECTURE
+M: Jonathan Richardson 
+M: Scott Branden 
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/arm/cygnus.txt
+F: arch/arm/boot/dts/bcm-cygnus.dtsi
+F: arch/arm/boot/dts/bcm911360_entphn.dts
+F: arch/arm/configs/bcm_cygnus_defconfig
+F: arch/arm/mach-bcm/board_bcm_cygnus.c
+F: Documentation/devicetree/bindings/clock/clk-cygnus.txt
+F: Documentation/devicetree/bindings/clock/clk-iproc.txt
+F: drivers/clk/bcm/clk-cygnus.c
+F: drivers/clk/bcm/clk-iproc.c
+
 BROADCOM KONA GPIO DRIVER
 M: Ray Jui 
 L: bcm-kernel-feedback-l...@broadcom.com
-- 
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/

[PATCH V3 0/6] Add initial support for Broadcom Cygnus SoC

[Scott Branden]

This patchset contains initial support for Broadcom's Cygnus SoC based on our
iProc architecture. Initial support is minimal and includes just the mach
platform code, clock driver, and a basic device tree configuration. Peripheral
drivers will be submitted soon, as will device tree configurations for other
Cygnus board variants.

Changes from v2:
 - rebased to 3.17 kernel

Changes from v1:
 - Address code review comments as per previous responses.
 - Copyright headers updated to remove Broadcom URL.
 - mach platform code still contains hard coded addresses. These address are
   the same for all Cygnus variants. Could you please provide guidance on where
   they should go if you would still like them changed.  There does not seem to
   be a reason to change them to device tree as they do not change.

Jonathan Richardson (6):
  ARM: cygnus: Initial support for Broadcom Cygnus SoC
  clk: Clock driver support for Broadcom Cygnus SoC
  dt-bindings: Document Broadcom Cygnus SoC and clock driver
  ARM: cygnus defconfig : Initial defconfig for Broadcom Cygnus SoC
  ARM: dts: Enable Broadcom Cygnus SoC
  MAINTAINERS: Entry for Cygnus/iproc arm architecture and clock
drivers

 Documentation/devicetree/bindings/arm/cygnus.txt   |   12 +
 .../devicetree/bindings/clock/clk-cygnus.txt   |  121 ++
 .../devicetree/bindings/clock/clk-iproc.txt|   48 +
 MAINTAINERS|   15 +
 arch/arm/boot/dts/Makefile |1 +
 arch/arm/boot/dts/bcm-cygnus.dtsi  |  349 ++
 arch/arm/boot/dts/bcm911360_entphn.dts |   22 +
 arch/arm/configs/bcm_cygnus_defconfig  |  222 
 arch/arm/mach-bcm/Kconfig  |   31 +
 arch/arm/mach-bcm/Makefile |3 +
 arch/arm/mach-bcm/bcm_cygnus.c |  166 +++
 drivers/clk/Makefile   |1 +
 drivers/clk/bcm/Makefile   |2 +
 drivers/clk/bcm/clk-cygnus.c   | 1186 
 drivers/clk/bcm/clk-iproc.c|  451 
 15 files changed, 2630 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/cygnus.txt
 create mode 100644 Documentation/devicetree/bindings/clock/clk-cygnus.txt
 create mode 100644 Documentation/devicetree/bindings/clock/clk-iproc.txt
 create mode 100644 arch/arm/boot/dts/bcm-cygnus.dtsi
 create mode 100644 arch/arm/boot/dts/bcm911360_entphn.dts
 create mode 100644 arch/arm/configs/bcm_cygnus_defconfig
 create mode 100644 arch/arm/mach-bcm/bcm_cygnus.c
 create mode 100644 drivers/clk/bcm/clk-cygnus.c
 create mode 100644 drivers/clk/bcm/clk-iproc.c

-- 
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 v3] Tools: hv: vssdaemon: ignore the EBUSY on multiple freezing the same partition

[Dexuan Cui]

> -Original Message-
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf
> Of Dexuan Cui
> Sent: Friday, September 26, 2014 12:52 PM
> To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com
> Cc: Haiyang Zhang
> Subject: [PATCH v3] Tools: hv: vssdaemon: ignore the EBUSY on multiple
> freezing the same partition
> 
> If a partition appears mounted more than once in /proc/mounts, vss_do_freeze()
> succeeds only for the first time and gets EBUSY (on freeze) or EINVAL (on
> thaw) for the second time. The patch ignores these to make the backup feature
> work.
> 
> Also improved the error handling in case a freeze operation fails.
> 
> Signed-off-by: Dexuan Cui 
> Reviewed-by: K. Y. Srinivasan 
> ---
> 
> v2: Add "errno = 0;" before the ioctl()
> (Unnecessary and removed now since we remove syslog() in vss_do_freeze() in
> v3)
> 
> v3: Remove the unsafe syslog() in vss_do_freeze(): that could write the disk.
> Thaw the filesystems in case the freezing operation fails.
> In main(), add syslog() when we check the return value of vss_operate().
> 
>  tools/hv/hv_vss_daemon.c | 48

Hi Greg,
Ping.

Thanks,
-- Dexuan
--
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] net: fec: fix regression on i.MX28 introduced by rx_copybreak support

[Lothar Waßmann]

Hi,

David Laight wrote:
> From: Eric Dumazet
> > On Tue, 2014-10-07 at 15:19 +0200, Lothar Wamann wrote:
> > > commit 1b7bde6d659d ("net: fec: implement rx_copybreak to improve rx 
> > > performance")
> > > introduced a regression for i.MX28. The swap_buffer() function doing
> > > the endian conversion of the received data on i.MX28 may access memory
> > > beyond the actual packet size in the DMA buffer. fec_enet_copybreak()
> > > does not copy those bytes, so that the last bytes of a packet may be
> > > filled with invalid data after swapping.
> > > This will likely lead to checksum errors on received packets.
> > > E.g. when trying to mount an NFS rootfs:
> > > UDP: bad checksum. From 192.168.1.225:111 to 192.168.100.73:44662 ulen 36
> > >
> > > Do the byte swapping and copying to the new skb in one go if
> > > necessary.
> > >
> > > Signed-off-by: Lothar Wamann 
> > > ---
> > >  drivers/net/ethernet/freescale/fec_main.c |   25 
> > > +
> > >  1 file changed, 21 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/freescale/fec_main.c 
> > > b/drivers/net/ethernet/freescale/fec_main.c
> > > index 87975b5..eaaebad 100644
> > > --- a/drivers/net/ethernet/freescale/fec_main.c
> > > +++ b/drivers/net/ethernet/freescale/fec_main.c
> > > @@ -339,6 +339,18 @@ static void *swap_buffer(void *bufaddr, int len)
> > >   return bufaddr;
> > >  }
> > >
> > > +static void *swap_buffer2(void *dst_buf, void *src_buf, int len)
> > > +{
> > > + int i;
> > > + unsigned int *src = src_buf;
> > > + unsigned int *dst = dst_buf;
> > > +
> > > + for (i = 0; i < DIV_ROUND_UP(len, 4); i++, src++, dst++)
> > > + *dst = cpu_to_be32(*src);
> > 
> > No need for the DIV :
> > 
> > for (i = 0; i < len; i += sizeof(*dst), src++, dst++)
> > *dst = cpu_to_be32(*src);
> > 
> > Also are you sure both src/dst are aligned to word boundaries, or is
> > this architecture OK with possible misalignment ?
> 
> I wondered about that as well.
> I wouldn't have expected ppc to support misaligned transfers, and you'd also
> want to make sure that cpu_to_be(*src) was using a byte-swapping instruction.
> Hmmm... cpu_to_be() doesn't sound like the right 'swap' macro name.
> 
??? So what is cpu_to_be32() then?
The new swap function is an exact copy of the original one already in
use except for the fact that it uses distinct source and destination
buffers.


Lothar Waßmann
-- 
___

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | i...@karo-electronics.de
___
--
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] net: fec: fix regression on i.MX28 introduced by rx_copybreak support

[Lothar Waßmann]

Hi,

David Laight wrote:
> From: Lothar
> > David Laight wrote:
> > > From: Lothar Waßmann
> > > > commit 1b7bde6d659d ("net: fec: implement rx_copybreak to improve rx 
> > > > performance")
> > > > introduced a regression for i.MX28. The swap_buffer() function doing
> > > > the endian conversion of the received data on i.MX28 may access memory
> > > > beyond the actual packet size in the DMA buffer. fec_enet_copybreak()
> > > > does not copy those bytes, so that the last bytes of a packet may be
> > > > filled with invalid data after swapping.
> > > > This will likely lead to checksum errors on received packets.
> > > > E.g. when trying to mount an NFS rootfs:
> > > > UDP: bad checksum. From 192.168.1.225:111 to 192.168.100.73:44662 ulen 
> > > > 36
> > > >
> > > > Do the byte swapping and copying to the new skb in one go if
> > > > necessary.
> > >
> > > ISTM that if you need to do the 'swap' you should copy the data regardless
> > > of the length.
> > >
> > The swap function has to look at at most 3 bytes beyond the actual
> > packet length. That is what the original swap_buffer() function does and
> > what the new function swap_buffer2(), that does the endian swapping
> > while copying to the new buffer, also does.
> 
> I understood the bug.
> 
> The point I was making is that if you have to do a read-write of the received
> data (to byteswap it) then you might as well always copy it into a new skb 
> that
> is just big enough for the actual receive frame.
> 
I wanted to use the least intrusive solution.


Lothar Waßmann
-- 
___

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | i...@karo-electronics.de
___
--
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.16 00/26] 3.16.5-stable review

[Greg Kroah-Hartman]

On Tue, Oct 07, 2014 at 07:47:13PM -0700, Guenter Roeck wrote:
> On 10/07/2014 04:19 PM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 3.16.5 release.
> >There are 26 patches in this series, all will be posted as a response
> >to this one.  If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Thu Oct  9 23:18:40 UTC 2014.
> >Anything received after that time might be too late.
> >
> 
> Build results:
>   total: 136 pass: 136 fail: 0
> Qemu tests:
>   total: 30 pass: 30 fail: 0
> 
> Details are available at http://server.roeck-us.net:8010/builders.

Wonderful, thanks for testing all 3 of these and letting me know.

greg k-h
--
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: [GIT PULL] ring-buffer: Fix infinite spin in reading buffer

[Greg Kroah-Hartman]

On Tue, Oct 07, 2014 at 09:40:11PM -0500, Chuck Ebbert wrote:
> On Sun, 5 Oct 2014 16:49:43 -0700
> Greg Kroah-Hartman  wrote:
> 
> > On Fri, Oct 03, 2014 at 04:20:43PM -0400, Steven Rostedt wrote:
> 
> ...
> 
> > > Fixes: 651e22f2701b "ring-buffer: Always reset iterator to reader 
> > > page"
> > > Signed-off-by: Steven Rostedt 
> > 
> > Next time, please also add a Cc: stable...  here so that my tools pick
> > it up automatically.
> > 
> 
> Can you add "Fixes:" to the list of keywords your tools pick up, and
> determine if the patch is needed in -stable by looking at the commit ID
> that's being fixed? Some authors might not remember if the thing being
> fixed has made it into an older release via -stable.

I do that as well, but I don't advertise it as much, as it's easier for
me with the cc: stable marking :)

thanks,

greg k-h
--
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] net: fec: fix regression on i.MX28 introduced by rx_copybreak support

[Lothar Waßmann]

Hi,

David Miller wrote:
> From: Lothar Waßmann 
> Date: Tue,  7 Oct 2014 15:19:37 +0200
> 
> > commit 1b7bde6d659d ("net: fec: implement rx_copybreak to improve rx 
> > performance")
> > introduced a regression for i.MX28. The swap_buffer() function doing
> > the endian conversion of the received data on i.MX28 may access memory
> > beyond the actual packet size in the DMA buffer. fec_enet_copybreak()
> > does not copy those bytes, so that the last bytes of a packet may be
> > filled with invalid data after swapping.
> > This will likely lead to checksum errors on received packets.
> > E.g. when trying to mount an NFS rootfs:
> > UDP: bad checksum. From 192.168.1.225:111 to 192.168.100.73:44662 ulen 36
> > 
> > Do the byte swapping and copying to the new skb in one go if
> > necessary.
> > 
> > Signed-off-by: Lothar Waßmann 
> 
> Why don't you just round up the length fec_enet_copybreak() uses when
> need_swap is true?  Then you will end up mimicking the original behavior
> and not require this new helper function.
> 
I wanted to eliminate the need to access the buffer twice (once for
copying and once for swapping).

> And in any case I agree with Sergei that if you do retain your approach,
> the new 'swap' argument to fec_enet_copybreak() should be a 'bool'.
> 
Right.

> I'm really surprised there isn't a control register bit to adjust the
> endianness of the data DMA'd to/from the network.
>
This is a "feature" of the i.MX28.


Lothar Waßmann
-- 
___

Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Geschäftsführer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | i...@karo-electronics.de
___
--
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] spi: pl022: Fix broken spidev when DMA is enabled

[Ray Jui]

The PL022 SPI driver maps the DMA RX buffer before the DMA TX buffer. In
most cases, the sequence of the mapping does not matter. But in cases
where TX and RX happen to use the same buffer, e.g., spidev, it causes
the cached TX data not written to memory, because the same memory has
been marked invalid when dma_map_sg on the RX buffer is called

The solution is to reverse the sequence so it maps the TX buffer before
the RX buffer

Signed-off-by: Ray Jui 
Reviewed-by: JD (Jiandong) Zheng 
Tested-by: Scott Branden 
Reviewed-by: Scott Branden 
---
 drivers/spi/spi-pl022.c |   20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 1189cfd..edb7298 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -773,10 +773,10 @@ static void *next_transfer(struct pl022 *pl022)
 static void unmap_free_dma_scatter(struct pl022 *pl022)
 {
/* Unmap and free the SG tables */
-   dma_unmap_sg(pl022->dma_tx_channel->device->dev, pl022->sgt_tx.sgl,
-pl022->sgt_tx.nents, DMA_TO_DEVICE);
dma_unmap_sg(pl022->dma_rx_channel->device->dev, pl022->sgt_rx.sgl,
 pl022->sgt_rx.nents, DMA_FROM_DEVICE);
+   dma_unmap_sg(pl022->dma_tx_channel->device->dev, pl022->sgt_tx.sgl,
+pl022->sgt_tx.nents, DMA_TO_DEVICE);
sg_free_table(&pl022->sgt_rx);
sg_free_table(&pl022->sgt_tx);
 }
@@ -1026,16 +1026,16 @@ static int configure_dma(struct pl022 *pl022)
  pl022->cur_transfer->len, &pl022->sgt_tx);
 
/* Map DMA buffers */
-   rx_sglen = dma_map_sg(rxchan->device->dev, pl022->sgt_rx.sgl,
-  pl022->sgt_rx.nents, DMA_FROM_DEVICE);
-   if (!rx_sglen)
-   goto err_rx_sgmap;
-
tx_sglen = dma_map_sg(txchan->device->dev, pl022->sgt_tx.sgl,
   pl022->sgt_tx.nents, DMA_TO_DEVICE);
if (!tx_sglen)
goto err_tx_sgmap;
 
+   rx_sglen = dma_map_sg(rxchan->device->dev, pl022->sgt_rx.sgl,
+  pl022->sgt_rx.nents, DMA_FROM_DEVICE);
+   if (!rx_sglen)
+   goto err_rx_sgmap;
+
/* Send both scatterlists */
rxdesc = dmaengine_prep_slave_sg(rxchan,
  pl022->sgt_rx.sgl,
@@ -1070,12 +1070,12 @@ err_txdesc:
dmaengine_terminate_all(txchan);
 err_rxdesc:
dmaengine_terminate_all(rxchan);
+   dma_unmap_sg(rxchan->device->dev, pl022->sgt_rx.sgl,
+pl022->sgt_rx.nents, DMA_FROM_DEVICE);
+err_rx_sgmap:
dma_unmap_sg(txchan->device->dev, pl022->sgt_tx.sgl,
 pl022->sgt_tx.nents, DMA_TO_DEVICE);
 err_tx_sgmap:
-   dma_unmap_sg(rxchan->device->dev, pl022->sgt_rx.sgl,
-pl022->sgt_tx.nents, DMA_FROM_DEVICE);
-err_rx_sgmap:
sg_free_table(&pl022->sgt_tx);
 err_alloc_tx_sg:
sg_free_table(&pl022->sgt_rx);
-- 
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/

[PATCH v10 3/3] dt-bindings: video: Add documentation for rockchip vop

[Mark Yao]

From: Mark yao 

This adds binding documentation for Rockchip SoC VOP driver.

Signed-off-by: Mark Yao 
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem

Changes in v3: None

Changes in v4: None

Changes in v5: None

Changes in v6: None

Changes in v7: None

Changes in v8: None

Changes in v9: None

Changes in v10: None

 .../devicetree/bindings/video/rockchip-vop.txt |   58 
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-vop.txt

diff --git a/Documentation/devicetree/bindings/video/rockchip-vop.txt 
b/Documentation/devicetree/bindings/video/rockchip-vop.txt
new file mode 100644
index 000..d15351f
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-vop.txt
@@ -0,0 +1,58 @@
+device-tree bindings for rockchip soc display controller (vop)
+
+VOP (Visual Output Processor) is the Display Controller for the Rockchip
+series of SoCs which transfers the image data from a video memory
+buffer to an external LCD interface.
+
+Required properties:
+- compatible: value should be one of the following
+   "rockchip,rk3288-vop";
+
+- interrupts: should contain a list of all VOP IP block interrupts in the
+order: VSYNC, LCD_SYSTEM. The interrupt specifier
+format depends on the interrupt controller used.
+
+- clocks: must include clock specifiers corresponding to entries in the
+   clock-names property.
+
+- clock-names: Must contain
+   aclk_vop: for ddr buffer transfer.
+   hclk_vop: for ahb bus to R/W the phy regs.
+   dclk_vop: pixel clock.
+
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - axi
+  - ahb
+  - dclk
+
+- iommus: required a iommu node
+
+- port: A port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+SoC specific DT entry:
+   vopb: vopb@ff93 {
+   compatible = "rockchip,rk3288-vop";
+   reg = <0xff93 0x19c>;
+   interrupts = ;
+   clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>;
+   clock-names = "aclk_vop", "dclk_vop", "hclk_vop";
+   resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru 
SRST_LCDC1_DCLK>;
+   reset-names = "axi", "ahb", "dclk";
+   iommus = <&vopb_mmu>;
+   vopb_out: port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   vopb_out_edp: endpoint@0 {
+   reg = <0>;
+   remote-endpoint=<&edp_in_vopb>;
+   };
+   vopb_out_hdmi: endpoint@1 {
+   reg = <1>;
+   remote-endpoint=<&hdmi_in_vopb>;
+   };
+   };
+   };
-- 
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/

[PATCH v10 1/3] drm: rockchip: Add basic drm driver

[Mark Yao]

From: Mark yao 

This patch adds the basic structure of a DRM Driver for Rockchip Socs.

Signed-off-by: Mark Yao 
Signed-off-by: Daniel Kurtz 
Acked-by: Daniel Vetter 
Reviewed-by: Rob Clark 
---
Changes in v2:
- use the component framework to defer main drm driver probe
  until all VOP devices have been probed.
- use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
  master device and each vop device can shared the drm dma mapping.
- use drm_crtc_init_with_planes and drm_universal_plane_init.
- remove unnecessary middle layers.
- add cursor set, move funcs to rockchip drm crtc.
- use vop reset at first init
- reference framebuffer when used and unreference when swap out vop

Changes in v3:
- change "crtc->fb" to "crtc->primary-fb"
Adviced by Daniel Vetter
- init cursor plane with universal api, remove unnecessary cursor set,move 

Changes in v4:
Adviced by David Herrmann
- remove drm_platform_*() usage, use register drm device directly.
Adviced by Rob Clark
- remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset

Changes in v5:
Adviced by Arnd Bergmann
- doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
- fix some incorrect dependencies.
Adviced by Boris BREZILLON
- fix some mistake and bugs. 
Adviced by Daniel Vetter
- drop all special ioctl and use generic kms ioctl instead.
Adviced by Rob Clark
- use unlocked api for drm_fb_helper_restore_fbdev_mode.
- remove unused rockchip_gem_prime_import_sg_table.

Changes in v6:
- set gem buffer pitch 64 bytes align, needed by mali gpu.
Adviced by Daniel Kurtz
- fix some mistake, bugs, remove unused define, more better code style etc. 
- use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable()
  at runtime instead of clk_prepare_enable().
- provide a help function from vop for encoder to do mode config, instead of
  using drm_diaplay_mode private method.
- change vop mode_set timing to make it more safely. 

Changes in v7:
- fix memory leakage problem

Changes in v8:
- fix iommu crash when use dual crtc.
- use frame start interrupt for vsync instead of line flag interrupt,
because the win config take affect at frame start time, if we use ling flag
interrupt, the address check often failed.
Adviced by Daniel Kurtz
- fix some bugs, mistake, remove unused function
- keep clock and vop disabled when probe end
- use drm_plane_helper_check_update to check update_plane if vaild

Changes in v9:
- fix suspend and resume bug, make iommu attach and detach safely.

Changes in v10:
Adviced by Andrzej Hajda
- check drm_dev if it's NULL at PM suspend/resume
Adviced by Sean Paul
- use drm_fb_helper_prepare to init fb_helper funcs
- Optimized code structure and remove some unnecessary Variables.

 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/rockchip/Kconfig  |   17 +
 drivers/gpu/drm/rockchip/Makefile |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  465 
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h   |   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c|  200 
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h|   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c |  210 
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c   |  294 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h   |   54 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c   | 1415 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h   |  196 
 14 files changed, 2965 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/Kconfig
 create mode 100644 drivers/gpu/drm/rockchip/Makefile
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_drv.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fb.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_gem.h
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.c
 create mode 100644 drivers/gpu/drm/rockchip/rockchip_drm_vop.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b066bb3..7c4c3c6 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -171,6 +171,8 @@ config DRM_SAVAGE
 
 source "drivers/gpu/drm/exynos/Kconfig"
 
+source "drivers/gpu/drm/rockchip/Kconfig"
+
 source "drivers/gpu/drm/vmwgfx/Kconfig"
 
 source "drivers/gpu/drm/gma500/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 4a55d59..d03387a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/
 obj-$(CONFIG_DRM_VIA)  +=via/
 obj-$(CONFIG_DRM_NOUVEAU) 

[PATCH v10 2/3] dt-bindings: video: Add for rockchip display subsytem

[Mark Yao]

From: Mark yao 

This add a display subsystem comprise the all display interface nodes.

Signed-off-by: Mark Yao 
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
  the graphics subsystem.

Changes in v3: None

Changes in v4: None

Changes in v5: None

Changes in v6: None

Changes in v7: None

Changes in v8: None

Changes in v9: None

Changes in v10: None

 .../devicetree/bindings/video/rockchip-drm.txt |   19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/rockchip-drm.txt

diff --git a/Documentation/devicetree/bindings/video/rockchip-drm.txt 
b/Documentation/devicetree/bindings/video/rockchip-drm.txt
new file mode 100644
index 000..7fff582
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/rockchip-drm.txt
@@ -0,0 +1,19 @@
+Rockchip DRM master device
+
+
+The Rockchip DRM master device is a virtual device needed to list all
+vop devices or other display interface nodes that comprise the
+graphics subsystem.
+
+Required properties:
+- compatible: Should be "rockchip,display-subsystem"
+- ports: Should contain a list of phandles pointing to display interface port
+  of vop devices. vop definitions as defined in
+  Documentation/devicetree/bindings/video/rockchip-vop.txt
+
+example:
+
+display-subsystem {
+   compatible = "rockchip,display-subsystem";
+   ports = <&vopl_out>, <&vopb_out>;
+};
-- 
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/

[PATCH v10 0/3] Add drm driver for Rockchip Socs

[Mark Yao]

This a series of patches is a DRM Driver for Rockchip Socs, add support
for vop devices. Future patches will add additional encoders/connectors,
such as eDP, HDMI.

The basic "crtc" for rockchip is a "VOP" - Video Output Processor.
the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two similar
Vop devices. Vop devices support iommu mapping, we use dma-mapping API with
ARM_DMA_USE_IOMMU.

Changes in v2:
- add DRM master device node to list all display nodes that comprise
  the graphics subsystem.
- use the component framework to defer main drm driver probe
  until all VOP devices have been probed.
- use dma-mapping API with ARM_DMA_USE_IOMMU, create dma mapping by
  master device and each vop device can shared the drm dma mapping.
- use drm_crtc_init_with_planes and drm_universal_plane_init.
- remove unnecessary middle layers.
- add cursor set, move funcs to rockchip drm crtc.
- add vop reset.

Changes in v3:
- change "crtc->fb" to "crtc->primary-fb"
Adviced by Daniel Vetter
- init cursor plane with universal api, remove unnecessary cursor set,move 

Changes in v4:
Adviced by David Herrmann
- remove drm_platform_*() usage, use register drm device directly.
Adviced by Rob Clark
- remove special mmap ioctl, do userspace mmap with normal mmap() or mmap offset

Changes in v5:
Adviced by Arnd Bergmann
- doing DMA start with a 32-bit masks with dma_mask and dma_coherent_mark
- fix some incorrect dependencies.
Adviced by Boris BREZILLON
- fix some mistake and bugs. 
Adviced by Daniel Vetter
- drop all special ioctl and use generic kms ioctl instead.
Adviced by Rob Clark
- use unlocked api for drm_fb_helper_restore_fbdev_mode.
- remove unused rockchip_gem_prime_import_sg_table.

Changes in v6:
- set gem buffer pitch 64 bytes align, needed by mali gpu.
Adviced by Daniel Kurtz
- fix some mistake, bugs, remove unused define, more better code style etc. 
- use clk_prepare()/unprepare() at probe()/remove() and clk_enable()/disable()
  at runtime instead of clk_prepare_enable().
- provide a help function from vop for encoder to do mode config, instead of
  using drm_diaplay_mode private method.
- change vop mode_set timing to make it more safely. 

Changes in v7:
- fix memory leakage problem.

Changes in v8:
- fix iommu crash when use dual crtc.
- use frame start interrupt for vsync instead of line flag interrupt,
because the win config take affect at frame start time, if we use ling flag
interrupt, the address check often failed.
Adviced by Daniel Kurtz
- fix some bugs, mistake, remove unused function
- keep clock and vop disabled when probe end
- use drm_plane_helper_check_update to check update_plane if vaild

Changes in v9:
- fix suspend and resume bug, make iommu attach and detach safely.
- fix mail info style.

Changes in v10:
Adviced by Andrzej Hajda
- check drm_dev if it's NULL at PM suspend/resume
Adviced by Sean Paul
- use drm_fb_helper_prepare to init fb_helper funcs
- Optimized code structure and remove some unnecessary Variables.

Mark yao (3):
  drm: rockchip: Add basic drm driver
  dt-bindings: video: Add for rockchip display subsytem
  dt-bindings: video: Add documentation for rockchip vop

 .../devicetree/bindings/video/rockchip-drm.txt |   19 +
 .../devicetree/bindings/video/rockchip-vop.txt |   58 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/rockchip/Kconfig   |   17 +
 drivers/gpu/drm/rockchip/Makefile  |8 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c|  465 +++
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h|   55 +
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c |  200 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h |   28 +
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c  |  210 +++
 drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h  |   20 +
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c|  294 
 drivers/gpu/drm/rockchip/rockchip_drm_gem.h|   54 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 1415 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h|  196 +++
 16 files changed, 3042 insertions(+)

-- 
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/

[PATCH ftrace/for-next V2] tracing/kprobes: Add selftest scripts testing kprobe-tracer as startup test

[Masami Hiramatsu]

Add two selftest scripts which tests kprobe-tracer as the startup
selftest does.
These test cases are testing that the kprobe_event can accept a
kprobe event with $stack related arguments and a kretprobe event
with $retval argument.

Signed-off-by: Masami Hiramatsu 
---
 .../selftests/ftrace/test.d/kprobe/kprobe_args.tc  |   16 
 .../ftrace/test.d/kprobe/kretprobe_args.tc |   15 +++
 2 files changed, 31 insertions(+)
 create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args.tc
 create mode 100644 
tools/testing/selftests/ftrace/test.d/kprobe/kretprobe_args.tc

diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args.tc 
b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args.tc
new file mode 100644
index 000..a603d3f
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args.tc
@@ -0,0 +1,16 @@
+#!/bin/sh
+# description: Kprobe dynamic event with arguments
+
+[ -f kprobe_events ] || exit_unsupported # this is configurable
+
+echo 0 > events/enable
+echo > kprobe_events
+echo 'p:testprobe do_fork $stack $stack0 +0($stack)' > kprobe_events
+grep testprobe kprobe_events
+test -d events/kprobes/testprobe
+echo 1 > events/kprobes/testprobe/enable
+( echo "forked")
+echo 0 > events/kprobes/testprobe/enable
+echo "-:testprobe" >> kprobe_events
+test -d events/kprobes/testprobe && exit 1 || exit 0
+
diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kretprobe_args.tc 
b/tools/testing/selftests/ftrace/test.d/kprobe/kretprobe_args.tc
new file mode 100644
index 000..283c29e
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kretprobe_args.tc
@@ -0,0 +1,15 @@
+#!/bin/sh
+# description: Kretprobe dynamic event with arguments
+
+[ -f kprobe_events ] || exit_unsupported # this is configurable
+
+echo 0 > events/enable
+echo > kprobe_events
+echo 'r:testprobe2 do_fork $retval' > kprobe_events
+grep testprobe2 kprobe_events
+test -d events/kprobes/testprobe2
+echo 1 > events/kprobes/testprobe2/enable
+( echo "forked")
+echo 0 > events/kprobes/testprobe2/enable
+echo '-:testprobe2' >> kprobe_events
+test -d events/kprobes/testprobe2 && exit 1 || exit 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/

Re: Re: [PATCH ftrace/for-next ] tracing/kprobes: Replace startup test with selftest script

[Masami Hiramatsu]

(2014/10/08 11:20), Steven Rostedt wrote:
> On Wed, 08 Oct 2014 10:59:49 +0900
> Masami Hiramatsu  wrote:
>  
>>> Both of these have valid reasons staying in the kernel and I don't see
>>> either as dead weight. Is there a maintenance issue with keeping it in
>>> the kernel? There doesn't seem to be much done to it. It seems
>>> untouched for over a year, and that was to add support for multiple
>>> buffers.
>>
>> Keeping it has no issue. But it's much easier to expand the test
>> in userspace than the kernel code. I'll add more feature tests in
>> kselftest, but not in this code. This means that this startup
>> test code will get behind.
> 
> And that's exactly what I expect you to do. I have lots of tests to
> test ftrace, but what gets tested at kernel startup is just a bare
> minimum, and that's all it needs to be. I don't expect you to extend
> the start up self tests. That should be only done for the scripts. But
> we have this start up test and I don't see a reason to get rid of it.
> If anything, it gives me warm fuzzies in my stomach when I see it
> pass :-)
> 
> The start up tests in the kernel should really just be the basic of the
> basic tests, that give a small sanity check that a change didn't
> totally screw things up.
> 
> Can you send a new patch that doesn't remove the start up test?

OK, I'll send it asap :)

Thank you,


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


--
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: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support

[Yuantian Tang]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, September 30, 2014 7:58 AM
> To: Tang Yuantian-B29983
> Cc: Mike Turquette; linuxppc-...@lists.ozlabs.org; 
> linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; Lu Jingchang-B35083
> Subject: Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add
> CLK_OF_DECLARE support
> 
> On Sat, 2014-09-27 at 21:18 -0500, Tang Yuantian-B29983 wrote:
> > > -Original Message-
> > > From: Linuxppc-dev
> > > [mailto:linuxppc-dev-bounces+b29983=freescale@lists.ozlabs.org]
> > > On Behalf Of Mike Turquette
> > > Sent: Saturday, September 27, 2014 7:29 AM
> > > To: Wood Scott-B07421
> > > Cc: linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> > > linux-arm-ker...@lists.infradead.org; Lu Jingchang-B35083
> > > Subject: Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add
> > > CLK_OF_DECLARE support
> > >
> > > Quoting Scott Wood (2014-09-25 15:56:20)
> > > > On Thu, 2014-09-25 at 15:54 -0700, Mike Turquette wrote:
> > > > > Quoting Scott Wood (2014-09-25 13:08:00)
> > > > > > Well, like I said, I'd rather see the CLK_OF_DECLARE stuff be
> > > > > > made to work on PPC rather than have the driver carry around
> > > > > > two binding methods.
> > > > >
> > > > > I guess that is an existing problem, and not related directly to
> > > > > this patch? This patch is essentially just renames (though the
> > > > > V1.0/V2.0 stuff seems weird).
> > > >
> > > > This patch is adding CLK_OF_DECLARE.
> > >
> > > I'm fine taking this patch but your comments are still unresolved.
> > > What do you think needs to be done to fix the problems that you see?
> > >
> > CLK_OF_DECLARE is totally worked on PPC. I will do it in a separate patch.
> > Regarding V1.0 and V2.0, it is not wired just same for now. But we are not 
> > sure
> if it is same for v3.0 in the future.
> >
> > Besides updating drivers/cpufreq/Kconfig.powerpc, there is one more thing I
> am not comfortable with:
> > This patch uses " fixed-clock" as sysclk's compatible string, while on PPC 
> > we
> treated it as " fsl,qoriq-sysclk-[1-2].0".
> > That's inconsistent on both ARM and PPC platforms, neither did on bindings.
> 
> fsl,qoriq-sysclk-XXX is the way it is because of compatibility with the 
> fixups in
> existing U-Boots.  It shouldn't be used as a model.
> 
> That said, I don't think you really mean "this patch", as it doesn't contain 
> the
> device tree updates, and "fixed-clock" does not appear.
> 
"fixed-clock" will appear when ls102x platform DTS gets upstreamed eventually.
That would be fine if you don't think "fsl,qoriq-sysclk-xxx" having different 
meaning on ARM and PowerPC is a issue.

Thanks,
Yuantian
> -Scott
> 

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH tty-next 14/22] tty: Remove tty_wait_until_sent_from_close()

[Peter Hurley]

On 06/17/2014 07:03 AM, David Laight wrote:
> From: Peter Hurley
> ...
>>> I don't understand the second half of the changelog, it doesn't seem
>>> to fit here: there deadlock that we are trying to avoid here happens
>>> when the *same* tty needs the lock to complete the function that
>>> sends the pending data. I don't think we do still do that any more,
>>> but it doesn't seem related to the tty lock being system-wide or not.
>>
>> The tty lock is not used in the i/o path; it's purpose is to
>> mutually exclude state changes in open(), close() and hangup().
>>
>> The commit that added this [1] comments that _other_ ttys may wait
>> for this tty to complete, and comments in the code note that this
>> function should be removed when the system-wide tty mutex was removed
>> (which happened with the commit noted in the changelog).

I just wanted to revisit this discussion briefly so I can clarify the
situation regarding holding the tty lock while closing, and how that
affects parallel opens.

I've unnested the tty lock from the tty mutex (which I'm still testing)
but will be submitting after the merge window re-opens for 3.19. So this
is more relevant now.

The original patch that led to this thread is here:
https://lkml.org/lkml/2014/6/16/306


> What happens if another process tries to do a non-blocking open
> while you are sleeping in close waiting for output to drain?
> 
> Hopefully this returns before that data has drained.

Current mainline blocks on _any_ racing re-open while this lock is
dropped in tty_wait_until_sent_from_close(); blocking while
ASYNC_CLOSING has been in mainline since at least 2.6.29 and that just
merged existing code together. See tty_port_block_til_ready(); note
the test for O_NONBLOCK is after the wait while ASYNC_CLOSING.

IOW, currently a non-blocking open will sleep for the _entire_ duration
of a parallel hardware shutdown, and when it wakes, the error return will
cause a release of its tty, and it will restart with a fresh attempt
to open. Same with a blocking open that is already waiting; when its
woken the hardware shutdown has already completed so ASYNC_INITIALIZED
is cleared, which forces a release and restart too.

The point being that holding the tty lock across the _entire_ close
is equivalent to the current outcome, regardless of O_NONBLOCK.

I'm reluctant to start returning EGAIN for non-blocking tty opens
because no tty driver does that now, and I don't think userspace will
deal well with new return codes from tty opens.

Regards,
Peter Hurley

--
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/3] workqueue: extend wq_pool_mutex to also protect pwq-installation

[Lai Jiangshan]

Athough pwq-installation without wq_pool_mutex held is not bug,
but it is not good design, it is better to make the pwq-allocation and 
installation
are in the (same) wq_pool_mutex.

And since the pwq-allocation and installation are in the same wq_pool_mutex,
get_online_cpus() will not be needed for this reason, and it will be remove
in later patch.

Signed-off-by: Lai Jiangshan 
---
 kernel/workqueue.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 7a217f0..9bc3a87 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3805,8 +3805,6 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
}
}
 
-   mutex_unlock(&wq_pool_mutex);
-
/* all pwqs have been created successfully, let's install'em */
mutex_lock(&wq->mutex);
 
@@ -3827,6 +3825,8 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
put_pwq_unlocked(pwq_tbl[node]);
put_pwq_unlocked(dfl_pwq);
 
+   mutex_unlock(&wq_pool_mutex);
+
put_online_cpus();
ret = 0;
/* fall through */
-- 
1.7.4.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/

[PATCH 0/3] workqueue: unbound workqueue management Vs hotplug

[Lai Jiangshan]

Hi, TJ

These patches are for unbound workqueue management (hotplug).

This patchset simplify the unbound workqueue management when hotplug.
This is also a preparation patchset for later unbound workqueue management
patches.

Thanks,
Lai.

Lai Jiangshan (3):
  workqueue: add wq_unbound_online_cpumask
  workqueue: extend wq_pool_mutex to also protect pwq-installation
  workqueue: remove get_online_cpus() from apply_workqueue_attrs()

 kernel/workqueue.c |   61 ---
 1 files changed, 24 insertions(+), 37 deletions(-)

-- 
1.7.4.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/

[PATCH 3/3] workqueue: remove get_online_cpus() from apply_workqueue_attrs()

[Lai Jiangshan]

There are two aims for get_online_cpus():
  1) Protects cpumask_of_node(node). (CPUs should stay stable)
  2) Protects the pwq-allocation and installation

But both aims are settled by other methods in previous patches:
cpumask_of_node(node) is replaced by wq_unbound_online_cpumask, and
the pwq-allocation and installation are changed to be protected by
wq_pool_mutex.  Now the get_online_cpus() is no reason to exist,
remove it!

Signed-off-by: Lai Jiangshan 
---
 kernel/workqueue.c |   15 ++-
 1 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 9bc3a87..63a8000 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -3776,13 +3776,6 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
 */
copy_workqueue_attrs(tmp_attrs, new_attrs);
 
-   /*
-* CPUs should stay stable across pwq creations and installations.
-* Pin CPUs, determine the target cpumask for each node and create
-* pwqs accordingly.
-*/
-   get_online_cpus();
-
mutex_lock(&wq_pool_mutex);
 
/*
@@ -3827,7 +3820,6 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
 
mutex_unlock(&wq_pool_mutex);
 
-   put_online_cpus();
ret = 0;
/* fall through */
 out_free:
@@ -3842,7 +3834,6 @@ enomem_pwq:
if (pwq_tbl && pwq_tbl[node] != dfl_pwq)
free_unbound_pwq(pwq_tbl[node]);
mutex_unlock(&wq_pool_mutex);
-   put_online_cpus();
 enomem:
ret = -ENOMEM;
goto out_free;
@@ -3921,10 +3912,8 @@ static void wq_update_unbound_numa(struct 
workqueue_struct *wq, int cpu)
}
 
/*
-* Install the new pwq.  As this function is called only from CPU
-* hotplug callbacks and applying a new attrs is wrapped with
-* get/put_online_cpus(), @wq->unbound_attrs couldn't have changed
-* inbetween.
+* Install the new pwq.  As this function is called with wq_pool_mutex
+* held, @wq->unbound_attrs couldn't have changed inbetween.
 */
mutex_lock(&wq->mutex);
old_pwq = numa_pwq_tbl_install(wq, node, pwq);
-- 
1.7.4.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/

[PATCH 1/3] workqueue: add wq_unbound_online_cpumask

[Lai Jiangshan]

Current wq_calc_node_cpumask() is complicated by cpumask_of_node(node) whose
value need to be revised before using and the "revising" needs @cpu_going_down
which makes more complicated.

This patch introduces wq_unbound_online_cpumask which is updated before
wq_update_unbound_numa() in the cpu-hotplug callbacks and wq_calc_node_cpumask()
can use it instead of cpumask_of_node(node). Thus wq_calc_node_cpumask()
becomes much simpler and @cpu_going_down is gone.

Signed-off-by: Lai Jiangshan 
---
 kernel/workqueue.c |   42 --
 1 files changed, 20 insertions(+), 22 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 5dbe22a..7a217f0 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -282,6 +282,9 @@ module_param_named(power_efficient, wq_power_efficient, 
bool, 0444);
 
 static bool wq_numa_enabled;   /* unbound NUMA affinity enabled */
 
+/* PL: online cpumask for all unbound wqs */
+static struct cpumask wq_unbound_online_cpumask;
+
 /* buf for wq_update_unbound_numa_attrs(), protected by CPU hotplug exclusion 
*/
 static struct workqueue_attrs *wq_update_unbound_numa_attrs_buf;
 
@@ -3675,12 +3678,9 @@ static void free_unbound_pwq(struct pool_workqueue *pwq)
  * wq_calc_node_mask - calculate a wq_attrs' cpumask for the specified node
  * @attrs: the wq_attrs of interest
  * @node: the target NUMA node
- * @cpu_going_down: if >= 0, the CPU to consider as offline
  * @cpumask: outarg, the resulting cpumask
  *
- * Calculate the cpumask a workqueue with @attrs should use on @node.  If
- * @cpu_going_down is >= 0, that cpu is considered offline during
- * calculation.  The result is stored in @cpumask.
+ * Calculate the cpumask a workqueue with @attrs should use on @node.
  *
  * If NUMA affinity is not enabled, @attrs->cpumask is always used.  If
  * enabled and @node has online CPUs requested by @attrs, the returned
@@ -3694,22 +3694,17 @@ static void free_unbound_pwq(struct pool_workqueue *pwq)
  * %false if equal.
  */
 static bool wq_calc_node_cpumask(const struct workqueue_attrs *attrs, int node,
-int cpu_going_down, cpumask_t *cpumask)
+struct cpumask *cpumask)
 {
if (!wq_numa_enabled || attrs->no_numa)
goto use_dfl;
 
/* does @node have any online CPUs @attrs wants? */
-   cpumask_and(cpumask, cpumask_of_node(node), attrs->cpumask);
-   if (cpu_going_down >= 0)
-   cpumask_clear_cpu(cpu_going_down, cpumask);
-
-   if (cpumask_empty(cpumask))
-   goto use_dfl;
-
-   /* yeap, return possible CPUs in @node that @attrs wants */
cpumask_and(cpumask, attrs->cpumask, wq_numa_possible_cpumask[node]);
-   return !cpumask_equal(cpumask, attrs->cpumask);
+   if (cpumask_intersects(cpumask, &wq_unbound_online_cpumask)) {
+   /* yeap, return possible CPUs in @node that @attrs wants */
+   return !cpumask_equal(cpumask, attrs->cpumask);
+   }
 
 use_dfl:
cpumask_copy(cpumask, attrs->cpumask);
@@ -3800,7 +3795,7 @@ int apply_workqueue_attrs(struct workqueue_struct *wq,
goto enomem_pwq;
 
for_each_node(node) {
-   if (wq_calc_node_cpumask(attrs, node, -1, tmp_attrs->cpumask)) {
+   if (wq_calc_node_cpumask(attrs, node, tmp_attrs->cpumask)) {
pwq_tbl[node] = alloc_unbound_pwq(wq, tmp_attrs);
if (!pwq_tbl[node])
goto enomem_pwq;
@@ -3857,7 +3852,6 @@ enomem:
  * wq_update_unbound_numa - update NUMA affinity of a wq for CPU hot[un]plug
  * @wq: the target workqueue
  * @cpu: the CPU coming up or going down
- * @online: whether @cpu is coming up or going down
  *
  * This function is to be called from %CPU_DOWN_PREPARE, %CPU_ONLINE and
  * %CPU_DOWN_FAILED.  @cpu is being hot[un]plugged, update NUMA affinity of
@@ -3875,11 +3869,9 @@ enomem:
  * affinity, it's the user's responsibility to flush the work item from
  * CPU_DOWN_PREPARE.
  */
-static void wq_update_unbound_numa(struct workqueue_struct *wq, int cpu,
-  bool online)
+static void wq_update_unbound_numa(struct workqueue_struct *wq, int cpu)
 {
int node = cpu_to_node(cpu);
-   int cpu_off = online ? -1 : cpu;
struct pool_workqueue *old_pwq = NULL, *pwq;
struct workqueue_attrs *target_attrs;
cpumask_t *cpumask;
@@ -3910,7 +3902,7 @@ static void wq_update_unbound_numa(struct 
workqueue_struct *wq, int cpu,
 * a new one if they don't match.  If the target cpumask equals
 * wq's, the default pwq should be used.
 */
-   if (wq_calc_node_cpumask(wq->unbound_attrs, node, cpu_off, cpumask)) {
+   if (wq_calc_node_cpumask(wq->unbound_attrs, node, cpumask)) {
if (cpumask_equal(cpumask, pwq->pool->attrs->cpumask))
goto out_unlock;
} else {
@@ -

[PATCH v3] i2c: rk3x: adjust the LOW divison based on characteristics of SCL

[Addy Ke]

As show in I2C specification:
- Standard-mode: the minimum HIGH period of the scl clock is 4.0us
 the minimum LOW period of the scl clock is 4.7us
- Fast-mode: the minimum HIGH period of the scl clock is 0.6us
 the minimum LOW period of the scl clock is 1.3us

I have measured i2c SCL waveforms in fast-mode by oscilloscope
on rk3288-pinky board. the LOW period of the scl clock is 1.3us.
It is so critical that we must adjust LOW division to increase
the LOW period of the scl clock.

Thanks Doug for the suggestion about division formulas.

Signed-off-by: Addy Ke 
---
Changes in v2:
- remove Fast-mode plus and HS-mode
- use new formulas suggested by Doug
Changes in V3:
- use new formulas (sep 30) suggested by Doug

 drivers/i2c/busses/i2c-rk3x.c | 135 +++---
 1 file changed, 128 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index b41d979..9612eba 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 /* Register Map */
@@ -428,18 +429,138 @@ out:
return IRQ_HANDLED;
 }
 
+static void rk3x_i2c_calc_divs(unsigned long i2c_rate, unsigned long scl_rate,
+  unsigned long *div_low, unsigned long *div_high)
+{
+   unsigned long min_low_ns, min_high_ns;
+   unsigned long max_data_hold_ns;
+   unsigned long data_hold_buffer_ns;
+   unsigned long max_low_ns, min_total_ns;
+
+   unsigned long i2c_rate_khz, scl_rate_khz;
+
+   unsigned long min_low_div, min_high_div;
+   unsigned long max_low_div;
+
+   unsigned long min_div_for_hold, min_total_div;
+   unsigned long extra_div, extra_low_div, ideal_low_div;
+
+   /* Only support standard-mode and fast-mode */
+   WARN_ON(scl_rate > 40);
+
+   /*
+* min_low_ns:  The minimum number of ns we need to hold low
+*  to meet i2c spec
+* min_high_ns: The minimum number of ns we need to hold high
+*  to meet i2c spec
+* max_low_ns:  The maximum number of ns we can hold low
+*  to meet i2c spec
+*
+* Note: max_low_ns should be (max data hold time * 2 - buffer)
+*   This is because the i2c host on Rockchip holds the data line
+*   for half the low time.
+*/
+   if (scl_rate <= 10) {
+   min_low_ns = 4700;
+   min_high_ns = 4000;
+   max_data_hold_ns = 3450;
+   data_hold_buffer_ns = 50;
+   } else {
+   min_low_ns = 1300;
+   min_high_ns = 600;
+   max_data_hold_ns = 900;
+   data_hold_buffer_ns = 50;
+   }
+   max_low_ns = max_data_hold_ns * 2 - data_hold_buffer_ns;
+   min_total_ns = min_low_ns + min_high_ns;
+
+   /* Adjust to avoid overflow */
+   i2c_rate_khz = DIV_ROUND_UP(i2c_rate, 1000);
+   scl_rate_khz = DIV_ROUND_UP(scl_rate, 1000);
+
+   /*
+* We need the total div to be >= this number
+* so we don't clock too fast.
+*/
+   min_total_div = DIV_ROUND_UP(i2c_rate_khz, scl_rate_khz * 8);
+
+   /* These are the min dividers needed for min hold times.*/
+   min_low_div = DIV_ROUND_UP(i2c_rate_khz * min_low_ns, 8 * 100);
+   min_high_div = DIV_ROUND_UP(i2c_rate_khz * min_high_ns, 8 * 100);
+   min_div_for_hold = (min_low_div + min_high_div);
+
+   /*
+* This is the maximum divider so we don't go over the max.
+* We don't round up here (we round down) since this is a max.
+*/
+   max_low_div = i2c_rate_khz * max_low_ns / (8 * 100);
+
+   if (min_low_div > max_low_div)
+   max_low_div = min_low_div;
+
+   if (min_div_for_hold > min_total_div) {
+   /*
+* Time needed to meet hold requirements is important.
+* Just use that.
+*/
+   *div_low = min_low_div;
+   *div_high = min_high_div;
+   } else {
+   /*
+* We've got to distribute some time among the low and high
+* so we don't run too fast.
+*/
+   extra_div = min_total_div - min_div_for_hold;
+   /*
+* We'll try to split things up perfectly evenly,
+* biasing slightly towards having a higher div
+* for low (spend more time low).
+*/
+
+   ideal_low_div = DIV_ROUND_UP(i2c_rate_khz * min_low_ns,
+scl_rate_khz * 8 * min_total_ns);
+
+   /* Don't allow it to go over the max */
+   if (ideal_low_div > max_low_div)
+   ideal_low_div = max_low_div;
+
+   /* Handle when the ideal low div is going to take up
+* mor

RE: [PATCH] powerpc/fsl: Add support for pci(e) machine check exception on E500MC / E5500

[Hongtao Jia]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Wednesday, October 01, 2014 8:44 AM
> To: Guenter Roeck
> Cc: Jojy Varghese; Benjamin Herrenschmidt; Paul Mackerras; Michael
> Ellerman; linuxppc-...@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> Guenter Roeck; Jia Hongtao-B38951
> Subject: Re: [PATCH] powerpc/fsl: Add support for pci(e) machine check
> exception on E500MC / E5500
> 
> On Tue, 2014-09-30 at 08:50 -0700, Guenter Roeck wrote:
> > On Mon, Sep 29, 2014 at 06:31:06PM -0500, Scott Wood wrote:
> > > On Mon, 2014-09-29 at 23:03 +, Jojy Varghese wrote:
> > > >
> > > > On 9/29/14 12:06 PM, "Guenter Roeck"  wrote:
> > > >
> > > > >Those are errors related to PCIe hotplug, and are seen with
> > > > >unexpected PCIe device removals (triggered, for example, by
> > > > >removing power from a PCIe adapter).
> > > > >The behavior we see on E5500 is quite similar to the same
> > > > >behavior on
> > > > >E500:
> > > > >If unhandled, the CPU keeps executing the same instruction over
> > > > >and over again if there is an error on a PCIe access and thus
> > > > >stalls. I don't know if this is considered an erratum or expected
> > > > >behavior, but it is one we have to address since we have to be
> > > > >able to handle that condition.
> > >
> > > The reason I ask is that the handling for e500 was described as an
> > > erratum workaround.  If it is an erratum it would be nice to know
> > > the erratum number and the full list of affected chips.
> > >
> > My understanding, which may be wrong, was that this is expected
> > behavior, at least for E5500. I actually thought I had seen it
> > somewhere in the specification (response to PCIe errors), but I don't
> recall where exactly.
> >
> > At least for my part I am not aware of an erratum.
> 
> Jia Hongtao, can you comment here?

I did not find any related erratum either.

> 
> > > > >Ultimately, we'll want
> > > > >to
> > > > >implement PCIe error handlers for the affected drivers, but that
> > > > >will be a next step.
> > >
> > > For now can we at least print a ratelimited error message?  I don't
> > > like the idea of silently ignoring these errors.  I suppose it's a
> > > separate issue from extending the workaround to cover e500mc, though.
> > >
> > I don't really like the idea of printing an error message pretty much
> > each time when an unexpected hotplug event occurs.
> 
> Unexpected events seem like the sort of thing you'd want to log, but my
> concern is that this might not be the only cause of PCI errors.
> 
> -Scott
> 

Re: [PATCH v2 1/2] workqueue: add quiescent state between work items

[Paul E. McKenney]

On Tue, Oct 07, 2014 at 01:45:28PM -0400, Joe Lawrence wrote:
> On Tue, 7 Oct 2014 06:43:29 -0700
> "Paul E. McKenney"  wrote:
> 
> > On Tue, Oct 07, 2014 at 09:29:42AM +0200, Jiri Pirko wrote:
> [ ... snip ... ]
> > > 
> > > Paul, Tehun, how do you propose to fix this on older kernels which do
> > > not have rcu_note_voluntary_context_switch? I'm particullary interested
> > > in 3.10.
> > 
> > Hello, Jiri,
> > 
> > Older kernels can instead use rcu_note_context_switch().
> 
> Hi Paul,
> 
> Does 4a81e8328d37 ("rcu: Reduce overhead of cond_resched() checks for
> RCU") affect a backport to 3.10?
> 
> I noticed that rcu_note_context_switch added a call to
> rcu_momentary_dyntick_idle in that change, which is only present in
> v3.16+.
> 
> Would rcu_note_context_switch be effective by itself on a 3.10 kernel?

Should be fine.  There is more overhead than current mainline, but that
should not be in the noise compared to executing a work-queue item.

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: [PATCH] powerpc/fsl: Add support for pci(e) machine check exception on E500MC / E5500

[Hongtao Jia]

> -Original Message-
> From: Wood Scott-B07421
> Sent: Tuesday, September 30, 2014 2:36 AM
> To: Guenter Roeck
> Cc: Benjamin Herrenschmidt; Paul Mackerras; Michael Ellerman; linuxppc-
> d...@lists.ozlabs.org; linux-kernel@vger.kernel.org; Jojy G Varghese;
> Guenter Roeck; Jia Hongtao-B38951
> Subject: Re: [PATCH] powerpc/fsl: Add support for pci(e) machine check
> exception on E500MC / E5500
> 
> On Mon, 2014-09-29 at 09:48 -0700, Guenter Roeck wrote:
> > From: Jojy G Varghese 
> >
> > For E500MC and E5500, a machine check exception in pci(e) memory space
> > crashes the kernel.
> >
> > Testing shows that the MCAR(U) register is zero on a MC exception for
> > the
> > E5500 core. At the same time, DEAR register has been found to have the
> > address of the faulty load address during an MC exception for this core.
> >
> > This fix changes the current behavior to fixup the result register and
> > instruction pointers in the case of a load operation on a faulty PCI
> > address.
> >
> > The changes are:
> > - Added the hook to pci machine check handing to the e500mc machine
> check
> >   exception handler.
> > - For the E5500 core, load faulting address from SPRN_DEAR register.
> >   As mentioned above, this is necessary because the E5500 core does not
> >   report the fault address in the MCAR register.
> >
> > Cc: Scott Wood 
> > Signed-off-by: Jojy G Varghese  [Guenter Roeck:
> > updated description]
> > Signed-off-by: Guenter Roeck 
> > Signed-off-by: Guenter Roeck 
> > ---
> >  arch/powerpc/kernel/traps.c   | 3 ++-
> >  arch/powerpc/sysdev/fsl_pci.c | 5 +
> >  2 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> > index 0dc43f9..ecb709b 100644
> > --- a/arch/powerpc/kernel/traps.c
> > +++ b/arch/powerpc/kernel/traps.c
> > @@ -494,7 +494,8 @@ int machine_check_e500mc(struct pt_regs *regs)
> > int recoverable = 1;
> >
> > if (reason & MCSR_LD) {
> > -   recoverable = fsl_rio_mcheck_exception(regs);
> > +   recoverable = fsl_rio_mcheck_exception(regs) ||
> > +   fsl_pci_mcheck_exception(regs);
> > if (recoverable == 1)
> > goto silent_out;
> > }
> > diff --git a/arch/powerpc/sysdev/fsl_pci.c
> > b/arch/powerpc/sysdev/fsl_pci.c index c507767..bdb956b 100644
> > --- a/arch/powerpc/sysdev/fsl_pci.c
> > +++ b/arch/powerpc/sysdev/fsl_pci.c
> > @@ -1021,6 +1021,11 @@ int fsl_pci_mcheck_exception(struct pt_regs
> > *regs)  #endif
> > addr += mfspr(SPRN_MCAR);
> >
> > +#ifdef CONFIG_E5500_CPU
> > +   if (mfspr(SPRN_EPCR) & SPRN_EPCR_ICM)
> > +   addr = PFN_PHYS(vmalloc_to_pfn((void *)mfspr(SPRN_DEAR)));
> #endif
> 
> Kconfig tells you what hardware is supported, not what hardware you're
> actually running on.
> 
> Jia Hongtao, do you know anything about this issue?  Is there an erratum?

Sorry for the late response, I just return from my vacation.
I don't know this issue.

> What chips are affected by the the erratum covered by
> ?

MPC8544, MPC8548, MPC8572 are affected by this erratum.
I checked P4080 which using e500mc and no such erratum is found.

> 
> Can we rely on DEAR or is this just a side effect of likely having taken
> a TLB miss for the address recently?  Perhaps we should use the
> instruction emulation to determine the effective address instead.
> 
> Guenter, is this patch intended to deal with an erratum or are you
> covering up legitimate errors?
> 
> -Scott
> 

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH 2/3] drm/exynos: dp: Remove support for unused dptx-phy

[Inki Dae]

On 2014년 10월 08일 11:57, Vivek Gautam wrote:
> Hi,
> 
> 
> On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  
> wrote:
>> Now that we have moved to generic phy based bindings,
>> we don't need to have any code related to older dptx-phy.
>> Nobody is using this dptx-phy anymore, so removing the
>> same.
>>
>> Signed-off-by: Vivek Gautam 
>> Cc: Jingoo Han 
>> ---
> 
> Is someone taking care of this patch ? We already have got the corresponsding
> dp-phy patch merged, so we should also get this patch in.
> 

Can anyone give me tested-by after test? I cannot test this module
because I have no any board equipped with dp panel.

Jingoo or other?

Thanks,
Inki Dae

>>  drivers/gpu/drm/exynos/exynos_dp_core.c |   58 
>> +++
>>  drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
>>  2 files changed, 13 insertions(+), 47 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 4f3c7eb..5ffc1b2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct 
>> exynos_drm_display *display,
>>
>>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>>  {
>> -   if (dp->phy) {
>> +   if (dp->phy)
>> phy_power_on(dp->phy);
>> -   } else if (dp->phy_addr) {
>> -   u32 reg;
>> -
>> -   reg = __raw_readl(dp->phy_addr);
>> -   reg |= dp->enable_mask;
>> -   __raw_writel(reg, dp->phy_addr);
>> -   }
>>  }
>>
>>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>>  {
>> -   if (dp->phy) {
>> +   if (dp->phy)
>> phy_power_off(dp->phy);
>> -   } else if (dp->phy_addr) {
>> -   u32 reg;
>> -
>> -   reg = __raw_readl(dp->phy_addr);
>> -   reg &= ~(dp->enable_mask);
>> -   __raw_writel(reg, dp->phy_addr);
>> -   }
>>  }
>>
>>  static void exynos_dp_poweron(struct exynos_drm_display *display)
>> @@ -1210,39 +1196,21 @@ static struct video_info 
>> *exynos_dp_dt_parse_pdata(struct device *dev)
>>
>>  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
>>  {
>> -   struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
>> -   u32 phy_base;
>> int ret = 0;
>>
>> -   dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
>> -   if (!dp_phy_node) {
>> -   dp->phy = devm_phy_get(dp->dev, "dp");
>> -   return PTR_ERR_OR_ZERO(dp->phy);
>> -   }
>> -
>> -   if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
>> -   dev_err(dp->dev, "failed to get reg for dptx-phy\n");
>> -   ret = -EINVAL;
>> -   goto err;
>> -   }
>> -
>> -   if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
>> -   &dp->enable_mask)) {
>> -   dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
>> -   ret = -EINVAL;
>> -   goto err;
>> -   }
>> -
>> -   dp->phy_addr = ioremap(phy_base, SZ_4);
>> -   if (!dp->phy_addr) {
>> -   dev_err(dp->dev, "failed to ioremap dp-phy\n");
>> -   ret = -ENOMEM;
>> -   goto err;
>> +   dp->phy = devm_phy_get(dp->dev, "dp");
>> +   if (IS_ERR(dp->phy)) {
>> +   ret = PTR_ERR(dp->phy);
>> +   if (ret == -ENOSYS || ret == -ENODEV) {
>> +   dp->phy = NULL;
>> +   } else if (ret == -EPROBE_DEFER) {
>> +   return ret;
>> +   } else {
>> +   dev_err(dp->dev, "no DP phy configured\n");
>> +   return ret;
>> +   }
>> }
>>
>> -err:
>> -   of_node_put(dp_phy_node);
>> -
>> return ret;
>>  }
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.h
>> index a1aee69..6426201 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
>> @@ -153,8 +153,6 @@ struct exynos_dp_device {
>> struct clk  *clock;
>> unsigned intirq;
>> void __iomem*reg_base;
>> -   void __iomem*phy_addr;
>> -   unsigned intenable_mask;
>>
>> struct video_info   *video_info;
>> struct link_train   link_train;
>> --
>> 1.7.10.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/

[PATCH] arm: armv7: perf: fix armv7 ref-cycles error

[zhangzhiqiang]

hi all,


ref-cycles event is specially to Intel core, but can still used in arm 
architecture
with the wrong return value with 3.10 stable. for instance:

 perf stat -e ref-cycles sleep 1

 Performance counter stats for 'sleep 1':

0 ref-cycles

   1.002381916 seconds time elapsed

this patch fix the bug and make it return NOT SUPPORTED
distinctly.

In upstream this bug has been fixed by other way(not primary for the bug), 
which changes more than one file
and more than 1000 lines. the primary commit is 
6b7658ec8a100b608e59e3cde353434db51f5be0.
besides we can not simply cherry-pick.

Signed-off-by: Zhiqiang Zhang 
---
 arch/arm/kernel/perf_event_v7.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm/kernel/perf_event_v7.c b/arch/arm/kernel/perf_event_v7.c
index 039cffb..c3d24aa 100644
--- a/arch/arm/kernel/perf_event_v7.c
+++ b/arch/arm/kernel/perf_event_v7.c
@@ -126,6 +126,7 @@ static const unsigned armv7_a8_perf_map[PERF_COUNT_HW_MAX] 
= {
[PERF_COUNT_HW_BUS_CYCLES]  = HW_OP_UNSUPPORTED,
[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = ARMV7_A8_PERFCTR_STALL_ISIDE,
[PERF_COUNT_HW_STALLED_CYCLES_BACKEND]  = HW_OP_UNSUPPORTED,
+   [PERF_COUNT_HW_REF_CPU_CYCLES]  = HW_OP_UNSUPPORTED,
 };

 static const unsigned armv7_a8_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
@@ -250,6 +251,7 @@ static const unsigned armv7_a9_perf_map[PERF_COUNT_HW_MAX] 
= {
[PERF_COUNT_HW_BUS_CYCLES]  = HW_OP_UNSUPPORTED,
[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = ARMV7_A9_PERFCTR_STALL_ICACHE,
[PERF_COUNT_HW_STALLED_CYCLES_BACKEND]  = 
ARMV7_A9_PERFCTR_STALL_DISPATCH,
+   [PERF_COUNT_HW_REF_CPU_CYCLES]  = HW_OP_UNSUPPORTED,
 };

 static const unsigned armv7_a9_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
@@ -374,6 +376,7 @@ static const unsigned armv7_a5_perf_map[PERF_COUNT_HW_MAX] 
= {
[PERF_COUNT_HW_BUS_CYCLES]  = HW_OP_UNSUPPORTED,
[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = HW_OP_UNSUPPORTED,
[PERF_COUNT_HW_STALLED_CYCLES_BACKEND]  = HW_OP_UNSUPPORTED,
+   [PERF_COUNT_HW_REF_CPU_CYCLES] = HW_OP_UNSUPPORTED,
 };

 static const unsigned armv7_a5_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
@@ -496,6 +499,7 @@ static const unsigned armv7_a15_perf_map[PERF_COUNT_HW_MAX] 
= {
[PERF_COUNT_HW_BUS_CYCLES]  = ARMV7_PERFCTR_BUS_CYCLES,
[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = HW_OP_UNSUPPORTED,
[PERF_COUNT_HW_STALLED_CYCLES_BACKEND]  = HW_OP_UNSUPPORTED,
+   [PERF_COUNT_HW_REF_CPU_CYCLES] = HW_OP_UNSUPPORTED,
 };

 static const unsigned armv7_a15_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
@@ -620,6 +624,7 @@ static const unsigned armv7_a7_perf_map[PERF_COUNT_HW_MAX] 
= {
[PERF_COUNT_HW_BUS_CYCLES]  = ARMV7_PERFCTR_BUS_CYCLES,
[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = HW_OP_UNSUPPORTED,
[PERF_COUNT_HW_STALLED_CYCLES_BACKEND]  = HW_OP_UNSUPPORTED,
+   [PERF_COUNT_HW_REF_CPU_CYCLES] = HW_OP_UNSUPPORTED,
 };

 static const unsigned armv7_a7_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
--

so, can we fix it in this way and put it into 3.10 stable repo.

--
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] dwc3: exynos: Add support for SCLK present on Exynos7

[Vivek Gautam]

On Tue, Oct 7, 2014 at 7:41 PM, Felipe Balbi  wrote:
> On Tue, Oct 07, 2014 at 03:49:33PM +0530, Vivek Gautam wrote:
>> Exynos7 also has a separate special gate clock going to the IP
>> apart from the usual AHB clock. So add support for the same.
>>
>> Signed-off-by: Vivek Gautam 
>
> I'll take this one once -rc1 is tagged. The others have no direct
> dependency on this so I'll leave them to Kishon.

Thanks Felipe !



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
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/3] drm/exynos: dp: Remove support for unused dptx-phy

[Vivek Gautam]

Hi,


CC'ing Kukjin,
my bad, missed him while sending the patch. :-(

On Wed, Oct 8, 2014 at 8:27 AM, Vivek Gautam  wrote:
> Hi,
>
>
> On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  
> wrote:
>> Now that we have moved to generic phy based bindings,
>> we don't need to have any code related to older dptx-phy.
>> Nobody is using this dptx-phy anymore, so removing the
>> same.
>>
>> Signed-off-by: Vivek Gautam 
>> Cc: Jingoo Han 
>> ---
>
> Is someone taking care of this patch ? We already have got the corresponsding
> dp-phy patch merged, so we should also get this patch in.
>
>>  drivers/gpu/drm/exynos/exynos_dp_core.c |   58 
>> +++
>>  drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
>>  2 files changed, 13 insertions(+), 47 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> index 4f3c7eb..5ffc1b2 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
>> @@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct 
>> exynos_drm_display *display,
>>
>>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>>  {
>> -   if (dp->phy) {
>> +   if (dp->phy)
>> phy_power_on(dp->phy);
>> -   } else if (dp->phy_addr) {
>> -   u32 reg;
>> -
>> -   reg = __raw_readl(dp->phy_addr);
>> -   reg |= dp->enable_mask;
>> -   __raw_writel(reg, dp->phy_addr);
>> -   }
>>  }
>>
>>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>>  {
>> -   if (dp->phy) {
>> +   if (dp->phy)
>> phy_power_off(dp->phy);
>> -   } else if (dp->phy_addr) {
>> -   u32 reg;
>> -
>> -   reg = __raw_readl(dp->phy_addr);
>> -   reg &= ~(dp->enable_mask);
>> -   __raw_writel(reg, dp->phy_addr);
>> -   }
>>  }
>>
>>  static void exynos_dp_poweron(struct exynos_drm_display *display)
>> @@ -1210,39 +1196,21 @@ static struct video_info 
>> *exynos_dp_dt_parse_pdata(struct device *dev)
>>
>>  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
>>  {
>> -   struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
>> -   u32 phy_base;
>> int ret = 0;
>>
>> -   dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
>> -   if (!dp_phy_node) {
>> -   dp->phy = devm_phy_get(dp->dev, "dp");
>> -   return PTR_ERR_OR_ZERO(dp->phy);
>> -   }
>> -
>> -   if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
>> -   dev_err(dp->dev, "failed to get reg for dptx-phy\n");
>> -   ret = -EINVAL;
>> -   goto err;
>> -   }
>> -
>> -   if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
>> -   &dp->enable_mask)) {
>> -   dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
>> -   ret = -EINVAL;
>> -   goto err;
>> -   }
>> -
>> -   dp->phy_addr = ioremap(phy_base, SZ_4);
>> -   if (!dp->phy_addr) {
>> -   dev_err(dp->dev, "failed to ioremap dp-phy\n");
>> -   ret = -ENOMEM;
>> -   goto err;
>> +   dp->phy = devm_phy_get(dp->dev, "dp");
>> +   if (IS_ERR(dp->phy)) {
>> +   ret = PTR_ERR(dp->phy);
>> +   if (ret == -ENOSYS || ret == -ENODEV) {
>> +   dp->phy = NULL;
>> +   } else if (ret == -EPROBE_DEFER) {
>> +   return ret;
>> +   } else {
>> +   dev_err(dp->dev, "no DP phy configured\n");
>> +   return ret;
>> +   }
>> }
>>
>> -err:
>> -   of_node_put(dp_phy_node);
>> -
>> return ret;
>>  }
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
>> b/drivers/gpu/drm/exynos/exynos_dp_core.h
>> index a1aee69..6426201 100644
>> --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
>> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
>> @@ -153,8 +153,6 @@ struct exynos_dp_device {
>> struct clk  *clock;
>> unsigned intirq;
>> void __iomem*reg_base;
>> -   void __iomem*phy_addr;
>> -   unsigned intenable_mask;
>>
>> struct video_info   *video_info;
>> struct link_train   link_train;
>> --
>> 1.7.10.4
>>
>
>
>
> --
> Best Regards
> Vivek Gautam
> Samsung R&D Institute, Bangalore
> India



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
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] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy

[Vivek Gautam]

Hi,

CC'ing Kukjin,
my bad, missed him while sending the patch. :-(

On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  wrote:
> DP PHY now require pmu-system-controller to handle PMU register
> to control PHY's power isolation. Adding the same to dp-phy
> node.
>
> Signed-off-by: Vivek Gautam 
> Cc: Jingoo Han 
> ---

Is someone taking care of this patch ? We already have got the corresponsding
dp-phy patch merged, so we should also get this patch in.

>  arch/arm/boot/dts/exynos5250.dtsi |2 +-
>  arch/arm/boot/dts/exynos5420.dtsi |4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
> b/arch/arm/boot/dts/exynos5250.dtsi
> index f21b9aa..9b85a2b 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -732,7 +732,7 @@
>
> dp_phy: video-phy@10040720 {
> compatible = "samsung,exynos5250-dp-video-phy";
> -   reg = <0x10040720 4>;
> +   samsung,pmu-syscon = <&pmu_system_controller>;
> #phy-cells = <0>;
> };
>
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
> b/arch/arm/boot/dts/exynos5420.dtsi
> index bfe056d..a677812 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -503,8 +503,8 @@
> };
>
> dp_phy: video-phy@10040728 {
> -   compatible = "samsung,exynos5250-dp-video-phy";
> -   reg = <0x10040728 4>;
> +   compatible = "samsung,exynos5420-dp-video-phy";
> +   samsung,pmu-syscon = <&pmu_system_controller>;
> #phy-cells = <0>;
> };
>
> --
> 1.7.10.4
>



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
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/3] drm/exynos: dp: Remove support for unused dptx-phy

[Vivek Gautam]

Hi,


On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam  wrote:
> Now that we have moved to generic phy based bindings,
> we don't need to have any code related to older dptx-phy.
> Nobody is using this dptx-phy anymore, so removing the
> same.
>
> Signed-off-by: Vivek Gautam 
> Cc: Jingoo Han 
> ---

Is someone taking care of this patch ? We already have got the corresponsding
dp-phy patch merged, so we should also get this patch in.

>  drivers/gpu/drm/exynos/exynos_dp_core.c |   58 
> +++
>  drivers/gpu/drm/exynos/exynos_dp_core.h |2 --
>  2 files changed, 13 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 4f3c7eb..5ffc1b2 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1050,28 +1050,14 @@ static int exynos_dp_create_connector(struct 
> exynos_drm_display *display,
>
>  static void exynos_dp_phy_init(struct exynos_dp_device *dp)
>  {
> -   if (dp->phy) {
> +   if (dp->phy)
> phy_power_on(dp->phy);
> -   } else if (dp->phy_addr) {
> -   u32 reg;
> -
> -   reg = __raw_readl(dp->phy_addr);
> -   reg |= dp->enable_mask;
> -   __raw_writel(reg, dp->phy_addr);
> -   }
>  }
>
>  static void exynos_dp_phy_exit(struct exynos_dp_device *dp)
>  {
> -   if (dp->phy) {
> +   if (dp->phy)
> phy_power_off(dp->phy);
> -   } else if (dp->phy_addr) {
> -   u32 reg;
> -
> -   reg = __raw_readl(dp->phy_addr);
> -   reg &= ~(dp->enable_mask);
> -   __raw_writel(reg, dp->phy_addr);
> -   }
>  }
>
>  static void exynos_dp_poweron(struct exynos_drm_display *display)
> @@ -1210,39 +1196,21 @@ static struct video_info 
> *exynos_dp_dt_parse_pdata(struct device *dev)
>
>  static int exynos_dp_dt_parse_phydata(struct exynos_dp_device *dp)
>  {
> -   struct device_node *dp_phy_node = of_node_get(dp->dev->of_node);
> -   u32 phy_base;
> int ret = 0;
>
> -   dp_phy_node = of_find_node_by_name(dp_phy_node, "dptx-phy");
> -   if (!dp_phy_node) {
> -   dp->phy = devm_phy_get(dp->dev, "dp");
> -   return PTR_ERR_OR_ZERO(dp->phy);
> -   }
> -
> -   if (of_property_read_u32(dp_phy_node, "reg", &phy_base)) {
> -   dev_err(dp->dev, "failed to get reg for dptx-phy\n");
> -   ret = -EINVAL;
> -   goto err;
> -   }
> -
> -   if (of_property_read_u32(dp_phy_node, "samsung,enable-mask",
> -   &dp->enable_mask)) {
> -   dev_err(dp->dev, "failed to get enable-mask for dptx-phy\n");
> -   ret = -EINVAL;
> -   goto err;
> -   }
> -
> -   dp->phy_addr = ioremap(phy_base, SZ_4);
> -   if (!dp->phy_addr) {
> -   dev_err(dp->dev, "failed to ioremap dp-phy\n");
> -   ret = -ENOMEM;
> -   goto err;
> +   dp->phy = devm_phy_get(dp->dev, "dp");
> +   if (IS_ERR(dp->phy)) {
> +   ret = PTR_ERR(dp->phy);
> +   if (ret == -ENOSYS || ret == -ENODEV) {
> +   dp->phy = NULL;
> +   } else if (ret == -EPROBE_DEFER) {
> +   return ret;
> +   } else {
> +   dev_err(dp->dev, "no DP phy configured\n");
> +   return ret;
> +   }
> }
>
> -err:
> -   of_node_put(dp_phy_node);
> -
> return ret;
>  }
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.h 
> b/drivers/gpu/drm/exynos/exynos_dp_core.h
> index a1aee69..6426201 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.h
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.h
> @@ -153,8 +153,6 @@ struct exynos_dp_device {
> struct clk  *clock;
> unsigned intirq;
> void __iomem*reg_base;
> -   void __iomem*phy_addr;
> -   unsigned intenable_mask;
>
> struct video_info   *video_info;
> struct link_train   link_train;
> --
> 1.7.10.4
>



-- 
Best Regards
Vivek Gautam
Samsung R&D Institute, Bangalore
India
--
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 11/13] gpio: Support for unified device properties interface

[Alexandre Courbot]

On Wed, Oct 8, 2014 at 9:09 AM, Rafael J. Wysocki  wrote:
> On Tuesday, October 07, 2014 07:52:02 PM Alexandre Courbot wrote:
>> On Tue, Oct 7, 2014 at 7:40 PM, Mika Westerberg
>>  wrote:
>> > On Tue, Oct 07, 2014 at 07:22:13PM +0900, Alexandre Courbot wrote:
>> >> On Tue, Oct 7, 2014 at 9:18 AM, Rafael J. Wysocki  
>> >> wrote:
>> >> > From: Mika Westerberg 
>> >> >
>> >> > Some drivers need to deal with only firmware representation of its
>> >> > GPIOs. An example would be a GPIO button array driver where each button
>> >> > is described as a separate firmware node in device tree. Typically these
>> >> > child nodes do not have physical representation in the Linux device
>> >> > model.
>> >> >
>> >> > In order to help device drivers to handle such firmware child nodes we
>> >> > add dev[m]_get_named_gpiod_from_child() that takes a child firmware
>> >> > node pointer as its second argument (the first one is the parent device
>> >> > itself), finds the GPIO using whatever is the underlying firmware
>> >> > method, and requests the GPIO properly.
>> >> >
>> >> > Signed-off-by: Mika Westerberg 
>> >> > Signed-off-by: Rafael J. Wysocki 
>> >>
>> >> ...
>> >>
>> >> > +/* Child properties interface */
>> >> > +struct gpio_desc *dev_get_named_gpiod_from_child(struct device *dev, 
>> >> > void *child,
>> >> > +const char *propname, 
>> >> > int index);
>> >> > +struct gpio_desc *devm_get_named_gpiod_from_child(struct device *dev, 
>> >> > void *child,
>> >> > + const char *propname, 
>> >> > int index);
>> >>
>> >> I see the reason for these functions and am not opposed to them.
>> >> However, I wonder if we could not replace propname by a con_id that
>> >> would be resolved to one of con_id-gpio for DT and whatever naming
>> >> convention ACPI is using?
>> >
>> > The code in gpio-leds.c and gpio_keys_polled.c refers to "gpios" as the
>> > property name. If we can change that somehow to work with con_id-gpio
>> > instead without breaking things, then why not.
>> >
>> >> This would prevent users to name GPIOs outside of the conventions
>> >> defined in the bindings and be generally safer. Is there a particular
>> >> reason (used by some old code?) for the current direct property
>> >> access? If not, maybe we could call a slightly-modified of_find_gpio()
>> >> to resolve the GPIO property for DT, and the equivalent function for
>> >> ACPI?
>> >
>> > Only reason I can think of is support for the existing properties that
>> > are used directly. Drivers using gpiod_get() and friends do not need
>> > dev_get_named_gpiod_from_child() anyway.
>>
>> Right. Another thing is that the property handling code (active low
>> only for now) is duplicated again, but that can be addressed
>> separately.
>>
>> I will have a look at gpio-leds and gpio_keys_polled to see if we
>> cannot make this work at a higher level. It's easier to have the
>> bindings respected if the code itself enforces them.
>
> I'm wondering if that can be done after merging the current work?
>
> We'll be able to use the drivers in question with our hardware in the
> meantime then ...

Yeah, that's probably ok. The properties in question already exist so
we will have to support them anyway ; it's just a matter of seeing
whether we can improve the proposed way.

So for now:

Acked-by: Alexandre Courbot 
--
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 v3 0/4] vfs: Non-blockling buffered fs read (page cache only)

[Milosz Tanski]

I haven't seen too many replies to this last request so I imagine
there's not to many things to fix.. which is good to see.

Additionally, with Jeff's help I wrote up man pages to be ready to go
with these changes.

I'm thinking of changing the preadv2 call to be a preadv6/pwritev6
call for the next submission... so the number represents the argument
count. This should more closely follow the other syscall convention
(like accept4, wait4, dup3).

I'm going to be away for a week. I hope to have the next version (with
the above change) for you guys to review next Wednesday.

Best,
- Milosz

On Wed, Sep 24, 2014 at 5:46 PM, Milosz Tanski  wrote:
> This patcheset introduces an ability to perform a non-blocking read from
> regular files in buffered IO mode. This works by only for those filesystems
> that have data in the page cache.
>
> It does this by introducing new syscalls new syscalls preadv2/pwritev2. These
> new syscalls behave like the network sendmsg, recvmsg syscalls that accept an
> extra flag argument (RWF_NONBLOCK).
>
> It's a very common patern today (samba, libuv, etc..) use a large threadpool 
> to
> perform buffered IO operations. They submit the work form another thread
> that performs network IO and epoll or other threads that perform CPU work. 
> This
> leads to increased latency for processing, esp. in the case of data that's
> already cached in the page cache.
>
> With the new interface the applications will now be able to fetch the data in
> their network / cpu bound thread(s) and only defer to a threadpool if it's not
> there. In our own application (VLDB) we've observed a decrease in latency for
> "fast" request by avoiding unnecessary queuing and having to swap out current
> tasks in IO bound work threads.
>
>
> Version 3 highlights:
>  - Down to 2 syscalls from 4; can user fp or argument position.
>  - RWF_NONBLOCK value flag is not the same O_NONBLOCK, per Jeff.
>
> Version 2 highlights:
>  - Put the flags argument into kiocb (less noise), per. Al Viro
>  - O_DIRECT checking early in the process, per. Jeff Moyer
>  - Resolved duplicate (c&p) code in syscall code, per. Jeff
>  - Included perf data in thread cover letter, per. Jeff
>  - Created a new flag (not O_NONBLOCK) for readv2, perf Jeff
>
>
> Some perf data generated using fio comparing the posix aio engine to a version
> of the posix AIO engine that attempts to performs "fast" reads before
> submitting the operations to the queue. This workflow is on ext4 partition on
> raid0 (test / build-rig.) Simulating our database access patern workload using
> 16kb read accesses. Our database uses a home-spun posix aio like queue (samba
> does the same thing.)
>
> f1: ~73% rand read over mostly cached data (zipf med-size dataset)
> f2: ~18% rand read over mostly un-cached data (uniform large-dataset)
> f3: ~9% seq-read over large dataset
>
> before:
>
> f1:
> bw (KB  /s): min=   11, max= 9088, per=0.56%, avg=969.54, stdev=827.99
> lat (msec) : 50=0.01%, 100=1.06%, 250=5.88%, 500=4.08%, 750=12.48%
> lat (msec) : 1000=17.27%, 2000=49.86%, >=2000=9.42%
> f2:
> bw (KB  /s): min=2, max= 1882, per=0.16%, avg=273.28, stdev=220.26
> lat (msec) : 250=5.65%, 500=3.31%, 750=15.64%, 1000=24.59%, 2000=46.56%
> lat (msec) : >=2000=4.33%
> f3:
> bw (KB  /s): min=0, max=265568, per=99.95%, avg=174575.10,
>  stdev=34526.89
> lat (usec) : 2=0.01%, 4=0.01%, 10=0.02%, 20=0.27%, 50=10.82%
> lat (usec) : 100=50.34%, 250=5.05%, 500=7.12%, 750=6.60%, 1000=4.55%
> lat (msec) : 2=8.73%, 4=3.49%, 10=1.83%, 20=0.89%, 50=0.22%
> lat (msec) : 100=0.05%, 250=0.02%, 500=0.01%
> total:
>READ: io=102365MB, aggrb=174669KB/s, minb=240KB/s, maxb=173599KB/s,
>  mint=61msec, maxt=600113msec
>
> after (with fast read using preadv2 before submit):
>
> f1:
> bw (KB  /s): min=3, max=14897, per=1.28%, avg=2276.69, stdev=2930.39
> lat (usec) : 2=70.63%, 4=0.01%
> lat (msec) : 250=0.20%, 500=2.26%, 750=1.18%, 2000=0.22%, >=2000=25.53%
> f2:
> bw (KB  /s): min=2, max= 2362, per=0.14%, avg=249.83, stdev=222.00
> lat (msec) : 250=6.35%, 500=1.78%, 750=9.29%, 1000=20.49%, 2000=52.18%
> lat (msec) : >=2000=9.99%
> f3:
> bw (KB  /s): min=1, max=245448, per=100.00%, avg=177366.50,
>  stdev=35995.60
> lat (usec) : 2=64.04%, 4=0.01%, 10=0.01%, 20=0.06%, 50=0.43%
> lat (usec) : 100=0.20%, 250=1.27%, 500=2.93%, 750=3.93%, 1000=7.35%
> lat (msec) : 2=14.27%, 4=2.88%, 10=1.54%, 20=0.81%, 50=0.22%
> lat (msec) : 100=0.05%, 250=0.02%
> total:
>READ: io=103941MB, aggrb=177339KB/s, minb=213KB/s, maxb=176375KB/s,
>  mint=600020msec, maxt=600178msec
>
> Interpreting the results you can see total bandwidth stays the same but 
> overall
> request latency is decreased in f1 (random, mostly cached) and f3 (sequential)
> workloads. There is a slight bump in latency for since it's random data that's
> unlikely to be cached but we're always try

Re: [PATCH 3.10 00/13] 3.10.57-stable review

[Guenter Roeck]

On 10/07/2014 04:20 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.10.57 release.
There are 13 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Oct  9 23:19:13 UTC 2014.
Anything received after that time might be too late.



Build results:
total: 137 pass: 137 fail: 0
Qemu tests:
total: 27 pass: 27 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

--
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.14 00/37] 3.14.21-stable review

[Guenter Roeck]

On 10/07/2014 04:19 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.14.21 release.
There are 37 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Oct  9 23:18:16 UTC 2014.
Anything received after that time might be too late.



Build results:
total: 137 pass: 137 fail: 0
Qemu tests:
total: 30 pass: 30 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

--
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.16 00/26] 3.16.5-stable review

[Guenter Roeck]

On 10/07/2014 04:19 PM, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 3.16.5 release.
There are 26 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Oct  9 23:18:40 UTC 2014.
Anything received after that time might be too late.



Build results:
total: 136 pass: 136 fail: 0
Qemu tests:
total: 30 pass: 30 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

--
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: [GIT PULL] ring-buffer: Fix infinite spin in reading buffer

[Chuck Ebbert]

On Sun, 5 Oct 2014 16:49:43 -0700
Greg Kroah-Hartman  wrote:

> On Fri, Oct 03, 2014 at 04:20:43PM -0400, Steven Rostedt wrote:

...

> > Fixes: 651e22f2701b "ring-buffer: Always reset iterator to reader page"
> > Signed-off-by: Steven Rostedt 
> 
> Next time, please also add a Cc: stable...  here so that my tools pick
> it up automatically.
> 

Can you add "Fixes:" to the list of keywords your tools pick up, and
determine if the patch is needed in -stable by looking at the commit ID
that's being fixed? Some authors might not remember if the thing being
fixed has made it into an older release via -stable.
--
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 resend] MIPS: Allow FPU emulator to use non-stack area.

[Rich Felker]

On Tue, Oct 07, 2014 at 07:18:33PM -0500, Chuck Ebbert wrote:
> On Tue, 7 Oct 2014 16:59:03 -0700
> David Daney  wrote:
> 
> > On 10/07/2014 04:20 PM, Ralf Baechle wrote:
> > > On Mon, Oct 06, 2014 at 02:18:19PM -0700, David Daney wrote:
> > >
> > >>> As an alternative, if the space of possible instruction with a delay
> > >>> slot is sufficiently small, all such instructions could be mapped as
> > >>> immutable code in a shared mapping, each at a fixed offset in the
> > >>> mapping. I suspect this would be borderline-impractical (multiple
> > >>> megabytes?), but it is the cleanest solution otherwise.
> > >>>
> > >>
> > >> Yes, there are 2^32 possible instructions.  Each one is 4 bytes, plus you
> > >> need a way to exit after the instruction has executed, which would 
> > >> require
> > >> another instruction.  So you would need 32GB of memory to hold all those
> > >> instructions, larger than the 32-bit virtual address space.
> > >
> > > Plus errata support for some older CPUs requires no other instructions
> > > that might cause an exception to be present in the same cache line 
> > > inflating
> > > the size to 32 bytes per instruction.
> > >
> > > I've contemplated a full emulation - but that would require an emulator 
> > > that
> > > is capable of most of the instruction set.  With all the random ASEs 
> > > around
> > > that would be hard to implement while the FPU emulator trampoline as 
> > > currently
> > > used has the advantage of automatically supporting ASEs, known and 
> > > unknown.
> > > So it's a huge bonus for maintenance.
> > >
> > 
> > Unfortunatly it breaks when our friends at Imgtec introduce their PC 
> > relative instructions in mipsr6, so an emulator may be unavoidable.
> > 
> 
> The x86 kprobes code deals with executing relocated insns with
> PC-relative offsets by adjusting the offset in a relocated instruction
> before executing it.
> 
> See arch/x86/kernel/kprobes/core.c::__copy_instruction()

This only works if you have an ISA that can represent the full range
of possible relative addresses. It does not work for MIPS where the
range is quite restricted by the fixed instruction size.

Rich
--
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] mm/afmalloc: introduce anti-fragmentation memory allocator

[Joonsoo Kim]

On Tue, Oct 07, 2014 at 03:26:35PM -0500, Seth Jennings wrote:
> On Tue, Oct 07, 2014 at 04:42:33PM +0900, Joonsoo Kim wrote:
> > Hello, Seth.
> > Sorry for late response. :)
> > 
> > 2014-09-30 4:53 GMT+09:00 Seth Jennings :
> > > On Fri, Sep 26, 2014 at 03:53:14PM +0900, Joonsoo Kim wrote:
> > >> WARNING: This is just RFC patchset. patch 2/2 is only for testing.
> > >> If you know useful place to use this allocator, please let me know.
> > >>
> > >> This is brand-new allocator, called anti-fragmentation memory allocator
> > >> (aka afmalloc), in order to deal with arbitrary sized object allocation
> > >> efficiently. zram and zswap uses arbitrary sized object to store
> > >> compressed data so they can use this allocator. If there are any other
> > >> use cases, they can use it, too.
> > >>
> > >> This work is motivated by observation of fragmentation on zsmalloc which
> > >> intended for storing arbitrary sized object with low fragmentation.
> > >> Although it works well on allocation-intensive workload, memory could be
> > >> highly fragmented after many free occurs. In some cases, unused memory 
> > >> due
> > >> to fragmentation occupy 20% ~ 50% amount of real used memory. The other
> > >> problem is that other subsystem cannot use these unused memory. These
> > >> fragmented memory are zsmalloc specific, so most of other subsystem 
> > >> cannot
> > >> use it until zspage is freed to page allocator.
> > >
> > > Yes, zsmalloc has a fragmentation issue.  This has been a topic lately.
> > > I and others are looking at putting compaction logic into zsmalloc to
> > > help with this.
> > >
> > >>
> > >> I guess that there are similar fragmentation problem in zbud, but, I
> > >> didn't deeply investigate it.
> > >>
> > >> This new allocator uses SLAB allocator to solve above problems. When
> > >> request comes, it returns handle that is pointer of metatdata to point
> > >> many small chunks. These small chunks are in power of 2 size and
> > >> build up whole requested memory. We can easily acquire these chunks
> > >> using SLAB allocator. Following is conceptual represetation of metadata
> > >> used in this allocator to help understanding of this allocator.
> > >>
> > >> Handle A for 400 bytes
> > >> {
> > >>   Pointer for 256 bytes chunk
> > >>   Pointer for 128 bytes chunk
> > >>   Pointer for 16 bytes chunk
> > >>
> > >>   (256 + 128 + 16 = 400)
> > >> }
> > >>
> > >> As you can see, 400 bytes memory are not contiguous in afmalloc so that
> > >> allocator specific store/load functions are needed. These require some
> > >> computation overhead and I guess that this is the only drawback this
> > >> allocator has.
> > >
> > > One problem with using the SLAB allocator is that kmalloc caches greater
> > > than 256 bytes, at least on my x86_64 machine, have slabs that require
> > > high order page allocations, which are going to be really hard to come
> > > by in the memory stressed environment in which zswap/zram are expected
> > > to operate.  I guess you could max out at 256 byte chunks to overcome
> > > this.  However, if you have a 3k object, that would require copying 12
> > > chunks from potentially 12 different pages into a contiguous area at
> > > mapping time and a larger metadata size.
> > 
> > SLUB uses high order allocation by default, but, it has fallback method. It
> > uses low order allocation if failed with high order allocation. So, we don't
> > need to worry about high order allocation.
> 
> Didn't know about the fallback method :)
> 
> > 
> > >>
> > >> For optimization, it uses another approach for power of 2 sized request.
> > >> Instead of returning handle for metadata, it adds tag on pointer from
> > >> SLAB allocator and directly returns this value as handle. With this tag,
> > >> afmalloc can recognize whether handle is for metadata or not and do 
> > >> proper
> > >> processing on it. This optimization can save some memory.
> > >>
> > >> Although afmalloc use some memory for metadata, overall utilization of
> > >> memory is really good due to zero internal fragmentation by using power
> > >
> > > Smallest kmalloc cache is 8 bytes so up to 7 bytes of internal
> > > fragmentation per object right?  If so, "near zero".
> > >
> > >> of 2 sized object. Although zsmalloc has many size class, there is
> > >> considerable internal fragmentation in zsmalloc.
> > >
> > > Lets put a number on it. Internal fragmentation on objects with size >
> > > ZS_MIN_ALLOC_SIZE is ZS_SIZE_CLASS_DELTA-1, which is 15 bytes with
> > > PAGE_SIZE of 4k.  If the allocation is less than ZS_MIN_ALLOC_SIZE,
> > > fragmentation could be as high as ZS_MIN_ALLOC_SIZE-1 which is 31 on a
> > > 64-bit system with 4k pages.  (Note: I don't think that is it possible to
> > > compress a 4k page to less than 32 bytes, so for zswap, there will be no
> > > allocations in this size range).
> > >
> > > So we are looking at up to 7 vs 15 bytes of internal fragmentation per
> > > object in the case when allocations 

Re: [GIT PULL] ring-buffer: Fix infinite spin in reading buffer

[Steven Rostedt]

On Sun, 5 Oct 2014 16:49:43 -0700
Greg Kroah-Hartman  wrote:

  
> > Fixes: 651e22f2701b "ring-buffer: Always reset iterator to reader page"
> > Signed-off-by: Steven Rostedt 
> 
> Next time, please also add a Cc: stable...  here so that my tools pick
> it up automatically.

Sure. I was a bit confused by exactly how to do that as it was a fix to
something that went to stable but wasn't in the original release.

But thinking about it now, I guess a Cc: stable without a version would
have sufficed. I'm too much in the habit of always adding a version and
didn't know what to add for this change as it was for 3.17-rcX. I guess
I just thought too hard about what to do.

-- Steve
--
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 3/3] ARM: dts: rk3288: add VOP iommu nodes

[Daniel Kurtz]

Add device nodes for the VOP iommus.
Device nodes for other iommus will be added in later patches.

The iommu nodes use the #iommu-cells property as described in:
  Documentation/devicetree/bindings/iommu/iommu.txt

Signed-off-by: Daniel Kurtz 
Signed-off-by: Simon Xue 
---
 arch/arm/boot/dts/rk3288.dtsi | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 5950b0a..cbc92fa 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -271,6 +271,24 @@
status = "disabled";
};
 
+   vopb_mmu: iommu@0xff930300 {
+   compatible = "rockchip,iommu";
+   reg = <0xff930300 0x100>;
+   interrupts = ;
+   interrupt-names = "vopb_mmu";
+   #iommu-cells = <0>;
+   status = "disabled";
+   };
+
+   vopl_mmu: iommu@0xff940300 {
+   compatible = "rockchip,iommu";
+   reg = <0xff940300 0x100>;
+   interrupts = ;
+   interrupt-names = "vopl_mmu";
+   #iommu-cells = <0>;
+   status = "disabled";
+   };
+
gic: interrupt-controller@ffc01000 {
compatible = "arm,gic-400";
interrupt-controller;
-- 
2.1.0.rc2.206.gedb03e5

--
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 ftrace/for-next ] tracing/kprobes: Replace startup test with selftest script

[Steven Rostedt]

On Wed, 08 Oct 2014 10:59:49 +0900
Masami Hiramatsu  wrote:
 
> > Both of these have valid reasons staying in the kernel and I don't see
> > either as dead weight. Is there a maintenance issue with keeping it in
> > the kernel? There doesn't seem to be much done to it. It seems
> > untouched for over a year, and that was to add support for multiple
> > buffers.
> 
> Keeping it has no issue. But it's much easier to expand the test
> in userspace than the kernel code. I'll add more feature tests in
> kselftest, but not in this code. This means that this startup
> test code will get behind.

And that's exactly what I expect you to do. I have lots of tests to
test ftrace, but what gets tested at kernel startup is just a bare
minimum, and that's all it needs to be. I don't expect you to extend
the start up self tests. That should be only done for the scripts. But
we have this start up test and I don't see a reason to get rid of it.
If anything, it gives me warm fuzzies in my stomach when I see it
pass :-)

The start up tests in the kernel should really just be the basic of the
basic tests, that give a small sanity check that a change didn't
totally screw things up.

Can you send a new patch that doesn't remove the start up test?

Thanks!

-- Steve
--
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 1/3] iommu/rockchip: rk3288 iommu driver

[Daniel Kurtz]

The rk3288 has several iommus.  Each iommu belongs to a single master
device.  There is one device (ISP) that has two slave iommus, but that
case is not yet supported by this driver.

At subsys init, the iommu driver registers itself as the iommu driver for
the platform bus.  The master devices find their slave iommus using the
"iommus" field in their devicetree description.  Since each slave iommu
belongs to exactly one master, their is no additional data needed at probe
to associate a slave with its master.

An iommu device's power domain, clock and irq are all shared with its
master device, and the master device must be careful to attach from the
iommu only after powering and clocking it (and leave it powered and
clocked before detaching).  Because their is no guarantee what the status
of the iommu is at probe, and since the driver does not even know if the
device is powered, we delay requesting its irq until the master device
attaches, at which point we have a guarantee that the device is powered
and clocked and we can reset it and disable its interrupt mask.

An iommu_domain describes a virtual iova address space.  Each iommu_domain
has a corresponding page table that lists the mappings from iova to
physical address.

For the rk3288 iommu, the page table has two levels:
 The Level 1 "directory_table" has 1024 4-byte dte entries.
 Each dte points to a level 2 "page_table".
 Each level 2 page_table has 1024 4-byte pte entries.
 Each pte points to a 4 KiB page of memory.

An iommu_domain is created when a dma_iommu_mapping is created via
arm_iommu_create_mapping.  Master devices can then attach themselves to
this mapping (or attach the mapping to themselves?) by calling
arm_iommu_attach_device().  This in turn instructs the iommu driver to
write the page table's physical address into the slave iommu's "Directory
Table Entry" (DTE) register.

In fact multiple master devices, each with their own slave iommu device,
can all attach to the same mapping.  The iommus for these devices will
share the same iommu_domain and therefore point to the same page table.
Thus, the iommu domain maintains a list of iommu devices which are
attached.  This driver relies on the iommu core to ensure that all devices
have detached before destroying a domain.

Changes in v2:
 - Allocate page tables using GFP_DMA32
 - Reorder structs to put spinlocks together
 - Reword comment in map/unmap about > 4MB mappings

Signed-off-by: Daniel Kurtz 
Signed-off-by: Simon Xue 
Reviewed-by: Grant Grundler 
Reviewed-by: Stéphane Marchesin 
---
 drivers/iommu/Kconfig  |  11 +
 drivers/iommu/Makefile |   1 +
 drivers/iommu/rockchip-iommu.c | 924 +
 3 files changed, 936 insertions(+)
 create mode 100644 drivers/iommu/rockchip-iommu.c

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index dd51122..b80454c 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -152,6 +152,17 @@ config OMAP_IOMMU_DEBUG
 
  Say N unless you know you need this.
 
+config ROCKCHIP_IOMMU
+   bool "Rockchip IOMMU Support"
+   depends on ARCH_ROCKCHIP
+   select IOMMU_API
+   help
+ Support for IOMMUs found on Rockchip rk32xx SOCs.
+ These IOMMUs allow virtualization of the address space used by most
+ cores within the multimedia subsystem.
+ Say Y here if you are using a Rockchip SoC that includes an IOMMU
+ device.
+
 config TEGRA_IOMMU_GART
bool "Tegra GART IOMMU Support"
depends on ARCH_TEGRA_2x_SOC
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 16edef7..3e47ef3 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o 
irq_remapping.o
 obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
 obj-$(CONFIG_OMAP_IOMMU) += omap-iommu2.o
 obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
+obj-$(CONFIG_ROCKCHIP_IOMMU) += rockchip-iommu.o
 obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
 obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
 obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
new file mode 100644
index 000..08e50fc
--- /dev/null
+++ b/drivers/iommu/rockchip-iommu.c
@@ -0,0 +1,924 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/** MMU register offsets */
+#define RK_MMU_DTE_ADDR0x00/* Directory table address */
+#define RK_MMU_STATUS  0x04
+#define RK_MMU_COMMAND 0x08
+#define RK_MMU_PAGE_FAULT_ADDR 0x0C/* IOVA of last page fault */
+#define RK_MMU_ZAP_ONE_LINE0x10/* Shoo

[PATCH v2 2/3] dt-bindings: iommu: Add documentation for rockchip iommu

[Daniel Kurtz]

Add binding documentation for Rockchip IOMMU.

Signed-off-by: Daniel Kurtz 
Signed-off-by: Simon Xue 
---
 .../devicetree/bindings/iommu/rockchip,iommu.txt   | 26 ++
 1 file changed, 26 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/rockchip,iommu.txt

diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt 
b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
new file mode 100644
index 000..810e058a
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
@@ -0,0 +1,26 @@
+Rockchip IOMMU
+==
+
+A Rockchip DRM iommu translates io virtual addresses to physical addresses for
+its master device.  Each slave device is bound to a single master device, and
+shares its clocks, power domain and irq.
+
+Required properties:
+- compatible  : Should be "rockchip,iommu"
+- reg : Address space for the configuration registers
+- interrupts  : Interrupt specifier for the IOMMU instance
+- interrupt-names : Interrupt name for the IOMMU instance
+- #iommu-cells: Should be <0>.  This indicates the iommu is a
+"single-master" device, and needs no additional information
+to associate with its master device.  See:
+Documentation/devicetree/bindings/iommu/iommu.txt
+
+Example:
+
+   vopl_mmu: iommu@0xff940300 {
+   compatible = "rockchip,iommu";
+   reg = <0xff940300 0x100>;
+   interrupts = ;
+   interrupt-names = "vopl_mmu";
+   #iommu-cells = <0>;
+   };
-- 
2.1.0.rc2.206.gedb03e5

--
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] drivers/rtc/interface.c: check the validation of rtc_time in __rtc_read_time

[Hyogi Gim]

Some of rtc devices always return '0' when rtc_class_ops.read_time is called.
So if rtc_time isn't verified in callback, rtc interface cannot know whether
rtc_time is valid.

Check rtc_time by using 'rtc_valid_tm' in '__rtc_read_time'. And add the
message for debugging.

Signed-off-by: Hyogi Gim 
---
 drivers/rtc/interface.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/rtc/interface.c b/drivers/rtc/interface.c
index 5b2717f..818ea97 100644
--- a/drivers/rtc/interface.c
+++ b/drivers/rtc/interface.c
@@ -30,6 +30,14 @@ static int __rtc_read_time(struct rtc_device *rtc, struct 
rtc_time *tm)
else {
memset(tm, 0, sizeof(struct rtc_time));
err = rtc->ops->read_time(rtc->dev.parent, tm);
+   if (err < 0) {
+   dev_err(&rtc->dev, "read_time: fail to read\n");
+   return err;
+   }
+
+   err = rtc_valid_tm(tm);
+   if (err < 0)
+   dev_err(&rtc->dev, "read_time: rtc_time isn't valid\n");
}
return err;
 }
-- 
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: Re: [PATCH ftrace/for-next ] tracing/kprobes: Replace startup test with selftest script

[Masami Hiramatsu]

(2014/10/08 1:05), Steven Rostedt wrote:
> On Tue, 07 Oct 2014 15:00:28 +0900
> Masami Hiramatsu  wrote:
> 
>> (2014/10/07 7:33), Steven Rostedt wrote:
>>> On Mon, 06 Oct 2014 11:48:06 +
>>> Masami Hiramatsu  wrote:
>>>
 Replace the kprobe_tracer's startup test with two selftest scripts.
 These test cases are testing that the kprobe_event can accept a
 kprobe event with $stack related arguments and a kretprobe event
 with $retval argument.
>>>
>>> Can't we keep both? I have boxes I run my own tests with and enables
>>> these start up tests in the kernel. I don't plan on testing on all
>>> theses boxes using the scripts in the kernel.
>>>
>>> Having a self test in the kernel itself can be useful too.
>>
>> Hmm, deprecating the test is acceptable, but I think it is just
>> a dead weight that if we have both of them forever in the kernel.
>> Of course, if that feature is fundamentally related to booting up
>> the kernel, we need to keep them in boot up code. But if it is
>> possible to run after booting up, I think we'd better to move it
>> under kselftest, since we can do more investigation after booting.
>>
> 
> I'm just saying that it is more likely to have this test run if it's in
> the kernel than in userspace. But as you say, we can debug it better if
> there's a userspace tool that can run too. This is why I'm saying we
> should keep both. I think they are both useful for different reasons.
> Keeping it in the kernel as a config option will give it more exposure,
> and keeping it in the tools/testing directory gives us a way to debug
> it if there an issue should arise.

OK, I can keep both in the kernel at this point. I just expected when we
have kselftest which becomes good enough and widely used, then it is more
likely to be run than the startup selftest, because the startup selftest
requires kernel configuration but kselftest is completely add-on test
(so that we can run it on distro kernel too :)
However, yes, it is just my guess.

> Both of these have valid reasons staying in the kernel and I don't see
> either as dead weight. Is there a maintenance issue with keeping it in
> the kernel? There doesn't seem to be much done to it. It seems
> untouched for over a year, and that was to add support for multiple
> buffers.

Keeping it has no issue. But it's much easier to expand the test
in userspace than the kernel code. I'll add more feature tests in
kselftest, but not in this code. This means that this startup
test code will get behind.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


--
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] regulator: sky81452: Remove module version

[Axel Lin]

The module version is unlikely to be updated, use kernel version should be
enough.

Signed-off-by: Axel Lin 
---
Hi Gyungoh,
Seems you have added MODULE_VERSION for the sky81452 serial patches.
Do you really need that and will keep updating it?
Otherwise, you may want to drop the MODULE_VERSION in sky81452 serial patches.

 drivers/regulator/sky81452-regulator.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/regulator/sky81452-regulator.c 
b/drivers/regulator/sky81452-regulator.c
index 97aff0c..476b80a 100644
--- a/drivers/regulator/sky81452-regulator.c
+++ b/drivers/regulator/sky81452-regulator.c
@@ -127,4 +127,3 @@ module_platform_driver(sky81452_reg_driver);
 MODULE_DESCRIPTION("Skyworks SKY81452 Regulator driver");
 MODULE_AUTHOR("Gyungoh Yoo ");
 MODULE_LICENSE("GPL");
-MODULE_VERSION("1.0");
-- 
1.9.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 1/1] pci/quirks: fix a dmar fault for intel 82599 card

[Li, ZhenHua]

well,  then I will create a patch for ALL pcie devices.
On 10/03/2014 10:28 PM, Alexander Duyck wrote:

On 10/02/2014 08:09 AM, Bjorn Helgaas wrote:

On Tue, Sep 30, 2014 at 12:15 AM, Li, ZhenHua  wrote:

Add Joerg to CC list. For it is also related to iommu module.

Joerg,
There was a try for this dmar fault,
 https://lkml.org/lkml/2014/8/18/118

This patch is trying to fix the same thing.


Zhenhua

On 09/30/2014 02:09 PM, Li, Zhen-Hua wrote:

On a HP system with Intel Corporation 82599 ethernet adapter, when kernel
crashed and the kdump kernel boots with intel_iommu=on, there may be some
unexpected DMA requests on this adapter, which will cause DMA Remapping
faults like:
  dmar: DRHD: handling fault status reg 102
  dmar: DMAR:[DMA Read] Request device [41:00.0] fault addr fff81000
  DMAR:[fault reason 01] Present bit in root entry is clear

Analysis for this bug:

The present bit is set in this function:

static struct context_entry * device_to_context_entry(
 struct intel_iommu *iommu, u8 bus, u8 devfn)
{
  ..
  set_root_present(root);
  ..
}

Calling tree:
ixgbe_open
  ixgbe_setup_tx_resources
  intel_alloc_coherent
  __intel_map_single
  domain_context_mapping
  domain_context_mapping_one
  device_to_context_entry

This means, the present bit in root entry will not be set until the device
   driver is loaded.

But in the kdump kernel, some hardware device does not know the OS is the
   second kernel and the drivers should be loaded again, this causes there
are
   some unexpected DMA requsts on this device when it has not been
initialized,
   and then the DMA Remapping errors come.

To fix this DMAR fault, we need to reset the bus that this device on.
Reset
   the device itself does not work.

This seems like something that could happen with *any* device, not
just the 82599 NIC.  Or is there something in the "kernel crash ->
kexec -> kdump kernel" path that stops DMA for most devices, but not
for the 82599?lex



This is an *any* device problem.  Specifically any device that is doing
active DMA when a kdump kernel is triggered will cause this issue since
the IOMMU will not have valid mappings for the DMA events until the
device driver itself is loaded and resets the device.

Thanks,

Alex



--
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] pinctrl: pinctrl-single.c: init pinctrl single at arch_initcall time

[He YunLei]

On 2014/9/30 1:54, Tony Lindgren wrote:

* He YunLei  [140929 03:32]:

On our arm platform, some modules (e.g. I2C bus driver) will use the
pinctrl-single driver to configure the SoC pin, but pinctrl-single driver
uses module_init time, that makes some modules initialize ahead the
pinctrl-single and fail to register.

This patch promotes the initialization priority of pinctrl-single from
module_init time to arch_initcall time.


This has come up earlier and so far in all cases the problem
is that you have custom initcall levels for your other drivers.

Get rid of custom initcall levels for your drivers and the
problem goes away. There's no need to init the drivers earlier
nowadays. If you have other dependencies then deferred probe
helps but should be only needed for a limited number of cases.

We want to initialize things later, not earlier in general. That
removes the issues of no proper debug output while booting the
kernel.

Regards,

Tony



Signed-off-by: Yunlei He 
Signed-off-by: Xinwei Kong 
---
  drivers/pinctrl/pinctrl-single.c |   13 -
  1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/pinctrl-single.c
b/drivers/pinctrl/pinctrl-single.c
index 95dd9cf..4b9e5b9 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -2012,7 +2012,18 @@ static struct platform_driver pcs_driver = {
  #endif
  };

-module_platform_driver(pcs_driver);
+static int __init pinctrl_single_init(void)
+{
+   return platform_driver_register(&pcs_driver);
+}
+
+static void __exit pinctrl_single_exit(void)
+{
+   platform_driver_unregister(&pcs_driver);
+}
+
+arch_initcall(pinctrl_single_init);
+module_exit(pinctrl_single_exit);

  MODULE_AUTHOR("Tony Lindgren ");
  MODULE_DESCRIPTION("One-register-per-pin type device tree based pinctrl
driver");
--
1.7.9.5



.



Thanks for your review and I am really appreciated it, but in our arm 
platform, we haven't custom initcall levels for other drivers. Although 
deferred probe helps other drivers to register well, we are also 
confused for the issues of lots of pin request errors debug output while 
booting the kernel. Besides, if the number is bigger than the limited 
number, whether deferred probe can solve this problem.


Regards,
He YunLei

--
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 v2] SPI: spi-pxa2xx: SPI support for Intel Quark X1000

[Chen, Alvin]

> > The SPI memory mapped I/O registers supported by Quark are different
> > from the current implementation, and Quark only supports the registers
> > of 'SSCR0', 'SSCR1', 'SSSR', 'SSDR', and 'DDS_RATE'. This patch is to
> > enable the SPI for Intel Quark X1000.
> >
> > This piece of work is derived from Dan O'Donovan's initial work for
> > Intel Quark
> > X1000 SPI enabling.
> 
> Minor comments are below.
> 
> After addressing them
> Reviewed-by: Andy Shevchenko 
> 
OK.
> > +   case QUARK_X1000_SSP:
> > +   return RX_THRESH_QUARK_X1000_DFLT;
> > default:
> > return RX_THRESH_DFLT;
> > }
> > +
> 
> Redundant empty line.
> 
OK. I will remove it.

> >  static void pxa2xx_spi_clear_rx_thre(const struct driver_data *drv_data,
> > -u32 *sccr1_reg)
> > + u32 *sccr1_reg)
> 
> Unnecessary change.
> 
Improve it in the first patch.
> >  static void pxa2xx_spi_set_rx_thre(const struct driver_data *drv_data,
> > -  u32 *sccr1_reg, u32 threshold)
> > +   u32 *sccr1_reg, u32 threshold)
> 
> Ditto.
> 
> Or you may do that in the first patch.
> 
Improve it in the first patch.
> >
> > pxa2xx_spi_set_rx_thre(drv_data, &sccr1_reg,
> > -  rx_thre);
> > +   rx_thre);
> 
> Ditto.
> 
Improve it in the first patch.
> > +   if (is_quark_x1000_ssp(drv_data) &&
> > +   (read_DDS_RATE(reg) != chip->dds_rate))
> 
> Could it be one line?
> 
No, it is beyond 80 characters if it is in one line.

Re: [PATCH] drm/exynos: init vblank with real number of crtcs

[Inki Dae]

On 2014년 10월 08일 00:28, Inki Dae wrote:
> 
> Sorry for late.
> 
> On 2014년 10월 07일 21:27, Andrzej Hajda wrote:
>> Hi Inki,
>>
>> Gently ping.
>>
>> Andrzej
>>
>>
>> On 09/19/2014 02:57 PM, Andrzej Hajda wrote:
>>> Initialization of vblank with MAX_CRTC caused attempts
>>> to disabling vblanks for non-existing crtcs in case
>>> drm used fewer crtcs. The patch fixes it.
> 
> Nice catch~ This patch also resolves unbind issue. When exynos driver is
> unbound, disable_vblank callback is called as dev->num_crtcs so if the
> number of probed crtc drivers is different from the one of enabled crtc

Oops, s/the one of enabled crtc drivers/MAX_CRTC

> drivers then it could attempt to disabling vblank for non-existing crtc,
> which in turn, null pointer access occurs.
> 
> Thanks,
> Inki Dae
> 
>>>
>>> Signed-off-by: Andrzej Hajda 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 +-
>>>  1 file changed, 9 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> index 9b00e4e..dc4affd 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
>>> @@ -94,10 +94,6 @@ static int exynos_drm_load(struct drm_device *dev, 
>>> unsigned long flags)
>>> /* init kms poll for handling hpd */
>>> drm_kms_helper_poll_init(dev);
>>>  
>>> -   ret = drm_vblank_init(dev, MAX_CRTC);
>>> -   if (ret)
>>> -   goto err_mode_config_cleanup;
>>> -
>>> /* setup possible_clones. */
>>> exynos_drm_encoder_setup(dev);
>>>  
>>> @@ -106,22 +102,26 @@ static int exynos_drm_load(struct drm_device *dev, 
>>> unsigned long flags)
>>> /* Try to bind all sub drivers. */
>>> ret = component_bind_all(dev->dev, dev);
>>> if (ret)
>>> -   goto err_cleanup_vblank;
>>> +   goto err_mode_config_cleanup;
>>> +
>>> +   ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
>>> +   if (ret)
>>> +   goto err_unbind_all;
>>>  
>>> /* Probe non kms sub drivers and virtual display driver. */
>>> ret = exynos_drm_device_subdrv_probe(dev);
>>> if (ret)
>>> -   goto err_unbind_all;
>>> +   goto err_cleanup_vblank;
>>>  
>>> /* force connectors detection */
>>> drm_helper_hpd_irq_event(dev);
>>>  
>>> return 0;
>>>  
>>> -err_unbind_all:
>>> -   component_unbind_all(dev->dev, dev);
>>>  err_cleanup_vblank:
>>> drm_vblank_cleanup(dev);
>>> +err_unbind_all:
>>> +   component_unbind_all(dev->dev, dev);
>>>  err_mode_config_cleanup:
>>> drm_mode_config_cleanup(dev);
>>> drm_release_iommu_mapping(dev);
>>> @@ -138,8 +138,8 @@ static int exynos_drm_unload(struct drm_device *dev)
>>> exynos_drm_fbdev_fini(dev);
>>> drm_kms_helper_poll_fini(dev);
>>>  
>>> -   component_unbind_all(dev->dev, dev);
>>> drm_vblank_cleanup(dev);
>>> +   component_unbind_all(dev->dev, dev);
>>> drm_mode_config_cleanup(dev);
>>> drm_release_iommu_mapping(dev);
>>>  
>>>
>>
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
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] mm: memcontrol: fix transparent huge page allocations under pressure

[Johannes Weiner]

On Tue, Oct 07, 2014 at 03:59:50PM +0200, Michal Hocko wrote:
> On Mon 29-09-14 13:57:00, Johannes Weiner wrote:
> > Every change we make is a trade-off and bears a certain risk.  THP is
> > a trade-off, it's pretty pointless to ignore the upsides and ride
> > around on the downsides.  Of course there are downsides.  This patch
> > makes THP work properly inside memcg, which invites both the upsides
> > as well as the downsides of THP into memcg.  But they are well known
> > and we can deal with them. 
> 
> I do not see any evaluation nor discussion of the upsides and downsides
> in the changelog. You are selling this as a net win which I cannot
> agree with.

I'm not sure why you want me to regurgitate the pros and cons of
transparent huge pages here.  They have been a well-established
default feature for a while now, and they are currently not working
properly inside memcg, which this patch addresses.

The only valid argument against merging this patch at this point can
be that THP inside memcg will lead to distinct issues that do not
exist on the global level.  So let's find out if there are any, okay?

> I am completely missing any notes about potential excessive
> swapouts or longer reclaim stalls which are a natural side effect of direct
> reclaim with a larger target (or is this something we do not agree on?).

Yes, we disagree here.  Why is reclaiming 2MB once worse than entering
reclaim 16 times to reclaim SWAP_CLUSTER_MAX?  There is no inherent
difference in reclaiming a big chunk and reclaiming many small chunks
that add up to the same size.

It's only different if you don't actually use the full 2MB pages, but
then the issue simply boils down to increased memory consumption.  But
that is easy to deal with and I offered two solutions in my changelog.

> What is an admin/user supposed to do when one of the above happens?
> Disable THP globally?

I already wrote all that.  It would be easier if you read my entire
line of reasoning instead of attacking fragments in isolation, so that
we can make forward progress on this.

> I still remember when THP was introduced and we have seen boatload of
> reclaim related bugs. These were exactly those long stalls, excessive
> swapouts and reclaim.

THP certainly had a bumpy introduction, and I can understand that you
want to prevent the same happening to memcg.

But it's important to evaluate which THP costs actually translate to
memcg.  The worst problems we had came *not* from faulting in bigger
steps, but from creating physically contiguous pages: aggressive lumpy
reclaim, (synchroneous) migration, reclaim beyond the allocation size
to create breathing room for compaction etc.  This is a massive amount
of work ON TOP of the bigger fault granularity.

Memcg only has to reclaim the allocation size in individual 4k pages.
Our only risk from THP is internal fragmentation from users not fully
utilizing the entire 2MB regions, but the work we MIGHT waste is
negligible compared to the work we are DEFINITELY wasting right now by
failing to charge already allocated THPs.

> > Why is THP inside memcg special?
> 
> For one thing the global case is hitting its limit (watermarks) much
> more slowly and gracefully because it has kswapd working on the
> background before we are getting into troubles. Memcg will just hit the
> wall and rely solely on the direct reclaim so everything we do will end
> up latency sensitive.

THP allocations do not wake up kswapd, they go into direct reclaim.
It's likely that kswapd balancing triggered by concurrent order-0
allocations will help THP somewhat, but because the global level needs
contiguous pages, it will still likely enter direct reclaim and direct
compaction.  For example, on my 16G desktop, there are 12MB between
the high and low watermark in the Normal zone; compaction needs double
the allocation size to work, so kswapd can cache reclaim work for up
to 3 THP in the best case (which those concurrent order-0 allocations
that woke kswapd in the first place will likely eat into), and direct
compaction will still have to run.

So AFAICS the synchroneous work required to fit a THP inside memcg is
much less.  And again, under pressure all this global work is already
expensed at that point anyway.

> Moreover, THP allocations have self regulatory mechanisms to prevent
> from excessive stalls. This means that THP allocations are less probable
> under heavy memory pressure.

These mechanisms exist for migration/compaction, but direct reclaim is
still fairly persistent - again, see should_continue_reclaim().

Am I missing something?

> On the other hand, memcg might be under serious memory pressure when
> THP charge comes. The only back off mechanism we use in memcg is
> GFP_NORETRY and that happens after one round of the reclaim. So we
> should make sure that the first round of the reclaim doesn't take
> terribly long.

The same applies globally.  ANY allocation under serious memory
pressure will have a high latency, but nobody forces

Re: [PATCH v2 4/4] clk: Use ww_mutexes for clk_prepare_{lock/unlock}

[Stephen Boyd]

On 09/29/2014 05:12 PM, Stephen Boyd wrote:

  I'm also auditing clock
drivers to find potential brokenness.



These are places where we re-enter the framework under drivers/clk/. It 
looks like sirf can be ported to use determine_rate() and something like 
my "safe parent" patch. Tegra is concerning given that they call 
clk_get_rate() in atomic context which is bad because that 
clk_get_rate() can sleep on the prepare mutex. Otherwise we can probably 
just convert that to use the unlocked variants. I'm aware of the qcom 
one, maybe we need a framework flag that indicates that all parent 
clocks must be enabled to switch this clock's parent. The last one is 
versatile which I hope we can convert to use assigned-rates?


drivers/clk/sirf/clk-common.c:409:ret1 = clk_set_parent(hw->clk, 
clk_pll1.hw.clk);
drivers/clk/sirf/clk-common.c:414:ret1 = clk_set_parent(hw->clk, 
clk_pll2.hw.clk);
drivers/clk/sirf/clk-common.c:419:ret1 = clk_set_parent(hw->clk, 
clk_pll3.hw.clk);
drivers/clk/sirf/clk-common.c:427:ret1 = clk_set_parent(hw->clk, 
clk_pll2.hw.clk);
drivers/clk/sirf/clk-common.c:433:ret1 = clk_set_parent(hw->clk, 
clk_pll1.hw.clk);

drivers/clk/versatile/clk-sp810.c:103: clk_set_parent(hw->clk, new_parent);
drivers/clk/sirf/clk-common.c:431:ret2 = 
clk_set_rate(clk_pll1.hw.clk, rate);
drivers/clk/qcom/mmcc-msm8960.c:520:ret = 
clk_prepare_enable(clk_get_parent_by_index(clk, i));
drivers/clk/qcom/mmcc-msm8960.c:549: 
clk_disable_unprepare(clk_get_parent_by_index(clk, i));
Not necessary? drivers/clk/sirf/clk-common.c:168:struct clk 
*parent_clk = clk_get_parent(hw->clk);
Not necessary? drivers/clk/sirf/clk-common.c:169:struct clk 
*pll_parent_clk = clk_get_parent(parent_clk);
Not necessary! drivers/clk/sirf/clk-common.c:181:struct clk 
*parent_clk = clk_get_parent(hw->clk);

drivers/clk/sirf/clk-common.c:423:cur_parent = clk_get_parent(hw->clk);
drivers/clk/spear/clk-vco-pll.c:90: 
__clk_get_rate(__clk_get_parent(__clk_get_parent(hw->clk)));
drivers/clk/tegra/clk-pll.c:732:unsigned long input_rate = 
clk_get_rate(clk_get_parent(hw->clk));
drivers/clk/tegra/clk-pll.c:1288:unsigned long input_rate = 
clk_get_rate(clk_get_parent(hw->clk));
drivers/clk/versatile/clk-sp810.c:82:struct clk *old_parent = 
__clk_get_parent(hw->clk);
drivers/clk/qcom/mmcc-msm8960.c:520:ret = 
clk_prepare_enable(clk_get_parent_by_index(clk, i));

drivers/clk/versatile/clk-sp810.c:102: clk_prepare(new_parent);
drivers/clk/versatile/clk-sp810.c:104: clk_unprepare(old_parent);

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

--
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: [RESUBMIT PATCH v3 2/8] backlight: Add support Skyworks SKY81452 backlight driver

[Jingoo Han]

On Tuesday, October 07, 2014 2:01 PM, Gyungoh Yoo wrote:
> 

If possible, please add more detailed commit message for this patch.

> Signed-off-by: Gyungoh Yoo 
> ---
>  drivers/video/backlight/Kconfig  |  10 +
>  drivers/video/backlight/Makefile |   1 +
>  drivers/video/backlight/sky81452-backlight.c | 347 
> +++
>  3 files changed, 358 insertions(+)
>  create mode 100644 drivers/video/backlight/sky81452-backlight.c
> 
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 8d03924..2586fdd 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -409,6 +409,16 @@ config BACKLIGHT_PANDORA
> If you have a Pandora console, say Y to enable the
> backlight driver.
> 
> +config BACKLIGHT_SKY81452
> + tristate "Backlight driver for SKY81452"
> + depends on BACKLIGHT_CLASS_DEVICE && MFD_SKY81452
> + help
> +   If you have a Skyworks SKY81452, say Y to enable the
> +   backlight driver.
> +
> +   To compile this driver as a module, choose M here: the module will
> +   be called sky81452-backlight
> +
>  config BACKLIGHT_TPS65217
>   tristate "TPS65217 Backlight"
>   depends on BACKLIGHT_CLASS_DEVICE && MFD_TPS65217
> diff --git a/drivers/video/backlight/Makefile 
> b/drivers/video/backlight/Makefile
> index fcd50b73..d67073f 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -50,6 +50,7 @@ obj-$(CONFIG_BACKLIGHT_PANDORA) += pandora_bl.o
>  obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
>  obj-$(CONFIG_BACKLIGHT_PWM)  += pwm_bl.o
>  obj-$(CONFIG_BACKLIGHT_SAHARA)   += kb3886_bl.o
> +obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
>  obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
>  obj-$(CONFIG_BACKLIGHT_TPS65217) += tps65217_bl.o
>  obj-$(CONFIG_BACKLIGHT_WM831X)   += wm831x_bl.o
> diff --git a/drivers/video/backlight/sky81452-backlight.c 
> b/drivers/video/backlight/sky81452-
> backlight.c
> new file mode 100644
> index 000..101399d
> --- /dev/null
> +++ b/drivers/video/backlight/sky81452-backlight.c
> @@ -0,0 +1,347 @@
> +/*
> + * sky81452-backlight.c  SKY81452 backlight driver
> + *
> + * Copyright 2014 Skyworks Solutions Inc.
> + * Author : Gyungoh Yoo 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2, or (at your option) any
> + * later version.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Please, re-order these headers alphabetically.
It enhances the readability.

> +
> +/* registers */
> +#define SKY81452_REG00x00
> +#define SKY81452_REG10x01
> +#define SKY81452_REG20x02
> +#define SKY81452_REG40x04
> +#define SKY81452_REG50x05
> +
> +/* bit mask */
> +#define SKY81452_CS  0xFF
> +#define SKY81452_EN  0x3F
> +#define SKY81452_IGPW0x20
> +#define SKY81452_PWMMD   0x10
> +#define SKY81452_PHASE   0x08
> +#define SKY81452_ILIM0x04
> +#define SKY81452_VSHRT   0x03
> +#define SKY81452_OCP 0x80
> +#define SKY81452_OTMP0x40
> +#define SKY81452_SHRT0x3F
> +#define SKY81452_OPN 0x3F
> +
> +#define SKY81452_DEFAULT_NAME "lcd-backlight"
> +#define SKY81452_MAX_BRIGHTNESS  (SKY81452_CS + 1)
> +
> +#define CTZ(b) __builtin_ctz(b)
> +
> +static int sky81452_bl_update_status(struct backlight_device *bd)
> +{
> + const struct sky81452_bl_platform_data *pdata =
> + dev_get_platdata(bd->dev.parent);
> + const unsigned int brightness = (unsigned int)bd->props.brightness;
> + struct regmap *regmap = bl_get_data(bd);
> + int ret;
> +
> + if (brightness > 0) {
> + ret = regmap_write(regmap, SKY81452_REG0, brightness - 1);
> + if (IS_ERR_VALUE(ret))
> + return ret;
> +
> + return regmap_update_bits(regmap, SKY81452_REG1, SKY81452_EN,
> + pdata->enable << CTZ(SKY81452_EN));
> + }
> +
> + return regmap_update_bits(regmap, SKY81452_REG1, SKY81452_EN, 0);
> +}
> +
> +static int sky81452_bl_get_brightness(struct backlight_device *bd)
> +{
> + return bd->props.brightness;
> +}
> +
> +static const struct backlight_ops sky81452_bl_

Re: [PATCH 2/2 v2] SPI: spi-pxa2xx: SPI support for Intel Quark X1000

[Bryan O'Donoghue]

On 29/09/14 15:22, Weike Chen wrote:

+   .num_chipselect = 4,


How is this right ?

There's only one physical chip-select line per SPI master...

It's a 1:1 mapping.

Best,
Bryan
--
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] staging: rtl8712: fix unnecessary elses after return/break in rtl8712_efuse.c

[Joe Perches]

On Tue, 2014-10-07 at 16:48 -0700, Serguey Parkhomovsky wrote:
> This patch fixes two unnecessary else conditions that were found by 
> checkpatch.pl.
[]
> diff --git a/drivers/staging/rtl8712/rtl8712_efuse.c 
> b/drivers/staging/rtl8712/rtl8712_efuse.c
[]
> @@ -414,19 +414,19 @@ u8 r8712_efuse_pg_packet_write(struct _adapter 
> *padapter, const u8 offset,
[]
> + /* call rescue procedure */
> + if (fix_header(padapter, efuse_data, efuse_addr) ==
> + false)
> + return false; /* rescue fail */

Probably better as:

if (!fix_header(padapter, efuse_data, efuse_addr))
return false;   /* rescue fail */



--
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: PERF_EVENT_IOC_SET_FILTER has different values based on bitness

[Andi Kleen]

David Ahern  writes:

> On 10/7/14, 6:50 PM, Andi Kleen wrote:
>> David Ahern  writes:

 diff --git a/kernel/events/core.c b/kernel/events/core.c
 index 963bf139e2b2..c805132ac1cf 100644
 --- a/kernel/events/core.c
 +++ b/kernel/events/core.c
 @@ -3714,6 +3714,7 @@ static long perf_ioctl(struct file *file, unsigned
 int cmd, unsigned long arg)
   }

   case PERF_EVENT_IOC_SET_FILTER:
 +   case PERF_EVENT_IOC_SET_FILTER_32:
   return perf_event_set_filter(event, (void __user *)arg);

   default:

>>>
>>> Oh, PERF_EVENT_IOC_ID has the same problem:
>>>
>>> #define PERF_EVENT_IOC_ID   _IOR('$', 7, __u64 *)
>>
>> The right way is to add a compat_perf_ioctl()
>
> Sure, looked into that way as well. But SET_FILTER and IOC_ID will
> still compile to the same values for a 64-bit kernel.

Sure you have to add/use the new defines too.

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only
--
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: PERF_EVENT_IOC_SET_FILTER has different values based on bitness

[David Ahern]

On 10/7/14, 6:50 PM, Andi Kleen wrote:

David Ahern  writes:


diff --git a/kernel/events/core.c b/kernel/events/core.c
index 963bf139e2b2..c805132ac1cf 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -3714,6 +3714,7 @@ static long perf_ioctl(struct file *file, unsigned
int cmd, unsigned long arg)
  }

  case PERF_EVENT_IOC_SET_FILTER:
+   case PERF_EVENT_IOC_SET_FILTER_32:
  return perf_event_set_filter(event, (void __user *)arg);

  default:



Oh, PERF_EVENT_IOC_ID has the same problem:

#define PERF_EVENT_IOC_ID   _IOR('$', 7, __u64 *)


The right way is to add a compat_perf_ioctl()


Sure, looked into that way as well. But SET_FILTER and IOC_ID will still 
compile to the same values for a 64-bit kernel.


David

--
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: PERF_EVENT_IOC_SET_FILTER has different values based on bitness

[Andi Kleen]

David Ahern  writes:
>>
>> diff --git a/kernel/events/core.c b/kernel/events/core.c
>> index 963bf139e2b2..c805132ac1cf 100644
>> --- a/kernel/events/core.c
>> +++ b/kernel/events/core.c
>> @@ -3714,6 +3714,7 @@ static long perf_ioctl(struct file *file, unsigned
>> int cmd, unsigned long arg)
>>  }
>>
>>  case PERF_EVENT_IOC_SET_FILTER:
>> +   case PERF_EVENT_IOC_SET_FILTER_32:
>>  return perf_event_set_filter(event, (void __user *)arg);
>>
>>  default:
>>
>
> Oh, PERF_EVENT_IOC_ID has the same problem:
>
> #define PERF_EVENT_IOC_ID   _IOR('$', 7, __u64 *)

The right way is to add a compat_perf_ioctl() 

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only
--
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 resend] perf top: Add a visual cue for toggle zeroing of samples

[Namhyung Kim]

Hi Taeung,

On Tue,  7 Oct 2014 16:13:15 +0900, Taeung Song wrote:
> When 'perf top' is run, one can't easily find a difference
> between -z option and normal output.
> So I added a visual cue to know whether it is the zeroing or not.
>
> Output is as below.
>
> Before:
>  $ perf top
>
>  Samples: 61K of event 'cycles', Event count (approx.): 3908136933
>  Overhead  Shared Object   Symbol
> 1.42%  firefox [.] 0x00011e76
> 1.32%  libpthread-2.17.so  [.] pthread_mutex_lock
>
> If you press key 'z' or run with zero option like '$ perf top --zero', it is 
> as below.
>
> After:
>  Samples: 61K of event 'cycles', Event count (approx.): 3908136933 [z]
>  Overhead  Shared Object   Symbol
> 1.42%  firefox [.] 0x00011e76
> 1.32%  libpthread-2.17.so  [.] pthread_mutex_lock
>
> Signed-off-by: Taeung Song 

Acked-by: Namhyung Kim 

Thanks,
Namhyung


> ---
>  tools/perf/ui/browsers/hists.c | 32 ++--
>  1 file changed, 22 insertions(+), 10 deletions(-)
>
> diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
> index 8f60a97..79b66d0 100644
> --- a/tools/perf/ui/browsers/hists.c
> +++ b/tools/perf/ui/browsers/hists.c
> @@ -35,7 +35,9 @@ struct hist_browser {
>  
>  extern void hist_browser__init_hpp(void);
>  
> -static int hists__browser_title(struct hists *hists, char *bf, size_t size);
> +static int hists__browser_title(struct hists *hists,
> + struct hist_browser_timer *hbt,
> + char *bf, size_t size);
>  static void hist_browser__update_nr_entries(struct hist_browser *hb);
>  
>  static struct rb_node *hists__filter_entries(struct rb_node *nd,
> @@ -390,7 +392,7 @@ static int hist_browser__run(struct hist_browser *browser,
>   browser->b.entries = &browser->hists->entries;
>   browser->b.nr_entries = hist_browser__nr_entries(browser);
>  
> - hists__browser_title(browser->hists, title, sizeof(title));
> + hists__browser_title(browser->hists, hbt, title, sizeof(title));
>  
>   if (ui_browser__show(&browser->b, title,
>"Press '?' for help on key bindings") < 0)
> @@ -417,7 +419,8 @@ static int hist_browser__run(struct hist_browser *browser,
>   ui_browser__warn_lost_events(&browser->b);
>   }
>  
> - hists__browser_title(browser->hists, title, 
> sizeof(title));
> + hists__browser_title(browser->hists,
> +  hbt, title, sizeof(title));
>   ui_browser__show_title(&browser->b, title);
>   continue;
>   }
> @@ -1204,7 +1207,15 @@ static struct thread 
> *hist_browser__selected_thread(struct hist_browser *browser
>   return browser->he_selection->thread;
>  }
>  
> -static int hists__browser_title(struct hists *hists, char *bf, size_t size)
> +/* Check whether the browser is for 'top' or 'report' */
> +static inline bool is_report_browser(void *timer)
> +{
> + return timer == NULL;
> +}
> +
> +static int hists__browser_title(struct hists *hists,
> + struct hist_browser_timer *hbt,
> + char *bf, size_t size)
>  {
>   char unit;
>   int printed;
> @@ -1256,6 +1267,13 @@ static int hists__browser_title(struct hists *hists, 
> char *bf, size_t size)
>   if (dso)
>   printed += scnprintf(bf + printed, size - printed,
>   ", DSO: %s", dso->short_name);
> + if (!is_report_browser(hbt)) {
> + struct perf_top *top = hbt->arg;
> +
> + if (top->zero)
> + printed += scnprintf(bf + printed, size - printed, " 
> [z]");
> + }
> +
>   return printed;
>  }
>  
> @@ -1267,12 +1285,6 @@ static inline void free_popup_options(char **options, 
> int n)
>   zfree(&options[i]);
>  }
>  
> -/* Check whether the browser is for 'top' or 'report' */
> -static inline bool is_report_browser(void *timer)
> -{
> - return timer == NULL;
> -}
> -
>  /*
>   * Only runtime switching of perf data file will make "input_name" point
>   * to a malloced buffer. So add "is_input_name_malloced" flag to decide
--
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 v2] SPI: spi-pxa2xx: Add helpers for regiseters' accessing

[Chen, Alvin]

> I'm okay with the current version, though I have few minor comments below.
> 
> > Introduce helper functions to access the 'SSCR0' and 'SSCR1'.
> >
> 
> Like you said in the summary there are many accessors to many registers, not
> only cr1/cr0. Perhaps, you may extend your commit message.
> 
OK.

> In any case
> Reviewed-by: Andy Shevchenko 
> 
OK.
> > +
> >  /*
> >   * Read and write LPSS SSP private registers. Caller must first check that
> >   * is_lpss_ssp() returns true before these can be called.
> > @@ -234,7 +301,7 @@ static int null_writer(struct driver_data *drv_data)
> > void __iomem *reg = drv_data->ioaddr;
> > u8 n_bytes = drv_data->n_bytes;
> >
> > -   if (((read_SSSR(reg) & SSSR_TFL_MASK) == SSSR_TFL_MASK)
> > +   if (pxa2xx_spi_txfifo_full(drv_data)
> > || (drv_data->tx == drv_data->tx_end))
> 
> Just wondering if those two could fit one line.
> 
No, if make the two in one line, it is 84 characters.

Re: [v3, 08/16] powerpc/powerpc: Add new PCIe functions for allocating cxl interrupts

[Michael Neuling]

On Wed, 2014-10-08 at 09:59 +1100, Michael Ellerman wrote:
> On Tue, 2014-07-10 at 10:48:14 UTC, Michael Neuling wrote:
> > From: Ian Munsie 
> > 
> > This adds a number of functions for allocating IRQs under powernv PCIe for 
> > cxl.
> > 
> > diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
> > b/arch/powerpc/platforms/powernv/pci-ioda.c
> > index baf3de6..3b67010b 100644
> > --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> > +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> > @@ -38,6 +38,8 @@
> >  #include 
> >  #include 
> >  
> > +#include 
> 
> You should be including pnv-pci.h here.
> 
> Otherwise the header and the implementation could get out of sync, it will 
> also
> fix these:
> 
>   arch/powerpc/platforms/powernv/pci-ioda.c:1365:5: warning: symbol 
> 'pnv_phb_to_cxl' was not declared. Should it be static?
>   arch/powerpc/platforms/powernv/pci-ioda.c:1389:5: warning: symbol 
> 'pnv_cxl_alloc_hwirqs' was not declared. Should it be static?
>   arch/powerpc/platforms/powernv/pci-ioda.c:1404:6: warning: symbol 
> 'pnv_cxl_release_hwirqs' was not declared. Should it be static?
>   arch/powerpc/platforms/powernv/pci-ioda.c:1413:6: warning: symbol 
> 'pnv_cxl_release_hwirq_ranges' was not declared. Should it be static?
>   arch/powerpc/platforms/powernv/pci-ioda.c:1433:5: warning: symbol 
> 'pnv_cxl_alloc_hwirq_ranges' was not declared. Should it be static?
>   arch/powerpc/platforms/powernv/pci-ioda.c:1470:5: warning: symbol 
> 'pnv_cxl_get_irq_count' was not declared. Should it be static?
>   arch/powerpc/platforms/powernv/pci-ioda.c:1479:5: warning: symbol 
> 'pnv_cxl_ioda_msi_setup' was not declared. Should it be static?

Ok... will fix.

Mikey
--
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: [v3,12/16] cxl: Add base builtin support

[Michael Neuling]

On Wed, 2014-10-08 at 10:04 +1100, Michael Ellerman wrote:
> On Tue, 2014-07-10 at 10:48:18 UTC, Michael Neuling wrote:
> > From: Ian Munsie 
> > 
> > This adds the base cxl support that needs to be build into the kernel to use
> > cxl as a module. This is needed so that the cxl call backs from the core
> > powerpc mm code always exist irrespective of if the cxl module is loaded or
> > not. This is similar to how cell works with CONFIG_SPU_BASE.
> > 
> > This adds a cxl_slbia() call (similar to spu_flush_all_slbs()) which checks 
> > for
> > the cxl module being loaded. If the modules is not loaded we return, 
> > otherwise
> > we call into the cxl SLB invalidation code.
> > 
> > This also adds the cxl_ctx_in_use() function for use in the mm code to see 
> > if
> > any cxl contexts are currently in use. This is used by the tlbie() to
> > determine if it can do local TLB invalidations or not. This also adds 
> > get/put
> > calls for the cxl driver module to refcount the active cxl contexts.
> 
> This last paragraph is no longer true.

Yep, thanks.  I'll move it to patch 7 where it does apply.

Mikey

--
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] HID: rmi: Scan the report descriptor to determine if the device is suitable for the hid-rmi driver

[Andrew Duggan]

Hi Benjamin,

Thanks for reviewing.

On 10/03/2014 02:25 PM, Benjamin Tissoires wrote:

Hi Andrew,

On Oct 02 2014 or thereabouts, Andrew Duggan wrote:

On composite HID devices there may be multiple HID devices on separate 
interfaces, but hid-rmi
should only bind to the touchpad. Commit 
e19ff99f256aeeff6c07b373e01883b72e049552 simply checked
that the interface protocol was set to mouse. Unfortuately, it is not always 
the case that the
touchpad has the mouse interface protocol set. This patch takes a different 
approach and scans
the report descriptor looking for the Vendor Specific Top Level Collection and 
the associated
usages and report IDs needed by the hid-rmi driver to interface with the device.

I am going to leave for XDC 2014 next week and then I'll have one week
off, so I prefer sending my impressions now (or it will have to wait 2
more weeks).

I am not sure this solution is sustainable in the long term. If every
driver starts checking each vendor collection in core, there is no point
in having core and drivers separated.
Unfortunately, I can not think of an easier way of doing it. So I think
(but Jiri can choose to ignore me) that we should at least hold this
until 3.19 development starts.
I agree checking for specific vendor's reports in core isn't ideal, but 
I couldn't figure out a better way to uniquely identify our touchpad on 
certain composite USB devices.


Specifically, I am looking at the Razer Blade 14" laptop which has a 
composite USB device with 4 HID devices on separate interfaces. One is 
the touchpad, two others report to be keyboards, and the forth device 
shows up as a mouse. Since the VID and PID are identical, scanning the 
report descriptor is the only way to determine which device. There are 
slight differences in the report descriptors which we could use to make 
a guess. For instance our touchpad uses Application 
GenericDesktop.Pointer while the other device uses GenericDesktop.Mouse. 
The fact that only one has a vendor specific collection is also an 
indication. But, these indicators don't seem particularly conclusive. 
Also, the mouse device has it's interface protocol set to mouse instead 
of the touchpad, so the current code which checks that value would 
attach to the wrong device (if you add the Razer VID and PID to the 
Vendor specific handling check in hid_scan_report).



One or two more comments inlined:


Signed-off-by: Andrew Duggan 
---
  drivers/hid/hid-core.c | 42 +-
  include/linux/hid.h|  8 +++-
  2 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 12b6e67..498f674 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -686,6 +686,23 @@ static void hid_scan_input_usage(struct hid_parser 
*parser, u32 usage)
  
  	if (usage == HID_DG_CONTACTID)

hid->group = HID_GROUP_MULTITOUCH;
+
+   if (usage == 0xff04 && parser->global.report_id == 0xb)
+   parser->scan_flags |= HID_SCAN_FLAG_RMI_INPUT_READ;
+
+   if (usage == 0xff05 && parser->global.report_id == 0xc)
+   parser->scan_flags |= HID_SCAN_FLAG_RMI_ATTN;
+}
+
+static void hid_scan_output_usage(struct hid_parser *parser, u32 usage)
+{
+   struct hid_device *hid = parser->device;
+
+   if (usage == 0xff02 && parser->global.report_id == 0x9)
+   parser->scan_flags |= HID_SCAN_FLAG_RMI_WRITE;
+
+   if (usage == 0xff03 && parser->global.report_id == 0xa)
+   parser->scan_flags |= HID_SCAN_FLAG_RMI_OUTPUT_READ;
  }
  
  static void hid_scan_feature_usage(struct hid_parser *parser, u32 usage)

@@ -693,6 +710,9 @@ static void hid_scan_feature_usage(struct hid_parser 
*parser, u32 usage)
if (usage == 0xffc5 && parser->global.report_count == 256 &&
parser->global.report_size == 8)
parser->scan_flags |= HID_SCAN_FLAG_MT_WIN_8;
+
+   if (usage == 0xff06 && parser->global.report_id == 0xf)
+   parser->scan_flags |= HID_SCAN_FLAG_RMI_MODE;
  }
  
  static void hid_scan_collection(struct hid_parser *parser, unsigned type)

@@ -702,6 +722,9 @@ static void hid_scan_collection(struct hid_parser *parser, 
unsigned type)
if (((parser->global.usage_page << 16) == HID_UP_SENSOR) &&
type == HID_COLLECTION_PHYSICAL)
hid->group = HID_GROUP_SENSOR_HUB;
+
+   if ((parser->global.usage_page << 16) == HID_UP_MSVENDOR)
+   parser->scan_flags |= HID_SCAN_FLAG_VENDOR_SPECIFIC;
  }
  
  static int hid_scan_main(struct hid_parser *parser, struct hid_item *item)

@@ -725,6 +748,10 @@ static int hid_scan_main(struct hid_parser *parser, struct 
hid_item *item)
hid_scan_input_usage(parser, parser->local.usage[i]);
break;
case HID_MAIN_ITEM_TAG_OUTPUT:
+   if (data & HID_MAIN_ITEM_CONSTANT)
+   break;
+   for (i

[PATCH] serial: 8250_dw: Add DMA support for non-ACPI platforms

[Ray Jui]

The dma pointer under struct uart_8250_port is currently left
unassigned for non-ACPI platforms. It should be pointing to the dma
member in struct dw8250_data like how it was done for ACPI, so the core
8250 code will try to request for DMA when registering the port

If DMA is not enabled in device tree, request DMA will fail and the
driver will fall back to PIO

Signed-off-by: Ray Jui 
Reviewed-by: JD (Jiandong) Zheng 
Reviewed-by: Scott Branden 
Tested-by: Scott Branden 
---
 drivers/tty/serial/8250/8250_dw.c |8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index 4db7987..1038ea8 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -293,6 +293,14 @@ static int dw8250_probe_of(struct uart_port *p,
if (has_ucv)
dw8250_setup_port(up);
 
+   /* if we have a valid fifosize, try hooking up DMA here */
+   if (p->fifosize) {
+   up->dma = &data->dma;
+
+   up->dma->rxconf.src_maxburst = p->fifosize / 4;
+   up->dma->txconf.dst_maxburst = p->fifosize / 4;
+   }
+
if (!of_property_read_u32(np, "reg-shift", &val))
p->regshift = val;
 
-- 
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] usb: ffs: fix regression when quirk_ep_out_aligned_size flag is set

[Felipe Balbi]

Hi again,

On Tue, Oct 07, 2014 at 05:18:06PM -0700, David Cohen wrote:
> The commit '2e4c7553cd usb: gadget: f_fs: add aio support' broke the
> quirk implemented to align buffer size to maxpacketsize on out endpoint.
> As result, functionfs does not work on Intel platforms using dwc3 driver
> (i.e. Bay Trail and Merrifield). This patch fixes the issue.
> 
> This code is based on a previous Qiuxu's patch.
> 

btw, please resend and add below right here:

Fixes: 2e4c7553cd (usb: gadget: f_fs: add aio support)
Cc:  # v3.16+

> Signed-off-by: David Cohen 
> Signed-off-by: Qiuxu Zhuo 

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: ffs: fix regression when quirk_ep_out_aligned_size flag is set

[Felipe Balbi]

Hi,

On Tue, Oct 07, 2014 at 05:18:06PM -0700, David Cohen wrote:
> The commit '2e4c7553cd usb: gadget: f_fs: add aio support' broke the

did that commit non-aio or is only aio broken ?

> quirk implemented to align buffer size to maxpacketsize on out endpoint.
> As result, functionfs does not work on Intel platforms using dwc3 driver
> (i.e. Bay Trail and Merrifield). This patch fixes the issue.

and Braswell.

> This code is based on a previous Qiuxu's patch.

How have you tested this ? Do you have a test-case to share ? Then I can
add it to my tests which I have been running on my platforms too (they
include USB20CV and USB30CV where applicable - quite a few fixes coming
soon).

cheers

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH 1/1 net-next] netlabel: kernel-doc warning fix

[David Miller]

From: Paul Moore 
Date: Tue, 07 Oct 2014 18:13:34 -0400

> On Tuesday, October 07, 2014 10:31:32 PM Fabian Frederick wrote:
>> no secid argument in netlbl_cfg_unlbl_static_del
>> 
>> Signed-off-by: Fabian Frederick 
> 
> Thanks.  Likely a copy/paste error from netlbl_cfg_unlbl_static_add().
> 
> Acked-by: Paul Moore 

Applied, thanks everyone.
--
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/1 net-next] wimax: convert printk to pr_foo()

[David Miller]

From: Fabian Frederick 
Date: Tue,  7 Oct 2014 22:12:03 +0200

> Use current logging functions and add module name prefix.
> 
> Signed-off-by: Fabian Frederick 

Applied, 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/

[PATCH] staging: rtl8712: fix unnecessary elses after return/break in rtl8712_efuse.c

[Serguey Parkhomovsky]

This patch fixes two unnecessary else conditions that were found by 
checkpatch.pl.

Signed-off-by: Serguey Parkhomovsky 
---
 drivers/staging/rtl8712/rtl8712_efuse.c | 41 +
 1 file changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl8712_efuse.c 
b/drivers/staging/rtl8712/rtl8712_efuse.c
index c9eeb42..0e155d9 100644
--- a/drivers/staging/rtl8712/rtl8712_efuse.c
+++ b/drivers/staging/rtl8712/rtl8712_efuse.c
@@ -414,19 +414,19 @@ u8 r8712_efuse_pg_packet_write(struct _adapter *padapter, 
const u8 offset,
bResult = false;
}
break;
-   } else { /* write header fail */
-   bResult = false;
-   if (0xFF == efuse_data)
-   return bResult; /* nothing damaged. */
-   /* call rescue procedure */
-   if (fix_header(padapter, efuse_data, efuse_addr) ==
-   false)
-   return false; /* rescue fail */
-
-   if (++repeat_times > _REPEAT_THRESHOLD_) /* fail */
-   break;
-   /* otherwise, take another risk... */
}
+   /* write header fail */
+   bResult = false;
+   if (0xFF == efuse_data)
+   return bResult; /* nothing damaged. */
+   /* call rescue procedure */
+   if (fix_header(padapter, efuse_data, efuse_addr) ==
+   false)
+   return false; /* rescue fail */
+
+   if (++repeat_times > _REPEAT_THRESHOLD_) /* fail */
+   break;
+   /* otherwise, take another risk... */
}
return bResult;
 }
@@ -541,15 +541,16 @@ u8 r8712_efuse_map_write(struct _adapter *padapter, u16 
addr, u16 cnts,
}
idx++;
break;
-   } else {
-   if ((data[idx] != pktdata[i]) || (data[idx+1] !=
-pktdata[i+1])) {
-   word_en &= ~BIT(i >> 1);
-   newdata[j++] = data[idx];
-   newdata[j++] = data[idx + 1];
-   }
-   idx += 2;
}
+
+   if ((data[idx] != pktdata[i]) || (data[idx+1] !=
+pktdata[i+1])) {
+   word_en &= ~BIT(i >> 1);
+   newdata[j++] = data[idx];
+   newdata[j++] = data[idx + 1];
+   }
+   idx += 2;
+
if (idx == cnts)
break;
}
-- 
1.9.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: [PATCH] [RFC] mnt: add ability to clone mntns starting with the current root

[Andy Lutomirski]

On Tue, Oct 7, 2014 at 5:20 PM, Eric W. Biederman  wrote:
> Andy Lutomirski  writes:
>
>> On Tue, Oct 7, 2014 at 4:42 PM, Eric W. Biederman  
>> wrote:
>>> Andy Lutomirski  writes:
>>>
 On Tue, Oct 7, 2014 at 3:42 PM, Eric W. Biederman  
 wrote:
> Andy Lutomirski  writes:
>
>> On Tue, Oct 7, 2014 at 2:42 PM, Eric W. Biederman 
>>  wrote:
>>>
>>> I am squinting and looking this way and that but while I can imagine
>>> someone more clever than I can think up some unique property of rootfs
>>> that makes it a little more exploitable than just mounting a ramfs,
>>> but since you have to be root to exploit those properties I think the
>>> game is pretty much lost.
>>
>> Yes.  rootfs might not be empty, it might have totally insane
>> permissions, and it's globally shared, which makes it into a wonderful
>> channel to pass things around that shouldn't be passed around.
>
> But if only root with proc mounted can reach it...  I don't know.

 It doesn't have to be global root.  It could be userns root.

> There might be a case for setting MNT_LOCKED when we overmount "/"
> as root but I don't yet see it.
>
>> Can non-root do this?  You'd need to be in a userns with a "/" that
>> isn't MNT_LOCKED.  Can this happen on any normal setup?
>>
>> FWIW, I think we should unconditionally MNT_LOCKED the root on userns
>> unshare, even if it's the only mount.
>
> To the best of my knowledge MNT_LOCKED is set uncondintially on userns
> unshare.

 Only if list_empty(&old->mnt_expire), whatever that means, I think.
>>>
>>> An autofs or nfs automounted mount.  Can those ever become root?
>>
>> Dunno.
>>
>> I thought that this code was what set MNT_LOCKED for things that
>> should be locked:
>
> It does.
>
>> /* Don't allow unprivileged users to reveal what is under a mount */
>> if ((flag & CL_UNPRIVILEGED) && list_empty(&old->mnt_expire))
>> mnt->mnt.mnt_flags |= MNT_LOCKED;
>>
>> Now I'm confused.  Shouldn't that be checking for submounts?  Is that
>> what it's doing?
>
> As it copies each mount (mostly submounts) it sets MNT_LOCKED.

Oh.  They're *all* MNT_LOCKED.  Duh.

>
>> Anyway, I think that this should unconditionally set MNT_LOCKED on the
>> thing that mounted on rootfs.
>
> As I read the code mnt_set_expiry is only for nfs, cifs, and afs
> submounts (and perhaps proc should use them). So as they are generated
> mnt_expiry should never start on the root of filesystem of the mount tree.
>
> Furthermore mnt_expiry is cleared when a mount is moved, and when
> it is bind mounted, or propagated.
>
> pivot_root does look as though it may be missing the proper mnt_expiry
> handling list_del_init(&old->mnt_expire), but pivot_root does have
> proper MNT_LOCKED handling.

pivot_root is quite broken, as noted in my other email.  It's just not
broken like this, I think. :)

>
> Looking that test was slightly off and it should be:
> if ((flag & CL_UNPRIVILEGED) &&
> (!(flag & CL_EXPIRE) || list_empty(&old->mnt_expire))
> mnt->mnt.mnt_flags |= MNT_LOCKED;
>
> So on that note we might clear CL_EXPIRE when CL_UNPRIVILEGED is set
> in copy_tree but I don't see that as being really needed.
>
> Eric



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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 resend] MIPS: Allow FPU emulator to use non-stack area.

[Andy Lutomirski]

On Oct 7, 2014 1:03 PM, "David Daney"  wrote:
>
> On 10/07/2014 12:28 PM, Andy Lutomirski wrote:
>>
>> On Tue, Oct 7, 2014 at 12:21 PM, Rich Felker  wrote:
>>>
>>> On Tue, Oct 07, 2014 at 12:16:59PM -0700, Leonid Yegoshin wrote:

 On 10/07/2014 12:09 PM, Rich Felker wrote:
>
> I agree completely here. We should not break things (or, as it
> seems, leave them broken) for common usage cases that affect
> everyone just to coddle proprietary vendor-specific instructions.
> The latter just should not be used in delay slots unless the chip
> vendor also promises to provide fpu branch in hardware. Rich

 And what do you propose - remove a current in-stack emulation and
 you still think it doesn't break a status-quo?
>>>
>>>
>>> The in-stack trampoline support could be left but used only for
>>> emulating instructions the kernel doesn't know. This would make all
>>> normal binaries immediately usable with non-executable stack, and
>>> would avoid the only potential source of regressions. Ultimately I
>>> think the "xol" stuff should be removed, but that could be a long term
>>> goal.
>>
>>
>> Does anything break if the xol stuff is disabled for PT_GNU_STACK tasks?
>>
>
> The instructions must be executed, if you turn on a non-executable stack, you 
> cannot execute them on the stack, so they must be handled in another way, 
> which is the subject of this thread.
>
> Options:
>
> 1a) XOL kernel manages the memory
> 1b) XOL userspace manages the menory
> 2) Emulate the instructions.
> 3) I don't think there is a 3rd. option.

4) SIGILL

5) single-step or use an HW breakpoint if available


But, yes, 3 seems reasonable.

--Andy
--
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] [RFC] mnt: add ability to clone mntns starting with the current root

[Eric W. Biederman]

Andy Lutomirski  writes:

> On Tue, Oct 7, 2014 at 4:42 PM, Eric W. Biederman  
> wrote:
>> Andy Lutomirski  writes:
>>
>>> On Tue, Oct 7, 2014 at 3:42 PM, Eric W. Biederman  
>>> wrote:
 Andy Lutomirski  writes:

> On Tue, Oct 7, 2014 at 2:42 PM, Eric W. Biederman  
> wrote:
>>
>> I am squinting and looking this way and that but while I can imagine
>> someone more clever than I can think up some unique property of rootfs
>> that makes it a little more exploitable than just mounting a ramfs,
>> but since you have to be root to exploit those properties I think the
>> game is pretty much lost.
>
> Yes.  rootfs might not be empty, it might have totally insane
> permissions, and it's globally shared, which makes it into a wonderful
> channel to pass things around that shouldn't be passed around.

 But if only root with proc mounted can reach it...  I don't know.
>>>
>>> It doesn't have to be global root.  It could be userns root.
>>>
 There might be a case for setting MNT_LOCKED when we overmount "/"
 as root but I don't yet see it.

> Can non-root do this?  You'd need to be in a userns with a "/" that
> isn't MNT_LOCKED.  Can this happen on any normal setup?
>
> FWIW, I think we should unconditionally MNT_LOCKED the root on userns
> unshare, even if it's the only mount.

 To the best of my knowledge MNT_LOCKED is set uncondintially on userns
 unshare.
>>>
>>> Only if list_empty(&old->mnt_expire), whatever that means, I think.
>>
>> An autofs or nfs automounted mount.  Can those ever become root?
>
> Dunno.
>
> I thought that this code was what set MNT_LOCKED for things that
> should be locked:

It does.

> /* Don't allow unprivileged users to reveal what is under a mount */
> if ((flag & CL_UNPRIVILEGED) && list_empty(&old->mnt_expire))
> mnt->mnt.mnt_flags |= MNT_LOCKED;
>
> Now I'm confused.  Shouldn't that be checking for submounts?  Is that
> what it's doing?

As it copies each mount (mostly submounts) it sets MNT_LOCKED.

> Anyway, I think that this should unconditionally set MNT_LOCKED on the
> thing that mounted on rootfs.

As I read the code mnt_set_expiry is only for nfs, cifs, and afs
submounts (and perhaps proc should use them). So as they are generated
mnt_expiry should never start on the root of filesystem of the mount tree.

Furthermore mnt_expiry is cleared when a mount is moved, and when
it is bind mounted, or propagated.

pivot_root does look as though it may be missing the proper mnt_expiry
handling list_del_init(&old->mnt_expire), but pivot_root does have
proper MNT_LOCKED handling.

Looking that test was slightly off and it should be:
if ((flag & CL_UNPRIVILEGED) &&
(!(flag & CL_EXPIRE) || list_empty(&old->mnt_expire))
mnt->mnt.mnt_flags |= MNT_LOCKED;

So on that note we might clear CL_EXPIRE when CL_UNPRIVILEGED is set
in copy_tree but I don't see that as being really needed.

Eric
--
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/