[PATCH v3 0/3]: ezusb FX2 support, firmware downloading support
Hello, this is v3 of a patches-series for controllers using the ezusb-functions. euzsb: add support for Cypress FX2LP ezusb: add functions for firmware download ezusb: move ezusb.c from drivers/usb/serial to drivers/usb/misc -- René Bürgel SOHARD Embedded Systems GmbH -- 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 4/7] dw_dmac: autoconfigure block_size or use platform data
On Mon, Sep 17, 2012 at 1:09 PM, Andy Shevchenko
wrote:
> @@ -1380,6 +1370,7 @@ static int __devinit dw_probe(struct platform_device
> *pdev)
> boolautocfg;
> unsigned intdw_params;
> unsigned intnr_channels;
> + unsigned intmax_blk_size;
> int irq;
> int err;
> int i;
> @@ -1420,6 +1411,9 @@ static int __devinit dw_probe(struct platform_device
> *pdev)
>
> dw->regs = regs;
>
> + /* get hardware configuration parameters */
> + max_blk_size = dma_readl(dw, MAX_BLK_SIZE);
> +
Do this only for autocfg case.
> /* Calculate all channel mask before DMA setup */
> dw->all_chan_mask = (1 << nr_channels) - 1;
>
> @@ -1465,6 +1459,14 @@ static int __devinit dw_probe(struct platform_device
> *pdev)
> INIT_LIST_HEAD(&dwc->free_list);
>
> channel_clear_bit(dw, CH_EN, dwc->mask);
> +
> + /* hardware configuration */
> + if (autocfg) {
> + dwc->block_size =
> + (4 << ((max_blk_size >> 4 * i) & 0xf)) - 1;
Put a comment on what are you doing here.
> + } else {
> + dwc->block_size = pdata->block_size;
> + }
Don't need {} for single line statements.
> }
>
> /* Clear all interrupts on all channels. */
> diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
> index 0f96965..233f5e5 100644
> --- a/drivers/dma/dw_dmac_regs.h
> +++ b/drivers/dma/dw_dmac_regs.h
> @@ -186,6 +186,9 @@ struct dw_dma_chan {
>
> unsigned intdescs_allocated;
>
> + /* hardware configuration */
> + unsigned short block_size;
> +
You actually don't save any memory here with short and actually makes access
to block_size more complex. keeping it int would be better i believe.
viresh
--
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/
[GIT PULL] rpmsg: a fix for 3.6
Hi Linus, The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217: Linux 3.6-rc5 (2012-09-08 16:43:45 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git tags/rpmsg-3.6-fix for you to fetch changes up to eeb0074f36d1ab0729d06f1c56add9c7799679e2: rpmsg: fix dma_free_coherent dev parameter (2012-09-12 12:03:57 +0300) A quick rpmsg fix from Fernando, fixing two buggy invocations of dma_free_coherent. Fernando Guzman Lugo (1): rpmsg: fix dma_free_coherent dev parameter drivers/rpmsg/virtio_rpmsg_bus.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch] [SCSI] lpfc: fix an '&&' vs '&' typo
The intent here was clearly to do a bitwise AND similar to the others in
this file. The current condition is never true.
Signed-off-by: Dan Carpenter
---
Only needed in linux-next.
diff --git a/drivers/scsi/lpfc/lpfc_ct.c b/drivers/scsi/lpfc/lpfc_ct.c
index 7ffabb7..65f9fb6 100644
--- a/drivers/scsi/lpfc/lpfc_ct.c
+++ b/drivers/scsi/lpfc/lpfc_ct.c
@@ -634,7 +634,7 @@ lpfc_cmpl_ct_cmd_gid_ft(struct lpfc_hba *phba, struct
lpfc_iocbq *cmdiocb,
/* Check for retry */
if (vport->fc_ns_retry < LPFC_MAX_NS_RETRY) {
if (irsp->ulpStatus != IOSTAT_LOCAL_REJECT ||
- (irsp->un.ulpWord[4] && IOERR_PARAM_MASK) !=
+ (irsp->un.ulpWord[4] & IOERR_PARAM_MASK) !=
IOERR_NO_RESOURCES)
vport->fc_ns_retry++;
--
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/
[GIT PULL] hwspinlock: a single fix for 3.6
Hi Linus, The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217: Linux 3.6-rc5 (2012-09-08 16:43:45 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ohad/hwspinlock.git tags/hwspinlock-3.6-fix for you to fetch changes up to e352614cd3e7a5f7af7cff894a3b5a705181de21: hwspinlock/core: move the dereference below the NULL test (2012-09-10 13:19:25 +0300) A single hwspinlock fix by Wei Yongjun, which prevents potential NULL dereferences. Wei Yongjun (1): hwspinlock/core: move the dereference below the NULL test drivers/hwspinlock/hwspinlock_core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 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: 2 physical-cpu (like 2x6core) config and NUMA?
On Tue, Sep 18, 2012 at 2:00 AM, Linda Walsh wrote: > Does the kernel support scheduling based on the different speed of > memory between "on die" vs. "off die"? I was surprised to see > that it viewed my system as 1 NUMA node with all 12 on 1 node -- when > I know that it is physically organized as 2x6. > Do I have to configure that manually or did I maybe turn off something > in my kernel config I should have turned on? Do you have anything printed with: # acpidump -a --table SRAT ? I have a Dell box with 2 physical CPUs, each of them has 6 cores. If I enable "Node Interleaving" in BIOS' Memory Setting, and boot the kernel, the SRAT table will be invisible to Linux - results the same topology as you got. If I disable "Node Interleaving" and boot the kernel, SRAT is present, and the topology is correct. Hope that helps. -- Thanks, Jike -- 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] dw_dmac: fill optional encoded parameters in register structure
On Tue, 2012-09-18 at 12:09 +0530, viresh kumar wrote: [snip] > > +#define dma_raw_readl(addr, name) \ > > + readl((addr) + offsetof(struct dw_dma_regs, name)) > > + > > +#define dma_raw_writel(addr, name, val) \ > > + writel((val), (addr) + offsetof(struct dw_dma_regs, name)) > > + > > But why don't you use earlier defined readl/writel macros: > dma_readl and dma_writel? If you look at further patches, namely 3rd, the access to the register is needed before we allocate memory for the dw_dma structure. -- Andy Shevchenko Intel Finland Oy -- 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] pinctrl: imx: remove duplicated const
fix smatch warning:
drivers/pinctrl/pinctrl-imx.c:435:21: warning: duplicate const
Signed-off-by: Richard Zhao
---
drivers/pinctrl/pinctrl-imx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-imx.c b/drivers/pinctrl/pinctrl-imx.c
index a13b888..b3c994a 100644
--- a/drivers/pinctrl/pinctrl-imx.c
+++ b/drivers/pinctrl/pinctrl-imx.c
@@ -432,7 +432,7 @@ static int __devinit imx_pinctrl_parse_groups(struct
device_node *np,
{
unsigned int pin_func_id;
int ret, size;
- const const __be32 *list;
+ const __be32 *list;
int i, j;
u32 config;
--
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 3/7] dw_dmac: get number of channels from hardware if possible
On Mon, Sep 17, 2012 at 1:09 PM, Andy Shevchenko
wrote:
> In case the controller has the encoded parameters feature enabled the driver
> will use it to get the number of channels. In the future it will be used for
> the other important parameters as well.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/dma/dw_dmac.c | 33 +++--
> drivers/dma/dw_dmac_regs.h |4
> 2 files changed, 27 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index 75ab5af..2a3b730 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -1376,6 +1376,10 @@ static int __devinit dw_probe(struct platform_device
> *pdev)
> struct resource *io;
> struct dw_dma *dw;
> size_t size;
> + void __iomem*regs;
> + boolautocfg;
> + unsigned intdw_params;
> + unsigned intnr_channels;
> int irq;
> int err;
> int i;
> @@ -1392,23 +1396,32 @@ static int __devinit dw_probe(struct platform_device
> *pdev)
> if (irq < 0)
> return irq;
>
> - size = sizeof(struct dw_dma);
> - size += pdata->nr_channels * sizeof(struct dw_dma_chan);
> + regs = devm_request_and_ioremap(&pdev->dev, io);
> + if (!regs)
> + return -EBUSY;
> +
> + dw_params = dma_raw_readl(regs, DW_PARAMS);
Is this valid for every SoC implementation. What if this configuration
is not valid
for a particular SoC and it is invalid to access this address? Or this
gives a invalid
value instead of returning 0?
> + autocfg = dw_params >> DW_PARAMS_EN & 0x1;
> +
> + if (autocfg)
> + nr_channels = (dw_params >> DW_PARAMS_NR_CHAN & 0x7) + 1;
> + else
> + nr_channels = pdata->nr_channels;
> +
> + size = sizeof(struct dw_dma) + nr_channels * sizeof(struct
> dw_dma_chan);
> dw = devm_kzalloc(&pdev->dev, size, GFP_KERNEL);
> if (!dw)
> return -ENOMEM;
>
> - dw->regs = devm_request_and_ioremap(&pdev->dev, io);
> - if (!dw->regs)
> - return -EBUSY;
> -
> dw->clk = devm_clk_get(&pdev->dev, "hclk");
> if (IS_ERR(dw->clk))
> return PTR_ERR(dw->clk);
> clk_prepare_enable(dw->clk);
>
> + dw->regs = regs;
> +
> /* Calculate all channel mask before DMA setup */
> - dw->all_chan_mask = (1 << pdata->nr_channels) - 1;
> + dw->all_chan_mask = (1 << nr_channels) - 1;
>
> /* force dma off, just in case */
> dw_dma_off(dw);
> @@ -1426,7 +1439,7 @@ static int __devinit dw_probe(struct platform_device
> *pdev)
> tasklet_init(&dw->tasklet, dw_dma_tasklet, (unsigned long)dw);
>
> INIT_LIST_HEAD(&dw->dma.channels);
> - for (i = 0; i < pdata->nr_channels; i++) {
> + for (i = 0; i < nr_channels; i++) {
> struct dw_dma_chan *dwc = &dw->chan[i];
>
> dwc->chan.device = &dw->dma;
> @@ -1439,7 +1452,7 @@ static int __devinit dw_probe(struct platform_device
> *pdev)
>
> /* 7 is highest priority & 0 is lowest. */
> if (pdata->chan_priority == CHAN_PRIORITY_ASCENDING)
> - dwc->priority = pdata->nr_channels - i - 1;
> + dwc->priority = nr_channels - i - 1;
> else
> dwc->priority = i;
>
> @@ -1480,7 +1493,7 @@ static int __devinit dw_probe(struct platform_device
> *pdev)
> dma_writel(dw, CFG, DW_CFG_DMA_EN);
>
> printk(KERN_INFO "%s: DesignWare DMA Controller, %d channels\n",
> - dev_name(&pdev->dev), pdata->nr_channels);
> + dev_name(&pdev->dev), nr_channels);
>
> dma_async_device_register(&dw->dma);
>
> diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
> index 4633d39..0f96965 100644
> --- a/drivers/dma/dw_dmac_regs.h
> +++ b/drivers/dma/dw_dmac_regs.h
> @@ -104,6 +104,10 @@ struct dw_dma_regs {
> #define dma_raw_writel(addr, name, val) \
> writel((val), (addr) + offsetof(struct dw_dma_regs, name))
>
> +/* Bitfields in DW_PARAMS */
> +#define DW_PARAMS_NR_CHAN 8 /* number of channels */
> +#define DW_PARAMS_EN 28 /* encoded parameters */
> +
Can you make this part of patch 2/7?
> /* Bitfields in CTL_LO */
> #define DWC_CTLL_INT_EN(1 << 0)/* irqs enabled? */
> #define DWC_CTLL_DST_WIDTH(n) ((n)<<1)/* bytes per element */
> --
> 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/
Re: [PATCH] ARM: OMAP: OMAP_DEBUG_LEDS needs to select LEDS_CLASS
2012/9/18 Bryan Wu : > On Tue, Sep 18, 2012 at 11:30 AM, Axel Lin wrote: >> This fixes below build error when CONFIG_LEDS_CLASS is not set. >> >> LD init/built-in.o >> arch/arm/plat-omap/built-in.o: In function `fpga_probe': >> arch/arm/plat-omap/debug-leds.c:113: undefined reference to >> `led_classdev_register' >> make: *** [vmlinux] Error 1 >> > > Thanks for posting this. But I think Tony has already fixed it in mainline: > -- > commit 359f64f7b3997e94ee71039b5fcdc1278b9b77c4 > Author: Tony Lindgren > Date: Wed Sep 15 10:18:51 2010 -0700 > > omap: Fix compile dependency to LEDS_CLASS > > If we LEDS_CLASS is not selected, we will get undefined reference > to `led_classdev_register'. > > Signed-off-by: Tony Lindgren Commit 359f64f7b was commited on Sep 15 2010. This patch is against current linux-next tree. I got the build error on linux-next tree (next-20120917). Regards, Axel -- 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 v1 00/11] vfs: hot data tracking
On Tue, Sep 18, 2012 at 2:20 PM, Dave Chinner wrote: > On Tue, Sep 18, 2012 at 10:24:55AM +0800, Zhi Yong Wu wrote: >> On Tue, Sep 18, 2012 at 5:30 AM, Dave Chinner wrote: >> > On Mon, Sep 17, 2012 at 03:18:34PM +0800, zwu.ker...@gmail.com wrote: >> >> 20 files changed, 2275 insertions(+), 1 deletions(-) >> >> create mode 100644 fs/hot_debugfs.c >> >> create mode 100644 fs/hot_debugfs.h >> >> create mode 100644 fs/hot_hash.c >> >> create mode 100644 fs/hot_hash.h >> >> create mode 100644 fs/hot_rb.c >> >> create mode 100644 fs/hot_rb.h >> >> create mode 100644 fs/hot_track.c >> >> create mode 100644 fs/hot_track.h >> >> create mode 100644 include/linux/hot_track.h >> > >> > So, 9 new files for tracking all of this? I'm not sure that so >> > many new files are needed - putting it all in fs/hot_tracking.[ch] >> > might make more sense, or if all 8 fs/hot* files remain, putting >> > them in their own subdirectory might be an idea (like quota). >> If all functions are in two files, they will be large and the logic is >> not so clear. so i prefer the latter. thanks. > > A single file is much easier to handle when searching and editting, > though. And realistically: > > $ wc -l fs/*.c |sort -nr -k 1 |head -10 > 62483 total >4000 fs/namei.c >3281 fs/buffer.c >3169 fs/dcache.c >2677 fs/namespace.c >2364 fs/locks.c >2321 fs/exec.c >2120 fs/binfmt_elf.c >2053 fs/splice.c >1934 fs/eventpoll.c > $ > > There are plenty of files for a single function/subsystem of around > the aggregate size of this code, so everyone is used to dealing with > this amount of logic for a particular feature in a single file. > > I much prefer it that way, to tell the truth, because I find it > fairly common to have 5-10 files open at once when tracking > something through, say, the buffered IO path. If I've now got to > have another 5-10 files open just to track that same code path > through this index, then that makes it much more difficult to > manage than if were all in one .c file. > > IOWs, splitting code up into multiple files is not a win when the > resultant files are all small and interdependent and you need to > look at multiple files at the same time to understand what the code > does as a whole Just completed move them to one separate directory fs/hot_tracking/. But what you said makes sense to me, OK, i will adopt your suggestion, thanks. > > Cheers, > > Dave. > -- > Dave Chinner > da...@fromorbit.com -- Regards, Zhi Yong Wu -- 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: [tip:x86/asm] x86: Prefer TZCNT over BFS
>>> On 17.09.12 at 19:05, "H. Peter Anvin" wrote: > Honestly, I don't see a reason to not do this unconditionally. On > anything but (pre-686-era) extremely old CPUs the cost of the extra > prefix is zero. On the really old CPUs the cost of the BSF instruction > will dwarf the penalty cycle for the extra prefix, so the whole > mechanism around doing it conditionally seems pointless. I certainly don't mind re-submitting with the whole thing made unconditional (implying that the prior version would be dropped in any case). Jan -- 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] gpio: pxa: using for_each_set_bit to simplify the code
On Tue, Sep 18, 2012 at 1:56 PM, Haojian Zhuang wrote: > On Tue, Sep 18, 2012 at 1:43 PM, Eric Miao wrote: >> On Mon, Sep 17, 2012 at 6:56 PM, Linus Walleij >> wrote: >>> On Fri, Sep 14, 2012 at 4:36 AM, Wei Yongjun wrote: >>> From: Wei Yongjun Using for_each_set_bit() to simplify the code. spatch with a semantic match is used to found this. (http://coccinelle.lip6.fr/) Signed-off-by: Wei Yongjun >>> >>> PXA maintainers: does this look OK? >> >> I seem to have Acked this already in another mail, if that got lost, here >> it is: >> >> Acked-by: Eric Miao >> > The another mail thread is for irq, not gpio. I'll apply it today. :) Thanks Haojian! -- 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] dw_dmac: fill optional encoded parameters in register structure
On Mon, Sep 17, 2012 at 1:09 PM, Andy Shevchenko
wrote:
> diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
> index f6d92d7..4633d39 100644
> --- a/drivers/dma/dw_dmac_regs.h
> +++ b/drivers/dma/dw_dmac_regs.h
> @@ -82,9 +82,28 @@ struct dw_dma_regs {
> DW_REG(ID);
> DW_REG(TEST);
>
> + /* reserved */
> + DW_REG(__reserved0);
> + DW_REG(__reserved1);
> +
> /* optional encoded params, 0x3c8..0x3f7 */
> + u32 __reserved;
> +
> + /* per-channel configuration registers */
> + u32 DWC_PARAMS[DW_DMA_MAX_NR_CHANNELS];
> + u32 MULTI_BLK_TYPE;
> + u32 MAX_BLK_SIZE;
> +
> + /* top-level parameters */
> + u32 DW_PARAMS;
> };
Above is Ok.
> +#define dma_raw_readl(addr, name) \
> + readl((addr) + offsetof(struct dw_dma_regs, name))
> +
> +#define dma_raw_writel(addr, name, val) \
> + writel((val), (addr) + offsetof(struct dw_dma_regs, name))
> +
But why don't you use earlier defined readl/writel macros:
dma_readl and dma_writel?
--
viresh
--
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 Sept 18
Hi all, Changes since 201209017: Undropped tree: target-updates The arm64 tree lost its build failure. The hid tree lost its conflict. The target-updates tree lost its conflict and build failure. The sound-asoc tree gained a conflict against the v4l-dvb tree. The mfd tree lost its build failure and gained a conflict against Linus' tree. The usb tree lost 2 conflicts. The akpm tree lost its build failureand lost a few patches that turned up elsewhere. 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" as mentioned in the FAQ on the wiki (see below). 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. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 200 trees (counting Linus' and 26 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. 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. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (4651afb Merge branch 'for-3.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq) Merging fixes/master (9023a40 Merge tag 'mmc-fixes-for-3.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc) Merging kbuild-current/rc-fixes (6c7080a firmware: fix directory creation rule matching with make 3.82) Merging arm-current/fixes (beafa0d ARM: 7529/1: delay: set loops_per_jiffy when moving to timer-based loop) Merging m68k-current/for-linus (3be7184 m68k: Add missing RCU idle APIs on idle loop) Merging powerpc-merge/merge (636802e powerpc: Don't use __put_user() in patch_instruction) Merging sparc/master (5698bd7 Linux 3.6-rc6) Merging net/master (a1f6d8f Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless) Merging sound-current/for-linus (5d037f9 Merge tag 'asoc-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging pci-current/for-linus (0ff9514 PCI: Don't print anything while decoding is disabled) Merging wireless/master (e020a83 brcmfmac: Fix big endian host configuration data.) Merging driver-core.current/driver-core-linus (5698bd7 Linux 3.6-rc6) Merging tty.current/tty-linus (5698bd7 Linux 3.6-rc6) Merging usb.current/usb-linus (5698bd7 Linux 3.6-rc6) Merging staging.current/staging-linus (5698bd7 Linux 3.6-rc6) Merging char-misc.current/char-misc-linus (fea7a08 Linux 3.6-rc3) Merging input-current/for-linus (6f4d038 Input: wacom - add support for EMR on Cintiq 24HD touch) Merging md-current/for-linus (58e94ae md/raid1: close some possible races on write errors during resync) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (9b2f4cb crypto: authenc - Fix crash with zero-length assoc data) Merging ide/master (9974e43 ide: fix generic_ide_suspend/resume Oops) Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (15e06bf irqdomain: Fix debugfs formatting) Merging devicetree-current/devicetree/merge (4e8383b of: release node fix for of_parse_phandle_with_args) Merging spi-current/spi/merge (d1c185b of/spi: Fix SPI module loading by using proper "spi:" modalias prefixes.) Merging gpio-current/gpio/merge (96b7064 gpio/tca6424: merge I2C transactions, remove cast) Merging arm/for-next (8249694 Merge branches 'atags', 'fixes' and 'misc' into for-next) Merging arm-perf/for-next/
Re: [PATCH 1/7] dw_dmac: mark dwc_dump_chan_regs as inline
On Mon, Sep 17, 2012 at 1:09 PM, Andy Shevchenko
wrote:
> Signed-off-by: Andy Shevchenko
> ---
> drivers/dma/dw_dmac.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index 832538c..75ab5af 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -208,7 +208,7 @@ static inline unsigned int dwc_fast_fls(unsigned long
> long v)
> return 0;
> }
>
> -static void dwc_dump_chan_regs(struct dw_dma_chan *dwc)
> +static inline void dwc_dump_chan_regs(struct dw_dma_chan *dwc)
> {
> dev_err(chan2dev(&dwc->chan),
> " SAR: 0x%x DAR: 0x%x LLP: 0x%x CTL: 0x%x:%08x\n",
Acked-by: Viresh Kumar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: OMAP: OMAP_DEBUG_LEDS needs to select LEDS_CLASS
On Tue, Sep 18, 2012 at 11:30 AM, Axel Lin wrote: > This fixes below build error when CONFIG_LEDS_CLASS is not set. > > LD init/built-in.o > arch/arm/plat-omap/built-in.o: In function `fpga_probe': > arch/arm/plat-omap/debug-leds.c:113: undefined reference to > `led_classdev_register' > make: *** [vmlinux] Error 1 > Thanks for posting this. But I think Tony has already fixed it in mainline: -- commit 359f64f7b3997e94ee71039b5fcdc1278b9b77c4 Author: Tony Lindgren Date: Wed Sep 15 10:18:51 2010 -0700 omap: Fix compile dependency to LEDS_CLASS If we LEDS_CLASS is not selected, we will get undefined reference to `led_classdev_register'. Signed-off-by: Tony Lindgren -- -Bryan > Signed-off-by: Axel Lin > --- > arch/arm/plat-omap/Kconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig > index ca83a76..c262781 100644 > --- a/arch/arm/plat-omap/Kconfig > +++ b/arch/arm/plat-omap/Kconfig > @@ -43,6 +43,7 @@ config OMAP_DEBUG_DEVICES > > config OMAP_DEBUG_LEDS > def_bool y if NEW_LEDS > + select LEDS_CLASS > depends on OMAP_DEBUG_DEVICES > > config POWER_AVS_OMAP > -- > 1.7.9.5 > > > -- Bryan Wu Kernel Developer+86.186-168-78255 Mobile Canonical Ltd. www.canonical.com Ubuntu - Linux for human beings | www.ubuntu.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: Re: Why blktrace didn't trace requests merge?
On 2012-09-18 13:49 Jens Axboe Wrote: >On 2012-09-18 02:30, Jianpeng Ma wrote: >> On 2012-09-18 02:27 Jens Axboe Wrote: >>> On 2012-09-17 19:55, Tejun Heo wrote: (cc'ing Jens) On Mon, Sep 17, 2012 at 09:22:28AM -0400, Steven Rostedt wrote: > On Mon, 2012-09-17 at 19:33 +0800, Jianpeng Ma wrote: >> Hi all: >> I used blktrace to trace some io.But i can't find requests merge. I >> searched the code and did't not find. >> Why? >> > > No idea. I don't use blktrace much, but I Cc'd those that understand it > better than I. >>> >>> Works for me: >>> >>> [...] >>> >>> >>> 8,00 26 0.009147735 664 A WS 315226143 + 8 <- (8,7) >>> 19406344 >>> 8,00 27 0.009148677 664 Q WS 315226143 + 8 >>> [btrfs-submit-1] >>> 8,00 28 0.009152967 664 G WS 315226143 + 8 >>> [btrfs-submit-1] >>> 8,00 29 0.009154242 664 P N [btrfs-submit-1] >>> 8,00 30 0.009155538 664 A WS 315226151 + 8 <- (8,7) >>> 19406352 >>> 8,00 31 0.009155743 664 Q WS 315226151 + 8 >>> [btrfs-submit-1] >>> 8,00 32 0.009157086 664 M WS 315226151 + 8 >>> [btrfs-submit-1] >>> 8,00 33 0.009158716 664 I WS 315226143 + 16 >>> [btrfs-submit-1] >>> >>> That's from a quick trace of /dev/sda. I started blktrace, then did: >>> >>> $ dd if=/dev/zero of=foo bs=4k count=128 && sync >>> >>> to ensure that I knew merges would be happening. Output stats at the end: >>> >>> Total (sda): >>> Reads Queued: 7, 44KiB Writes Queued: 447, >>> 7692KiB >>> Read Dispatches:7, 44KiB Write Dispatches: 416, >>> 7692KiB >>> Reads Requeued: 0 Writes Requeued: 0 >>> Reads Completed:7, 44KiB Writes Completed: 435, >>> 5864KiB >>> Read Merges:0,0KiB Write Merges: 23, >>> 428KiB >>> IO unplugs:78 Timer unplugs: 0 >>> >>> -- >>> Jens Axboe >>> >> First, Thanks your time! >> If i understand correctly, the merge of your example is bio with >> request, not request wiht request. Yes or no? > >It is bio to request, correct. Request to request merges are relatively >more rare. > >-- >Jens Axboe > Thanks very much, I know. Jianpeng
Re: [RFC v1 00/11] vfs: hot data tracking
On Tue, Sep 18, 2012 at 10:24:55AM +0800, Zhi Yong Wu wrote: > On Tue, Sep 18, 2012 at 5:30 AM, Dave Chinner wrote: > > On Mon, Sep 17, 2012 at 03:18:34PM +0800, zwu.ker...@gmail.com wrote: > >> 20 files changed, 2275 insertions(+), 1 deletions(-) > >> create mode 100644 fs/hot_debugfs.c > >> create mode 100644 fs/hot_debugfs.h > >> create mode 100644 fs/hot_hash.c > >> create mode 100644 fs/hot_hash.h > >> create mode 100644 fs/hot_rb.c > >> create mode 100644 fs/hot_rb.h > >> create mode 100644 fs/hot_track.c > >> create mode 100644 fs/hot_track.h > >> create mode 100644 include/linux/hot_track.h > > > > So, 9 new files for tracking all of this? I'm not sure that so > > many new files are needed - putting it all in fs/hot_tracking.[ch] > > might make more sense, or if all 8 fs/hot* files remain, putting > > them in their own subdirectory might be an idea (like quota). > If all functions are in two files, they will be large and the logic is > not so clear. so i prefer the latter. thanks. A single file is much easier to handle when searching and editting, though. And realistically: $ wc -l fs/*.c |sort -nr -k 1 |head -10 62483 total 4000 fs/namei.c 3281 fs/buffer.c 3169 fs/dcache.c 2677 fs/namespace.c 2364 fs/locks.c 2321 fs/exec.c 2120 fs/binfmt_elf.c 2053 fs/splice.c 1934 fs/eventpoll.c $ There are plenty of files for a single function/subsystem of around the aggregate size of this code, so everyone is used to dealing with this amount of logic for a particular feature in a single file. I much prefer it that way, to tell the truth, because I find it fairly common to have 5-10 files open at once when tracking something through, say, the buffered IO path. If I've now got to have another 5-10 files open just to track that same code path through this index, then that makes it much more difficult to manage than if were all in one .c file. IOWs, splitting code up into multiple files is not a win when the resultant files are all small and interdependent and you need to look at multiple files at the same time to understand what the code does as a whole Cheers, Dave. -- Dave Chinner da...@fromorbit.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: [patch net] sky2: fix rx filter setup on link up
Tue, Sep 18, 2012 at 02:38:52AM CEST, mlind...@marvell.com wrote: >>Mon, Sep 17, 2012 at 06:12:14PM CEST, shemmin...@vyatta.com wrote: >>>On Mon, 17 Sep 2012 17:10:17 +0200 >>>Jiri Pirko wrote: >>> In my case I have following problem. sky2_set_multicast() sets registers GM_MC_ADDR_H[1-4] correctly to: 0800 0001 0410 However, when adapter gets link and sky2_link_up() is called, the values are for some reason different: 0800 0016 0410 >>> >>>Rather than papering over the problem, it would be better to >>>trace back what is setting those registers and fix that code. > >>Yes, I did that. No code at sky2.[ch] is writing to this registers other >>than sky2_set_multicast() and sky2_gmac_reset() (I hooked on sky2_write*()). >>So I strongly believe this is a HW issue (maybe only issue of my revision >>"Yukon-2 EC chip revision 2") > >I would like to check the registers as soon as I'm back in my office next week >and report my findings. Okay, I'll wait for you. If you need more info from my side, please do not hesitate to ask. Thanks! >Could you also please check the hint from Stephen? -- 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] sky2: fix rx filter setup on link up
Mon, Sep 17, 2012 at 11:15:07PM CEST, shemmin...@vyatta.com wrote: >On Mon, 17 Sep 2012 22:47:24 +0200 >Jiri Pirko wrote: > >> Mon, Sep 17, 2012 at 06:12:14PM CEST, shemmin...@vyatta.com wrote: >> >On Mon, 17 Sep 2012 17:10:17 +0200 >> >Jiri Pirko wrote: >> > >> >> In my case I have following problem. sky2_set_multicast() sets registers >> >> GM_MC_ADDR_H[1-4] correctly to: >> >> 0800 0001 0410 >> >> However, when adapter gets link and sky2_link_up() is called, the values >> >> are for some reason different: >> >> 0800 0016 0410 >> > >> >Rather than papering over the problem, it would be better to >> >trace back what is setting those registers and fix that code. >> >> Yes, I did that. No code at sky2.[ch] is writing to this registers other >> than sky2_set_multicast() and sky2_gmac_reset() (I hooked on sky2_write*()). >> So I strongly believe this is a HW issue (maybe only issue of my revision >> "Yukon-2 EC chip revision 2") >> >> > >> >> This in my case prevents iface to be able to receive packets with dst mac >> >> 01:80:C2:00:00:02 (LACPDU dst mac), which I set up previously by >> >> SIOCADDMULTI. >> >> >> >> So remember computed rx_filter data and write it to GM_MC_ADDR_H[1-4] on >> >> link_up. >> >> >> > >> >Please do some more root cause analysis. Just save/restoring the >> >registers is just a temporary workaround. > >Are you sure it isn't IPv6 or something else setting additional mulitcast >addresses. You may need to instrument the set_multicast call. I'm very sure that no code in sky2 is writing to GM_MC_ADDR_H[1-4] the change I see in sky2_link_up(). When sky2_set_multicast() is called again for any reason, the issue goes away and lacpdus are coming in. I also experimentally used sky2_set_multicast() called from sky2_link_up() and it helped as well. -- 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 5/7] pwm: i.MX: add devicetree support
On Wed, Sep 12, 2012 at 11:04:58AM +0200, Sascha Hauer wrote: > On Tue, Sep 11, 2012 at 04:40:43PM +0200, Thierry Reding wrote: > > On Mon, Sep 10, 2012 at 10:59:35AM +0200, Sascha Hauer wrote: > > > From: Philipp Zabel > > > > > > At the same time remove platform based support. No user for > > > this driver has made it into mainline so far, so all we break > > > is out of tree stuff. > > > > > > Signed-off-by: Philipp Zabel > > > Signed-off-by: Sascha Hauer > > > Reviewed-by: Shawn Guo > > > Reviewed-by: Benoît Thébaudeau > > [...] > > > > I was just doing some build tests on the series and noticed that it > > fails with this: > > > > CC [M] drivers/pwm/pwm-imx.o > > /home/thierry.reding/src/kernel/linux-pwm.git/drivers/pwm/pwm-imx.c: In > > function 'imx_pwm_config_v2': > > > > /home/thierry.reding/src/kernel/linux-pwm.git/drivers/pwm/pwm-imx.c:140:2: > > error: implicit declaration of function 'cpu_is_mx25' > > [-Werror=implicit-function-declaration] > > > > This breaks bisection in the middle of the series. It seems to be > > related to this change. > > > > > diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c > > > index a1e799e..b4e0ad3 100644 > > > --- a/drivers/pwm/pwm-imx.c > > > +++ b/drivers/pwm/pwm-imx.c > > > @@ -16,8 +16,7 @@ > > > #include > > > #include > > > #include > > > -#include > > > > This probably needs to be postponed to the next patch, until the final > > reference to cpu_is_mx25() is removed. > > Oops, you are right. I updated the tag accordingly, and did a full > compile test over this series, so please pull again: > > > The following changes since commit fea7a08acb13524b47711625eebea40a0ede69a0: > > Linux 3.6-rc3 (2012-08-22 13:29:06 -0700) > > are available in the git repository at: > > git://git.pengutronix.de/git/imx/linux-2.6.git tags/imx-pwm-oftree > > for you to fetch changes up to a1d38ca9e249e670aa9f608e1cc7491fb4ca45af: > > pwm: i.MX: fix clock lookup (2012-09-12 11:00:55 +0200) > > > Cleanup i.MX PWM driver and add devicetree support > > > Philipp Zabel (2): > pwm: i.MX: add devicetree support > pwm: i.MX: fix clock lookup > > Sascha Hauer (5): > pwm: i.MX: factor out SoC specific functions > pwm: i.MX: remove unnecessary if in pwm_[en|dis]able > pwm: i.MX: add functions to enable/disable pwm. > pwm: i.MX: Use module_platform_driver > pwm: i.MX: use per clock unconditionally > > Documentation/devicetree/bindings/pwm/imx-pwm.txt | 17 ++ > drivers/pwm/pwm-imx.c | 278 > ++--- > 2 files changed, 199 insertions(+), 96 deletions(-) > create mode 100644 Documentation/devicetree/bindings/pwm/imx-pwm.txt Applied, thanks. On a side note, I decided to pull the branch, extract the patches and apply them to my tree with git am, so this won't show up as a proper merge. This is all still pretty new to me and I'm still in the process of finding out what works best, so I hope you don't mind. Thierry pgpOJoHXqvSMC.pgp Description: PGP signature
Re: [PATCH 1/7] rtc: Convert struct i2c_msg initialization to C99 format
On 18/09/12 16:05, Shubhrajyoti wrote:
> On Tuesday 18 September 2012 07:14 AM, Ryan Mallon wrote:
>> On 17/09/12 23:58, Shubhrajyoti D wrote:
>>> Convert the struct i2c_msg initialization to C99 format. This makes
>>> maintaining and editing the code simpler. Also helps once other fields
>>> like transferred are added in future.
>>>
>>> Signed-off-by: Shubhrajyoti D
>>> ---
>>> drivers/rtc/rtc-ds1672.c | 26 ++
>>> 1 files changed, 22 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/rtc/rtc-ds1672.c b/drivers/rtc/rtc-ds1672.c
>>> index 7fa67d0..b44b2a1 100644
>>> --- a/drivers/rtc/rtc-ds1672.c
>>> +++ b/drivers/rtc/rtc-ds1672.c
>>> @@ -37,8 +37,18 @@ static int ds1672_get_datetime(struct i2c_client
>>> *client, struct rtc_time *tm)
>>> unsigned char buf[4];
>>>
>>> struct i2c_msg msgs[] = {
>>> - {client->addr, 0, 1, &addr},/* setup read ptr */
>>> - {client->addr, I2C_M_RD, 4, buf}, /* read date */
>>> + {
>>> + .addr = client->addr,
>>> + .flags = 0,
>>> + .len = 1,
>>> + .buf = &addr
>>> + }, /* setup read ptr */
>> It would be nice to tabify the fields, and put the comments on their own
>> lines while you are here. With the C99 format you can also omit fields
>> which are initialised to zero. Like this:
> For local structures also?
Yes, C99 initialisers automatically clear all unspecified fields to
zero. See:
http://stackoverflow.com/questions/3374446/what-happens-to-fields-not-named-by-a-designated-initializer
~Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] pwm: Fix compilation error when CONFIG_PWM is not defined
On Wed, Sep 12, 2012 at 03:31:46PM +0530, Tushar Behera wrote: > Add dummy implemention of public symbols for compilation-safe inclusion > of include/linux/pwm.h file when CONFIG_PWM is not defined. > > Reported-by: Sachin Kamat > Signed-off-by: Tushar Behera > --- > Changes since v3: > * Nitpicks > > Changes since v2: > * #if condition for legacy functions modified > * Reverted layout changes, can be taken up when HAVE_PWM is no longer > required. > > Changes since v1: > * Incorporated Thierry's suggestions regarding adding dummy function > implemention for all global functions > * Reorganized header file to have structure definitions first and then the > function definitions. > > include/linux/pwm.h | 71 +- > 1 files changed, 69 insertions(+), 2 deletions(-) Okay, I've applied this to my for-next branch, with some minor changes. For one I had to merge it with Alex's managed functions patch. Second I changed all dummy functions that return a struct pwm_device * to return ERR_PTR(-ENODEV) instead of NULL because PWM users typically check for IS_ERR(pwm) and not for NULL. Thierry pgpFqq45CtWkP.pgp Description: PGP signature
Re: [PATCH 1/7] rtc: Convert struct i2c_msg initialization to C99 format
On Tuesday 18 September 2012 07:14 AM, Ryan Mallon wrote:
> On 17/09/12 23:58, Shubhrajyoti D wrote:
>> Convert the struct i2c_msg initialization to C99 format. This makes
>> maintaining and editing the code simpler. Also helps once other fields
>> like transferred are added in future.
>>
>> Signed-off-by: Shubhrajyoti D
>> ---
>> drivers/rtc/rtc-ds1672.c | 26 ++
>> 1 files changed, 22 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-ds1672.c b/drivers/rtc/rtc-ds1672.c
>> index 7fa67d0..b44b2a1 100644
>> --- a/drivers/rtc/rtc-ds1672.c
>> +++ b/drivers/rtc/rtc-ds1672.c
>> @@ -37,8 +37,18 @@ static int ds1672_get_datetime(struct i2c_client *client,
>> struct rtc_time *tm)
>> unsigned char buf[4];
>>
>> struct i2c_msg msgs[] = {
>> -{client->addr, 0, 1, &addr},/* setup read ptr */
>> -{client->addr, I2C_M_RD, 4, buf}, /* read date */
>> +{
>> +.addr = client->addr,
>> +.flags = 0,
>> +.len = 1,
>> +.buf = &addr
>> +}, /* setup read ptr */
> It would be nice to tabify the fields, and put the comments on their own
> lines while you are here. With the C99 format you can also omit fields
> which are initialised to zero. Like this:
For local structures also?
>
> {
> /* Setup read pointer */
> .addr = client->addr,
> .len= 1,
> .buf= &addr,
> },
>
> ~Ryan
>
>
--
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] gpio: pxa: using for_each_set_bit to simplify the code
On Tue, Sep 18, 2012 at 1:43 PM, Eric Miao wrote: > On Mon, Sep 17, 2012 at 6:56 PM, Linus Walleij > wrote: >> On Fri, Sep 14, 2012 at 4:36 AM, Wei Yongjun wrote: >> >>> From: Wei Yongjun >>> >>> Using for_each_set_bit() to simplify the code. >>> >>> spatch with a semantic match is used to found this. >>> (http://coccinelle.lip6.fr/) >>> >>> Signed-off-by: Wei Yongjun >> >> PXA maintainers: does this look OK? > > I seem to have Acked this already in another mail, if that got lost, here > it is: > > Acked-by: Eric Miao > The another mail thread is for irq, not gpio. I'll apply it today. :) -- 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/
[V2 -stable PATCH 1/2] workqueue: fix leak of active
try_to_grab_pending() leave LINKED tagalong in delayed queue when
it deletes a work. This behavior will cause future
cwq_activate_first_delayed() increase the ->nr_active wrongly,
and may cause the whole cwq frozen.
example:
state: cwq->max_active = 1, cwq->nr_active = 1
one work in cwq->pool, many in cwq->delayed_works.
step1: try_to_grab_pending() remove a work from delayed_works
but leave tagalong.
step2: when the work in cwq->pool is finished,
cwq_activate_first_delayed() move the tagalong to cwq->pool
and increase the ->nr_active.
current state: cwq->nr_active = 1, but works of the cwq
in cwq->pool are all NO_COLOR, so even when
these works are finished, cwq->nr_active will
not be decreased, and no work will be moved from
cwq->delayed_works. the whole cwq is frozen.
Fix it by moving the work to cwq->pool before delete it
in try_to_grab_pending(), thus the tagalong is left in
cwq->pool like as grabbing non-delayed work.
Signed-off-by: Lai Jiangshan
---
kernel/workqueue.c | 26 +++---
1 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 7b91332..834aa62 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -973,10 +973,9 @@ static void move_linked_works(struct work_struct *work,
struct list_head *head,
*nextp = n;
}
-static void cwq_activate_first_delayed(struct cpu_workqueue_struct *cwq)
+static void cwq_activate_delayed_work(struct work_struct *work)
{
- struct work_struct *work = list_first_entry(&cwq->delayed_works,
- struct work_struct, entry);
+ struct cpu_workqueue_struct *cwq = get_work_cwq(work);
trace_workqueue_activate_work(work);
move_linked_works(work, &cwq->pool->worklist, NULL);
@@ -984,6 +983,14 @@ static void cwq_activate_first_delayed(struct
cpu_workqueue_struct *cwq)
cwq->nr_active++;
}
+static void cwq_activate_first_delayed(struct cpu_workqueue_struct *cwq)
+{
+ struct work_struct *work = list_first_entry(&cwq->delayed_works,
+ struct work_struct, entry);
+
+ cwq_activate_delayed_work(work);
+}
+
/**
* cwq_dec_nr_in_flight - decrement cwq's nr_in_flight
* @cwq: cwq of interest
@@ -1102,6 +1109,19 @@ static int try_to_grab_pending(struct work_struct *work,
bool is_dwork,
smp_rmb();
if (gcwq == get_work_gcwq(work)) {
debug_work_deactivate(work);
+
+ /*
+* We cannot remove delayed work directly.
+* Otherwise we may leave some LINKED
+* tagalong(if exist) in the ->delayed_works,
+* and future cwq_activate_first_delayed() will
+* move this tagalong works((which are all NO_COLOR)
+* to cwq->pool and increase the ->nr_active,
+* and it may cause the whole cwq frozen.
+*/
+ if (*work_data_bits(work) & WORK_STRUCT_DELAYED)
+ cwq_activate_delayed_work(work);
+
list_del_init(&work->entry);
cwq_dec_nr_in_flight(get_work_cwq(work),
get_work_color(work),
--
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/
[V2 for-next PATCH 2/2] workqueue: remove @delayed argument from cwq_dec_nr_in_flight()
The argument @delayed is always false in all call site,
we simply remove it.
Signed-off-by: Lai Jiangshan
---
kernel/workqueue.c | 21 -
1 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 834aa62..d15d383 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -995,7 +995,6 @@ static void cwq_activate_first_delayed(struct
cpu_workqueue_struct *cwq)
* cwq_dec_nr_in_flight - decrement cwq's nr_in_flight
* @cwq: cwq of interest
* @color: color of work which left the queue
- * @delayed: for a delayed work
*
* A work either has completed or is removed from pending queue,
* decrement nr_in_flight of its cwq and handle workqueue flushing.
@@ -1003,8 +1002,7 @@ static void cwq_activate_first_delayed(struct
cpu_workqueue_struct *cwq)
* CONTEXT:
* spin_lock_irq(gcwq->lock).
*/
-static void cwq_dec_nr_in_flight(struct cpu_workqueue_struct *cwq, int color,
-bool delayed)
+static void cwq_dec_nr_in_flight(struct cpu_workqueue_struct *cwq, int color)
{
/* ignore uncolored works */
if (color == WORK_NO_COLOR)
@@ -1012,13 +1010,11 @@ static void cwq_dec_nr_in_flight(struct
cpu_workqueue_struct *cwq, int color,
cwq->nr_in_flight[color]--;
- if (!delayed) {
- cwq->nr_active--;
- if (!list_empty(&cwq->delayed_works)) {
- /* one down, submit a delayed one */
- if (cwq->nr_active < cwq->max_active)
- cwq_activate_first_delayed(cwq);
- }
+ cwq->nr_active--;
+ if (!list_empty(&cwq->delayed_works)) {
+ /* one down, submit a delayed one */
+ if (cwq->nr_active < cwq->max_active)
+ cwq_activate_first_delayed(cwq);
}
/* is flush in progress and are we at the flushing tip? */
@@ -1124,8 +1120,7 @@ static int try_to_grab_pending(struct work_struct *work,
bool is_dwork,
list_del_init(&work->entry);
cwq_dec_nr_in_flight(get_work_cwq(work),
- get_work_color(work),
- *work_data_bits(work) & WORK_STRUCT_DELAYED);
+ get_work_color(work));
spin_unlock(&gcwq->lock);
return 1;
@@ -2336,7 +2331,7 @@ __acquires(&gcwq->lock)
hlist_del_init(&worker->hentry);
worker->current_work = NULL;
worker->current_cwq = NULL;
- cwq_dec_nr_in_flight(cwq, work_color, false);
+ cwq_dec_nr_in_flight(cwq, work_color);
}
/**
--
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/
Re: [PATCH 3/7] rtc: Convert struct i2c_msg initialization to C99 format
On Tue, 18 Sep 2012, Ryan Mallon wrote:
On 18/09/12 15:40, Shubhrajyoti wrote:
On Tuesday 18 September 2012 07:21 AM, Ryan Mallon wrote:
Actually, I wonder if it is useful to have something like:.
Read and write differ only in the flag also it will be a deviation from
what $SUBJECT
would warrant. So could be a separate patch.
Sure, but I think it would help make the code even more readable than
just converting to C99 initialisers (especially since putting the C99
initialiser all on one line is hard to read),
The one line thing is the fault of Coccinelle :)
julia
and there is little sense
in doing one clean up and then replacing it later with a different clean up.
If you are worried about the duplication of code for a single flag
difference you could always do:
#define I2C_OP(_addr, _buf, _len, _flags) \
...
#define I2C_WRITE(addr, buf, len) I2C_OP(addr, buf, len, 0)
#define I2C_READ(addr, buf, len) I2C_OP(addr, buf, len, I2C_M_RD)
~Ryan
#define I2C_WRITE(_addr, _buf, _len) { \
.addr = _addr,\
.buf= _buf, \
.len= _len, \
}
#define I2C_READ(_addr, _buf, _len) { \
.addr = _addr,\
.buf= _buf, \
.len= _len, \
.flags = I2C_M_RD, \
}
and then write this as:
struct i2c_msg msgs[2] = {
I2C_WRITE(client->addr, reg_addr, sizeof(reg_addr)),
I2C_READ(client->addr, buf, len),
};
--
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] arm/dts: AM33XX: Add SPI device tree data
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash
Tested-by: Matt Porter
---
Changes since v1:
- Corrected reg offset in reg DT entry.
:100644 100644 ff3badb... 065fd54... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index ff3badb..065fd54 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -219,5 +219,30 @@
interrupt-parent = <&intc>;
interrupts = <91>;
};
+
+ spi0: spi@4803 {
+ compatible = "ti,omap4-mcspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x4803 0x400>;
+ interrupt-parent = <&intc>;
+ interrupt = <65>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "spi0";
+ status = "disabled";
+
+ };
+
+ spi1: spi@481a {
+ compatible = "ti,omap4-mcspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x481a 0x400>;
+ interrupt-parent = <&intc>;
+ interrupt = <125>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "spi1";
+ status = "disabled";
+ };
};
};
--
1.7.4.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: Why blktrace didn't trace requests merge?
On 2012-09-18 02:30, Jianpeng Ma wrote: > On 2012-09-18 02:27 Jens Axboe Wrote: >> On 2012-09-17 19:55, Tejun Heo wrote: >>> (cc'ing Jens) >>> >>> On Mon, Sep 17, 2012 at 09:22:28AM -0400, Steven Rostedt wrote: On Mon, 2012-09-17 at 19:33 +0800, Jianpeng Ma wrote: > Hi all: > I used blktrace to trace some io.But i can't find requests merge. I > searched the code and did't not find. > Why? > No idea. I don't use blktrace much, but I Cc'd those that understand it better than I. >> >> Works for me: >> >> [...] >> >> >> 8,00 26 0.009147735 664 A WS 315226143 + 8 <- (8,7) >> 19406344 >> 8,00 27 0.009148677 664 Q WS 315226143 + 8 >> [btrfs-submit-1] >> 8,00 28 0.009152967 664 G WS 315226143 + 8 >> [btrfs-submit-1] >> 8,00 29 0.009154242 664 P N [btrfs-submit-1] >> 8,00 30 0.009155538 664 A WS 315226151 + 8 <- (8,7) >> 19406352 >> 8,00 31 0.009155743 664 Q WS 315226151 + 8 >> [btrfs-submit-1] >> 8,00 32 0.009157086 664 M WS 315226151 + 8 >> [btrfs-submit-1] >> 8,00 33 0.009158716 664 I WS 315226143 + 16 >> [btrfs-submit-1] >> >> That's from a quick trace of /dev/sda. I started blktrace, then did: >> >> $ dd if=/dev/zero of=foo bs=4k count=128 && sync >> >> to ensure that I knew merges would be happening. Output stats at the end: >> >> Total (sda): >> Reads Queued: 7, 44KiB Writes Queued: 447, >> 7692KiB >> Read Dispatches:7, 44KiB Write Dispatches: 416, >> 7692KiB >> Reads Requeued: 0 Writes Requeued: 0 >> Reads Completed:7, 44KiB Writes Completed: 435, >> 5864KiB >> Read Merges:0,0KiB Write Merges: 23, >> 428KiB >> IO unplugs:78 Timer unplugs: 0 >> >> -- >> Jens Axboe >> > First, Thanks your time! > If i understand correctly, the merge of your example is bio with > request, not request wiht request. Yes or no? It is bio to request, correct. Request to request merges are relatively more rare. -- Jens Axboe -- 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/7] rtc: Convert struct i2c_msg initialization to C99 format
On 18/09/12 15:40, Shubhrajyoti wrote:
> On Tuesday 18 September 2012 07:21 AM, Ryan Mallon wrote:
>> Actually, I wonder if it is useful to have something like:.
> Read and write differ only in the flag also it will be a deviation from
> what $SUBJECT
> would warrant. So could be a separate patch.
Sure, but I think it would help make the code even more readable than
just converting to C99 initialisers (especially since putting the C99
initialiser all on one line is hard to read), and there is little sense
in doing one clean up and then replacing it later with a different clean up.
If you are worried about the duplication of code for a single flag
difference you could always do:
#define I2C_OP(_addr, _buf, _len, _flags) \
...
#define I2C_WRITE(addr, buf, len) I2C_OP(addr, buf, len, 0)
#define I2C_READ(addr, buf, len) I2C_OP(addr, buf, len, I2C_M_RD)
~Ryan
>>
>> #define I2C_WRITE(_addr, _buf, _len) { \
>> .addr = _addr,\
>> .buf= _buf, \
>> .len= _len, \
>> }
>>
>> #define I2C_READ(_addr, _buf, _len) { \
>> .addr = _addr,\
>> .buf= _buf, \
>> .len= _len, \
>> .flags = I2C_M_RD, \
>> }
>>
>> and then write this as:
>>
>> struct i2c_msg msgs[2] = {
>> I2C_WRITE(client->addr, reg_addr, sizeof(reg_addr)),
>> I2C_READ(client->addr, buf, len),
>> };
>
--
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] gpio: pxa: using for_each_set_bit to simplify the code
On Mon, Sep 17, 2012 at 6:56 PM, Linus Walleij wrote: > On Fri, Sep 14, 2012 at 4:36 AM, Wei Yongjun wrote: > >> From: Wei Yongjun >> >> Using for_each_set_bit() to simplify the code. >> >> spatch with a semantic match is used to found this. >> (http://coccinelle.lip6.fr/) >> >> Signed-off-by: Wei Yongjun > > PXA maintainers: does this look OK? I seem to have Acked this already in another mail, if that got lost, here it is: Acked-by: Eric Miao > > Yours, > Linus Walleij -- 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 0/3] 3.2-stable timekeeping fixes merged in 3.6
Hi John, On Mon, Sep 17, 2012 at 10:32:07PM -0400, John Stultz wrote: > Just wanted to send out a few timekeeping fixes that were merged > in 3.6 which are appropriate for -stable. Thank you very much, I'm adding them to your last ones. I have not released the version yet but they're not lost. I will then release all of them at once. Best regards, Willy -- 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/7] rtc: Convert struct i2c_msg initialization to C99 format
On Tuesday 18 September 2012 07:21 AM, Ryan Mallon wrote:
> Actually, I wonder if it is useful to have something like:.
Read and write differ only in the flag also it will be a deviation from
what $SUBJECT
would warrant. So could be a separate patch.
>
> #define I2C_WRITE(_addr, _buf, _len) { \
> .addr = _addr,\
> .buf= _buf, \
> .len= _len, \
> }
>
> #define I2C_READ(_addr, _buf, _len) { \
> .addr = _addr,\
> .buf= _buf, \
> .len= _len, \
> .flags = I2C_M_RD, \
> }
>
> and then write this as:
>
> struct i2c_msg msgs[2] = {
> I2C_WRITE(client->addr, reg_addr, sizeof(reg_addr)),
> I2C_READ(client->addr, buf, len),
> };
--
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/7] rtc: Convert struct i2c_msg initialization to C99 format
On Tuesday 18 September 2012 07:15 AM, Ryan Mallon wrote: >> , > Putting the whole initialiser on one line is a bit ugly. Any reason not > to expand it over multiple lines as the previous patch (and majority of > other drivers) does? Will do that. -- 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 part2 6/6] PCI: Claim hw/fw allocated resources in hot add path.
On Mon, Sep 17, 2012 at 9:44 PM, Yinghai Lu wrote:
> On Mon, Sep 17, 2012 at 5:12 PM, Bjorn Helgaas wrote:
>> On Sun, Sep 2, 2012 at 3:50 PM, Yinghai Lu wrote:
>
>>> -static void __init pcibios_allocate_bridge_resources(struct pci_dev *dev)
>>> +static void pcibios_allocate_bridge_resources(struct pci_dev *dev)
>>
>> This patch has a little too much going on at the same time. Can you
>> split the __init removal into its own patch so we can focus on what's
>> left by itself?
>
> ok.
>
>>
>>> {
>>> int idx;
>>> struct resource *r;
>>>
>>> for (idx = PCI_BRIDGE_RESOURCES; idx < PCI_NUM_RESOURCES; idx++) {
>>> r = &dev->resource[idx];
>>> + if (r->parent) /* Already allocated */
>>> + continue;
>>
>> This is also a potentially interesting change that maybe should be in
>> its own patch.
>
> oh, we don't need that extra checking anymore. because support
> removing non-root bus is dropped.
I updated for-pci-root-bus-hotplug-part2.
http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=shortlog;h=refs/heads/for-pci-root-bus-hotplug-part2
Thanks
Yinghai
--
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: Re: [PATCH 1/3] devfreq: core updates to support devices which can idle
> Sender : Rajagopal Venkat > Date : 2012-09-18 14:20 (GMT+09:00) > Title : Re: Re: [PATCH 1/3] devfreq: core updates to support devices which > can idle > On 17 September 2012 17:46, MyungJoo Ham wrote: > >> On 10 September 2012 14:43, 함명주 wrote: > >> >> Prepare devfreq core framework to support devices which > >> >> can idle. When device idleness is detected perhaps through > >> >> runtime-pm, need some mechanism to suspend devfreq load > >> >> monitoring and resume back when device is online. Present > >> >> code continues monitoring unless device is removed from > >> >> devfreq core. > >> >> > >> >> This patch introduces following design changes, > >> >> > >> >> - use per device work instead of global work to monitor device > >> >> load. This enables suspend/resume of device devfreq and > >> >> reduces monitoring code complexity. > >> >> - decouple delayed work based load monitoring logic from core > >> >> by introducing helpers functions to be used by governors. This > >> >> provides flexibility for governors either to use delayed work > >> >> based monitoring functions or to implement their own mechanism. > >> >> - devfreq core interacts with governors via events to perform > >> >> specific actions. These events include start/stop devfreq. > >> >> This sets ground for adding suspend/resume events. > >> >> > >> >> The devfreq apis are not modified and are kept intact. > >> > > >> > Hello, > >> > > >> > Please revise locking mechanism along with event handler. > >> > > >> > It appears that we need to do mutex_lock(&devfreq->lock) before calling > >> > devfreq->governor->event_handler(); > >> > >> I don't think is the case. The governor can make use of devfreq->lock if > >> needed. > >> Anyways, I have revised locking mechanism in v2 set. > >> > >> > Or at least, userspace_init and userspace_exit functions require > >> > mutex_lock. > >> > >> The userspace_init function is executed only when device is added to > >> devfreq > >> framework. This function itself is creating sysfs attributes. So this > >> should not > >> be a concern for us. > >> > >> The userspace_exit is executed when device is removed from devfreq > >> framework. sysfs_remove_group() should take care of serving any pending > >> reference to sysfs attributes before removing them. No concern here as > >> well. > >> Am I missing something which demand locking for these functions? > >> > >> > Event_handler callback won't want the properties in devfreq to be > >> > changed externally during its execution. > >> > >> Agree. > > > > If so, the GOV_INTERVAL handler of ondemand requires mutex_lock. > > (and probably, nested mutex lock for monitor_resume) > > > I don't think so. The polling_ms value update and the GOV_INTERVAL > event are handled in store_polling_interval() i.e same caller's context. So > no reason for concern here. Also polling_ms value update and queuing > the work(using polling_ms) are synchronized. The proposed structure in this patch is: [mutex_lock] update value [mutex_unlock] ... [mutex_lock] use the updated value (including queueing the work) [mutex_unlock] It is not synchronized. If it is to be synchronized, the mutex should be kept locked. Besides, as mentioned below, in order to guarantee that the modified values related with an event trigger are kept intact for the event handlers, you need to keep the mutex locked. It may be a neglectible issue if we only consider polling_ms; however, we should never assume so because we can have custom governors and drivers. (or even more events are to be defined later) Please note that even if every devfreq driver implement mutex-lock/unlock appropriately, the consistency is not guaranteed as there is unlocked period between "update" and "read". Assuming that we are to support run-time governor changes and additional events later as discussed before, we'd better prepare this beforehand. > > > It determins next action based on the value protected by the > > devfreq lock. It won't crash the kernel and it won't happen > > often. However, it may behave incorrectly. > > > > Why don't we simply let the all the struct devfreq protected > > when the external code (governors) is probably reading/writing the > > protected values? > > > > This also guarantees that the event handler gets the exact status > > modified by the event caller. Otherwise, the event handler may > > get status different from the event caller's intention. > > > > > > Cheers! > > MyungJoo > > > > > >> > >> > > >> > Plus, please edit Documentation/ABI entry (central_polling is being > >> > removed) > >> Done. > >> > > >> > Other than that, it looks fine. > >> > > >> > Cheers! > >> > MyungJoo > >> > > >> >> > >> >> Signed-off-by: Rajagopal Venkat > >> >> --- > >> >> drivers/devfreq/devfreq.c | 376 > >> >> ++ > >> >> drivers/devfreq/governor.h| 9 + > >> >> drivers/devfreq/governor_performance.c| 16 +- > >> >> drivers/devfr
Re: [PATCH v2 1/2] spi: omap2-mcspi: add pinctrl support
On Monday 17 September 2012 10:52 PM, Matt Porter wrote:
> Adds pinctrl support to support OMAP platforms that boot from DT
> and rely on pinctrl support to set pinmuxes.
>
> Signed-off-by: Matt Porter
> ---
looks good to me.
you may want to repost with Mark in cc to review.
Acked-by: Shubhrajyoti D
> drivers/spi/spi-omap2-mcspi.c |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
> index b2fb141..9502566 100644
> --- a/drivers/spi/spi-omap2-mcspi.c
> +++ b/drivers/spi/spi-omap2-mcspi.c
> @@ -38,6 +38,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
>
> @@ -1124,6 +1126,7 @@ static int __devinit omap2_mcspi_probe(struct
> platform_device *pdev)
> static int bus_num = 1;
> struct device_node *node = pdev->dev.of_node;
> const struct of_device_id *match;
> + struct pinctrl *pinctrl;
>
> master = spi_alloc_master(&pdev->dev, sizeof *mcspi);
> if (master == NULL) {
> @@ -1219,6 +1222,11 @@ static int __devinit omap2_mcspi_probe(struct
> platform_device *pdev)
> if (status < 0)
> goto dma_chnl_free;
>
> + pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> + if (IS_ERR(pinctrl))
> + dev_warn(&pdev->dev,
> + "pins are not configured from the driver\n");
> +
> pm_runtime_use_autosuspend(&pdev->dev);
> pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
> pm_runtime_enable(&pdev->dev);
--
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 1/3] devfreq: core updates to support devices which can idle
On 17 September 2012 17:46, MyungJoo Ham wrote: >> On 10 September 2012 14:43, 함명주 wrote: >> >> Prepare devfreq core framework to support devices which >> >> can idle. When device idleness is detected perhaps through >> >> runtime-pm, need some mechanism to suspend devfreq load >> >> monitoring and resume back when device is online. Present >> >> code continues monitoring unless device is removed from >> >> devfreq core. >> >> >> >> This patch introduces following design changes, >> >> >> >> - use per device work instead of global work to monitor device >> >> load. This enables suspend/resume of device devfreq and >> >> reduces monitoring code complexity. >> >> - decouple delayed work based load monitoring logic from core >> >> by introducing helpers functions to be used by governors. This >> >> provides flexibility for governors either to use delayed work >> >> based monitoring functions or to implement their own mechanism. >> >> - devfreq core interacts with governors via events to perform >> >> specific actions. These events include start/stop devfreq. >> >> This sets ground for adding suspend/resume events. >> >> >> >> The devfreq apis are not modified and are kept intact. >> > >> > Hello, >> > >> > Please revise locking mechanism along with event handler. >> > >> > It appears that we need to do mutex_lock(&devfreq->lock) before calling >> > devfreq->governor->event_handler(); >> >> I don't think is the case. The governor can make use of devfreq->lock if >> needed. >> Anyways, I have revised locking mechanism in v2 set. >> >> > Or at least, userspace_init and userspace_exit functions require >> > mutex_lock. >> >> The userspace_init function is executed only when device is added to devfreq >> framework. This function itself is creating sysfs attributes. So this should >> not >> be a concern for us. >> >> The userspace_exit is executed when device is removed from devfreq >> framework. sysfs_remove_group() should take care of serving any pending >> reference to sysfs attributes before removing them. No concern here as well. >> Am I missing something which demand locking for these functions? >> >> > Event_handler callback won't want the properties in devfreq to be changed >> > externally during its execution. >> >> Agree. > > If so, the GOV_INTERVAL handler of ondemand requires mutex_lock. > (and probably, nested mutex lock for monitor_resume) > I don't think so. The polling_ms value update and the GOV_INTERVAL event are handled in store_polling_interval() i.e same caller's context. So no reason for concern here. Also polling_ms value update and queuing the work(using polling_ms) are synchronized. > It determins next action based on the value protected by the > devfreq lock. It won't crash the kernel and it won't happen > often. However, it may behave incorrectly. > > Why don't we simply let the all the struct devfreq protected > when the external code (governors) is probably reading/writing the > protected values? > > This also guarantees that the event handler gets the exact status > modified by the event caller. Otherwise, the event handler may > get status different from the event caller's intention. > > > Cheers! > MyungJoo > > >> >> > >> > Plus, please edit Documentation/ABI entry (central_polling is being >> > removed) >> Done. >> > >> > Other than that, it looks fine. >> > >> > Cheers! >> > MyungJoo >> > >> >> >> >> Signed-off-by: Rajagopal Venkat >> >> --- >> >> drivers/devfreq/devfreq.c | 376 >> >> ++ >> >> drivers/devfreq/governor.h| 9 + >> >> drivers/devfreq/governor_performance.c| 16 +- >> >> drivers/devfreq/governor_powersave.c | 16 +- >> >> drivers/devfreq/governor_simpleondemand.c | 33 +++ >> >> drivers/devfreq/governor_userspace.c | 23 +- >> >> include/linux/devfreq.h | 31 +-- >> >> 7 files changed, 220 insertions(+), 284 deletions(-) >> >> >> >> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c >> >> index b146d76..be524c7 100644 >> >> --- a/drivers/devfreq/devfreq.c >> >> +++ b/drivers/devfreq/devfreq.c >> >> @@ -30,17 +30,11 @@ >> >> struct class *devfreq_class; >> >> >> >> /* >> >> - * devfreq_work periodically monitors every registered device. >> >> - * The minimum polling interval is one jiffy. The polling interval is >> >> - * determined by the minimum polling period among all polling devfreq >> >> - * devices. The resolution of polling interval is one jiffy. >> >> + * devfreq core provides delayed work based load monitoring helper >> >> + * functions. Governors can use these or can implement their own >> >> + * monitoring mechanism. >> >> */ >> >> -static bool polling; >> >> static struct workqueue_struct *devfreq_wq; >> >> -static struct delayed_work devfreq_work; >> >> - >> >> -/* wait removing if this is to be removed */ >> >> -static struct devfreq *wait_remove_device; >> >> >> >> /* The list of all device-devfreq */ >> >>
Re: [PATCH 0/2] Replace the obsolete preset API by timings API
Hi Mauro/Sekhar On Wed, Aug 8, 2012 at 6:00 PM, Prabhakar Lad wrote: > This first patch replaces the obsolete preset API by timings > API for davinci VPBE, appropriate chnages in machine file for > dm644x in which VPBE is enabled. And the second patch adds support for > timings API for ths7303 driver. Sending them as s series > since VPBE uses the ths7303 driver. > > Hans Verkuil (1): > dm644x: replace the obsolete preset API by the timings API. > > Manjunath Hadli (1): > ths7303: enable THS7303 for HD modes > Can you pull this patchset ? Please inform me if anything is needed from my side. Regards, --Prabhakar > arch/arm/mach-davinci/board-dm644x-evm.c | 15 ++-- > arch/arm/mach-davinci/dm644x.c | 17 +--- > drivers/media/video/davinci/vpbe.c | 110 > > drivers/media/video/davinci/vpbe_display.c | 60 +++ > drivers/media/video/davinci/vpbe_venc.c| 25 +++--- > drivers/media/video/ths7303.c | 107 +++ > include/media/davinci/vpbe.h | 14 ++-- > include/media/davinci/vpbe_types.h |8 +-- > include/media/davinci/vpbe_venc.h |2 +- > 9 files changed, 202 insertions(+), 156 deletions(-) > > ___ > Davinci-linux-open-source mailing list > davinci-linux-open-sou...@linux.davincidsp.com > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- 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] vpif: replace preset with the timings API.
Hi Mauro,
On Wed, Aug 8, 2012 at 5:39 PM, Prabhakar Lad wrote:
> From: Hans Verkuil
>
> Signed-off-by: Hans Verkuil
> Signed-off-by: Lad, Prabhakar
> Signed-off-by: Manjunath Hadli
> ---
> drivers/media/video/davinci/vpif.c | 16 ++--
> drivers/media/video/davinci/vpif.h |4 +-
> drivers/media/video/davinci/vpif_capture.c | 114
> +---
> drivers/media/video/davinci/vpif_capture.h |3 +-
> drivers/media/video/davinci/vpif_display.c | 102 +++--
> drivers/media/video/davinci/vpif_display.h |3 +-
> 6 files changed, 43 insertions(+), 199 deletions(-)
>
Can you pull these patch ? Please inform me if anything is needed
from my side.
Regards,
--Prabhakar
> diff --git a/drivers/media/video/davinci/vpif.c
> b/drivers/media/video/davinci/vpif.c
> index b3637af..b95bff7 100644
> --- a/drivers/media/video/davinci/vpif.c
> +++ b/drivers/media/video/davinci/vpif.c
> @@ -25,6 +25,8 @@
> #include
> #include
> #include
> +#include
> +
> #include
>
> #include "vpif.h"
> @@ -65,7 +67,7 @@ const struct vpif_channel_config_params ch_params[] = {
> .capture_format = 0,
> .vbi_supported = 0,
> .hd_sd = 1,
> - .dv_preset = V4L2_DV_480P59_94,
> + .dv_timings = V4L2_DV_BT_CEA_720X480P59_94,
> },
> {
> .name = "576p50",
> @@ -82,7 +84,7 @@ const struct vpif_channel_config_params ch_params[] = {
> .capture_format = 0,
> .vbi_supported = 0,
> .hd_sd = 1,
> - .dv_preset = V4L2_DV_576P50,
> + .dv_timings = V4L2_DV_BT_CEA_720X576P50,
> },
> {
> .name = "720p50",
> @@ -99,7 +101,7 @@ const struct vpif_channel_config_params ch_params[] = {
> .capture_format = 0,
> .vbi_supported = 0,
> .hd_sd = 1,
> - .dv_preset = V4L2_DV_720P50,
> + .dv_timings = V4L2_DV_BT_CEA_1280X720P50,
> },
> {
> .name = "720p60",
> @@ -116,7 +118,7 @@ const struct vpif_channel_config_params ch_params[] = {
> .capture_format = 0,
> .vbi_supported = 0,
> .hd_sd = 1,
> - .dv_preset = V4L2_DV_720P60,
> + .dv_timings = V4L2_DV_BT_CEA_1280X720P60,
> },
> {
> .name = "1080I50",
> @@ -136,7 +138,7 @@ const struct vpif_channel_config_params ch_params[] = {
> .capture_format = 0,
> .vbi_supported = 0,
> .hd_sd = 1,
> - .dv_preset = V4L2_DV_1080I50,
> + .dv_timings = V4L2_DV_BT_CEA_1920X1080I50,
> },
> {
> .name = "1080I60",
> @@ -156,7 +158,7 @@ const struct vpif_channel_config_params ch_params[] = {
> .capture_format = 0,
> .vbi_supported = 0,
> .hd_sd = 1,
> - .dv_preset = V4L2_DV_1080I60,
> + .dv_timings = V4L2_DV_BT_CEA_1920X1080I60,
> },
> {
> .name = "1080p60",
> @@ -173,7 +175,7 @@ const struct vpif_channel_config_params ch_params[] = {
> .capture_format = 0,
> .vbi_supported = 0,
> .hd_sd = 1,
> - .dv_preset = V4L2_DV_1080P60,
> + .dv_timings = V4L2_DV_BT_CEA_1920X1080P60,
> },
>
> /* SDTV formats */
> diff --git a/drivers/media/video/davinci/vpif.h
> b/drivers/media/video/davinci/vpif.h
> index c2ce4d9..a1ab6a0 100644
> --- a/drivers/media/video/davinci/vpif.h
> +++ b/drivers/media/video/davinci/vpif.h
> @@ -533,7 +533,7 @@ static inline void channel2_clipping_enable(int enable)
> }
> }
>
> -/* function to enable clipping (for both active and blanking regions) on ch
> 2 */
> +/* function to enable clipping (for both active and blanking regions) on ch
> 3 */
> static inline void channel3_clipping_enable(int enable)
> {
> if (enable) {
> @@ -634,7 +634,7 @@ struct vpif_channel_config_params {
> * supports capturing vbi or not */
> u8 hd_sd; /* HDTV (1) or SDTV (0) format */
> v4l2_std_id stdid; /* SDTV format */
> - u32 dv_preset; /* HDTV format */
> + struct v4l2_dv_timings dv_timings; /* HDTV format */
> };
>
> extern const unsigned int vpif_ch_params_count;
> diff --git a/drivers/media/video/davinci/vpif_capture.c
> b/drivers/media/video/davinci/vpif_capture.c
> index 266025e..e684c48 100644
> --- a/drivers/media/video/davinci/vpif_capture.c
> +++ b/drivers/media/video/davinci/vpif_capture.c
> @@ -551,7 +551,8 @@ static int vpif_update_std_info(struct channel_obj *ch)
> }
> } else {
> vpif_dbg(2, debug, "HD format\n");
> -
Re: 2 physical-cpu (like 2x6core) config and NUMA?
On Mon, 2012-09-17 at 11:00 -0700, Linda Walsh wrote: > I was wondering, on dual processor MB's, Intel uses dedicated memory for > > each cpu 6 memchips in the X5XXX series, and to access the memory > of the other chip's cores, the memory has to be transferred over the QPI > bus. > > So wouldn't it be of benefit if such dual chip configurations were to > be setup as 'NUMA', as there is a higher cost between migrating > memory/processes > between Cores on different chips vs. on the same chip? > > I note from 'cpupower -c all frequency-info, that the "odd" cpu-cores > all hve to run at the same clock frequency, and the "even" all have > to run together, which I take to mean that the odd number cores are > on 1 chip and the even numbered cores are on the other chip. > > Since the QPI path is limited and appears to be < the local memory access > rate, wouldn't it be appropriate if 2 cpu-chip setups were configured > as 2 NUMA cores? > > Although -- I have no clue how the memory space is divided between the > two cores -- i.e. I don't know if say, I have 24G on each, if they > alternate 4G in the physical address space or what (that would all be > handed (or mapped) before the chips come up.. so it could be contiguous). > > > Does the kernel support scheduling based on the different speed of > memory between "on die" vs. "off die"? I was surprised to see > that it viewed my system as 1 NUMA node with all 12 on 1 node -- when > I know that it is physically organized as 2x6. Yeah, the scheduler will setup for numa if srat says the box is numa. I have a 64 core DL980 box that numactl --hardware says is a single node, but that's due to ram truly _existing_ only on one node. Not a wonderful (or even supported) setup. If ram isn't physically plugged into the right spots, or some bios option makes the box appear to be single node, that's what you'll see too, (SIBLING maybe) MC and CPU domains, but no NUMA. -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/
Re: [PATCH] genirq: Add the IRQS_ONESHOT support for edge interrupt
Sorry, update the patch.
On Tue, 2012-09-18 at 20:54 +0800, Chuansheng Liu wrote:
> In handle_edge_irq(), currently do not care about the flag IRQS_ONESHOT,
> but there are many edge interrupt handler with irq thread need it indeed,
> so implement here.
>
> Signed-off-by: liu chuansheng
> ---
> kernel/irq/chip.c |8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
>
In handle_edge_irq(), currently do not care about the flag IRQS_ONESHOT,
but there are many edge interrupt handler with irq thread need it indeed,
so implement here.
Signed-off-by: liu chuansheng
---
kernel/irq/chip.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
mode change 100644 => 100755 kernel/irq/chip.c
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
old mode 100644
new mode 100755
index eebd6d5..04da0d7
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -497,7 +497,13 @@ handle_edge_irq(unsigned int irq, struct irq_desc *desc)
kstat_incr_irqs_this_cpu(irq, desc);
/* Start handling the irq */
- desc->irq_data.chip->irq_ack(&desc->irq_data);
+ if (desc->istate & IRQS_ONESHOT) {
+ mask_ack_irq(desc);
+ handle_irq_event(desc);
+ cond_unmask_irq(desc);
+ goto out_unlock;
+ } else
+ desc->irq_data.chip->irq_ack(&desc->irq_data);
do {
if (unlikely(!desc->action)) {
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] iio: inkern: put the IIO device when mem alloc gets failed
> I can see your point, but Lars-Peter's way is the more commonly used > approach > so lets go with the ancient arguement of making it look like what those > reading the code expect to see ;) Two chained patches were sent. [PATCH 1/2] iio: inkern: put the IIO device when it fails to allocate memory [PATCH 2/2] iio: inkern: clean up error return code The first patch is same as previous one. The second one is for fixing error return code which Lars had suggested. I'd like to divide two things for better review. Many thanks ! Best Regards, Milo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] iio: inkern: clean up error return code
When the IIO consumer tries to get specific IIO channel,
few error cases can be happened.
(a) Memory allocation failure
(b) No matched ADC channel error
(c) Invalid input arguments
This patch enables cleaning up error handling in case of (a) and (b).
In error handling code,
(a): the reference count of the IIO device should be decreased.
(b): the allocated memory should be freed with restoring the reference count.
Therefore iio_deivce_put() is called in both cases.
This can be handled in the last error statement.
Additionally, integer variable is used for stating each error case explicitly.
Then, the error returns as ERR_PTR() with this value.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/iio/inkern.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index aff034b..656d4d4 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -111,6 +111,7 @@ struct iio_channel *iio_channel_get(const char *name, const
char *channel_name)
{
struct iio_map_internal *c_i = NULL, *c = NULL;
struct iio_channel *channel;
+ int err;
if (name == NULL && channel_name == NULL)
return ERR_PTR(-ENODEV);
@@ -131,8 +132,10 @@ struct iio_channel *iio_channel_get(const char *name,
const char *channel_name)
return ERR_PTR(-ENODEV);
channel = kzalloc(sizeof(*channel), GFP_KERNEL);
- if (channel == NULL)
+ if (channel == NULL) {
+ err = -ENOMEM;
goto error_no_mem;
+ }
channel->indio_dev = c->indio_dev;
@@ -141,19 +144,19 @@ struct iio_channel *iio_channel_get(const char *name,
const char *channel_name)
iio_chan_spec_from_name(channel->indio_dev,
c->map->adc_channel_label);
- if (channel->channel == NULL)
+ if (channel->channel == NULL) {
+ err = -EINVAL;
goto error_no_chan;
+ }
}
return channel;
error_no_chan:
- iio_device_put(c->indio_dev);
kfree(channel);
- return ERR_PTR(-EINVAL);
error_no_mem:
iio_device_put(c->indio_dev);
- return ERR_PTR(-ENOMEM);
+ return ERR_PTR(err);
}
EXPORT_SYMBOL_GPL(iio_channel_get);
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] iio: inkern: put the IIO device when it fails to allocate memory
The reference count of the IIO device is increased if the IIO map has matched consumer name. After then, it tries to allocate the iio_channel which is used by the consumer. If it fails to allocate memory, the reference count should be decreased. This patch enables restoring the reference count of the IIO device. Signed-off-by: Milo(Woogyom) Kim --- drivers/iio/inkern.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c index 13748c0..aff034b 100644 --- a/drivers/iio/inkern.c +++ b/drivers/iio/inkern.c @@ -132,7 +132,7 @@ struct iio_channel *iio_channel_get(const char *name, const char *channel_name) channel = kzalloc(sizeof(*channel), GFP_KERNEL); if (channel == NULL) - return ERR_PTR(-ENOMEM); + goto error_no_mem; channel->indio_dev = c->indio_dev; @@ -151,6 +151,9 @@ error_no_chan: iio_device_put(c->indio_dev); kfree(channel); return ERR_PTR(-EINVAL); +error_no_mem: + iio_device_put(c->indio_dev); + return ERR_PTR(-ENOMEM); } EXPORT_SYMBOL_GPL(iio_channel_get); -- 1.7.9.5 Best Regards, Milo -- 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] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
On Mon, Sep 17, 2012 at 01:29:44PM -0700, Tony Lindgren wrote:
> Commit 7d7e1eba (ARM: OMAP2+: Prepare for irqs.h removal) broke
> compile for non-omap as include plat/cpu.h was added:
>
> drivers/mfd/twl-core.c:49:22: fatal error: plat/cpu.h: No such file or
> directory
>
> This header was indirectly included earlier when SPARSE_IRQ was not
> set, but does not exist on most platforms.
>
> Fix the problem by removing the cpu_is_omap usage that should
> not exist in drivers at all. We can do this by adding proper
> clock aliases for the twl-core.c drivers, and drop separate
> handling for cases when clock framework is not available as
> the behaviour will stay the same.
>
> Note that we need to add a platform device to avoid using the
> i2c provided names that may be different on various omaps.
>
> Reported-by: Fengguang Wu
> Reported-by: Stephen Rothwell
> Cc: Paul Walmsley
> Cc: Samuel Ortiz
> Cc: Arnd Bergmann
> Cc: Olof Johansson
> Signed-off-by: Tony Lindgren
FWIW:
Reviewed-by: Felipe Balbi
> ---
>
> Samuel, I'd like to queue this via arm-soc as that's where I have
> the breaking patch is if this patch is OK with you.
>
> --- a/arch/arm/mach-omap2/clock2430_data.c
> +++ b/arch/arm/mach-omap2/clock2430_data.c
> @@ -1856,6 +1856,7 @@ static struct omap_clk omap2430_clks[] = {
> CLK(NULL, "func_32k_ck", &func_32k_ck, CK_243X),
> CLK(NULL, "secure_32k_ck", &secure_32k_ck, CK_243X),
> CLK(NULL, "osc_ck", &osc_ck,CK_243X),
> + CLK("twl", "fck", &osc_ck,CK_243X),
> CLK(NULL, "sys_ck", &sys_ck,CK_243X),
> CLK(NULL, "alt_ck", &alt_ck,CK_243X),
> CLK(NULL, "mcbsp_clks", &mcbsp_clks,CK_243X),
> --- a/arch/arm/mach-omap2/clock3xxx_data.c
> +++ b/arch/arm/mach-omap2/clock3xxx_data.c
> @@ -3226,6 +3226,7 @@ static struct omap_clk omap3xxx_clks[] = {
> CLK(NULL, "virt_2600_ck", &virt_2600_ck,
> CK_3XXX),
> CLK(NULL, "virt_38_4m_ck", &virt_38_4m_ck, CK_3XXX),
> CLK(NULL, "osc_sys_ck", &osc_sys_ck,CK_3XXX),
> + CLK("twl", "fck", &osc_sys_ck,CK_3XXX),
> CLK(NULL, "sys_ck", &sys_ck,CK_3XXX),
> CLK(NULL, "sys_altclk", &sys_altclk,CK_3XXX),
> CLK(NULL, "mcbsp_clks", &mcbsp_clks,CK_3XXX),
> --- a/drivers/mfd/twl-core.c
> +++ b/drivers/mfd/twl-core.c
> @@ -46,8 +46,6 @@
> #include
> #include
>
> -#include
> -
> #include "twl-core.h"
>
> /*
> @@ -1134,12 +1132,7 @@ static void clocks_init(struct device *dev,
> u32 rate;
> u8 ctrl = HFCLK_FREQ_26_MHZ;
>
> -#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
> - if (cpu_is_omap2430())
> - osc = clk_get(dev, "osc_ck");
> - else
> - osc = clk_get(dev, "osc_sys_ck");
> -
> + osc = clk_get(dev, "fck");
> if (IS_ERR(osc)) {
> printk(KERN_WARNING "Skipping twl internal clock init and "
> "using bootloader value (unknown osc rate)\n");
> @@ -1149,18 +1142,6 @@ static void clocks_init(struct device *dev,
> rate = clk_get_rate(osc);
> clk_put(osc);
>
> -#else
> - /* REVISIT for non-OMAP systems, pass the clock rate from
> - * board init code, using platform_data.
> - */
> - osc = ERR_PTR(-EIO);
> -
> - printk(KERN_WARNING "Skipping twl internal clock init and "
> -"using bootloader value (unknown osc rate)\n");
> -
> - return;
> -#endif
> -
> switch (rate) {
> case 1920:
> ctrl = HFCLK_FREQ_19p2_MHZ;
> @@ -1222,10 +1203,23 @@ twl_probe(struct i2c_client *client, const struct
> i2c_device_id *id)
> {
> struct twl4030_platform_data*pdata = client->dev.platform_data;
> struct device_node *node = client->dev.of_node;
> + struct platform_device *pdev;
> int irq_base = 0;
> int status;
> unsignedi, num_slaves;
>
> + pdev = platform_device_alloc(DRIVER_NAME, -1);
> + if (!pdev) {
> + dev_err(&client->dev, "can't alloc pdev\n");
> + return -ENOMEM;
> + }
> +
> + status = platform_device_add(pdev);
> + if (status) {
> + platform_device_put(pdev);
> + return status;
> + }
> +
> if (node && !pdata) {
> /*
>* XXX: Temporary pdata until the information is correctly
> @@ -1234,23 +1228,30 @@ twl_probe(struct i2c_client *client, const struct
> i2c_device_id *id)
> pdata = devm_kzalloc(&client->dev,
>sizeof(struct twl4030_platform_data),
>GFP_KERNEL);
> - if (!pdata)
> - return -ENOMEM;
> + if (!pdata) {
> +
RE: [PATCH] genirq: Add the IRQS_ONESHOT support for edge interrupt
> Just curios about the problem you are facing without this code?
The issue I meet is in my calling request_threaded_irq()[edge interrupt], even
with IRQS_ONESHOT,
When irq thread is handling, the interrupt is still coming, and the primary
handler is called,
It cause possible spin recursive locks if irq handler and irq thread use the
same spin lock.
> -Original Message-
> From: anish singh [mailto:anish198519851...@gmail.com]
> Sent: Tuesday, September 18, 2012 12:31 PM
> To: Liu, Chuansheng
> Subject: Re: [PATCH] genirq: Add the IRQS_ONESHOT support for edge interrupt
>
> On Tue, Sep 18, 2012 at 6:24 PM, Chuansheng Liu
> wrote:
> > In handle_edge_irq(), currently do not care about the flag IRQS_ONESHOT,
> > but there are many edge interrupt handler with irq thread need it indeed,
> > so implement here.
> Just curios about the problem you are facing without this code?
> >
> > Signed-off-by: liu chuansheng
> > ---
> > kernel/irq/chip.c |8 +++-
> > 1 files changed, 7 insertions(+), 1 deletions(-)
> >
> > diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
> > index eebd6d5..8e4e49a 100644
> > --- a/kernel/irq/chip.c
> > +++ b/kernel/irq/chip.c
> > @@ -497,7 +497,13 @@ handle_edge_irq(unsigned int irq, struct irq_desc
> *desc)
> > kstat_incr_irqs_this_cpu(irq, desc);
> >
> > /* Start handling the irq */
> > - desc->irq_data.chip->irq_ack(&desc->irq_data);
> > + if (desc->istate & IRQS_ONESHOT) {
> > + mask_ack_irq(desc);
> > + handle_irq_event(desc);
> > + cond_unmask_irq();
> > + goto out_unlock;
> > + } else
> > + desc->irq_data.chip->irq_ack(&desc->irq_data);
> >
> > do {
> > if (unlikely(!desc->action)) {
> > --
> > 1.7.0.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/
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
[PATCH] staging: usbip: vhci_hcd: Fixed oops during removal of vhci_hcd
In response to "usbip detach -p [port_number]" user command,vhci_shoutdown_connection gets executed which kills tcp_tx,tcp_rx kernel threads and then vhci_device_reset resets all usb_device struct variables except kernel thread pointers. so, at the time of vhci_hcd removal vhci_shoutdown_connection tries to kill kernel threads which are already killed. Signed-off-by: navin patidar --- drivers/staging/usbip/vhci_hcd.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c index 12a9a5f..eea8298 100644 --- a/drivers/staging/usbip/vhci_hcd.c +++ b/drivers/staging/usbip/vhci_hcd.c @@ -859,6 +859,8 @@ static void vhci_device_reset(struct usbip_device *ud) usb_put_dev(vdev->udev); vdev->udev = NULL; + ud->tcp_rx = NULL; + ud->tcp_tx = NULL; ud->tcp_socket = NULL; ud->status = VDEV_ST_NULL; -- 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 part2 6/6] PCI: Claim hw/fw allocated resources in hot add path.
On Mon, Sep 17, 2012 at 5:12 PM, Bjorn Helgaas wrote:
> On Sun, Sep 2, 2012 at 3:50 PM, Yinghai Lu wrote:
>> -static void __init pcibios_allocate_bridge_resources(struct pci_dev *dev)
>> +static void pcibios_allocate_bridge_resources(struct pci_dev *dev)
>
> This patch has a little too much going on at the same time. Can you
> split the __init removal into its own patch so we can focus on what's
> left by itself?
ok.
>
>> {
>> int idx;
>> struct resource *r;
>>
>> for (idx = PCI_BRIDGE_RESOURCES; idx < PCI_NUM_RESOURCES; idx++) {
>> r = &dev->resource[idx];
>> + if (r->parent) /* Already allocated */
>> + continue;
>
> This is also a potentially interesting change that maybe should be in
> its own patch.
oh, we don't need that extra checking anymore. because support
removing non-root bus is dropped.
>> +void pcibios_resource_survey_bus(struct pci_bus *bus)
>> +{
>> + dev_printk(KERN_DEBUG, &bus->dev, "Allocating resources\n");
>> +
>> + pcibios_allocate_bus_resources(bus);
>> +
>> + pcibios_allocate_resources(bus, 0);
>> + pcibios_allocate_resources(bus, 1);
>> +
>> + pcibios_allocate_rom_resources(bus);
>> +}
>> +
>> void __init pcibios_resource_survey(void)
>
> I wish pcibios_resource_survey() could look like this:
>
> void __init pcibios_resource_survey(void)
> {
> list_for_each_entry(bus, &pci_root_buses, node)
> pcibios_resource_survey_bus(bus)
>
> e820_reserve_resources_late();
> ...
>
> but maybe there's a reason why pcibios_allocate_rom_resources() really
> has to be in the pcibios_assign_resources() fs_initcall rather than in
> pcibios_resource_survey().
that should be another patch later.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] PM / devfreq: add global PM QoS support
On Mon, Sep 17, 2012 at 11:10:09PM +0200, Rafael J. Wysocki wrote:
> On Monday, September 17, 2012, MyungJoo Ham wrote:
> > Sender : Rafael J. Wysocki
> > Date : 2012-09-09 07:20 (GMT+09:00)
> > Title : Re: [PATCH v3 1/2] PM / devfreq: add global PM QoS support
> > > On Thursday, August 30, 2012, MyungJoo Ham wrote:
> > > > Even if the performance of a device is controlled properly with devfreq,
> > > > sometimes, we still need to get PM-QoS inputs in order to meet the
> > > > required performance.
> > > >
> > > > In our testbed of Exynos4412, which has on-chip various DMA devices, the
> > > > memory interface and system bus are controlled according to their
> > > > utilization by devfreq. However, in some multimedia applications
> > > > including video-playing with MFC (multi-function codec) H/W and
> > > > photo/video-capturing with FIMC H/W, we have observed issues due to
> > > > insufficient DMA throughput or latency.
> > > >
> > > > In such applications, there are deadlines: less than 16.6ms with 60Hz.
> > > > With shorter polling intervals (5 ~ 15ms), the frequencies fluctuate
> > > > within a frame and we get missing frames and distorted pictures.
> > > > With longer polling intervals (20 ~ 100ms), the response time is not
> > > > sufficient and we get distorted or broken images. In other words,
> > > > regardless of polling interval, we get poor results with hard-deadline
> > > > H/Ws. They, in fact, have a preset requirement on DMA throughput.
> > > >
> > > > Thus, we need PM-QoS capabilities in devfreq. (Note that for general
> > > > user applications, devfreq for bus/memory works fine. They are not so
> > > > sensitive to tens of ms in performance increasing responses in general.
> > > >
> > > > In order to express how to handle QoS requests in devfreq devices,
> > > > the devfreq device drivers only need to express the mappings of
> > > > QoS value and frequency pairs with QoS class along with
> > > > devfreq_add_device() call.
> > > >
> > > > As a side effect of the implementation, which happens to be positive,
> > > > min/max freq is now enforced regardless of governor implementation.
> > >
> > > Can you please explain in a few words how this is supposed to work in
> > > practice?
> >
> > Ah.. this "side effect" has been neutralized by the patch
> >
> > ab5f299f51259fd2466cf35c89d79bd960e0fc32
> > PM / devfreq: add relation of recommended frequency.
> >
> > I should've removed that comment.
>
> OK
>
> > > > Tested on Exynos4412 machines with memory/bus frequencies and multimedia
> > > > H/W blocks. (camera, video decoding, and video encoding)
> > > >
> > > > Signed-off-by: MyungJoo Ham
> > > > Signed-off-by: Kyungmin Park
> > >
> > > I'm not entirely convinced yet, but a few comments follow.
> > >
> > > > ---
> > > > Changed from V2-resend
> > > > - Removed dependencies on global pm-qos class definitions
> > > > - Revised data structure handling pm-qos (being ready for dev-pm-qos)
> > > >
> > > > Changes from V2
> > > > - Rebased
> > > >
> > > > Changes from V1
> > > > - Error handling at devfreq_add_device()
> > > > - Handling pm_qos_max information
> > > > - Styly update
> > > > ---
> > []
> > > > @@ -136,8 +137,13 @@ int update_devfreq(struct devfreq *devfreq)
> > > > * List from the highest proiority
> > > > * max_freq (probably called by thermal when it's too hot)
> > > > * min_freq
> > > > + * qos_min_freq
> > > > */
> > > >
> > > > + if (devfreq->qos_min_freq && freq < devfreq->qos_min_freq) {
> > > > + freq = devfreq->qos_min_freq;
> > > > + flags &= ~DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use GLB */
> > >
> > > What exactly is the purpose of this last line?
> >
> > It says target callback to use "qos_min_freq" as its greatest lower bound;
> > use any values that are "qos_min_freq" or above.
> > And it can be overriden by min_freq and max_freq.
>
> I see.
>
> > > > + }
> > > > if (devfreq->min_freq && freq < devfreq->min_freq) {
> > > > freq = devfreq->min_freq;
> > > > flags &= ~DEVFREQ_FLAG_LEAST_UPPER_BOUND; /* Use GLB */
> > > > @@ -164,12 +170,12 @@ int update_devfreq(struct devfreq *devfreq)
> > > > * devfreq_notifier_call() - Notify that the device frequency
> > > > requirements
> > > > *has been changed out of devfreq framework.
> > > > * @nb the notifier_block (supposed to be devfreq->nb)
> > > > - * @type not used
> > > > + * @val not used.
> > > > * @devp not used
> > > > *
> > > > * Called by a notifier that uses devfreq->nb.
> > > > */
> > > > -static int devfreq_notifier_call(struct notifier_block *nb, unsigned
> > > > long type,
> > > > +static int devfreq_notifier_call(struct notifier_block *nb, unsigned
> > > > long val,
> > > > void *devp)
> > > > {
> > > > struct devfreq *devfreq = container_of(nb, struct devfreq, nb);
> > >
> > > The above change is only a cleanup unrelated to the rest of modifications.
> > > Please push it separately (if you _really_ think it's necessary).
> >
> > oops.. yes..
> >
> >
Re: [PATCHv2] remoteproc: Export notification id range
Hi Sjur,
On Thu, Sep 13, 2012 at 9:03 PM, wrote:
> From: Sjur Brændeland
>
> Some of the rproc drivers needs to know the range
> of the notification IDs used for notifying the device.
> Export a variable in struct rproc holding the
> largest allocated notification id.
>
> Signed-off-by: Sjur Brændeland
> ---
...
> void rproc_free_vring(struct rproc_vring *rvring)
> {
> + int i, maxid = 0;
> + struct rproc_vdev *rvdev, *tmp;
> int size = PAGE_ALIGN(vring_size(rvring->len, rvring->align));
> struct rproc *rproc = rvring->rvdev->rproc;
>
> dma_free_coherent(rproc->dev.parent, size, rvring->va, rvring->dma);
> idr_remove(&rproc->notifyids, rvring->notifyid);
> +
> + /* Iterate over the new set of rings to find the largest id */
> + rvring->notifyid = 0;
> + list_for_each_entry_safe(rvdev, tmp, &rproc->rvdevs, node)
Why do you need the safe variant here ?
> + for (i = 0; i < RVDEV_NUM_VRINGS; i++)
Maybe instead of two nested loops, just use idr_for_each ?
Thanks,
Ohad.
--
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] spi: pl022: Add clk_{un}prepare() support in runtime PM
On Mon, Sep 17, 2012 at 7:09 PM, Linus Walleij wrote: > This driver does clk_prepare/unprepare at probe > and removed, so I guess what you're trying to say is that > on your platform the clk_unprepare() process context call > is needed to save power? > > Please elaborate... Hi Linus, Yes, we don't need to call prepare() again atleast for SPEAr. You are correct. I saw the driver after a long time :) Can you please elaborate, why can't i see any clk_disable/enable calls anywhere else from probe. If i remember correctly, earlier we used to enable/disable clk after transfers and also during suspend/resume. The amba layer is taking care of interface clock only and not functional clock. So i believe that's not the magic code. :) -- viresh -- 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] remoteproc: Add dependency to HAS_DMA
Hi Sjur, On Thu, Sep 13, 2012 at 9:03 PM, wrote: > From: Sjur Brændeland > > Remoteproc relies on HAS_DMA, add this dependency in Kconfig. > > Signed-off-by: Sjur Brændeland Applied to remoteproc-next, thanks. Btw: > --- > cc: linux-kernel@vger.kernel.org > cc: Rusty Russell These should be above the dashes if you want them included in the patch. > > drivers/remoteproc/Kconfig |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig > index f8d818a..e7d440c 100644 > --- a/drivers/remoteproc/Kconfig > +++ b/drivers/remoteproc/Kconfig > @@ -4,6 +4,7 @@ menu "Remoteproc drivers (EXPERIMENTAL)" > config REMOTEPROC > tristate > depends on EXPERIMENTAL > + depends on HAS_DMA I've added this to OMAP_REMOTEPROC too, because recursive dependencies don't work (REMOTEPROC could still be selected without HAS_DMA). Thanks, Ohad. -- 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: usbip: stub_dev: Fixed oops during removal of usbip_host
stub_device_reset should set kernel thread pointers to NULL.
so that at the time of usbip_host removal stub_shoutdown_connection
doesn't try to kill kernel threads which are already killed.
Signed-off-by: navin patidar
---
drivers/staging/usbip/stub_dev.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/usbip/stub_dev.c b/drivers/staging/usbip/stub_dev.c
index 92ced35..447a98c 100644
--- a/drivers/staging/usbip/stub_dev.c
+++ b/drivers/staging/usbip/stub_dev.c
@@ -198,10 +198,8 @@ static void stub_shutdown_connection(struct usbip_device
*ud)
* tcp_socket is freed after threads are killed so that usbip_xmit does
* not touch NULL socket.
*/
- if (ud->tcp_socket) {
+ if (ud->tcp_socket)
sock_release(ud->tcp_socket);
- ud->tcp_socket = NULL;
- }
/* 3. free used data */
stub_device_cleanup_urbs(sdev);
@@ -233,6 +231,9 @@ static void stub_device_reset(struct usbip_device *ud)
dev_dbg(&udev->dev, "device reset");
+ ud->tcp_socket = NULL;
+ ud->tcp_rx = NULL;
+ ud->tcp_tx = NULL;
ret = usb_lock_device_for_reset(udev, sdev->interface);
if (ret < 0) {
dev_err(&udev->dev, "lock for reset\n");
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] 3.0.43-rt65
Dear RT Folks, I'm pleased to announce the 3.0.43-rt65 stable release. This release is just an update to the new stable 3.0.43 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git Head SHA1: a13e9ee67bbc2d0870167dc0fe558cab3f117442 Or to build 3.0.43-rt65 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.0.tar.xz http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.0.43.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.0/patch-3.0.43-rt65.patch.xz Enjoy, -- 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] genirq: Add the IRQS_ONESHOT support for edge interrupt
In handle_edge_irq(), currently do not care about the flag IRQS_ONESHOT,
but there are many edge interrupt handler with irq thread need it indeed,
so implement here.
Signed-off-by: liu chuansheng
---
kernel/irq/chip.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index eebd6d5..8e4e49a 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -497,7 +497,13 @@ handle_edge_irq(unsigned int irq, struct irq_desc *desc)
kstat_incr_irqs_this_cpu(irq, desc);
/* Start handling the irq */
- desc->irq_data.chip->irq_ack(&desc->irq_data);
+ if (desc->istate & IRQS_ONESHOT) {
+ mask_ack_irq(desc);
+ handle_irq_event(desc);
+ cond_unmask_irq();
+ goto out_unlock;
+ } else
+ desc->irq_data.chip->irq_ack(&desc->irq_data);
do {
if (unlikely(!desc->action)) {
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] DMA: PL330: Check the pointer returned by kzalloc
On Mon, 2012-09-17 at 15:20 +0530, Sachin Kamat wrote:
> kzalloc could return NULL. Hence add a check to avoid
> NULL pointer dereference.
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/dma/pl330.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 018a445..5d3bbcd 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -2930,6 +2930,11 @@ pl330_probe(struct amba_device *adev, const struct
> amba_id *id)
> num_chan = max_t(int, pi->pcfg.num_peri, pi->pcfg.num_chan);
>
> pdmac->peripherals = kzalloc(num_chan * sizeof(*pch), GFP_KERNEL);
> + if (!pdmac->peripherals) {
> + ret = -ENOMEM;
> + dev_err(&adev->dev, "unable to allocate pdmac->peripherals\n");
> + goto probe_err5;
> + }
>
> for (i = 0; i < num_chan; i++) {
> pch = &pdmac->peripherals[i];
Thanks applied both to fixes.
I have cc'ed stable as well
--
~Vinod
--
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 0/2] DMA: PL330: Clock and runtime cleanup
On Fri, 2012-09-07 at 12:14 +0530, Inderpal Singh wrote: > The controller clock is being managed at AMBA bus level probe/remove and > pm_runtime/suspend functions. The existing driver does the clock > enable/disable > again in the same code paths, which unneccessarily increments the usage count > of > the clock for the same device. > > The following patches remove the redundant clock enable/disable from the > driver. Applied thanks -- ~Vinod -- 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: OMAP: OMAP_DEBUG_LEDS needs to select LEDS_CLASS
This fixes below build error when CONFIG_LEDS_CLASS is not set. LD init/built-in.o arch/arm/plat-omap/built-in.o: In function `fpga_probe': arch/arm/plat-omap/debug-leds.c:113: undefined reference to `led_classdev_register' make: *** [vmlinux] Error 1 Signed-off-by: Axel Lin --- arch/arm/plat-omap/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index ca83a76..c262781 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -43,6 +43,7 @@ config OMAP_DEBUG_DEVICES config OMAP_DEBUG_LEDS def_bool y if NEW_LEDS + select LEDS_CLASS depends on OMAP_DEBUG_DEVICES config POWER_AVS_OMAP -- 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] dmaengine: use kmem_cache_zalloc instead of kmem_cache_alloc/memset
On Mon, 2012-08-27 at 12:40 +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Using kmem_cache_zalloc() instead of kmem_cache_alloc() and memset().
>
> spatch with a semantic match is used to found this problem.
> (http://coccinelle.lip6.fr/)
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/dma/ioat/dma_v2.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/dma/ioat/dma_v2.c b/drivers/dma/ioat/dma_v2.c
> index 8689576..b9d6678 100644
> --- a/drivers/dma/ioat/dma_v2.c
> +++ b/drivers/dma/ioat/dma_v2.c
> @@ -434,12 +434,11 @@ static struct ioat_ring_ent
> *ioat2_alloc_ring_ent(struct dma_chan *chan, gfp_t f
> return NULL;
> memset(hw, 0, sizeof(*hw));
>
> - desc = kmem_cache_alloc(ioat2_cache, flags);
> + desc = kmem_cache_zalloc(ioat2_cache, flags);
> if (!desc) {
> pci_pool_free(dma->dma_pool, hw, phys);
> return NULL;
> }
> - memset(desc, 0, sizeof(*desc));
>
> dma_async_tx_descriptor_init(&desc->txd, chan);
> desc->txd.tx_submit = ioat2_tx_submit_unlock;
Applied thanks
--
~Vinod
--
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] dmaengine: add dmanegine slave map api's
On Mon, 2012-09-17 at 22:57 +0100, Russell King - ARM Linux wrote: > On Mon, Sep 17, 2012 at 03:20:29PM +0530, Vinod Koul wrote: > > On Mon, 2012-09-17 at 09:36 +0100, Russell King - ARM Linux wrote: > > > > > I'm not saying take the slave_id out of the map. I'm saying, let the > > > > > DMA engine driver itself figure out what dma_chan to return. > > > > But wont that assume the dma controller knows which channel to allocate. > > > > And how would it know this information? This can be problematic for hard > > > > wired muxes, but can be easily done for controller which have > > > > programmable mux. > > > > > > Well, as I have already said, at the moment you're returning the _first_ > > > _free_ _channel_ on a DMA device, which almost certainly will always be > > > the wrong one. > > Yes I overlooked, the continue is wrong. It needs to move to next > > available channel. I have fixed it. > > > > Now on the question if we should allow dmaengine to select channel or > > let dma engine driver do that, I don't see how that helps for hard wired > > muxes where dma engine driver doesn't know anything of mapping. > > > > For your OMAP dma this wont matter as I think you have a programmable > > mux so you maybe able to use any channel with rightly programmed mux, > > right? > > Except that we expose one 'channel' per mux setting, so as far as DMA > engine goes, the mux number _is_ the channel number - which is the same > approach taken by the PL08x and sa11x0 DMA engine drivers. It is the > only sane approach to dealing with N hardware channels vs >>N clients. Sure that makes things easy in dmaengine code. So we allocate channel number given by slave id (if set) or first free channel. This would also mean people need to update their drivers to use virtual channel which indeed is a good idea :) -- ~Vinod -- 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: manual merge of the mfd tree with Linus' tree
Hi Samuel,
Today's linux-next merge of the mfd tree got a conflict in
drivers/regulator/anatop-regulator.c between commit 3e2a928472da
("regulator: anatop: Fix wrong mask used in anatop_get_voltage_sel") from
Linus' tree and commit baa64151aecc ("regulator: anatop-regulator:
Convert to use syscon to access anatop register") from the mfd tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/regulator/anatop-regulator.c
index ce0fe72,596535d..000
--- a/drivers/regulator/anatop-regulator.c
+++ b/drivers/regulator/anatop-regulator.c
@@@ -61,18 -64,17 +64,18 @@@ static int anatop_regmap_set_voltage_se
return 0;
}
- static int anatop_get_voltage_sel(struct regulator_dev *reg)
+ static int anatop_regmap_get_voltage_sel(struct regulator_dev *reg)
{
struct anatop_regulator *anatop_reg = rdev_get_drvdata(reg);
- u32 val;
+ u32 val, mask;
if (!anatop_reg->control_reg)
return -ENOTSUPP;
- val = anatop_read_reg(anatop_reg->mfd, anatop_reg->control_reg);
+ regmap_read(anatop_reg->anatop, anatop_reg->control_reg, &val);
- val = (val & ((1 << anatop_reg->vol_bit_width) - 1)) >>
+ mask = ((1 << anatop_reg->vol_bit_width) - 1) <<
anatop_reg->vol_bit_shift;
+ val = (val & mask) >> anatop_reg->vol_bit_shift;
return val - anatop_reg->min_bit_val;
}
pgpX3AvJanfHK.pgp
Description: PGP signature
Re: [PATCH part2 4/6] x86, PCI: Separate rom resource claim out
On Mon, Sep 17, 2012 at 4:38 PM, Bjorn Helgaas wrote:
> On Sun, Sep 2, 2012 at 3:50 PM, Yinghai Lu wrote:
>> So could use it with hot-added root bus.
>>
>> Signed-off-by: Yinghai Lu
>> ---
>> arch/x86/pci/i386.c | 58
>> ---
>> 1 files changed, 41 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
>> index 84696ed..4fdf0b2 100644
>> --- a/arch/x86/pci/i386.c
>> +++ b/arch/x86/pci/i386.c
>> @@ -298,27 +298,51 @@ static void __init pcibios_allocate_resources(struct
>> pci_bus *bus, int pass)
>> }
>> }
>>
>> +static void __init __pcibios_allocate_rom_resources(struct pci_bus *bus)
>> +{
>> + struct pci_dev *dev;
>> + struct pci_bus *child;
>> +
>> + list_for_each_entry(dev, &bus->devices, bus_list) {
>> + pcibios_allocate_dev_rom_resource(dev);
>> +
>> + child = dev->subordinate;
>> + if (child)
>> + __pcibios_allocate_rom_resources(child);
>
> I really dislike the "__" prefix on the function names. It seems
> pointless to add another function and the "__" when all you need is a
> test of PCI_ASSIGN_ROMS. Also, it makes the structure of
> __pcibios_allocate_rom_resources() different from
> pcibios_allocate_resources() when they should be exactly the same.
>
> What if you made pcibios_assign_resources() look like this:
>
> if (!!(pci_probe & PCI_ASSIGN_ROMS)) {
> list_for_each_entry(bus, &pci_root_buses, node)
> pcibios_allocate_rom_resources(bus);
> }
>
> Then I don't think you'd need the extra function.
ok, will just move pci_probe checking back to
pcibios_allocate_rom_resources directly.
Yinghai
--
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 2/2] kvm: Add resampling irqfds for level triggered interrupts
To emulate level triggered interrupts, add a resample option to
KVM_IRQFD. When specified, a new resamplefd is provided that notifies
the user when the irqchip has been resampled by the VM. This may, for
instance, indicate an EOI. Also in this mode, injection of an
interrupt through an irqfd only asserts the interrupt. On resampling,
the interrupt is automatically de-asserted prior to user notification.
This enables level triggered interrupts to be injected and re-enabled
from vfio with no userspace intervention.
All resampling irqfds can make use of a single irq source ID, so we
reserve a new one for this interface.
Signed-off-by: Alex Williamson
---
Documentation/virtual/kvm/api.txt | 13 +++
arch/x86/kvm/x86.c|4 +
include/linux/kvm.h | 12 ++-
include/linux/kvm_host.h |4 +
virt/kvm/eventfd.c| 175 -
virt/kvm/irq_comm.c |6 +
virt/kvm/kvm_main.c |2
7 files changed, 210 insertions(+), 6 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt
b/Documentation/virtual/kvm/api.txt
index bf33aaa..d30af74 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1946,6 +1946,19 @@ the guest using the specified gsi pin. The irqfd is
removed using
the KVM_IRQFD_FLAG_DEASSIGN flag, specifying both kvm_irqfd.fd
and kvm_irqfd.gsi.
+With KVM_CAP_IRQFD_RESAMPLE, KVM_IRQFD supports a de-assert and notify
+mechanism allowing emulation of level-triggered, irqfd-based
+interrupts. When KVM_IRQFD_FLAG_RESAMPLE is set the user must pass an
+additional eventfd in the kvm_irqfd.resamplefd field. When operating
+in resample mode, injection of an interrupt through kvm_irq.fd asserts
+the specified gsi in the irqchip. When the irqchip is resampled, such
+as from an EOI, the gsi is de-asserted and the user is notifed via
+kvm_irqfd.resamplefd. It is the user's respnosibility to re-inject
+the interrupt if the device making use of it still requires service.
+Note that closing the resamplefd is not sufficient to disable the
+irqfd. The KVM_IRQFD_FLAG_RESAMPLE is only necessary on assignment
+and need not be specified with KVM_IRQFD_FLAG_DEASSIGN.
+
4.76 KVM_PPC_ALLOCATE_HTAB
Capability: KVM_CAP_PPC_ALLOC_HTAB
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 2966c84..56f9002 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2177,6 +2177,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_GET_TSC_KHZ:
case KVM_CAP_PCI_2_3:
case KVM_CAP_KVMCLOCK_CTRL:
+ case KVM_CAP_IRQFD_RESAMPLE:
r = 1;
break;
case KVM_CAP_COALESCED_MMIO:
@@ -6268,6 +6269,9 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
/* Reserve bit 0 of irq_sources_bitmap for userspace irq source */
set_bit(KVM_USERSPACE_IRQ_SOURCE_ID, &kvm->arch.irq_sources_bitmap);
+ /* Reserve bit 1 of irq_sources_bitmap for irqfd-resampler */
+ set_bit(KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
+ &kvm->arch.irq_sources_bitmap);
raw_spin_lock_init(&kvm->arch.tsc_write_lock);
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 2ce09aa..a01a3d5 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -618,6 +618,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_PPC_GET_SMMU_INFO 78
#define KVM_CAP_S390_COW 79
#define KVM_CAP_PPC_ALLOC_HTAB 80
+#define KVM_CAP_IRQFD_RESAMPLE 81
#ifdef KVM_CAP_IRQ_ROUTING
@@ -683,12 +684,21 @@ struct kvm_xen_hvm_config {
#endif
#define KVM_IRQFD_FLAG_DEASSIGN (1 << 0)
+/*
+ * Available with KVM_CAP_IRQFD_RESAMPLE
+ *
+ * KVM_IRQFD_FLAG_RESAMPLE indicates resamplefd is valid and specifies
+ * the irqfd to operate in resampling mode for level triggered interrupt
+ * emlation. See Documentation/virtual/kvm/api.txt.
+ */
+#define KVM_IRQFD_FLAG_RESAMPLE (1 << 1)
struct kvm_irqfd {
__u32 fd;
__u32 gsi;
__u32 flags;
- __u8 pad[20];
+ __u32 resamplefd;
+ __u8 pad[16];
};
struct kvm_clock_data {
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 84f6950..d7bc79c 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -70,7 +70,8 @@
#define KVM_REQ_PMU 16
#define KVM_REQ_PMI 17
-#define KVM_USERSPACE_IRQ_SOURCE_ID0
+#define KVM_USERSPACE_IRQ_SOURCE_ID0
+#define KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID 1
struct kvm;
struct kvm_vcpu;
@@ -283,6 +284,7 @@ struct kvm {
struct {
spinlock_tlock;
struct list_head items;
+ struct list_head resamplers;
} irqfds;
struct list_head ioeventfds;
#endif
diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index 7d7e2aa..822f50a 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -43,6 +43,31 @@
*
[PATCH v10 1/2] kvm: Provide pre-locked setup to irq ack notifier
This enables better integration into irqfd setup where we can adjust
our lock ordering to hold irq_lock, making these callable and avoiding
irq source ID races.
Signed-off-by: Alex Williamson
---
include/linux/kvm_host.h |4
virt/kvm/irq_comm.c | 18 --
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index b70b48b..84f6950 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -628,8 +628,12 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, u32
irq, int level);
int kvm_set_msi(struct kvm_kernel_irq_routing_entry *irq_entry, struct kvm
*kvm,
int irq_source_id, int level);
void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin);
+void __kvm_register_irq_ack_notifier(struct kvm *kvm,
+struct kvm_irq_ack_notifier *kian);
void kvm_register_irq_ack_notifier(struct kvm *kvm,
struct kvm_irq_ack_notifier *kian);
+void __kvm_unregister_irq_ack_notifier(struct kvm *kvm,
+ struct kvm_irq_ack_notifier *kian);
void kvm_unregister_irq_ack_notifier(struct kvm *kvm,
struct kvm_irq_ack_notifier *kian);
int kvm_request_irq_source_id(struct kvm *kvm);
diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
index 83402d7..dd0cbf6 100644
--- a/virt/kvm/irq_comm.c
+++ b/virt/kvm/irq_comm.c
@@ -191,19 +191,33 @@ void kvm_notify_acked_irq(struct kvm *kvm, unsigned
irqchip, unsigned pin)
rcu_read_unlock();
}
+/* hold kvm->irq_lock */
+void __kvm_register_irq_ack_notifier(struct kvm *kvm,
+struct kvm_irq_ack_notifier *kian)
+{
+ hlist_add_head_rcu(&kian->link, &kvm->irq_ack_notifier_list);
+}
+
void kvm_register_irq_ack_notifier(struct kvm *kvm,
struct kvm_irq_ack_notifier *kian)
{
mutex_lock(&kvm->irq_lock);
- hlist_add_head_rcu(&kian->link, &kvm->irq_ack_notifier_list);
+ __kvm_register_irq_ack_notifier(kvm, kian);
mutex_unlock(&kvm->irq_lock);
}
+/* hold kvm->irq_lock and wait for rcu grace period */
+void __kvm_unregister_irq_ack_notifier(struct kvm *kvm,
+ struct kvm_irq_ack_notifier *kian)
+{
+ hlist_del_init_rcu(&kian->link);
+}
+
void kvm_unregister_irq_ack_notifier(struct kvm *kvm,
struct kvm_irq_ack_notifier *kian)
{
mutex_lock(&kvm->irq_lock);
- hlist_del_init_rcu(&kian->link);
+ __kvm_unregister_irq_ack_notifier(kvm, kian);
mutex_unlock(&kvm->irq_lock);
synchronize_rcu();
}
--
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/2] kvm: level irqfd support
Updated with suggestions from Michael and Avi, the OADN option is now a "resample" option. Re-working locking went surprisingly well, lockdep clean, and now allows us to use a single irq source ID for all resample irqfds. I hope we're close. Thanks, Alex --- Alex Williamson (2): kvm: Add resampling irqfds for level triggered interrupts kvm: Provide pre-locked setup to irq ack notifier Documentation/virtual/kvm/api.txt | 13 +++ arch/x86/kvm/x86.c|4 + include/linux/kvm.h | 12 ++- include/linux/kvm_host.h |8 +- virt/kvm/eventfd.c| 175 - virt/kvm/irq_comm.c | 24 + virt/kvm/kvm_main.c |2 7 files changed, 230 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] alarmtimer: Use hrtimer per-alarm instead of per-base
Arve Hjønnevåg reported numerous crashes from the
"BUG_ON(timer->state != HRTIMER_STATE_CALLBACK)" check
in __run_hrtimer after it called alarmtimer_fired.
It ends up the alarmtimer code was not properly handling
possible failures of hrtimer_try_to_cancel, and because
these faulres occur when the underlying base hrtimer is
being run, this limits the ability to properly handle
modifications to any alarmtimers on that base.
Because much of the logic duplicates the hrtimer logic,
it seems that we might as well have a per-alarmtimer
hrtimer, and avoid the extra complextity of trying to
multiplex many alarmtimers off of one hrtimer.
Thus this patch moves the hrtimer to the alarm structure
and simplifies the management logic.
Cc: Arve Hjønnevåg
Cc: Colin Cross
Cc: Thomas Gleixner
Reported-by: Arve Hjønnevåg
Signed-off-by: John Stultz
---
include/linux/alarmtimer.h |3 +-
kernel/time/alarmtimer.c | 93 +---
2 files changed, 28 insertions(+), 68 deletions(-)
diff --git a/include/linux/alarmtimer.h b/include/linux/alarmtimer.h
index 96c5c24..f122c9f 100644
--- a/include/linux/alarmtimer.h
+++ b/include/linux/alarmtimer.h
@@ -35,6 +35,7 @@ enum alarmtimer_restart {
*/
struct alarm {
struct timerqueue_node node;
+ struct hrtimer timer;
enum alarmtimer_restart (*function)(struct alarm *, ktime_t now);
enum alarmtimer_typetype;
int state;
@@ -43,7 +44,7 @@ struct alarm {
void alarm_init(struct alarm *alarm, enum alarmtimer_type type,
enum alarmtimer_restart (*function)(struct alarm *, ktime_t));
-void alarm_start(struct alarm *alarm, ktime_t start);
+int alarm_start(struct alarm *alarm, ktime_t start);
int alarm_try_to_cancel(struct alarm *alarm);
int alarm_cancel(struct alarm *alarm);
diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index aa27d39..8c763ac 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -37,7 +37,6 @@
static struct alarm_base {
spinlock_t lock;
struct timerqueue_head timerqueue;
- struct hrtimer timer;
ktime_t (*gettime)(void);
clockid_t base_clockid;
} alarm_bases[ALARM_NUMTYPE];
@@ -130,21 +129,16 @@ static inline void alarmtimer_rtc_timer_init(void) { }
* @base: pointer to the base where the timer is being run
* @alarm: pointer to alarm being enqueued.
*
- * Adds alarm to a alarm_base timerqueue and if necessary sets
- * an hrtimer to run.
+ * Adds alarm to a alarm_base timerqueue
*
* Must hold base->lock when calling.
*/
static void alarmtimer_enqueue(struct alarm_base *base, struct alarm *alarm)
{
+ WARN_ON(alarm->state & ALARMTIMER_STATE_ENQUEUED);
+
timerqueue_add(&base->timerqueue, &alarm->node);
alarm->state |= ALARMTIMER_STATE_ENQUEUED;
-
- if (&alarm->node == timerqueue_getnext(&base->timerqueue)) {
- hrtimer_try_to_cancel(&base->timer);
- hrtimer_start(&base->timer, alarm->node.expires,
- HRTIMER_MODE_ABS);
- }
}
/**
@@ -152,28 +146,17 @@ static void alarmtimer_enqueue(struct alarm_base *base,
struct alarm *alarm)
* @base: pointer to the base where the timer is running
* @alarm: pointer to alarm being removed
*
- * Removes alarm to a alarm_base timerqueue and if necessary sets
- * a new timer to run.
+ * Removes alarm to a alarm_base timerqueue
*
* Must hold base->lock when calling.
*/
static void alarmtimer_remove(struct alarm_base *base, struct alarm *alarm)
{
- struct timerqueue_node *next = timerqueue_getnext(&base->timerqueue);
-
if (!(alarm->state & ALARMTIMER_STATE_ENQUEUED))
return;
timerqueue_del(&base->timerqueue, &alarm->node);
alarm->state &= ~ALARMTIMER_STATE_ENQUEUED;
-
- if (next == &alarm->node) {
- hrtimer_try_to_cancel(&base->timer);
- next = timerqueue_getnext(&base->timerqueue);
- if (!next)
- return;
- hrtimer_start(&base->timer, next->expires, HRTIMER_MODE_ABS);
- }
}
@@ -188,42 +171,23 @@ static void alarmtimer_remove(struct alarm_base *base,
struct alarm *alarm)
*/
static enum hrtimer_restart alarmtimer_fired(struct hrtimer *timer)
{
- struct alarm_base *base = container_of(timer, struct alarm_base, timer);
- struct timerqueue_node *next;
+ struct alarm *alarm = container_of(timer, struct alarm, timer);
+ struct alarm_base *base = &alarm_bases[alarm->type];
unsigned long flags;
- ktime_t now;
int ret = HRTIMER_NORESTART;
int restart = ALARMTIMER_NORESTART;
spin_lock_irqsave(&base->lock, flags);
- now = base->gettime();
- while ((next = timerqueue_getnext(&base->timerqueue))) {
- struct alarm *alarm;
- ktime_t exp
[PATCH 3/3] alarmtimer: Rename alarmtimer_remove to alarmtimer_dequeue
Now that alarmtimer_remove has been simplified, change
its name to _dequeue to better match its paired _enqueue
function.
Cc: Arve Hjønnevåg
Cc: Colin Cross
Cc: Thomas Gleixner
Signed-off-by: John Stultz
---
kernel/time/alarmtimer.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index 8c763ac..d14f833 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -142,7 +142,7 @@ static void alarmtimer_enqueue(struct alarm_base *base,
struct alarm *alarm)
}
/**
- * alarmtimer_remove - Removes an alarm timer from an alarm_base timerqueue
+ * alarmtimer_dequeue - Removes an alarm timer from an alarm_base timerqueue
* @base: pointer to the base where the timer is running
* @alarm: pointer to alarm being removed
*
@@ -150,7 +150,7 @@ static void alarmtimer_enqueue(struct alarm_base *base,
struct alarm *alarm)
*
* Must hold base->lock when calling.
*/
-static void alarmtimer_remove(struct alarm_base *base, struct alarm *alarm)
+static void alarmtimer_dequeue(struct alarm_base *base, struct alarm *alarm)
{
if (!(alarm->state & ALARMTIMER_STATE_ENQUEUED))
return;
@@ -178,7 +178,7 @@ static enum hrtimer_restart alarmtimer_fired(struct hrtimer
*timer)
int restart = ALARMTIMER_NORESTART;
spin_lock_irqsave(&base->lock, flags);
- alarmtimer_remove(base, alarm);
+ alarmtimer_dequeue(base, alarm);
spin_unlock_irqrestore(&base->lock, flags);
if (alarm->function)
@@ -332,7 +332,7 @@ int alarm_try_to_cancel(struct alarm *alarm)
spin_lock_irqsave(&base->lock, flags);
ret = hrtimer_try_to_cancel(&alarm->timer);
if (ret >= 0)
- alarmtimer_remove(base, alarm);
+ alarmtimer_dequeue(base, alarm);
spin_unlock_irqrestore(&base->lock, flags);
return ret;
}
--
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 2/3] alarmtimer: Remove unused helpers & defines
No one is using these alarmtimer state helpers, so yank them.
Cc: Arve Hjønnevåg
Cc: Colin Cross
Cc: Thomas Gleixner
Signed-off-by: John Stultz
---
include/linux/alarmtimer.h | 28
1 file changed, 28 deletions(-)
diff --git a/include/linux/alarmtimer.h b/include/linux/alarmtimer.h
index f122c9f..9069694 100644
--- a/include/linux/alarmtimer.h
+++ b/include/linux/alarmtimer.h
@@ -21,7 +21,6 @@ enum alarmtimer_restart {
#define ALARMTIMER_STATE_INACTIVE 0x00
#define ALARMTIMER_STATE_ENQUEUED 0x01
-#define ALARMTIMER_STATE_CALLBACK 0x02
/**
* struct alarm - Alarm timer structure
@@ -50,33 +49,6 @@ int alarm_cancel(struct alarm *alarm);
u64 alarm_forward(struct alarm *alarm, ktime_t now, ktime_t interval);
-/*
- * A alarmtimer is active, when it is enqueued into timerqueue or the
- * callback function is running.
- */
-static inline int alarmtimer_active(const struct alarm *timer)
-{
- return timer->state != ALARMTIMER_STATE_INACTIVE;
-}
-
-/*
- * Helper function to check, whether the timer is on one of the queues
- */
-static inline int alarmtimer_is_queued(struct alarm *timer)
-{
- return timer->state & ALARMTIMER_STATE_ENQUEUED;
-}
-
-/*
- * Helper function to check, whether the timer is running the callback
- * function
- */
-static inline int alarmtimer_callback_running(struct alarm *timer)
-{
- return timer->state & ALARMTIMER_STATE_CALLBACK;
-}
-
-
/* Provide way to access the rtc device being used by alarmtimers */
struct rtc_device *alarmtimer_get_rtcdev(void);
--
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 0/3][RFC] Alarmtimer fixes (hopefully 3.7 material)
Arve Hjønnevåg reported numerous crashes from the "BUG_ON(timer->state != HRTIMER_STATE_CALLBACK)" check in __run_hrtimer after it called alarmtimer_fired. Looking at the code, I realized much of the logic duplicated the hrtimer code, and that by multiplexing numerous alarmtimers onto a single hrtimer didn't really gain us anything over just using an hrtimer per alarmtimer. Especially given the various ways hrtimer actions can fail. So this patchset tries to simplify some of the alarmtimer code by utilizing the hrtimer logic in a more direct manner. Followed then by a few cleanup patches. I've done some brief testing with some simpler test cases, but I'd appreciate any additional testing or review. I'm hoping to resubmit this so it can go in for 3.7. thanks -john Cc: Arve Hjønnevåg Cc: Colin Cross Cc: Thomas Gleixner John Stultz (3): alarmtimer: Use hrtimer per-alarm instead of per-base alarmtimer: Remove unused helpers & defines alarmtimer: Rename alarmtimer_remove to alarmtimer_dequeue include/linux/alarmtimer.h | 31 +- kernel/time/alarmtimer.c | 99 +--- 2 files changed, 31 insertions(+), 99 deletions(-) -- 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: [RFC PATCH 3/3] perf tool: Allow wildcard in PMU name
On 09/17/2012 11:36 PM, Arnaldo Carvalho de Melo wrote:
> Em Tue, Sep 11, 2012 at 04:27:17PM +0200, Jiri Olsa escreveu:
>> On Mon, Sep 10, 2012 at 03:53:51PM +0800, Yan, Zheng wrote:
>>
>> Would it be possible to have all '*add_event' more obvious for usage.
>> Also following code is duplicated after each call of __add_event:
>>
>> evsel = __add_event(idx, &attr, pmu_event_name(head_config),
>> pmu->cpus);
>> if (!evsel) {
>> *idx = orig_idx;
>> free_event_list(list);
>> return -ENOMEM;
>> }
>> list_add_tail(&evsel->node, list);
>
> Any update here? Yan, did you look at folding Jiri's patch? I'm merging
> the first bit, the kernel part, that was Acked by Ingo and Peter,
> waiting on this part, looking at 2/3 now
>
Hi,
This patch still need some improvement, I don't expect it to get merged.
Please merged the patch 1 and patch 2 first. I will send a new one soon.
Regards
Yan, Zheng
--
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] Improving directed yield scalability for PLE handler
On Sun, 2012-09-16 at 11:55 +0300, Avi Kivity wrote: > On 09/14/2012 12:30 AM, Andrew Theurer wrote: > > > The concern I have is that even though we have gone through changes to > > help reduce the candidate vcpus we yield to, we still have a very poor > > idea of which vcpu really needs to run. The result is high cpu usage in > > the get_pid_task and still some contention in the double runqueue lock. > > To make this scalable, we either need to significantly reduce the > > occurrence of the lock-holder preemption, or do a much better job of > > knowing which vcpu needs to run (and not unnecessarily yielding to vcpus > > which do not need to run). > > > > On reducing the occurrence: The worst case for lock-holder preemption > > is having vcpus of same VM on the same runqueue. This guarantees the > > situation of 1 vcpu running while another [of the same VM] is not. To > > prove the point, I ran the same test, but with vcpus restricted to a > > range of host cpus, such that any single VM's vcpus can never be on the > > same runqueue. In this case, all 10 VMs' vcpu-0's are on host cpus 0-4, > > vcpu-1's are on host cpus 5-9, and so on. Here is the result: > > > > kvm_cpu_spin, and all > > yield_to changes, plus > > restricted vcpu placement: 8823 +/- 3.20% much, much better > > > > On picking a better vcpu to yield to: I really hesitate to rely on > > paravirt hint [telling us which vcpu is holding a lock], but I am not > > sure how else to reduce the candidate vcpus to yield to. I suspect we > > are yielding to way more vcpus than are prempted lock-holders, and that > > IMO is just work accomplishing nothing. Trying to think of way to > > further reduce candidate vcpus > > I wouldn't say that yielding to the "wrong" vcpu accomplishes nothing. > That other vcpu gets work done (unless it is in pause loop itself) and > the yielding vcpu gets put to sleep for a while, so it doesn't spend > cycles spinning. While we haven't fixed the problem at least the guest > is accomplishing work, and meanwhile the real lock holder may get > naturally scheduled and clear the lock. OK, yes, if the other thread gets useful work done, then it is not wasteful. I was thinking of the worst case scenario, where any other vcpu would likely spin as well, and the host side cpu-time for switching vcpu threads was not all that productive. Well, I suppose it does help eliminate potential lock holding vcpus; it just seems to be not that efficient or fast enough. > The main problem with this theory is that the experiments don't seem to > bear it out. Granted, my test case is quite brutal. It's nothing but over-committed VMs which always have some spin lock activity. However, we really should try to fix the worst case scenario. > So maybe one of the assumptions is wrong - the yielding > vcpu gets scheduled early. That could be the case if the two vcpus are > on different runqueues - you could be changing the relative priority of > vcpus on the target runqueue, but still remain on top yourself. Is this > possible with the current code? > > Maybe we should prefer vcpus on the same runqueue as yield_to targets, > and only fall back to remote vcpus when we see it didn't help. > > Let's examine a few cases: > > 1. spinner on cpu 0, lock holder on cpu 0 > > win! > > 2. spinner on cpu 0, random vcpu(s) (or normal processes) on cpu 0 > > Spinner gets put to sleep, random vcpus get to work, low lock contention > (no double_rq_lock), by the time spinner gets scheduled we might have won > > 3. spinner on cpu 0, another spinner on cpu 0 > > Worst case, we'll just spin some more. Need to detect this case and > migrate something in. Well, we can certainly experiment and see what we get. IMO, the key to getting this working really well on the large VMs is finding the lock-holding cpu -quickly-. What I think is happening is that we go through a relatively long process to get to that one right vcpu. I guess I need to find a faster way to get there. > 4. spinner on cpu 0, alone > > Similar > > > It seems we need to tie in to the load balancer. > > Would changing the priority of the task while it is spinning help the > load balancer? Not sure. -Andrew -- 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 v5 06/17] docs: Xen ARM DT bindings
On 09/17/2012 12:38 PM, Stefano Stabellini wrote:
> Add a doc to describe the Xen ARM device tree bindings
>
>
> Changes in v5:
>
> - add a comment about the size of the grant table memory region;
> - add a comment about the required presence of a GIC node;
> - specify that the described properties are part of a top-level
> "hypervisor" node;
> - specify #address-cells and #size-cells for the example.
>
>
> Changes in v4:
>
> - "xen,xen" should be last as it is less specific;
> - update reg property using 2 address-cells and 2 size-cells.
>
>
> Signed-off-by: Stefano Stabellini
> CC: devicetree-disc...@lists.ozlabs.org
> CC: David Vrabel
> CC: Rob Herring
> CC: Dave Martin
This is so minimal now and it doesn't seem to have any overlap with kvm, so:
Acked-by: Rob Herring
> ---
> Documentation/devicetree/bindings/arm/xen.txt | 25
> +
> 1 files changed, 25 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/xen.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/xen.txt
> b/Documentation/devicetree/bindings/arm/xen.txt
> new file mode 100644
> index 000..0f7b9c2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> @@ -0,0 +1,25 @@
> +* Xen hypervisor device tree bindings
> +
> +Xen ARM virtual platforms shall have a top-level "hypervisor" node with
> +the following properties:
> +
> +- compatible:
> + compatible = "xen,xen-", "xen,xen";
> + where is the version of the Xen ABI of the platform.
> +
> +- reg: specifies the base physical address and size of a region in
> + memory where the grant table should be mapped to, using an
> + HYPERVISOR_memory_op hypercall. The memory region is large enough to map
> + the whole grant table (it is larger or equal to gnttab_max_grant_frames()).
> +
> +- interrupts: the interrupt used by Xen to inject event notifications.
> + A GIC node is also required.
> +
> +
> +Example (assuming #address-cells = <2> and #size-cells = <2>):
> +
> +hypervisor {
> + compatible = "xen,xen-4.3", "xen,xen";
> + reg = <0 0xb000 0 0x2>;
> + interrupts = <1 15 0xf08>;
> +};
>
--
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/
[ANNOUNCE] 3.2.29-rt44
Dear RT Folks, I'm pleased to announce the 3.2.29-rt44 stable release. This release is just an update to the new stable 3.2.29 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git Head SHA1: f3df66e98b6e42ff2c50c80f43e0667c896b Or to build 3.2.29-rt44 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.29.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.29-rt44.patch.xz Enjoy, -- 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/
Re: [PATCH 0/3] 3.2-stable timekeeping fixes merged in 3.6
On 09/17/2012 07:32 PM, John Stultz wrote: Just wanted to send out a few timekeeping fixes that were merged in 3.6 which are appropriate for -stable. And I did it again. The subject of this should have been: "2.6.32-stable timekeeping fixes merged in 3.6" Apologies for any confusion. thanks -john -- 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 0/3] 3.4-stable timekeeping fixes merged in 3.6
On 09/17/2012 06:38 PM, John Stultz wrote: Just wanted to send out a few timekeeping fixes that were merged in 3.6 which are appropriate for -stable. Manabu Ori noted that the subject here should have been: "2.6.34-stable timekeeping fixes merged in 3.6" My brain is apparently more excited about the 3.x series. Apologies for any confusion! -john -- 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] 2.6.32.y: time: Improve sanity checking of timekeeping inputs
This is a -stable backport of 4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b
Unexpected behavior could occur if the time is set to a value large
enough to overflow a 64bit ktime_t (which is something larger then the
year 2262).
Also unexpected behavior could occur if large negative offsets are
injected via adjtimex.
So this patch improves the sanity check timekeeping inputs by
improving the timespec_valid() check, and then makes better use of
timespec_valid() to make sure we don't set the time to an invalid
negative value or one that overflows ktime_t.
Note: This does not protect from setting the time close to overflowing
ktime_t and then letting natural accumulation cause the overflow.
Reported-by: CAI Qian
Reported-by: Sasha Levin
Signed-off-by: John Stultz
Cc: Peter Zijlstra
Cc: Prarit Bhargava
Cc: Zhouping Liu
Cc: Ingo Molnar
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1344454580-17031-1-git-send-email-john.stu...@linaro.org
Signed-off-by: Thomas Gleixner
Cc: Linux Kernel
Signed-off-by: John Stultz
---
include/linux/ktime.h |7 ---
include/linux/time.h | 22 --
kernel/time/timekeeping.c | 15 ++-
3 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/include/linux/ktime.h b/include/linux/ktime.h
index ce59832..ecdf64e 100644
--- a/include/linux/ktime.h
+++ b/include/linux/ktime.h
@@ -58,13 +58,6 @@ union ktime {
typedef union ktime ktime_t; /* Kill this */
-#define KTIME_MAX ((s64)~((u64)1 << 63))
-#if (BITS_PER_LONG == 64)
-# define KTIME_SEC_MAX (KTIME_MAX / NSEC_PER_SEC)
-#else
-# define KTIME_SEC_MAX LONG_MAX
-#endif
-
/*
* ktime_t definitions when using the 64-bit scalar representation:
*/
diff --git a/include/linux/time.h b/include/linux/time.h
index 6e026e4..146b6f3 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -91,11 +91,29 @@ static inline struct timespec timespec_sub(struct timespec
lhs,
return ts_delta;
}
+#define KTIME_MAX ((s64)~((u64)1 << 63))
+#if (BITS_PER_LONG == 64)
+# define KTIME_SEC_MAX (KTIME_MAX / NSEC_PER_SEC)
+#else
+# define KTIME_SEC_MAX LONG_MAX
+#endif
+
/*
* Returns true if the timespec is norm, false if denorm:
*/
-#define timespec_valid(ts) \
- (((ts)->tv_sec >= 0) && (((unsigned long) (ts)->tv_nsec) <
NSEC_PER_SEC))
+static inline bool timespec_valid(const struct timespec *ts)
+{
+ /* Dates before 1970 are bogus */
+ if (ts->tv_sec < 0)
+ return false;
+ /* Can't have more nanoseconds then a second */
+ if ((unsigned long)ts->tv_nsec >= NSEC_PER_SEC)
+ return false;
+ /* Disallow values that could overflow ktime_t */
+ if ((unsigned long long)ts->tv_sec >= KTIME_SEC_MAX)
+ return false;
+ return true;
+}
extern struct timespec xtime;
extern struct timespec wall_to_monotonic;
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 3f7e53f..85d51c4 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -354,7 +354,7 @@ int do_settimeofday(struct timespec *tv)
struct timespec ts_delta;
unsigned long flags;
- if ((unsigned long)tv->tv_nsec >= NSEC_PER_SEC)
+ if (!timespec_valid(tv))
return -EINVAL;
write_seqlock_irqsave(&xtime_lock, flags);
@@ -570,7 +570,20 @@ void __init timekeeping_init(void)
struct timespec now, boot;
read_persistent_clock(&now);
+ if (!timespec_valid(&now)) {
+ printk("WARNING: Persistent clock returned invalid value!\n"
+ " Check your CMOS/BIOS settings.\n");
+ now.tv_sec = 0;
+ now.tv_nsec = 0;
+ }
+
read_boot_clock(&boot);
+ if (!timespec_valid(&boot)) {
+ printk("WARNING: Boot clock returned invalid value!\n"
+ " Check your CMOS/BIOS settings.\n");
+ boot.tv_sec = 0;
+ boot.tv_nsec = 0;
+ }
write_seqlock_irqsave(&xtime_lock, flags);
--
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 3/3] 2.6.32.y: time: Move ktime_t overflow checking into timespec_valid_strict
This is a -stable backport of cee58483cf56e0ba355fdd97ff5e8925329aa936
Andreas Bombe reported that the added ktime_t overflow checking added to
timespec_valid in commit 4e8b14526ca7 ("time: Improve sanity checking of
timekeeping inputs") was causing problems with X.org because it caused
timeouts larger then KTIME_T to be invalid.
Previously, these large timeouts would be clamped to KTIME_MAX and would
never expire, which is valid.
This patch splits the ktime_t overflow checking into a new
timespec_valid_strict function, and converts the timekeeping codes
internal checking to use this more strict function.
Reported-and-tested-by: Andreas Bombe
Cc: Zhouping Liu
Cc: Ingo Molnar
Cc: Prarit Bhargava
Cc: Thomas Gleixner
Cc: sta...@vger.kernel.org
Signed-off-by: John Stultz
Signed-off-by: Linus Torvalds
Cc: Linux Kernel
Signed-off-by: John Stultz
---
include/linux/time.h |7 +++
kernel/time/timekeeping.c |6 +++---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/include/linux/time.h b/include/linux/time.h
index 146b6f3..bc93987 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -109,6 +109,13 @@ static inline bool timespec_valid(const struct timespec
*ts)
/* Can't have more nanoseconds then a second */
if ((unsigned long)ts->tv_nsec >= NSEC_PER_SEC)
return false;
+ return true;
+}
+
+static inline bool timespec_valid_strict(const struct timespec *ts)
+{
+ if (!timespec_valid(ts))
+ return false;
/* Disallow values that could overflow ktime_t */
if ((unsigned long long)ts->tv_sec >= KTIME_SEC_MAX)
return false;
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index b451c93..3d35af3 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -354,7 +354,7 @@ int do_settimeofday(struct timespec *tv)
struct timespec ts_delta;
unsigned long flags;
- if (!timespec_valid(tv))
+ if (!timespec_valid_strict(tv))
return -EINVAL;
write_seqlock_irqsave(&xtime_lock, flags);
@@ -570,7 +570,7 @@ void __init timekeeping_init(void)
struct timespec now, boot;
read_persistent_clock(&now);
- if (!timespec_valid(&now)) {
+ if (!timespec_valid_strict(&now)) {
printk("WARNING: Persistent clock returned invalid value!\n"
" Check your CMOS/BIOS settings.\n");
now.tv_sec = 0;
@@ -578,7 +578,7 @@ void __init timekeeping_init(void)
}
read_boot_clock(&boot);
- if (!timespec_valid(&boot)) {
+ if (!timespec_valid_strict(&boot)) {
printk("WARNING: Boot clock returned invalid value!\n"
" Check your CMOS/BIOS settings.\n");
boot.tv_sec = 0;
--
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 2/3] 2.6.32.y: time: Avoid making adjustments if we haven't accumulated anything
This is a -stable backport of bf2ac312195155511a0f79325515cbb61929898a If update_wall_time() is called and the current offset isn't large enough to accumulate, avoid re-calling timekeeping_adjust which may change the clock freq and can cause 1ns inconsistencies with CLOCK_REALTIME_COARSE/CLOCK_MONOTONIC_COARSE. Signed-off-by: John Stultz Cc: Prarit Bhargava Cc: Ingo Molnar Cc: sta...@vger.kernel.org Link: http://lkml.kernel.org/r/1345595449-34965-5-git-send-email-john.stu...@linaro.org Signed-off-by: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz --- kernel/time/timekeeping.c |4 1 file changed, 4 insertions(+) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 85d51c4..b451c93 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -807,6 +807,10 @@ void update_wall_time(void) #else offset = timekeeper.cycle_interval; #endif + /* Check if there's really nothing to do */ + if (offset < timekeeper.cycle_interval) + return; + timekeeper.xtime_nsec = (s64)xtime.tv_nsec << timekeeper.shift; /* normally this loop will run just once, however in the -- 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 0/3] 3.2-stable timekeeping fixes merged in 3.6
Just wanted to send out a few timekeeping fixes that were merged in 3.6 which are appropriate for -stable. This queue backports the following fixes: - cee58483cf56e0ba355fdd97ff5e8925329aa936time: Move ktime_t overflow checking into timespec_valid_strict bf2ac312195155511a0f79325515cbb61929898atime: Avoid making adjustments if we haven't accumulated anything 4e8b14526ca7fb046a81c94002c1c43b6fdf0e9btime: Improve sanity checking of timekeeping inputs I've run these through my timetest suite w/ kvm on both i386 & x86_64. But more testing would be of course appreciated. https://github.com/johnstultz-work/timetests This is the last of what I've backported. Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel John Stultz (3): 2.6.32.y: time: Improve sanity checking of timekeeping inputs 2.6.32.y: time: Avoid making adjustments if we haven't accumulated anything 2.6.32.y: time: Move ktime_t overflow checking into timespec_valid_strict include/linux/ktime.h |7 --- include/linux/time.h | 29 +++-- kernel/time/timekeeping.c | 19 ++- 3 files changed, 45 insertions(+), 10 deletions(-) -- 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] mfd: Fix compile for twl-core.c by removing cpu_is_omap usage
* Tony Lindgren [120917 15:27]: > * Paul Walmsley [120917 15:25]: > > On Mon, 17 Sep 2012, Tony Lindgren wrote: > > > > > We need to queue this ASAP and before other patches to fix the > > > build breakage in linux next. Then you can merge in that commit > > > too, does that work for you? > > > > That's fine, we'll just need a stable commit then that the CCF patches can > > be based on. > > OK cool, will let you know that once we hear from Samuel. Care to > ack the clock related changes? > > There's pm24xx.c at least using osc_ck naming, so I added a new > alias to keep it generic for the driver instead of using omap > specific names. Pushed out now with the ack from Samuel and sent the pull request. Regards, Tony -- 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: manual merge of the sound-asoc tree with the v4l-dvb tree
Hi all,
Today's linux-next merge of the sound-asoc tree got a conflict in
arch/arm/mach-imx/mach-imx27_visstrim_m10.c between commit b6c14dc29757
("[media] Visstrim M10: Add support for Coda") from the v4l-dvb tree and
commit d41789b2660e ("ASoC: mx27vis: retrieve gpio numbers from
platform_data") from the sound-asoc tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index 821d6aa,5627229..000
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@@ -32,6 -32,8 +32,7 @@@
#include
#include
#include
-#include
+ #include
#include
#include
#include
@@@ -403,47 -436,14 +434,55 @@@ static const struct imx_ssi_platform_da
.flags = IMX_SSI_DMA | IMX_SSI_SYN,
};
+/* coda */
+
+static void __init visstrim_coda_init(void)
+{
+ struct platform_device *pdev;
+ int dma;
+
+ pdev = imx27_add_coda();
+ dma = dma_declare_coherent_memory(&pdev->dev,
+mx2_camera_base + MX2_CAMERA_BUF_SIZE,
+mx2_camera_base + MX2_CAMERA_BUF_SIZE,
+MX2_CAMERA_BUF_SIZE,
+DMA_MEMORY_MAP |
DMA_MEMORY_EXCLUSIVE);
+ if (!(dma & DMA_MEMORY_MAP))
+ return;
+}
+
+/* DMA deinterlace */
+static struct platform_device visstrim_deinterlace = {
+ .name = "m2m-deinterlace",
+ .id = 0,
+};
+
+static void __init visstrim_deinterlace_init(void)
+{
+ int ret = -ENOMEM;
+ struct platform_device *pdev = &visstrim_deinterlace;
+ int dma;
+
+ ret = platform_device_register(pdev);
+
+ dma = dma_declare_coherent_memory(&pdev->dev,
+mx2_camera_base + 2 *
MX2_CAMERA_BUF_SIZE,
+mx2_camera_base + 2 *
MX2_CAMERA_BUF_SIZE,
+MX2_CAMERA_BUF_SIZE,
+DMA_MEMORY_MAP |
DMA_MEMORY_EXCLUSIVE);
+ if (!(dma & DMA_MEMORY_MAP))
+ return;
+}
+
+
+ /* Audio */
+ static const struct snd_mx27vis_platform_data snd_mx27vis_pdata __initconst =
{
+ .amp_gain0_gpio = AMP_GAIN_0,
+ .amp_gain1_gpio = AMP_GAIN_1,
+ .amp_mutel_gpio = AMP_MUTE_SDL,
+ .amp_muter_gpio = AMP_MUTE_SDR,
+ };
+
static void __init visstrim_m10_revision(void)
{
int exp_version = 0;
pgpNNmwSxxAGg.pgp
Description: PGP signature
Re: [RFC v1 00/11] vfs: hot data tracking
On Tue, Sep 18, 2012 at 5:30 AM, Dave Chinner wrote: > On Mon, Sep 17, 2012 at 03:18:34PM +0800, zwu.ker...@gmail.com wrote: >> From: Zhi Yong Wu >> >> NOTE: >> >> The patchset is currently post out mainly to make sure >> it is going in the correct direction and hope to get some >> helpful comments from other guys. >> >> TODO List: >> >> 1.) Need to do scalability or performance tests. >> 2.) Turn some Micro into tunables >>TIME_TO_KICK, and HEAT_UPDATE_DELAY >> 3.) Rafactor hot_hash_is_aging() >>If you just made the timeout value a timespec and compared >> the _timespecs_, you would be doing a lot fewer conversions. >> 4.) Cleanup some unnecessary lock protect >> 5.) Add more comments to explain how to calc temperature > > 0) Documentation. > >> Zhi Yong Wu (11): >> vfs: introduce one structure hot_info >> vfs: introduce one rb tree - hot_inode_tree >> vfs: introduce 2 rb tree items - inode and range > > These three patches can probably just be flattened into one. > Splitting out the first two doesn't add to the clarity of the > series - add the structures in the patch that actually uses them > so we don't ahve to jump between patches to see how they are used. It make sense to me, OK, thanks. > >> vfs: add support for updating access frequency >> vfs: add one new mount option '-o hottrack' >> vfs: add init and exit support >> vfs: introduce one hash table >> vfs: enable hot data tracking >> vfs: fork one private kthread to update temperature info >> vfs: add 3 new ioctl interfaces >> vfs: add debugfs support >> >> fs/Makefile |3 +- >> fs/compat_ioctl.c |8 + >> fs/dcache.c |2 + >> fs/direct-io.c| 10 + >> fs/hot_debugfs.c | 487 ++ >> fs/hot_debugfs.h | 60 + >> fs/hot_hash.c | 369 ++ >> fs/hot_hash.h | 108 >> fs/hot_rb.c | 648 >> + >> fs/hot_rb.h | 70 + >> fs/hot_track.c| 113 >> fs/hot_track.h| 23 ++ >> fs/ioctl.c| 132 + >> fs/namespace.c| 10 + >> fs/super.c| 11 + >> include/linux/fs.h| 15 + >> include/linux/hot_track.h | 169 >> mm/filemap.c |8 + >> mm/page-writeback.c | 21 ++ >> mm/readahead.c|9 + >> 20 files changed, 2275 insertions(+), 1 deletions(-) >> create mode 100644 fs/hot_debugfs.c >> create mode 100644 fs/hot_debugfs.h >> create mode 100644 fs/hot_hash.c >> create mode 100644 fs/hot_hash.h >> create mode 100644 fs/hot_rb.c >> create mode 100644 fs/hot_rb.h >> create mode 100644 fs/hot_track.c >> create mode 100644 fs/hot_track.h >> create mode 100644 include/linux/hot_track.h > > So, 9 new files for tracking all of this? I'm not sure that so > many new files are needed - putting it all in fs/hot_tracking.[ch] > might make more sense, or if all 8 fs/hot* files remain, putting > them in their own subdirectory might be an idea (like quota). If all functions are in two files, they will be large and the logic is not so clear. so i prefer the latter. thanks. > > I'll comment on the code when I get a bit of time to look at it. Great, very look forward to your more comments. > > Cheers, > > Dave. > -- > Dave Chinner > da...@fromorbit.com -- Regards, Zhi Yong Wu -- 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/
[ANNOUNCE] 3.4.11-rt19
Dear RT Folks, I'm pleased to announce the 3.4.11-rt19 stable release. This release is just an update to the new stable 3.4.11 version and no RT specific changes have been made. You can get this release via the git tree at: git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git Head SHA1: 78475c9d785a6d7b3d110e8ebcc9a4d6f1ff473b Or to build 3.4.11-rt19 directly, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.11.xz http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.11-rt19.patch.xz Enjoy, -- 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/
Re: [PATCH v6 0/4] add syscon driver based on regmap for general registers access
On Mon, Sep 17, 2012 at 09:30:54PM +0800, Samuel Ortiz wrote: > Hi Dong, > > On Mon, Sep 17, 2012 at 06:10:29PM +0800, Dong Aisheng wrote: > > Hi Samuel, > > > > On Wed, Sep 05, 2012 at 01:54:12PM +0800, Shawn Guo wrote: > > > Hi Samuel, > > > > > > The series needs to go via mfd or arm-soc tree as a whole. In case > > > you want to take it through mfd tree, here is my ack. > > > > > > Acked-by: Shawn Guo > > > > > > Otherwise, I can take it via arm-soc tree with your ack. > > > > > Ping... > All 4 patches applied to my for-next branch. Sorry for the delay. > Thanks. Regards Dong Aisheng -- 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/7] rtc: Convert struct i2c_msg initialization to C99 format
On 17/09/12 23:58, Shubhrajyoti D wrote:
> Convert the struct i2c_msg initialization to C99 format. This makes
> maintaining and editing the code simpler. Also helps once other fields
> like transferred are added in future.
>
> Signed-off-by: Shubhrajyoti D
> ---
> drivers/rtc/rtc-isl1208.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/rtc/rtc-isl1208.c b/drivers/rtc/rtc-isl1208.c
> index dd2aeee..c3a76ae 100644
> --- a/drivers/rtc/rtc-isl1208.c
> +++ b/drivers/rtc/rtc-isl1208.c
> @@ -68,9 +68,9 @@ isl1208_i2c_read_regs(struct i2c_client *client, u8 reg, u8
> buf[],
> {
> u8 reg_addr[1] = { reg };
> struct i2c_msg msgs[2] = {
> - {client->addr, 0, sizeof(reg_addr), reg_addr}
> + {.addr = client->addr, .flags = 0, .len = sizeof(reg_addr),
> .buf = reg_addr}
Actually, I wonder if it is useful to have something like:
#define I2C_WRITE(_addr, _buf, _len) { \
.addr = _addr,\
.buf= _buf, \
.len= _len, \
}
#define I2C_READ(_addr, _buf, _len) { \
.addr = _addr,\
.buf= _buf, \
.len= _len, \
.flags = I2C_M_RD, \
}
and then write this as:
struct i2c_msg msgs[2] = {
I2C_WRITE(client->addr, reg_addr, sizeof(reg_addr)),
I2C_READ(client->addr, buf, len),
};
~Ryan
--
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] cpufreq: OMAP: Check IS_ERR() instead of NULL for omap_device_get_by_hwmod_name
omap_device_get_by_hwmod_name() returns ERR_PTR on error.
Signed-off-by: Axel Lin
---
drivers/cpufreq/omap-cpufreq.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/omap-cpufreq.c b/drivers/cpufreq/omap-cpufreq.c
index 6e22f44..65f8e9a 100644
--- a/drivers/cpufreq/omap-cpufreq.c
+++ b/drivers/cpufreq/omap-cpufreq.c
@@ -266,9 +266,9 @@ static int __init omap_cpufreq_init(void)
}
mpu_dev = omap_device_get_by_hwmod_name("mpu");
- if (!mpu_dev) {
+ if (IS_ERR(mpu_dev)) {
pr_warning("%s: unable to get the mpu device\n", __func__);
- return -EINVAL;
+ return PTR_ERR(mpu_dev);
}
mpu_reg = regulator_get(mpu_dev, "vcc");
--
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 3/7] rtc: Convert struct i2c_msg initialization to C99 format
On 17/09/12 23:58, Shubhrajyoti D wrote:
> Convert the struct i2c_msg initialization to C99 format. This makes
> maintaining and editing the code simpler. Also helps once other fields
> like transferred are added in future.
>
> Signed-off-by: Shubhrajyoti D
> ---
> drivers/rtc/rtc-isl1208.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/rtc/rtc-isl1208.c b/drivers/rtc/rtc-isl1208.c
> index dd2aeee..c3a76ae 100644
> --- a/drivers/rtc/rtc-isl1208.c
> +++ b/drivers/rtc/rtc-isl1208.c
> @@ -68,9 +68,9 @@ isl1208_i2c_read_regs(struct i2c_client *client, u8 reg, u8
> buf[],
> {
> u8 reg_addr[1] = { reg };
> struct i2c_msg msgs[2] = {
> - {client->addr, 0, sizeof(reg_addr), reg_addr}
> + {.addr = client->addr, .flags = 0, .len = sizeof(reg_addr),
> .buf = reg_addr}
> ,
Putting the whole initialiser on one line is a bit ugly. Any reason not
to expand it over multiple lines as the previous patch (and majority of
other drivers) does?
~Ryan
--
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/7] rtc: Convert struct i2c_msg initialization to C99 format
On 17/09/12 23:58, Shubhrajyoti D wrote:
> Convert the struct i2c_msg initialization to C99 format. This makes
> maintaining and editing the code simpler. Also helps once other fields
> like transferred are added in future.
>
> Signed-off-by: Shubhrajyoti D
> ---
> drivers/rtc/rtc-ds1672.c | 26 ++
> 1 files changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/rtc/rtc-ds1672.c b/drivers/rtc/rtc-ds1672.c
> index 7fa67d0..b44b2a1 100644
> --- a/drivers/rtc/rtc-ds1672.c
> +++ b/drivers/rtc/rtc-ds1672.c
> @@ -37,8 +37,18 @@ static int ds1672_get_datetime(struct i2c_client *client,
> struct rtc_time *tm)
> unsigned char buf[4];
>
> struct i2c_msg msgs[] = {
> - {client->addr, 0, 1, &addr},/* setup read ptr */
> - {client->addr, I2C_M_RD, 4, buf}, /* read date */
> + {
> + .addr = client->addr,
> + .flags = 0,
> + .len = 1,
> + .buf = &addr
> + }, /* setup read ptr */
It would be nice to tabify the fields, and put the comments on their own
lines while you are here. With the C99 format you can also omit fields
which are initialised to zero. Like this:
{
/* Setup read pointer */
.addr = client->addr,
.len= 1,
.buf= &addr,
},
~Ryan
--
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] 2.6.34.y: time: Move ktime_t overflow checking into timespec_valid_strict
This is a -stable backport of cee58483cf56e0ba355fdd97ff5e8925329aa936
Andreas Bombe reported that the added ktime_t overflow checking added to
timespec_valid in commit 4e8b14526ca7 ("time: Improve sanity checking of
timekeeping inputs") was causing problems with X.org because it caused
timeouts larger then KTIME_T to be invalid.
Previously, these large timeouts would be clamped to KTIME_MAX and would
never expire, which is valid.
This patch splits the ktime_t overflow checking into a new
timespec_valid_strict function, and converts the timekeeping codes
internal checking to use this more strict function.
Reported-and-tested-by: Andreas Bombe
Cc: Zhouping Liu
Cc: Ingo Molnar
Cc: Prarit Bhargava
Cc: Thomas Gleixner
Cc: sta...@vger.kernel.org
Signed-off-by: John Stultz
Signed-off-by: Linus Torvalds
Cc: Linux Kernel
Signed-off-by: John Stultz
---
include/linux/time.h |7 +++
kernel/time/timekeeping.c |6 +++---
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/include/linux/time.h b/include/linux/time.h
index 146b6f3..bc93987 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -109,6 +109,13 @@ static inline bool timespec_valid(const struct timespec
*ts)
/* Can't have more nanoseconds then a second */
if ((unsigned long)ts->tv_nsec >= NSEC_PER_SEC)
return false;
+ return true;
+}
+
+static inline bool timespec_valid_strict(const struct timespec *ts)
+{
+ if (!timespec_valid(ts))
+ return false;
/* Disallow values that could overflow ktime_t */
if ((unsigned long long)ts->tv_sec >= KTIME_SEC_MAX)
return false;
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index bbdad71a..21cd75b 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -343,7 +343,7 @@ int do_settimeofday(struct timespec *tv)
struct timespec ts_delta;
unsigned long flags;
- if (!timespec_valid(tv))
+ if (!timespec_valid_strict(tv))
return -EINVAL;
write_seqlock_irqsave(&xtime_lock, flags);
@@ -559,7 +559,7 @@ void __init timekeeping_init(void)
struct timespec now, boot;
read_persistent_clock(&now);
- if (!timespec_valid(&now)) {
+ if (!timespec_valid_strict(&now)) {
printk("WARNING: Persistent clock returned invalid value!\n"
" Check your CMOS/BIOS settings.\n");
now.tv_sec = 0;
@@ -567,7 +567,7 @@ void __init timekeeping_init(void)
}
read_boot_clock(&boot);
- if (!timespec_valid(&boot)) {
+ if (!timespec_valid_strict(&boot)) {
printk("WARNING: Boot clock returned invalid value!\n"
" Check your CMOS/BIOS settings.\n");
boot.tv_sec = 0;
--
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 0/3] 3.4-stable timekeeping fixes merged in 3.6
Just wanted to send out a few timekeeping fixes that were merged in 3.6 which are appropriate for -stable. This queue backports the following fixes: - cee58483cf56e0ba355fdd97ff5e8925329aa936time: Move ktime_t overflow checking into timespec_valid_strict bf2ac312195155511a0f79325515cbb61929898atime: Avoid making adjustments if we haven't accumulated anything 4e8b14526ca7fb046a81c94002c1c43b6fdf0e9btime: Improve sanity checking of timekeeping inputs I've run these through my timetest suite w/ kvm on both i386 & x86_64. But more testing would be of course appreciated. https://github.com/johnstultz-work/timetests I also have patch queues for all the -stable trees that I'll be sending out as my testing completes for those trees. Cc: Prarit Bhargava Cc: Thomas Gleixner Cc: Linux Kernel John Stultz (3): 2.6.34.y: time: Improve sanity checking of timekeeping inputs 2.6.34.y: time: Avoid making adjustments if we haven't accumulated anything 2.6.34.y: time: Move ktime_t overflow checking into timespec_valid_strict include/linux/ktime.h |7 --- include/linux/time.h | 29 +++-- kernel/time/timekeeping.c | 19 ++- 3 files changed, 45 insertions(+), 10 deletions(-) -- 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 2/3] 2.6.34.y: time: Avoid making adjustments if we haven't accumulated anything
This is a -stable backport of bf2ac312195155511a0f79325515cbb61929898a If update_wall_time() is called and the current offset isn't large enough to accumulate, avoid re-calling timekeeping_adjust which may change the clock freq and can cause 1ns inconsistencies with CLOCK_REALTIME_COARSE/CLOCK_MONOTONIC_COARSE. Signed-off-by: John Stultz Cc: Prarit Bhargava Cc: Ingo Molnar Cc: sta...@vger.kernel.org Link: http://lkml.kernel.org/r/1345595449-34965-5-git-send-email-john.stu...@linaro.org Signed-off-by: Thomas Gleixner Cc: Linux Kernel Signed-off-by: John Stultz --- kernel/time/timekeeping.c |4 1 file changed, 4 insertions(+) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 0d59077..bbdad71a 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -849,6 +849,10 @@ void update_wall_time(void) #else offset = timekeeper.cycle_interval; #endif + /* Check if there's really nothing to do */ + if (offset < timekeeper.cycle_interval) + return; + timekeeper.xtime_nsec = (s64)xtime.tv_nsec << timekeeper.shift; /* -- 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 1/3] 2.6.34.y: time: Improve sanity checking of timekeeping inputs
This is a -stable backport of 4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b
Unexpected behavior could occur if the time is set to a value large
enough to overflow a 64bit ktime_t (which is something larger then the
year 2262).
Also unexpected behavior could occur if large negative offsets are
injected via adjtimex.
So this patch improves the sanity check timekeeping inputs by
improving the timespec_valid() check, and then makes better use of
timespec_valid() to make sure we don't set the time to an invalid
negative value or one that overflows ktime_t.
Note: This does not protect from setting the time close to overflowing
ktime_t and then letting natural accumulation cause the overflow.
Reported-by: CAI Qian
Reported-by: Sasha Levin
Signed-off-by: John Stultz
Cc: Peter Zijlstra
Cc: Prarit Bhargava
Cc: Zhouping Liu
Cc: Ingo Molnar
Cc: sta...@vger.kernel.org
Link:
http://lkml.kernel.org/r/1344454580-17031-1-git-send-email-john.stu...@linaro.org
Signed-off-by: Thomas Gleixner
Cc: Linux Kernel
Signed-off-by: John Stultz
---
include/linux/ktime.h |7 ---
include/linux/time.h | 22 --
kernel/time/timekeeping.c | 15 ++-
3 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/include/linux/ktime.h b/include/linux/ktime.h
index ce59832..ecdf64e 100644
--- a/include/linux/ktime.h
+++ b/include/linux/ktime.h
@@ -58,13 +58,6 @@ union ktime {
typedef union ktime ktime_t; /* Kill this */
-#define KTIME_MAX ((s64)~((u64)1 << 63))
-#if (BITS_PER_LONG == 64)
-# define KTIME_SEC_MAX (KTIME_MAX / NSEC_PER_SEC)
-#else
-# define KTIME_SEC_MAX LONG_MAX
-#endif
-
/*
* ktime_t definitions when using the 64-bit scalar representation:
*/
diff --git a/include/linux/time.h b/include/linux/time.h
index 6e026e4..146b6f3 100644
--- a/include/linux/time.h
+++ b/include/linux/time.h
@@ -91,11 +91,29 @@ static inline struct timespec timespec_sub(struct timespec
lhs,
return ts_delta;
}
+#define KTIME_MAX ((s64)~((u64)1 << 63))
+#if (BITS_PER_LONG == 64)
+# define KTIME_SEC_MAX (KTIME_MAX / NSEC_PER_SEC)
+#else
+# define KTIME_SEC_MAX LONG_MAX
+#endif
+
/*
* Returns true if the timespec is norm, false if denorm:
*/
-#define timespec_valid(ts) \
- (((ts)->tv_sec >= 0) && (((unsigned long) (ts)->tv_nsec) <
NSEC_PER_SEC))
+static inline bool timespec_valid(const struct timespec *ts)
+{
+ /* Dates before 1970 are bogus */
+ if (ts->tv_sec < 0)
+ return false;
+ /* Can't have more nanoseconds then a second */
+ if ((unsigned long)ts->tv_nsec >= NSEC_PER_SEC)
+ return false;
+ /* Disallow values that could overflow ktime_t */
+ if ((unsigned long long)ts->tv_sec >= KTIME_SEC_MAX)
+ return false;
+ return true;
+}
extern struct timespec xtime;
extern struct timespec wall_to_monotonic;
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 156fd67..0d59077 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -343,7 +343,7 @@ int do_settimeofday(struct timespec *tv)
struct timespec ts_delta;
unsigned long flags;
- if ((unsigned long)tv->tv_nsec >= NSEC_PER_SEC)
+ if (!timespec_valid(tv))
return -EINVAL;
write_seqlock_irqsave(&xtime_lock, flags);
@@ -559,7 +559,20 @@ void __init timekeeping_init(void)
struct timespec now, boot;
read_persistent_clock(&now);
+ if (!timespec_valid(&now)) {
+ printk("WARNING: Persistent clock returned invalid value!\n"
+ " Check your CMOS/BIOS settings.\n");
+ now.tv_sec = 0;
+ now.tv_nsec = 0;
+ }
+
read_boot_clock(&boot);
+ if (!timespec_valid(&boot)) {
+ printk("WARNING: Boot clock returned invalid value!\n"
+ " Check your CMOS/BIOS settings.\n");
+ boot.tv_sec = 0;
+ boot.tv_nsec = 0;
+ }
write_seqlock_irqsave(&xtime_lock, flags);
--
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: section mismatch for acpi_unmap_lsapic()
At 09/17/2012 07:07 PM, Ingo Molnar Wrote: > > * Jerry Snitselaar wrote: > >> Commit 13ad20c1 "x86 cpu_hotplug: unmap cpu2node when the cpu is >> hotremoved" in linux-next added code to acpi_unmap_lsapic() that >> causes section mismatch warnings: >> >> WARNING: vmlinux.o(.text+0x694f2): Section mismatch in reference from the >> function acpi_unmap_lsapic() >>to the function .cpuinit.text:numa_clear_node() >> WARNING: vmlinux.o(.text+0x694eb): Section mismatch in reference from the >> function acpi_unmap_lsapic() >>to the variable .cpuinit.data:__apicid_to_node >> >> >> Does acpi_unmap_lsapic() need a wrapper like the one that was made for >> acpi_map_lsapic() or can it just be annotated __ref ? I guess my >> question is would be there be a reason that the wrapper was created >> for acpi_map_lsapic() instead of just annotating __ref besides >> allowing the code for _apic_map_lsapic() to be dropped when >> HOTPLUG_CPU wasn't configured? > > That commit comes from -mm AFAICS. Involved parties Cc:-ed. Sorry for introducing this warning. numa_clear_node() is in cpuinit section, and it will be called in acpi_unmap_lsapic(), so I agree to add __ref to this function. Should I need to post another patch to fix it or just update the patch? Thanks Wen Congyang > > Thanks, > > Ingo > -- 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] numa: don't check if node is NUMA_NO_NODE
At 09/05/2012 07:11 AM, Andrew Morton Wrote: > On Mon, 03 Sep 2012 16:12:12 +0800 > Wen Congyang wrote: > >> If we don't debug per_cpu maps, the cpu's node is stored in per_cpu variable >> numa_node. If node is NUMA_NO_NODE, it means the caller want to clear the >> cpu's node. So we should also call set_cpu_numa_node() in this case. > > The changelog is missing important information. > > What is the runtime effect of the patch? In other words, please fully > describe the runtime effects of the bug which the patch fixed. > > Please always provide this information. It will help others decide > which kernel version(s) should be patched, and will help the > maintainers of other kernel trees (especially vendor trees) to work out > whether they should backport the fix into their kernels. Sorry for later reply. I found this bug when I try to fix a bug by patch 1/2 (The bug is descriptioned in patch 1/2). Thanks Wen Congyang > >> --- a/arch/x86/mm/numa.c >> +++ b/arch/x86/mm/numa.c >> @@ -97,8 +97,7 @@ void __cpuinit numa_set_node(int cpu, int node) >> #endif >> per_cpu(x86_cpu_to_node_map, cpu) = node; >> >> -if (node != NUMA_NO_NODE) >> -set_cpu_numa_node(cpu, node); >> +set_cpu_numa_node(cpu, node); >> } >> >> void __cpuinit numa_clear_node(int cpu) > > -- 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] drivers/target/target_core_configfs.c: fix error return code
On Mon, 2012-09-17 at 20:05 +0200, Peter Senna Tschudin wrote:
> From: Peter Senna Tschudin
>
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> Signed-off-by: Peter Senna Tschudin
> ---
This bug-fix patch with a slightly more verbose commit log has been
applied to target-pending/for-next, along with a CC' to stable so it
get's picked up for v3.6.1 + friends.
Thanks Peter!
--nab
> drivers/target/target_core_configfs.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/target/target_core_configfs.c
> b/drivers/target/target_core_configfs.c
> index a1b4171..015f5be 100644
> --- a/drivers/target/target_core_configfs.c
> +++ b/drivers/target/target_core_configfs.c
> @@ -3124,6 +3124,7 @@ static int __init target_core_init_configfs(void)
> GFP_KERNEL);
> if (!target_cg->default_groups) {
> pr_err("Unable to allocate target_cg->default_groups\n");
> + ret = -ENOMEM;
> goto out_global;
> }
>
> @@ -3139,6 +3140,7 @@ static int __init target_core_init_configfs(void)
> GFP_KERNEL);
> if (!hba_cg->default_groups) {
> pr_err("Unable to allocate hba_cg->default_groups\n");
> + ret = -ENOMEM;
> goto out_global;
> }
> config_group_init_type_name(&alua_group,
> @@ -3154,6 +3156,7 @@ static int __init target_core_init_configfs(void)
> GFP_KERNEL);
> if (!alua_cg->default_groups) {
> pr_err("Unable to allocate alua_cg->default_groups\n");
> + ret = -ENOMEM;
> goto out_global;
> }
>
> @@ -3165,14 +3168,17 @@ static int __init target_core_init_configfs(void)
>* Add core/alua/lu_gps/default_lu_gp
>*/
> lu_gp = core_alua_allocate_lu_gp("default_lu_gp", 1);
> - if (IS_ERR(lu_gp))
> + if (IS_ERR(lu_gp)) {
> + ret = -ENOMEM;
> goto out_global;
> + }
>
> lu_gp_cg = &alua_lu_gps_group;
> lu_gp_cg->default_groups = kzalloc(sizeof(struct config_group) * 2,
> GFP_KERNEL);
> if (!lu_gp_cg->default_groups) {
> pr_err("Unable to allocate lu_gp_cg->default_groups\n");
> + ret = -ENOMEM;
> goto out_global;
> }
>
--
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] mfd: Use devm_* APIs for mc13xxx: remove leftover kfree
2012/9/18 Andreas Pretzsch : > commit e7c706b1e5ccf28eaaf76c7a4613e80b0ca52863 migrated the allocation > of struct mc13xxx to devm_* functions, but left a kfree(mc13xxx) in the > mc13xxx_common_init error path. Remove it to prevent memory corruption. > > Signed-off-by: Andreas Pretzsch Reviewed-by: Axel Lin -- 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: linux-next: build failure after merge of the target-updates tree
On Mon, 2012-09-17 at 13:41 +1000, Stephen Rothwell wrote:
> Hi Nicholas,
>
> After merging the target-updates tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/target/target_core_transport.c: In function
> 'transport_get_sense_buffer':
> drivers/target/target_core_transport.c:582:22: error: 'struct
> target_core_fabric_ops' has no member named 'set_fabric_sense_len'
>
> I can only assume that this has been caused by the (largish) changes that
> went into Linus' tree recently conflicting with changes in the
> target-updates tree.
>
> I have dropped the target-updates tree for today. Please sort the mess out.
Hi Stephen,
Whoops, sorry about that..
So target-pending/for-next has been rebased + now includes the following
change to Roland's original patch that drops TFO->set_fabric_sense_len
core+fabric usage for v3.7-rc1. As reported, this ended up conflicting
with Paolo's recent pSCSI backend sense data handling bug-fixes that
went in for v3.6-rc6.
So with the following, for-next should be looking as expected now.
Thanks!
--nab
diff --git a/drivers/target/target_core_transport.c
b/drivers/target/target_core_transport.c
index fd0d0f0..d6d4844 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -567,9 +567,7 @@ static void target_complete_failure_work(struct work_struct
*work)
*/
static unsigned char *transport_get_sense_buffer(struct se_cmd *cmd)
{
- unsigned char *buffer = cmd->sense_buffer;
struct se_device *dev = cmd->se_dev;
- u32 offset = 0;
WARN_ON(!cmd->se_lun);
@@ -579,14 +577,11 @@ static unsigned char *transport_get_sense_buffer(struct
se_cmd *cmd)
if (cmd->se_cmd_flags & SCF_SENT_CHECK_CONDITION)
return NULL;
- offset = cmd->se_tfo->set_fabric_sense_len(cmd, TRANSPORT_SENSE_BUFFER);
-
- /* Automatically padded */
- cmd->scsi_sense_length = TRANSPORT_SENSE_BUFFER + offset;
+ cmd->scsi_sense_length = TRANSPORT_SENSE_BUFFER;
pr_debug("HBA_[%u]_PLUG[%s]: Requesting sense for SAM STATUS: 0x%02x\n",
dev->se_hba->hba_id, dev->transport->name, cmd->scsi_status);
- return &buffer[offset];
+ return cmd->sense_buffer;
}
void target_complete_cmd(struct se_cmd *cmd, u8 scsi_status)
--
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/
