Re: [PATCH v2 2/2] watchdog: imx2_wdt: add set_pretimeout interface
On 11/02/2015 10:11 PM, Robin Gong wrote:
Enable set_pretimeout interface and trigger the pretimeout interrupt before
watchdog timeout event happen.
Signed-off-by: Robin Gong
---
drivers/watchdog/imx2_wdt.c | 58 -
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 0bb1a1d..bd42857 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -52,12 +53,18 @@
#define IMX2_WDT_WRSR 0x04/* Reset Status Register */
#define IMX2_WDT_WRSR_TOUT(1 << 1) /* -> Reset due to Timeout */
+#define IMX2_WDT_WICR 0x06/*Interrupt Control Register*/
+#define IMX2_WDT_WICR_WIE (1 << 15) /* -> Interrupt Enable */
+#define IMX2_WDT_WICR_WTIS (1 << 14) /* -> Interrupt Status */
+#define IMX2_WDT_WICR_WICT (0xFF) /* Watchdog Interrupt Timeout */
Unnecessary ( )
+
#define IMX2_WDT_WMCR 0x08/* Misc Register */
#define IMX2_WDT_MAX_TIME 128
#define IMX2_WDT_DEFAULT_TIME 60 /* in seconds */
#define WDOG_SEC_TO_COUNT(s) ((s * 2 - 1) << 8)
+#define WDOG_SEC_TO_PRECOUNT(s)((s) * 2) /* set WDOG pre timeout
count*/
struct imx2_wdt_device {
struct clk *clk;
@@ -80,7 +87,8 @@ MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds
(default="
static const struct watchdog_info imx2_wdt_info = {
.identity = "imx2+ watchdog",
- .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE,
+ .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE
+ | WDIOF_PRETIMEOUT,
};
static int imx2_restart_handler(struct notifier_block *this, unsigned long
mode,
@@ -207,12 +215,49 @@ static inline void imx2_wdt_ping_if_active(struct
watchdog_device *wdog)
}
}
+static int imx2_wdt_set_pretimeout(struct watchdog_device *wdog,
+ unsigned int new_timeout)
+{
+ struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+ u32 val;
+
+ regmap_read(wdev->regmap, IMX2_WDT_WICR, );
+ /* set the new pre-timeout value in the WSR */
+ val &= ~IMX2_WDT_WICR_WICT;
+ val |= WDOG_SEC_TO_PRECOUNT(new_timeout);
Looking into this, I think we need more information in the first patch.
Specifically, we need a value for max_pretimeout and validate it
(new_timeout must be smaller than 128 to avoid overflows, independent
of the maximum timeout).
+
+ regmap_write(wdev->regmap, IMX2_WDT_WICR, val | IMX2_WDT_WICR_WIE);
+
+ wdog->pretimeout = new_timeout;
+
+ return 0;
+}
+
+static irqreturn_t imx2_wdt_isr(int irq, void *dev_id)
+{
+ struct platform_device *pdev = dev_id;
+ struct watchdog_device *wdog = platform_get_drvdata(pdev);
+ struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+ u32 val;
+
+ regmap_read(wdev->regmap, IMX2_WDT_WICR, );
+ if (val & IMX2_WDT_WICR_WTIS) {
+ /*clear interrupt status bit*/
+ regmap_write(wdev->regmap, IMX2_WDT_WICR, val);
+ panic("pre-timeout:%d, %d Seconds remained\n", wdog->pretimeout,
"seconds" - no capital 'S'.
+ wdog->timeout - wdog->pretimeout);
+ }
+
+ return IRQ_HANDLED;
+}
+
static const struct watchdog_ops imx2_wdt_ops = {
.owner = THIS_MODULE,
.start = imx2_wdt_start,
.stop = imx2_wdt_stop,
.ping = imx2_wdt_ping,
.set_timeout = imx2_wdt_set_timeout,
+ .set_pretimeout = imx2_wdt_set_pretimeout,
};
static const struct regmap_config imx2_wdt_regmap_config = {
@@ -229,6 +274,7 @@ static int __init imx2_wdt_probe(struct platform_device
*pdev)
struct resource *res;
void __iomem *base;
int ret;
+ int irq;
u32 val;
wdev = devm_kzalloc(>dev, sizeof(*wdev), GFP_KERNEL);
@@ -294,6 +340,16 @@ static int __init imx2_wdt_probe(struct platform_device
*pdev)
goto disable_clk;
}
+ irq = platform_get_irq(pdev, 0);
+ if (irq > 0) {
+ ret = devm_request_irq(>dev, irq, imx2_wdt_isr, 0,
+ dev_name(>dev), pdev);
+ if (ret) {
+ dev_err(>dev, "can't get irq %d\n", irq);
+ goto disable_clk;
+ }
+ }
+
wdev->restart_handler.notifier_call = imx2_restart_handler;
wdev->restart_handler.priority = 128;
ret = register_restart_handler(>restart_handler);
--
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-next rfc V2 0/2] basic busy polling support for vhost_net
On 10/30/2015 07:58 PM, Jason Wang wrote: > > On 10/29/2015 04:45 PM, Jason Wang wrote: >> Hi all: >> >> This series tries to add basic busy polling for vhost net. The idea is >> simple: at the end of tx processing, busy polling for new tx added >> descriptor and rx receive socket for a while. The maximum number of >> time (in us) could be spent on busy polling was specified through >> module parameter. >> >> Test were done through: >> >> - 50 us as busy loop timeout >> - Netperf 2.6 >> - Two machines with back to back connected mlx4 >> - Guest with 8 vcpus and 1 queue >> >> Result shows very huge improvement on both tx (at most 158%) and rr >> (at most 53%) while rx is as much as in the past. Most cases the cpu >> utilization is also improved: >> > Just notice there's something wrong in the setup. So the numbers are > incorrect here. Will re-run and post correct number here. > > Sorry. Here's the updated testing result: 1) 1 vcpu 1 queue: TCP_RR size/session/+thu%/+normalize% 1/ 1/0%/ -25% 1/50/ +12%/0% 1/ 100/ +12%/ +1% 1/ 200/ +9%/ -1% 64/ 1/ +3%/ -21% 64/50/ +8%/0% 64/ 100/ +7%/0% 64/ 200/ +9%/0% 256/ 1/ +1%/ -25% 256/50/ +7%/ -2% 256/ 100/ +6%/ -2% 256/ 200/ +4%/ -2% 512/ 1/ +2%/ -19% 512/50/ +5%/ -2% 512/ 100/ +3%/ -3% 512/ 200/ +6%/ -2% 1024/ 1/ +2%/ -20% 1024/50/ +3%/ -3% 1024/ 100/ +5%/ -3% 1024/ 200/ +4%/ -2% Guest RX size/session/+thu%/+normalize% 64/ 1/ -4%/ -5% 64/ 4/ -3%/ -10% 64/ 8/ -3%/ -5% 512/ 1/ +15%/ +1% 512/ 4/ -5%/ -5% 512/ 8/ -2%/ -4% 1024/ 1/ -5%/ -16% 1024/ 4/ -2%/ -5% 1024/ 8/ -6%/ -6% 2048/ 1/ +10%/ +5% 2048/ 4/ -8%/ -4% 2048/ 8/ -1%/ -4% 4096/ 1/ -9%/ -11% 4096/ 4/ +1%/ -1% 4096/ 8/ +1%/0% 16384/ 1/ +20%/ +11% 16384/ 4/0%/ -3% 16384/ 8/ +1%/0% 65535/ 1/ +36%/ +13% 65535/ 4/ -10%/ -9% 65535/ 8/ -3%/ -2% Guest TX size/session/+thu%/+normalize% 64/ 1/ -7%/ -16% 64/ 4/ -14%/ -23% 64/ 8/ -9%/ -20% 512/ 1/ -62%/ -56% 512/ 4/ -62%/ -56% 512/ 8/ -61%/ -53% 1024/ 1/ -66%/ -61% 1024/ 4/ -77%/ -73% 1024/ 8/ -73%/ -67% 2048/ 1/ -74%/ -75% 2048/ 4/ -77%/ -74% 2048/ 8/ -72%/ -68% 4096/ 1/ -65%/ -68% 4096/ 4/ -66%/ -63% 4096/ 8/ -62%/ -57% 16384/ 1/ -25%/ -28% 16384/ 4/ -28%/ -17% 16384/ 8/ -24%/ -10% 65535/ 1/ -17%/ -14% 65535/ 4/ -22%/ -5% 65535/ 8/ -25%/ -9% - obvious improvement on TCP_RR (at most 12%) - improvement on guest RX - huge decreasing on Guest TX (at most -75%), this is probably because virtio-net driver suffers from buffer bloat by orphaning skb before transmission. The faster vhost it is, the smaller packet it could produced. To reduce the impact on this, turning off gso in guest can result the following result: size/session/+thu%/+normalize% 64/ 1/ +3%/ -11% 64/ 4/ +4%/ -10% 64/ 8/ +4%/ -10% 512/ 1/ +2%/ +5% 512/ 4/0%/ -1% 512/ 8/0%/0% 1024/ 1/ +11%/0% 1024/ 4/0%/ -1% 1024/ 8/ +3%/ +1% 2048/ 1/ +4%/ -1% 2048/ 4/ +8%/ +3% 2048/ 8/0%/ -1% 4096/ 1/ +4%/ -1% 4096/ 4/ +1%/0% 4096/ 8/ +2%/0% 16384/ 1/ +2%/ -2% 16384/ 4/ +3%/ +1% 16384/ 8/0%/ -1% 65535/ 1/ +9%/ +7% 65535/ 4/0%/ -3% 65535/ 8/ -1%/ -1% 2) 8 vcpus 1 queue: TCP_RR size/session/+thu%/+normalize% 1/ 1/ +5%/ -14% 1/50/ +2%/ +1% 1/ 100/0%/ -1% 1/ 200/0%/0% 64/ 1/0%/ -25% 64/50/ +5%/ +5% 64/ 100/0%/0% 64/ 200/0%/ -1% 256/ 1/0%/ -30% 256/50/0%/0% 256/ 100/ -2%/ -2% 256/ 200/0%/0% 512/ 1/ +1%/ -23% 512/50/ +1%/ +1% 512/ 100/ +1%/0% 512/ 200/ +1%/ +1% 1024/ 1/ +1%/ -23% 1024/50/ +5%/ +5% 1024/ 100/0%/ -1% 1024/ 200/0%/0% Guest RX size/session/+thu%/+normalize% 64/ 1/ +1%/ +1% 64/ 4/ -2%/ +1% 64/ 8/ +6%/ +19% 512/ 1/ +5%/ -7% 512/ 4/ -4%/ -4% 512/ 8/0%/0% 1024/ 1/ +1%/ +2% 1024/ 4/ -2%/ -2% 1024/ 8/ -1%/ +7% 2048/ 1/ +8%/ -2% 2048/ 4/0%/ +5% 2048/ 8/ -1%/ +13% 4096/ 1/ -1%/ +2% 4096/ 4/0%/ +6% 4096/ 8/ -2%/ +15% 16384/ 1/ -1%/0% 16384/ 4/ -2%/ -1% 16384/ 8/ -2%/ +2% 65535/ 1/ -2%/0% 65535/ 4/ -3%/ -3% 65535/ 8/ -2%/ +2% Guest TX size/session/+thu%/+normalize% 64/ 1/ +6%/
Re: perf, tools: Refactor and support interval and CSV metrics v6
On Mon, Nov 02, 2015 at 05:50:19PM -0800, Andi Kleen wrote: > [v4: Addressed all review feedback.] > [v3: Addressed all review feedback. Update manpage for CSV. Various changes > (see individual patches). Remove some more redundant code > in printout callers.] > [v2: Addressed (near) all review feedback. No manpage updates so far. > Add support for --per-core metrics. Various cleanups.] > [v3: Everything compiles again. Some more cleanups.] > [v4: Split up abstract metrics patch into two. Fix bug with earlier > patch already enabling metrics for CSV/interval. Minor cleanups. > Man page is included] > [v5: Fix mainly bisect problems. No regressions introduced by one > patch and fixed again later. Some minor fixes in addition] > [v6: Fix running/noise printing patch.] I like the list.. starting with v4 goes down to v2 and raise again to v6 ;-) I'll try to check it this week thanks, jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/3] dmaselftest: add memcpy selftest support functions
On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul wrote: > On Mon, Nov 02, 2015 at 11:18:37PM -0500, Sinan Kaya wrote: >> >> >> On 11/2/2015 11:15 PM, Vinod Koul wrote: >> >On Mon, Nov 02, 2015 at 01:07:38AM -0500, Sinan Kaya wrote: >> >>This patch adds supporting utility functions >> >>for selftest. The intention is to share the self >> >>test code between different drivers. >> >> >> >>Supported test cases include: >> >>1. dma_map_single >> >>2. streaming DMA >> >>3. coherent DMA >> >>4. scatter-gather DMA >> > >> >This seems quite similar to dmatest, any reason why you cannot use/enhance >> >that? >> > >> Dmatest is a standalone kernel module intended for stress testing >> DMA engines from userspace with N number of threads and M size >> combinations etc. >> >> This one; on the other hand, is selftest to verify hardware is >> working as expected during power up. >> >> Almost all DMA engine drivers come with some sort of selftest code >> called from probe. I followed the same design pattern. > > which ones ? > >> >> I think the goal is to remove the duplicate self test code in all >> drivers over time. > > and what prevents us from having common selftest plus dmatest code. Most of > the code here to do selftest is _same_ dmaengine routine code used in > dmatest > > We can have common code which is used for dmatest as well as selftest. I do > not want to see same code duplicated.. Originally ioatdma and iop-adma had local self tests before Haavard created dmatest. I agree having the drivers also do a test each boot is redundant, but then again dmatest is not automatic and I saw the local self test catch an interrupt setup regression. Maybe you could arrange for drivers to do a quick autorun through dmatest on load if dmatest is enabled, but otherwise load without testing? Just my 2 cents from a dmaengine spectator. -- 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] perf sched latency: Fix removed thread issue
On Mon, Nov 02, 2015 at 07:53:53PM -0300, Arnaldo Carvalho de Melo wrote: > Em Mon, Nov 02, 2015 at 12:10:25PM +0100, Jiri Olsa escreveu: > > If machine's thread gets excited (EXIT event is received), > > we set thread->dead = true and it is later on removed from > > machine's tree if the pid is reused on new thread. > > > The latency subcommand holds tree of working atoms sorted > > by thread's pid/tid. If there's new thread with same pid > > Humm, wher is the latency subcommand handling the EXIT event? > > I see: > >perf_sched__lat > perf_sched__read_events >session = perf_session__new(, false, >tool); >perf_session__process_events(session) > > And sched->tool->exit() is not set, which will make > perf_session__process_events(), when calling perf_tool__fill_defaults() > set it to process_event_stub() which will do nothing for > PERF_RECORD_EXIT events, no? yep, latency command does not handle EXIT event, but the thread is removed via FORK event.. the first changelog paragraph might be a little misleading sorry ;-) could you please change it to: --- If machine's thread gets excited (EXIT event is received), we set thread->dead = true and it is later on removed from machine's tree if the pid is reused on new thread. We dont handle EXIT command in 'perf sched latency', however the old thread is removed anyway when FORK event is received for new thrad with same pid/tid. --- thanks, jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] watchdog: add WDIOC_SETPRETIMEOUT and WDIOC_GETPRETIMEOUT
On 11/02/2015 10:11 PM, Robin Gong wrote:
Since the watchdog common framework centrialize the IOCTL interfaces of
device driver now, the SETPRETIMEOUT and GETPRETIMEOUT need to be added
in the common code.
Signed-off-by: Robin Gong
---
It would help if you could document the changes made here.
drivers/watchdog/watchdog_dev.c | 37 +
include/linux/watchdog.h| 10 ++
2 files changed, 47 insertions(+)
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 6aaefba..f4a02e5 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -218,6 +218,37 @@ out_timeout:
}
/*
+ * watchdog_set_pretimeout: set the watchdog timer pretimeout
+ * @wddev: the watchdog device to set the timeout for
+ * @timeout: pretimeout to set in seconds
+ */
+
+static int watchdog_set_pretimeout(struct watchdog_device *wddev,
+ unsigned int timeout)
+{
+ int err;
+
+ if (!wddev->ops->set_pretimeout ||
+ !(wddev->info->options & WDIOF_PRETIMEOUT))
+ return -EOPNOTSUPP;
+ if (watchdog_pretimeout_invalid(wddev, timeout))
+ return -EINVAL;
+
+ mutex_lock(>lock);
+
+ if (test_bit(WDOG_UNREGISTERED, >status)) {
+ err = -ENODEV;
+ goto out_timeout;
+ }
+
+ err = wddev->ops->set_pretimeout(wddev, timeout);
+
+out_timeout:
+ mutex_unlock(>lock);
+ return err;
+}
+
+/*
*watchdog_get_timeleft: wrapper to get the time left before a reboot
*@wddev: the watchdog device to get the remaining time from
*@timeleft: the time that's left
@@ -393,6 +424,12 @@ static long watchdog_ioctl(struct file *file, unsigned int
cmd,
if (err)
return err;
return put_user(val, p);
+ case WDIOC_SETPRETIMEOUT:
+ if (get_user(val, p))
+ return -EFAULT;
+ return watchdog_set_pretimeout(wdd, val);
+ case WDIOC_GETPRETIMEOUT:
+ return put_user(wdd->pretimeout, p);
default:
return -ENOTTY;
}
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index d74a0e9..f936152 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -25,6 +25,7 @@ struct watchdog_device;
* @ping: The routine that sends a keepalive ping to the watchdog device.
* @status: The routine that shows the status of the watchdog device.
* @set_timeout:The routine for setting the watchdog devices timeout value.
+ * @set_pretimeout:The routine for setting the watchdog devices pretimeout.
* @get_timeleft:The routine that get's the time that's left before a reset.
* @ref: The ref operation for dyn. allocated watchdog_device structs
* @unref:The unref operation for dyn. allocated watchdog_device structs
@@ -44,6 +45,7 @@ struct watchdog_ops {
int (*ping)(struct watchdog_device *);
unsigned int (*status)(struct watchdog_device *);
int (*set_timeout)(struct watchdog_device *, unsigned int);
+ int (*set_pretimeout)(struct watchdog_device *, unsigned int);
unsigned int (*get_timeleft)(struct watchdog_device *);
void (*ref)(struct watchdog_device *);
void (*unref)(struct watchdog_device *);
@@ -86,6 +88,7 @@ struct watchdog_device {
const struct watchdog_ops *ops;
unsigned int bootstatus;
unsigned int timeout;
+ unsigned int pretimeout;
This new variable also needs to be added to and documented in
Documentation/watchdog/watchdog-kernel-api.txt.
Thanks,
Guenter
unsigned int min_timeout;
unsigned int max_timeout;
void *driver_data;
@@ -123,6 +126,13 @@ static inline bool watchdog_timeout_invalid(struct
watchdog_device *wdd, unsigne
(t < wdd->min_timeout || t > wdd->max_timeout));
}
+/* Use the following function to check if a pretimeout value is invalid */
+static inline bool watchdog_pretimeout_invalid(struct watchdog_device *wdd,
+ unsigned int t)
+{
+ return wdd->timeout && t >= wdd->timeout;
+}
+
/* Use the following functions to manipulate watchdog driver specific data */
static inline void watchdog_set_drvdata(struct watchdog_device *wdd, void
*data)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] keys, trusted: select the hash algorithm
On Mon, Nov 02, 2015 at 07:16:49AM -0500, Mimi Zohar wrote:
> On Fri, 2015-10-30 at 13:35 +0200, Jarkko Sakkinen wrote:
>
> > @@ -787,6 +791,20 @@ static int getoptions(char *c, struct
> > trusted_key_payload *pay,
> > return -EINVAL;
> > opt->pcrlock = lock;
> > break;
> > + case Opt_hash:
> > + for (i = 0; i < HASH_ALGO__LAST; i++) {
> > + if (!strcmp(args[0].from, hash_algo_name[i])) {
> > + opt->hash = i;
> > + break;
> > + }
> > + }
> > + res = tpm_is_tpm2(TPM_ANY_NUM);
>
> While looking at this, I wanted to verify that chips are still added to
> the tail of the tpm_chip_list. Unfortunately, commit "afb5abc tpm:
> two-phase chip management functions" reverted David Howell's commit
> "770ab65 TPM: Add new TPMs to the tail of the list to prevent
> inadvertent change of dev".
>
> > + if (res < 0)
> > + return res;
> > + if (i == HASH_ALGO__LAST ||
> > + (!res && i != HASH_ALGO_SHA1))
> > + return -EINVAL;
> > + break;
>
> If the first TPM registered is a TPM 1.2, then changing the default TPM
> 2.0 hash algorithm will fail.
Now that we are going fix this issue in 4.3 and 4.4 do you find this
patch otherwise acceptable?
PS. In other options that we don't support in TPM2 I'm planning to
submit a fix that they will return -EINVAL (like pcrinfo).
> Mimi
/Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 13/15] block, dax: make dax mappings opt-in by default
On Mon, Nov 2, 2015 at 4:32 PM, Dave Chinner wrote:
> On Sun, Nov 01, 2015 at 11:30:53PM -0500, Dan Williams wrote:
>> Now that we have the ability to dynamically enable DAX for a raw block
>> inode, make the behavior opt-in by default. DAX does not have feature
>> parity with pagecache backed mappings, so applications should knowingly
>> enable DAX semantics.
>>
>> Note, this is only for mappings returned to userspace. For the
>> synchronous usages of DAX, dax_do_io(), there is no semantic difference
>> with the bio submission path, so that path remains default enabled.
>>
>> Signed-off-by: Dan Williams
>> ---
>> block/ioctl.c |3 +--
>> fs/block_dev.c | 33 +++--
>> include/linux/fs.h |8
>> 3 files changed, 32 insertions(+), 12 deletions(-)
>>
>> diff --git a/block/ioctl.c b/block/ioctl.c
>> index 205d57612fbd..c4c3a09d9ca9 100644
>> --- a/block/ioctl.c
>> +++ b/block/ioctl.c
>> @@ -298,13 +298,12 @@ static inline int is_unrecognized_ioctl(int ret)
>> #ifdef CONFIG_FS_DAX
>> static int blkdev_set_dax(struct block_device *bdev, int n)
>> {
>> - struct gendisk *disk = bdev->bd_disk;
>> int rc = 0;
>>
>> if (n)
>> n = S_DAX;
>>
>> - if (n && !disk->fops->direct_access)
>> + if (n && !blkdev_dax_capable(bdev))
>> return -ENOTTY;
>>
>> mutex_lock(>bd_inode->i_mutex);
>> diff --git a/fs/block_dev.c b/fs/block_dev.c
>> index 13ce6d0ff7f6..ee34a31e6fa4 100644
>> --- a/fs/block_dev.c
>> +++ b/fs/block_dev.c
>> @@ -152,16 +152,37 @@ static struct inode *bdev_file_inode(struct file *file)
>> return file->f_mapping->host;
>> }
>>
>> +#ifdef CONFIG_FS_DAX
>> +bool blkdev_dax_capable(struct block_device *bdev)
>> +{
>> + struct gendisk *disk = bdev->bd_disk;
>> +
>> + if (!disk->fops->direct_access)
>> + return false;
>> +
>> + /*
>> + * If the partition is not aligned on a page boundary, we can't
>> + * do dax I/O to it.
>> + */
>> + if ((bdev->bd_part->start_sect % (PAGE_SIZE / 512))
>> + || (bdev->bd_part->nr_sects % (PAGE_SIZE / 512)))
>> + return false;
>> +
>> + return true;
>
> Where do you check that S_DAX has been enabled on the block device
> now?
>
Only in the mmap path:
static int blkdev_mmap(struct file *file, struct vm_area_struct *vma)
{
struct inode *bd_inode = bdev_file_inode(file);
struct block_device *bdev = I_BDEV(bd_inode);
file_accessed(file);
mutex_lock(_inode->i_mutex);
bdev->bd_map_count++;
if (IS_DAX(bd_inode)) {
vma->vm_ops = _dax_vm_ops;
vma->vm_flags |= VM_MIXEDMAP | VM_HUGEPAGE;
} else {
vma->vm_ops = _default_vm_ops;
}
mutex_unlock(_inode->i_mutex);
return 0;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel oops on mmotm-2015-10-15-15-20
On Tue, Nov 03, 2015 at 09:16:50AM +0200, Kirill A. Shutemov wrote: > On Tue, Nov 03, 2015 at 12:02:58PM +0900, Minchan Kim wrote: > > Hello Kirill, > > > > On Mon, Nov 02, 2015 at 02:57:49PM +0200, Kirill A. Shutemov wrote: > > > On Fri, Oct 30, 2015 at 04:03:50PM +0900, Minchan Kim wrote: > > > > On Thu, Oct 29, 2015 at 11:52:06AM +0200, Kirill A. Shutemov wrote: > > > > > On Thu, Oct 29, 2015 at 04:58:29PM +0900, Minchan Kim wrote: > > > > > > On Thu, Oct 29, 2015 at 02:25:24AM +0200, Kirill A. Shutemov wrote: > > > > > > > On Thu, Oct 22, 2015 at 06:00:51PM +0900, Minchan Kim wrote: > > > > > > > > On Thu, Oct 22, 2015 at 10:21:36AM +0900, Minchan Kim wrote: > > > > > > > > > Hello Hugh, > > > > > > > > > > > > > > > > > > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > > > > > > > > > > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > > > > > > > > > > > > > > > > > > > > I added the code to check it and queued it again but I > > > > > > > > > > > had another oops > > > > > > > > > > > in this time but symptom is related to anon_vma, too. > > > > > > > > > > > (kernel is based on recent mmotm + unconditional mkdirty > > > > > > > > > > > for bug fix) > > > > > > > > > > > It seems page_get_anon_vma returns NULL since the page > > > > > > > > > > > was not page_mapped > > > > > > > > > > > at that time but second check of page_mapped right before > > > > > > > > > > > try_to_unmap seems > > > > > > > > > > > to be true. > > > > > > > > > > > > > > > > > > > > > > Adding 4191228k swap on /dev/vda5. Priority:-1 extents:1 > > > > > > > > > > > across:4191228k FS > > > > > > > > > > > Adding 4191228k swap on /dev/vda5. Priority:-1 extents:1 > > > > > > > > > > > across:4191228k FS > > > > > > > > > > > page:ea0001cfbfc0 count:3 mapcount:1 > > > > > > > > > > > mapping:88007f1b5f51 index:0x60aff > > > > > > > > > > > flags: > > > > > > > > > > > 0x40048019(locked|uptodate|dirty|swapcache|swapbacked) > > > > > > > > > > > page dumped because: VM_BUG_ON_PAGE(PageAnon(page) && > > > > > > > > > > > !PageKsm(page) && !anon_vma) > > > > > > > > > > > > > > > > > > > > That's interesting, that's one I added in my page migration > > > > > > > > > > series. > > > > > > > > > > Let me think on it, but it could well relate to the one you > > > > > > > > > > got before. > > > > > > > > > > > > > > > > > > I will roll back to > > > > > > > > > mm/madv_free-v4.3-rc5-mmotm-2015-10-15-15-20 > > > > > > > > > instead of next-20151021 to remove noise from your migration > > > > > > > > > cleanup > > > > > > > > > series and will test it again. > > > > > > > > > If it is fixed, I will test again with your migration > > > > > > > > > patchset, then. > > > > > > > > > > > > > > > > I tested mmotm-2015-10-15-15-20 with test program I attach for > > > > > > > > a long time. > > > > > > > > Therefore, there is no patchset from Hugh's migration patch in > > > > > > > > there. > > > > > > > > And I added below debug code with request from Kirill to all > > > > > > > > test kernels. > > > > > > > > > > > > > > It took too long time (and a lot of printk()), but I think I > > > > > > > track it down > > > > > > > finally. > > > > > > > > > > > > > > The patch below seems fixes issue for me. It's not yet properly > > > > > > > tested, but > > > > > > > looks like it works. > > > > > > > > > > > > > > The problem was my wrong assumption on how migration works: I > > > > > > > thought that > > > > > > > kernel would wait migration to finish on before deconstruction > > > > > > > mapping. > > > > > > > > > > > > > > But turn out that's not true. > > > > > > > > > > > > > > As result if zap_pte_range() races with split_huge_page(), we can > > > > > > > end up > > > > > > > with page which is not mapped anymore but has _count and _mapcount > > > > > > > elevated. The page is on LRU too. So it's still reachable by > > > > > > > vmscan and by > > > > > > > pfn scanners (Sasha showed few similar traces from compaction > > > > > > > too). > > > > > > > It's likely that page->mapping in this case would point to freed > > > > > > > anon_vma. > > > > > > > > > > > > > > BOOM! > > > > > > > > > > > > > > The patch modify freeze/unfreeze_page() code to match normal > > > > > > > migration > > > > > > > entries logic: on setup we remove page from rmap and drop pin, on > > > > > > > removing > > > > > > > we get pin back and put page on rmap. This way even if migration > > > > > > > entry > > > > > > > will be removed under us we don't corrupt page's state. > > > > > > > > > > > > > > Please, test. > > > > > > > > > > > > > > > > > > > kernel: On mmotm-2015-10-15-15-20 + pte_mkdirty patch + your new > > > > > > patch, I tested > > > > > > one I sent to you(ie, oops.c + memcg_test.sh) > > > > > > > > > > > > page:ea00016a count:3 mapcount:0 mapping:88007f49d001 > > > > > > index:0x61800 compound_mapcount: 0 > > > > > > flags:
Re: [BUG, bisect] i2c: designware: Move common probe code into i2c_dw_probe()
Hi
On 03.11.2015 06:02, Jeremiah Mahler wrote:
Jarkko, all,
Commit d80d134182ba5 introduced a bug which causes a cyapa based touch
pad on an Acer C720 Chromebook to become inoperative. This is present
in the latest linux-next (20151101). The patch description is repeated
below.
From d80d134182ba536ececab8d5fca50d779befc9a6 Mon Sep 17 00:00:00 2001
From: Jarkko Nikula
Date: Mon, 12 Oct 2015 16:55:35 +0300
Subject: [PATCH] i2c: designware: Move common probe code into i2c_dw_probe()
There is some code duplication in i2c-designware-platdrv and
i2c-designware-pcidrv probe functions. What is even worse that duplication
requires i2c_dw_xfer(), i2c_dw_func() and i2c_dw_isr() i2c-designware-core
functions to be exported.
Therefore move common code into new i2c_dw_probe() and make functions above
local to i2c-designware-core.
While merging the code patch does following functional changes:
- I2C Adapter name will be "Synopsys DesignWare I2C adapter". Previously it
was used for platform and ACPI devices but PCI device used
"i2c-designware-pci".
- Using device name for interrupt name. Previous it was platform device name,
ACPI device name or "i2c-designware-pci".
- Error code from devm_request_irq() and i2c_add_numbered_adapter() will be
printed in case of error.
Signed-off-by: Jarkko Nikula
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-designware-core.c| 49
+
drivers/i2c/busses/i2c-designware-core.h| 5 +--
drivers/i2c/busses/i2c-designware-pcidrv.c | 30 ++
drivers/i2c/busses/i2c-designware-platdrv.c | 28 ++---
4 files changed, 49 insertions(+), 63 deletions(-)
Oh, I didn't notice adapter name was used
drivers/platform/chrome/chromeos_laptop.c. Could you try does a patch
below help?
CUT HERE
diff --git a/drivers/platform/chrome/chromeos_laptop.c
b/drivers/platform/chrome/chromeos_laptop.c
index 02072749fff3..2b441e9ae593 100644
--- a/drivers/platform/chrome/chromeos_laptop.c
+++ b/drivers/platform/chrome/chromeos_laptop.c
@@ -47,8 +47,8 @@ static const char *i2c_adapter_names[] = {
"SMBus I801 adapter",
"i915 gmbus vga",
"i915 gmbus panel",
- "i2c-designware-pci",
- "i2c-designware-pci",
+ "Synopsys DesignWare I2C adapter",
+ "Synopsys DesignWare I2C adapter",
};
/* Keep this enum consistent with i2c_adapter_names */
CUT HERE
--
Jarkko
--
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/4] perf report: Support folded callchain output (v3)
Hello, This is what Brendan requested on the perf-users mailing list [1] to support FlameGraphs [2] more efficiently. This patchset adds a few more callchain options to adjust the output for it. * changes in v3) - put the value before callchains - fix compile error At first, 'folded' output mode was added. The folded output puts the value, a space and all calchain nodes separated by semicolons. Now it only supports --stdio as other UI provides some way of folding and/or expanding callchains dynamically. The value is now can be one of 'percent', 'period', or 'count'. The percent is current default output and the period is the raw number of sample periods. The count is the number of samples for each callchain. Here's an example: $ perf report --no-children --show-nr-samples --stdio -g folded,count ... 39.93% 80 swapper [kernel.vmlinux] [k] intel_idel 57 intel_idle;cpuidle_enter_state;cpuidle_enter;call_cpuidle;cpu_startup_entry;start_secondary 23 intel_idle;cpuidle_enter_state;cpuidle_enter;call_cpuidle;cpu_startup_entry;rest_init;... $ perf report --no-children --stdio -g percent ... 39.93% swapper [kernel.vmlinux] [k] intel_idel | ---intel_idle cpuidle_enter_state cpuidle_enter call_cpuidle cpu_startup_entry | |--28.63%-- start_secondary | --11.30%-- rest_init $ perf report --no-children --stdio --show-total-period -g period ... 39.93% 13018705 swapper [kernel.vmlinux] [k] intel_idel | ---intel_idle cpuidle_enter_state cpuidle_enter call_cpuidle cpu_startup_entry | |--9334403-- start_secondary | --3684302-- rest_init $ perf report --no-children --stdio --show-nr-samples -g count ... 39.93% 80 swapper [kernel.vmlinux] [k] intel_idel | ---intel_idle cpuidle_enter_state cpuidle_enter call_cpuidle cpu_startup_entry | |--57-- start_secondary | --23-- rest_init You can get it from 'perf/callchain-fold-v3' branch on my tree: git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git Any comments are welcome, thanks Namhyung [1] http://www.spinics.net/lists/linux-perf-users/msg02498.html [2] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html Namhyung Kim (4): perf report: Support folded callchain mode on --stdio perf callchain: Abstract callchain print function perf callchain: Add count fields to struct callchain_node perf report: Add callchain value option tools/perf/Documentation/perf-report.txt | 13 +++-- tools/perf/builtin-report.c | 4 +- tools/perf/ui/browsers/hists.c | 8 +-- tools/perf/ui/gtk/hists.c| 8 +-- tools/perf/ui/stdio/hist.c | 93 ++-- tools/perf/util/callchain.c | 87 +- tools/perf/util/callchain.h | 24 - tools/perf/util/util.c | 3 +- 8 files changed, 205 insertions(+), 35 deletions(-) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] Documentation: dt-bindings: Describe SROMc configuration
On 03.11.2015 15:58, Pavel Fedin wrote:
> Hello!
>
> --- cut exynos5410.dtsi ---
> sromc: sromc@1225 {
> #address-cells = <2>;
> #size-cells = <1>;
> ranges = <0 0 0x0400 0x2
> 1 0 0x0500 0x2
> 2 0 0x0600 0x2
> 3 0 0x0700 0x2>;
Do you have to use 2 cells for address? Cannot it be:
ranges = <0 0x0400 0x2
1 0x0500 0x2
2 0x0600 0x2
3 0x0700 0x2>;
>>>
>>> I tried this first, but it didn't work, and ranges translation
>>> gave me something really weird (like addr = 0x80 and
>>> size = 0x0404).
>>
>> Did you change the address-cells to <1>?
>
> Of course i did.
I saw some other nodes use the ranges without the offset but maybe some
more steps are required for such configuration.
So anyway send the version with the child offset and I will try to
figure out why it is required.
Best regards,
Krzysztof
--
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: [LKP] [x86/context_tracking] db23da8b95: inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
Hi Paolo, Never mind, it just takes 2 minutes for me. :) Thanks, Fengguang On Mon, Nov 02, 2015 at 01:19:20PM +0100, Paolo Bonzini wrote: > Hi Fengguang, > > this patch is not ready, and is left for 4.5; see Andy's comment at > http://permalink.gmane.org/gmane.linux.kernel/2072877. Only the other > two are. > > I'm sorry for the inconvenience. > > Thanks, > > Paolo > > On 02/11/2015 13:11, Fengguang Wu wrote: > > Hi Paolo, > > > > FYI, here is another bisect result. > > > > https://github.com/0day-ci/linux > > Paolo-Bonzini/context_tracking-remove-duplicate-enabled-check/20151028-094317 > > > > commit db23da8b95ece9b57d4cfd63f5ee10502f1af0c8 > > Author: Paolo Bonzini > > AuthorDate: Wed Oct 28 02:39:57 2015 +0100 > > Commit: 0day robot > > CommitDate: Wed Oct 28 09:43:20 2015 +0800 > > > > x86: context_tracking: avoid irq_save/irq_restore on kernel entry and > > exit > > > > x86 always calls user_enter and user_exit with interrupt disabled. > > Therefore, it is not necessary to check for exceptions, nor to > > save/restore the IRQ state, when context tracking functions are > > called by guest_enter and guest_exit. > > > > Use the previously introduced __context_tracking_entry and > > __context_tracking_exit. > > > > Cc: Andy Lutomirski > > Cc: Frederic Weisbecker > > Cc: Rik van Riel > > Cc: Paul McKenney > > Signed-off-by: Paolo Bonzini > ___ > LKP mailing list > l...@lists.01.org > https://lists.01.org/mailman/listinfo/lkp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check
Hi Gang,
I didn't see a need to add a sysfs file for the check and repair. This
leaves a hard problem for customer to decide. How they decide whether
they should repair the bad inode since this may cause corruption even
harder?
I think the error should be fixed by this feature automaticlly if repair
helps, of course this can be done only when error=continue is enabled or
add some mount option for it.
Thanks,
Junxiao.
On 10/28/2015 02:25 PM, Gang He wrote:
> Implement online file check sysfile interfaces, e.g.
> how to create the related sysfile according to device name,
> how to display/handle file check request from the sysfile.
>
> Signed-off-by: Gang He
> ---
> fs/ocfs2/Makefile| 3 +-
> fs/ocfs2/filecheck.c | 566
> +++
> fs/ocfs2/filecheck.h | 48 +
> fs/ocfs2/inode.h | 3 +
> 4 files changed, 619 insertions(+), 1 deletion(-)
> create mode 100644 fs/ocfs2/filecheck.c
> create mode 100644 fs/ocfs2/filecheck.h
>
> diff --git a/fs/ocfs2/Makefile b/fs/ocfs2/Makefile
> index ce210d4..e27e652 100644
> --- a/fs/ocfs2/Makefile
> +++ b/fs/ocfs2/Makefile
> @@ -41,7 +41,8 @@ ocfs2-objs := \
> quota_local.o \
> quota_global.o \
> xattr.o \
> - acl.o
> + acl.o \
> + filecheck.o
>
> ocfs2_stackglue-objs := stackglue.o
> ocfs2_stack_o2cb-objs := stack_o2cb.o
> diff --git a/fs/ocfs2/filecheck.c b/fs/ocfs2/filecheck.c
> new file mode 100644
> index 000..f12ed1f
> --- /dev/null
> +++ b/fs/ocfs2/filecheck.c
> @@ -0,0 +1,566 @@
> +/* -*- mode: c; c-basic-offset: 8; -*-
> + * vim: noexpandtab sw=8 ts=8 sts=0:
> + *
> + * filecheck.c
> + *
> + * Code which implements online file check.
> + *
> + * Copyright (C) 2015 Novell. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public
> + * License as published by the Free Software Foundation, version 2.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ocfs2.h"
> +#include "ocfs2_fs.h"
> +#include "stackglue.h"
> +#include "inode.h"
> +
> +#include "filecheck.h"
> +
> +
> +/* File check error strings,
> + * must correspond with error number in header file.
> + */
> +static const char * const ocfs2_filecheck_errs[] = {
> + "SUCCESS",
> + "FAILED",
> + "INPROGRESS",
> + "READONLY",
> + "INVALIDINO",
> + "BLOCKECC",
> + "BLOCKNO",
> + "VALIDFLAG",
> + "GENERATION",
> + "UNSUPPORTED"
> +};
> +
> +static DEFINE_SPINLOCK(ocfs2_filecheck_sysfs_lock);
> +static LIST_HEAD(ocfs2_filecheck_sysfs_list);
> +
> +struct ocfs2_filecheck {
> + struct list_head fc_head; /* File check entry list head */
> + spinlock_t fc_lock;
> + unsigned int fc_max;/* Maximum number of entry in list */
> + unsigned int fc_size; /* Current entry count in list */
> + unsigned int fc_done; /* File check entries are done in list */
> +};
> +
> +struct ocfs2_filecheck_sysfs_entry {
> + struct list_head fs_list;
> + atomic_t fs_count;
> + struct super_block *fs_sb;
> + struct kset *fs_kset;
> + struct ocfs2_filecheck *fs_fcheck;
> +};
> +
> +#define OCFS2_FILECHECK_MAXSIZE 100
> +#define OCFS2_FILECHECK_MINSIZE 10
> +
> +/* File check operation type */
> +enum {
> + OCFS2_FILECHECK_TYPE_CHK = 0, /* Check a file */
> + OCFS2_FILECHECK_TYPE_FIX, /* Fix a file */
> + OCFS2_FILECHECK_TYPE_SET = 100 /* Set file check options */
> +};
> +
> +struct ocfs2_filecheck_entry {
> + struct list_head fe_list;
> + unsigned long fe_ino;
> + unsigned int fe_type;
> + unsigned short fe_done:1;
> + unsigned short fe_status:15;
> +};
> +
> +struct ocfs2_filecheck_args {
> + unsigned int fa_type;
> + union {
> + unsigned long fa_ino;
> + unsigned int fa_len;
> + };
> +};
> +
> +static const char *
> +ocfs2_filecheck_error(int errno)
> +{
> + if (!errno)
> + return ocfs2_filecheck_errs[errno];
> +
> + BUG_ON(errno < OCFS2_FILECHECK_ERR_START ||
> + errno > OCFS2_FILECHECK_ERR_END);
> + return ocfs2_filecheck_errs[errno - OCFS2_FILECHECK_ERR_START + 1];
> +}
> +
> +static ssize_t ocfs2_filecheck_show(struct kobject *kobj,
> + struct kobj_attribute *attr,
> + char *buf);
> +static ssize_t ocfs2_filecheck_store(struct kobject *kobj,
> + struct kobj_attribute *attr,
> +
Re: [PATCH v3 02/15] dax: increase granularity of dax_clear_blocks() operations
On Mon, Nov 2, 2015 at 9:52 PM, Dave Chinner wrote: > On Mon, Nov 02, 2015 at 09:31:11PM -0800, Dan Williams wrote: >> On Mon, Nov 2, 2015 at 8:48 PM, Dave Chinner wrote: >> > On Mon, Nov 02, 2015 at 07:27:26PM -0800, Dan Williams wrote: >> >> On Mon, Nov 2, 2015 at 4:51 PM, Dave Chinner wrote: >> >> > On Sun, Nov 01, 2015 at 11:29:53PM -0500, Dan Williams wrote: >> >> > The zeroing (and the data, for that matter) doesn't need to be >> >> > committed to persistent store until the allocation is written and >> >> > committed to the journal - that will happen with a REQ_FLUSH|REQ_FUA >> >> > write, so it makes sense to deploy the big hammer and delay the >> >> > blocking CPU cache flushes until the last possible moment in cases >> >> > like this. >> >> >> >> In pmem terms that would be a non-temporal memset plus a delayed >> >> wmb_pmem at REQ_FLUSH time. Better to write around the cache than >> >> loop over the dirty-data issuing flushes after the fact. We'll bump >> >> the priority of the non-temporal memset implementation. >> > >> > Why is it better to do two synchronous physical writes to memory >> > within a couple of microseconds of CPU time rather than writing them >> > through the cache and, in most cases, only doing one physical write >> > to memory in a separate context that expects to wait for a flush >> > to complete? >> >> With a switch to non-temporal writes they wouldn't be synchronous, >> although it's doubtful that the subsequent writes after zeroing would >> also hit the store buffer. >> >> If we had a method to flush by physical-cache-way rather than a >> virtual address then it would indeed be better to save up for one >> final flush, but when we need to resort to looping through all the >> virtual addresses that might have touched it gets expensive. > > msync() is for flushing userspace mmap ranges addresses back to > physical memory. fsync() is for flushing kernel addresses (i.e. as > returned by bdev_direct_access()) back to physical addresses. > msync() calls ->fsync() as part of it's operation, fsync() does not > care about whether mmap has been sync'd first or not. > > i.e. we don't care about random dirty userspace virtual mappings in > fsync() - if you have them then you need to call msync() first. So > we shouldn't ever be having to walk virtual addresses in fsync - > just the kaddr returned by bdev_direct_access() is all that fsync > needs to flush... > Neither Ross' solution nor mine use userspace addresses. Which comment of mine were you reacting to? -- 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 v2 4/5] drm/dsi: Add routine to unregister dsi device
On 11/02/2015 04:12 PM, Andrzej Hajda wrote:
On 11/02/2015 07:28 AM, Archit Taneja wrote:
On 10/30/2015 07:51 PM, Andrzej Hajda wrote:
On 10/06/2015 11:24 AM, Archit Taneja wrote:
A driver calling mipi_dsi_device_new might want to unregister the device
once it's done. It might also require it in an error handling path in
case something didn't go right.
When the dsi host driver calls mipi_dsi_host_unregister, the devices
created by both DT and and without DT will be removed. This does leave
the possibility of the host removing the dsi device without the
peripheral driver being aware of it. I don't know a good way to solve
this. Some suggestions here would be of help too.
The 2nd paragraph is not relevant here. It is another issue. Some comments
about it:
Yes, it's probably not the best to put it in the commit message of this
patch.
I am not sure, but I guess device should not be removed if it is refcounted
properly, it will be just detached from the driver, bus and system (whatever it
means:) ).
It does not mean it will be usable and probably some races can occur anyway.
I guess i2c and other buses have the same problem, am I right?
I was concerned about one particular sequence:
1) DSI host driver calls mipi_dsi_host_unregister: All dsi devices would
be unregistered.
2) dsi device driver calls mipi_dsi_device_unregister: This will try to
unregister our dsi device
The problem here is that the device will cease to exist after step (1)
itself, because the refcount of our device will never be 2.
mipi_dsi_host_register() will only register devices represented in DT,
not the one the drivers register manually.
In other words, the dsi pointer in our driver will point to nothing
valid after mipi_dsi_host_unregister is called.
As you said, I guess this exists in other buses too, and it's the
drivers job to not use them.
I think the whole problem is due to fact we try to use devices
as interfaces to some bus hosts (DSI in our case), these devices
are owned by bus host and we cannot control their lifetime from other code.
The best solution IMO would be to create separate lightweight framework
as I suggested in previous discussion[1]. It should be cleaner solution
without any 'dummy' proxy devices.
But even in this case we would need some callbacks to notify that the provider
is about to be removed.
2nd 'solution' is to leave it as is and pretend everything is OK,
as in case of other frameworks :)
Maybe it would be possible 3rd solution - we could use probe and remove
callbacks
from dsi driver to notify clients about adding/removal of dsi device to/from
bus.
So during dummy dsi dev creation we would provide some callbacks which would be
called
by dummy dsi driver probe/remove to notifiy client it can start/stop using dsi
device.
This crazy construction probably can work but looks insane :)
[1]: http://www.spinics.net/lists/linux-arm-msm/msg16945.html
I'm okay with the 2nd solution :). We can add callbacks or a
notification mechanism if anyone needs it in the future.
Thanks,
Archit
Regards
Andrzej
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/drm_mipi_dsi.c | 7 +++
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index db6130a..cbb7373 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -183,6 +183,13 @@ err:
}
EXPORT_SYMBOL(mipi_dsi_device_new);
+void mipi_dsi_device_unregister(struct mipi_dsi_device *dsi)
+{
+ if (dsi)
+ device_unregister(>dev);
+}
+EXPORT_SYMBOL(mipi_dsi_device_unregister);
+
I guess NULL check can be removed and the whole function can be inlined.
Yeah, this check won't help anyway.
I think I'll mention that drivers should use this only in error
handling paths, and not in the driver's remove() op.
I'll also change this to inlined.
Archit
Regards
Andrzej
static struct mipi_dsi_device *
of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct device_node *node)
{
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 93dec7b..68f49f4 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -197,6 +197,8 @@ ssize_t mipi_dsi_generic_read(struct mipi_dsi_device *dsi,
const void *params,
struct mipi_dsi_device *mipi_dsi_device_new(struct mipi_dsi_host *host,
struct mipi_dsi_device_info *info);
+void mipi_dsi_device_unregister(struct mipi_dsi_device *dsi);
+
/**
* enum mipi_dsi_dcs_tear_mode - Tearing Effect Output Line mode
* @MIPI_DSI_DCS_TEAR_MODE_VBLANK: the TE output line consists of V-Blanking
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body
Re: [PATCH 4/4] Input: tsc2004 - Document ts2004 dt bindings
On Mon, Nov 02, 2015 at 02:50:29PM -0600, Michael Welling wrote:
> On Mon, Nov 02, 2015 at 09:19:50AM -0600, Rob Herring wrote:
> > > +Required properties:
> > > + - compatible: "ti,tsc2004"
> > > + - interrupts: IRQ specifier
> > > + - vio-supply : Regulator specifier
> >
> > reg property?
>
> Rob,
>
> It appears that I missed this in the description.
>
> Probably because I was following the lead of the ts2005 description.
>
> How does this look:
> - reg : I2C address. 0x48 - 0x4b based on the voltage applied
> to
> the AD1 and AD0 inputs on the IC.
>
How about the version below?
Thanks.
--
Dmitry
Input: tsc2004 - document ts2004 dt bindings
From: Michael Welling
Adds documentation for the devicetree bindings of the new tsc2004 driver.
Signed-off-by: Michael Welling
Signed-off-by: Dmitry Torokhov
---
.../bindings/input/touchscreen/tsc2005.txt | 34
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
index 09089a6..b80c04b 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
@@ -1,14 +1,15 @@
-* Texas Instruments tsc2005 touchscreen controller
+* Texas Instruments tsc2004 and tsc2005 touchscreen controllers
Required properties:
- - compatible: "ti,tsc2005"
- - reg : SPI device address
- - spi-max-frequency : Maximal SPI speed
+ - compatible: "ti,tsc2004" or "ti,tsc2005"
+ - reg : Device address
- interrupts: IRQ specifier
- - reset-gpios : GPIO specifier
- - vio-supply : Regulator specifier
+ - spi-max-frequency : Maximum SPI clocking speed of the device
+ (for tsc2005)
Optional properties:
+ - vio-supply: Regulator specifier
+ - reset-gpios : GPIO specifier for the controller reset line
- ti,x-plate-ohms : integer, resistance of the touchscreen's X
plates
in ohm (defaults to 280)
- ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond
after
@@ -18,6 +19,27 @@ Optional properties:
Example:
+ {
+ tsc2004@48 {
+ compatible = "ti,tsc2004";
+ reg = <0x48>;
+ vio-supply = <>;
+
+ reset-gpios = < 8 GPIO_ACTIVE_HIGH>;
+ interrupts-extended = < 27 IRQ_TYPE_EDGE_RISING>;
+
+ touchscreen-fuzz-x = <4>;
+ touchscreen-fuzz-y = <7>;
+ touchscreen-fuzz-pressure = <2>;
+ touchscreen-size-x = <4096>;
+ touchscreen-size-y = <4096>;
+ touchscreen-max-pressure = <2048>;
+
+ ti,x-plate-ohms = <280>;
+ ti,esd-recovery-timeout-ms = <8000>;
+ };
+}
+
{
tsc2005@0 {
compatible = "ti,tsc2005";
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/4] perf report: Support folded callchain mode on --stdio
Add new call chain option (-g) 'folded' to print callchains in a line.
The callchains are separated by semicolons, and preceded by (absolute)
percent values and a space.
For example, following 20 lines can be printed in 3 lines with the
folded output mode;
$ perf report -g flat --no-children | grep -v ^# | head -20
60.48% swapper [kernel.vmlinux] [k] intel_idle
54.60%
intel_idle
cpuidle_enter_state
cpuidle_enter
call_cpuidle
cpu_startup_entry
start_secondary
5.88%
intel_idle
cpuidle_enter_state
cpuidle_enter
call_cpuidle
cpu_startup_entry
rest_init
start_kernel
x86_64_start_reservations
x86_64_start_kernel
$ perf report -g folded --no-children | grep -v ^# | head -3
60.48% swapper [kernel.vmlinux] [k] intel_idle
54.60%
intel_idle;cpuidle_enter_state;cpuidle_enter;call_cpuidle;cpu_startup_entry;start_secondary
5.88%
intel_idle;cpuidle_enter_state;cpuidle_enter;call_cpuidle;cpu_startup_entry;rest_init;start_kernel;x86_64_start_reservations;x86_64_start_kernel
This mode is supported only for --stdio now and intended to be used by
some scripts like in FlameGraphs[1]. Support for other UI might be
added later.
[1] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
Requested-by: Brendan Gregg
Signed-off-by: Namhyung Kim
---
tools/perf/ui/stdio/hist.c | 54 +
tools/perf/util/callchain.c | 6 +
tools/perf/util/callchain.h | 3 ++-
3 files changed, 62 insertions(+), 1 deletion(-)
diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index dfcbc90146ef..d04c068f4acf 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -260,6 +260,57 @@ static size_t callchain__fprintf_flat(FILE *fp, struct
rb_root *tree,
return ret;
}
+static size_t __callchain__fprintf_folded(FILE *fp, struct callchain_node
*node)
+{
+ struct callchain_list *chain;
+ size_t ret = 0;
+ char bf[1024];
+ bool first;
+
+ if (!node)
+ return 0;
+
+ ret += __callchain__fprintf_folded(fp, node->parent);
+
+ first = (ret == 0);
+ list_for_each_entry(chain, >val, list) {
+ if (chain->ip >= PERF_CONTEXT_MAX)
+ continue;
+ ret += fprintf(fp, "%s%s", first ? "" : ";",
+ callchain_list__sym_name(chain,
+ bf, sizeof(bf), false));
+ first = false;
+ }
+
+ return ret;
+}
+
+static size_t callchain__fprintf_folded(FILE *fp, struct rb_root *tree,
+ u64 total_samples)
+{
+ size_t ret = 0;
+ u32 entries_printed = 0;
+ struct callchain_node *chain;
+ struct rb_node *rb_node = rb_first(tree);
+
+ while (rb_node) {
+ double percent;
+
+ chain = rb_entry(rb_node, struct callchain_node, rb_node);
+ percent = chain->hit * 100.0 / total_samples;
+
+ ret += fprintf(fp, "%.2f%% ", percent);
+ ret += __callchain__fprintf_folded(fp, chain);
+ ret += fprintf(fp, "\n");
+ if (++entries_printed == callchain_param.print_limit)
+ break;
+
+ rb_node = rb_next(rb_node);
+ }
+
+ return ret;
+}
+
static size_t hist_entry_callchain__fprintf(struct hist_entry *he,
u64 total_samples, int left_margin,
FILE *fp)
@@ -278,6 +329,9 @@ static size_t hist_entry_callchain__fprintf(struct
hist_entry *he,
case CHAIN_FLAT:
return callchain__fprintf_flat(fp, >sorted_chain,
total_samples);
break;
+ case CHAIN_FOLDED:
+ return callchain__fprintf_folded(fp, >sorted_chain,
total_samples);
+ break;
case CHAIN_NONE:
break;
default:
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 735ad48e1858..08cb220ba5ea 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -44,6 +44,10 @@ static int parse_callchain_mode(const char *value)
callchain_param.mode = CHAIN_GRAPH_REL;
return 0;
}
+ if (!strncmp(value, "folded", strlen(value))) {
+ callchain_param.mode = CHAIN_FOLDED;
+ return 0;
+ }
return -1;
}
@@ -218,6 +222,7 @@ rb_insert_callchain(struct rb_root *root, struct
callchain_node *chain,
switch (mode) {
case CHAIN_FLAT:
+ case CHAIN_FOLDED:
if (rnode->hit <
Re: [PATCH v3 14/15] dax: dirty extent notification
On Mon, Nov 2, 2015 at 9:40 PM, Dave Chinner wrote: > On Mon, Nov 02, 2015 at 08:56:24PM -0800, Dan Williams wrote: >> No, we definitely can't do that. I think your mental model of the >> cache flushing is similar to the disk model where a small buffer is >> flushed after a large streaming write. Both Ross' patches and my >> approach suffer from the same horror that the cache flushing is O(N) >> currently, so we don't want to make it responsible for more data >> ranges areas than is strictly necessary. > > I didn't see anything that was O(N) in Ross's patches. What part of > the fsync algorithm that Ross proposed are you refering to here? We have to issue clflush per touched virtual address rather than a constant number of physical ways, or a flush-all instruction. >> >> We can later extend the DAX paths to indicate when an async mapping is >> >> "closed" allowing the active extents to be marked clean. >> > >> > Yes, that's a basic feature of Ross's patches. Hence I think this >> > special case DAX<->bdev interface is the wrong direction to be >> > taking. >> >> So here's my problem with the "track dirty mappings" in the core >> mm/vfs approach, it's harder to unwind and delete when it turns out no >> application actually needs it, or the platform gives us an O(1) flush >> method that is independent of dirty pte tracking. >> >> We have the NVML [1] library as the recommended method for >> applications to interact with persistent memory and it is not using >> fsync/msync for its synchronization primitives, it's managing the >> cache directly. The *only* user for tracking dirty DAX mappings is >> unmodified legacy applications that do mmap I/O and call fsync/msync. > > I'm pretty sure there are going to be many people still writing new > applications that use POSIX APIs they expect to work correctly on > pmem because, well, it's going to take 10 years before persistent > memory is common enough for most application developers to only > target storage via NVML. > > The whole world is not crazy HFT applications that need to bypass > the kernel for *everything* because even a few nanoseconds of extra > latency matters. I agree with all of that... >> DAX in my opinion is not a transparent accelerator of all existing >> apps, it's a targeted mechanism for applications ready to take >> advantage of byte addressable persistent memory. > > And this is where we disagree. DAX is a method of allowing POSIX > compliant applications get the best of both worlds - portability > with existing storage and filesystems, yet with the speed and byte > addressiblity of persistent storage through the use of mmap. > > Applications designed specifically for persistent memory don't want > a general purpose, POSIX compatible filesystem underneath them. The > should be interacting directly with, and only with, your NVML > library. If the NVML library is implemented by using DAX on a POSIX > compatible, general purpose filesystem, then you're just going to > have to live with everything we need to do to make DAX work with > general purpose POSIX compatible applications. > > DAX has always been intended as a *stopgap measure* designed to > bridge the gap between existing POSIX based storage APIs and PMEM > native filesystem implementations. You're advocating that DAX should > only be used by PMEM native applications using NVML and then saying > anything that might be needed for POSIX compatible behaviour is > unacceptible overhead... Also agreed, up until you this last sentence which is not what I am saying at all. I didn't say it is unacceptable overhead, my solution in the driver has the exact same overhead. Where I instead think we disagree is the acceptable cost of the "flush cache" operation before the recommended solution is to locally disable DAX, or require help from the platform to do this operation more efficiently. What I submit is unacceptable is to have the cpu loop over every address heading out to storage. The radix solution only makes the second fsync after the first potentially less costly over time. I don't think we'll need it long term, or so I hope. The question becomes do we want to carry this complexity in the core or push selectively disabling DAX in the interim and have the simple driver approach for cases where it's not feasible to disable DAX. For 4.4 we have the practical matter of not having the time to get mm folks to review the radix approach. I'm not opposed to ripping out the driver solution in 4.5 when we have the time to get Ross' implementation reviewed. I'm also holding back the get_user_page() patches until 4.5 and given the big fat comment in write_protect_page() about gup-fast interactions we'll need to think through similar implications. > >> This is why I'm a >> big supporter of your per-inode DAX control proposal. The fact that >> fsync is painful for large amounts of dirty data is a feature. It >> detects inodes that should have had DAX-disabled in the first >> instance. >
[PATCH v3 2/4] perf callchain: Abstract callchain print function
This is a preparation to support for printing other type of callchain
value like count or period.
Cc: Brendan Gregg
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 8 +---
tools/perf/ui/gtk/hists.c | 8 ++--
tools/perf/ui/stdio/hist.c | 35 +--
tools/perf/util/callchain.c| 25 +
tools/perf/util/callchain.h| 4
5 files changed, 53 insertions(+), 27 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index e5afb8936040..a8897aab4c4a 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -592,7 +592,6 @@ static int hist_browser__show_callchain(struct hist_browser
*browser,
while (node) {
struct callchain_node *child = rb_entry(node, struct
callchain_node, rb_node);
struct rb_node *next = rb_next(node);
- u64 cumul = callchain_cumul_hits(child);
struct callchain_list *chain;
char folded_sign = ' ';
int first = true;
@@ -619,9 +618,12 @@ static int hist_browser__show_callchain(struct
hist_browser *browser,
browser->show_dso);
if (was_first && need_percent) {
- double percent = cumul * 100.0 / total;
+ char buf[64];
- if (asprintf(_str, "%2.2f%% %s", percent,
str) < 0)
+ callchain_node__sprintf_value(child, buf,
sizeof(buf),
+ total);
+
+ if (asprintf(_str, "%s %s", buf, str) < 0)
str = "Not enough memory!";
else
str = alloc_str;
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 4b3585eed1e8..d8037b7023e8 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -100,14 +100,10 @@ static void perf_gtk__add_callchain(struct rb_root *root,
GtkTreeStore *store,
struct callchain_list *chain;
GtkTreeIter iter, new_parent;
bool need_new_parent;
- double percent;
- u64 hits, child_total;
+ u64 child_total;
node = rb_entry(nd, struct callchain_node, rb_node);
- hits = callchain_cumul_hits(node);
- percent = 100.0 * hits / total;
-
new_parent = *parent;
need_new_parent = !has_single_node && (node->val_nr > 1);
@@ -116,7 +112,7 @@ static void perf_gtk__add_callchain(struct rb_root *root,
GtkTreeStore *store,
gtk_tree_store_append(store, , _parent);
- scnprintf(buf, sizeof(buf), "%5.2f%%", percent);
+ callchain_node__sprintf_value(node, buf, sizeof(buf),
total);
gtk_tree_store_set(store, , 0, buf, -1);
callchain_list__sym_name(chain, buf, sizeof(buf),
false);
diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index d04c068f4acf..9b5a0d8a43dc 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -34,10 +34,10 @@ static size_t ipchain__fprintf_graph_line(FILE *fp, int
depth, int depth_mask,
return ret;
}
-static size_t ipchain__fprintf_graph(FILE *fp, struct callchain_list *chain,
+static size_t ipchain__fprintf_graph(FILE *fp, struct callchain_node *node,
+struct callchain_list *chain,
int depth, int depth_mask, int period,
-u64 total_samples, u64 hits,
-int left_margin)
+u64 total_samples, int left_margin)
{
int i;
size_t ret = 0;
@@ -50,10 +50,9 @@ static size_t ipchain__fprintf_graph(FILE *fp, struct
callchain_list *chain,
else
ret += fprintf(fp, " ");
if (!period && i == depth - 1) {
- double percent;
-
- percent = hits * 100.0 / total_samples;
- ret += percent_color_fprintf(fp, "--%2.2f%%-- ",
percent);
+ ret += fprintf(fp, "--");
+ ret += callchain_node__fprintf_value(node, fp,
total_samples);
+ ret += fprintf(fp, "--");
} else
ret += fprintf(fp, "%s", " ");
}
@@ -120,10 +119,9 @@ static size_t __callchain__fprintf_graph(FILE *fp, struct
rb_root *root,
left_margin);
i = 0;
list_for_each_entry(chain, >val, list) {
-
Re: [RFC v2 5/5] drm/dsi: Get DSI host by DT device node
On 11/02/2015 04:20 PM, Andrzej Hajda wrote:
On 10/06/2015 11:24 AM, Archit Taneja wrote:
mipi_dsi_devices are inherently aware of their host because they
share a parent-child hierarchy in the device tree.
Non-dsi drivers that create a dummy dsi device don't have this data.
In order to get this information, they require to a phandle to the dsi
host in the device tree.
Maintain a list of all the hosts DSI that are currently registered.
This list will be used to find the mipi_dsi_host corresponding to the
device_node passed in of_find_mipi_dsi_host_by_node.
Signed-off-by: Archit Taneja
Looks OK, beside lack of documentation, after fixing it you can add
Reviewed-by: Andrzej Hajda
I will add missing documentation before posting v3.
Thanks again for the review.
Archit
Regards
Andrzej
---
drivers/gpu/drm/drm_mipi_dsi.c | 30 ++
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index cbb7373..c51d73e 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -216,6 +216,28 @@ of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct
device_node *node)
return mipi_dsi_device_new(host, );
}
+static DEFINE_MUTEX(host_lock);
+static LIST_HEAD(host_list);
+
+struct mipi_dsi_host *of_find_mipi_dsi_host_by_node(struct device_node *node)
+{
+ struct mipi_dsi_host *host;
+
+ mutex_lock(_lock);
+
+ list_for_each_entry(host, _list, list) {
+ if (host->dev->of_node == node) {
+ mutex_unlock(_lock);
+ return host;
+ }
+ }
+
+ mutex_unlock(_lock);
+
+ return NULL;
+}
+EXPORT_SYMBOL(of_find_mipi_dsi_host_by_node);
+
int mipi_dsi_host_register(struct mipi_dsi_host *host)
{
struct device_node *node;
@@ -227,6 +249,10 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
of_mipi_dsi_device_add(host, node);
}
+ mutex_lock(_lock);
+ list_add_tail(>list, _list);
+ mutex_unlock(_lock);
+
return 0;
}
EXPORT_SYMBOL(mipi_dsi_host_register);
@@ -243,6 +269,10 @@ static int mipi_dsi_remove_device_fn(struct device *dev,
void *priv)
void mipi_dsi_host_unregister(struct mipi_dsi_host *host)
{
device_for_each_child(host->dev, NULL, mipi_dsi_remove_device_fn);
+
+ mutex_lock(_lock);
+ list_del_init(>list);
+ mutex_unlock(_lock);
}
EXPORT_SYMBOL(mipi_dsi_host_unregister);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 68f49f4..15d3068 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -100,10 +100,12 @@ struct mipi_dsi_host_ops {
struct mipi_dsi_host {
struct device *dev;
const struct mipi_dsi_host_ops *ops;
+ struct list_head list;
};
int mipi_dsi_host_register(struct mipi_dsi_host *host);
void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
+struct mipi_dsi_host *of_find_mipi_dsi_host_by_node(struct device_node *node);
/* DSI mode flags */
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/4] perf report: Add callchain value option
Now -g/--call-graph option supports how to display callchain values.
Possible values are 'percent', 'period' and 'count'. The percent is
same as before and it's the default behavior. The period displays the
raw period value rather than the percentage. The count displays the
number of occurrences.
$ perf report --no-children --stdio -g percent
...
39.93% swapper [kernel.vmlinux] [k] intel_idel
|
---intel_idle
cpuidle_enter_state
cpuidle_enter
call_cpuidle
cpu_startup_entry
|
|--28.63%-- start_secondary
|
--11.30%-- rest_init
$ perf report --no-children --show-total-period --stdio -g period
...
39.93% 13018705 swapper [kernel.vmlinux] [k] intel_idel
|
---intel_idle
cpuidle_enter_state
cpuidle_enter
call_cpuidle
cpu_startup_entry
|
|--9334403-- start_secondary
|
--3684302-- rest_init
$ perf report --no-children --show-nr-samples --stdio -g count
...
39.93% 80 swapper [kernel.vmlinux] [k] intel_idel
|
---intel_idle
cpuidle_enter_state
cpuidle_enter
call_cpuidle
cpu_startup_entry
|
|--57-- start_secondary
|
--23-- rest_init
Cc: Brendan Gregg
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-report.txt | 13 ---
tools/perf/builtin-report.c | 4 +--
tools/perf/ui/stdio/hist.c | 10 +-
tools/perf/util/callchain.c | 60 +++-
tools/perf/util/callchain.h | 10 +-
tools/perf/util/util.c | 3 +-
6 files changed, 83 insertions(+), 17 deletions(-)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 5ce8da1e1256..bb9fd23a105e 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -170,11 +170,11 @@ OPTIONS
Dump raw trace in ASCII.
-g::
---call-graph=::
+--call-graph=::
Display call chains using type, min percent threshold, print limit,
- call order, sort key and branch. Note that ordering of parameters is
not
- fixed so any parement can be given in an arbitraty order. One exception
- is the print_limit which should be preceded by threshold.
+ call order, sort key, optional branch and value. Note that ordering of
+ parameters is not fixed so any parement can be given in an arbitraty
order.
+ One exception is the print_limit which should be preceded by threshold.
print_type can be either:
- flat: single column, linear exposure of call chains.
@@ -204,6 +204,11 @@ OPTIONS
- branch: include last branch information in callgraph when available.
Usually more convenient to use --branch-history for this.
+ value can be:
+ - percent: diplay overhead percent (default)
+ - period: display event period
+ - count: display evnt count
+
--children::
Accumulate callchain of children to parent entry so that then can
show up in the output. The output will have a new "Children" column
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 2853ad2bd435..3dd4bb4ded1a 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -625,7 +625,7 @@ parse_percent_limit(const struct option *opt, const char
*str,
return 0;
}
-#define CALLCHAIN_DEFAULT_OPT "graph,0.5,caller,function"
+#define CALLCHAIN_DEFAULT_OPT "graph,0.5,caller,function,percent"
const char report_callchain_help[] = "Display call graph (stack
chain/backtrace):\n\n"
CALLCHAIN_REPORT_HELP
@@ -708,7 +708,7 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_BOOLEAN('x', "exclude-other", _conf.exclude_other,
"Only display entries with parent-match"),
OPT_CALLBACK_DEFAULT('g', "call-graph", ,
-
"print_type,threshold[,print_limit],order,sort_key[,branch]",
+
"print_type,threshold[,print_limit],order,sort_key[,branch],value",
report_callchain_help, _parse_callchain_opt,
callchain_default_opt),
OPT_BOOLEAN(0, "children", _conf.cumulate_callchain,
diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index 9b5a0d8a43dc..c0580f5ea7ea 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -81,13 +81,14 @@ static size_t __callchain__fprintf_graph(FILE *fp, struct
rb_root *root,
int
[PATCH v3 3/4] perf callchain: Add count fields to struct callchain_node
It's to track the count of occurrences of the callchains.
Cc: Brendan Gregg
Signed-off-by: Namhyung Kim
---
tools/perf/util/callchain.c | 10 ++
tools/perf/util/callchain.h | 7 +++
2 files changed, 17 insertions(+)
diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
index 44184d198855..0a97d77509bd 100644
--- a/tools/perf/util/callchain.c
+++ b/tools/perf/util/callchain.c
@@ -437,6 +437,8 @@ add_child(struct callchain_node *parent,
new->children_hit = 0;
new->hit = period;
+ new->children_count = 0;
+ new->count = 1;
return new;
}
@@ -484,6 +486,9 @@ split_add_child(struct callchain_node *parent,
parent->children_hit = callchain_cumul_hits(new);
new->val_nr = parent->val_nr - idx_local;
parent->val_nr = idx_local;
+ new->count = parent->count;
+ new->children_count = parent->children_count;
+ parent->children_count = callchain_cumul_counts(new);
/* create a new child for the new branch if any */
if (idx_total < cursor->nr) {
@@ -494,6 +499,8 @@ split_add_child(struct callchain_node *parent,
parent->hit = 0;
parent->children_hit += period;
+ parent->count = 0;
+ parent->children_count += 1;
node = callchain_cursor_current(cursor);
new = add_child(parent, cursor, period);
@@ -516,6 +523,7 @@ split_add_child(struct callchain_node *parent,
rb_insert_color(>rb_node_in, >rb_root_in);
} else {
parent->hit = period;
+ parent->count = 1;
}
}
@@ -562,6 +570,7 @@ append_chain_children(struct callchain_node *root,
inc_children_hit:
root->children_hit += period;
+ root->children_count++;
}
static int
@@ -614,6 +623,7 @@ append_chain(struct callchain_node *root,
/* we match 100% of the path, increment the hit */
if (matches == root->val_nr && cursor->pos == cursor->nr) {
root->hit += period;
+ root->count++;
return 0;
}
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index 3a90a57f6213..2f948f0ff034 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -60,6 +60,8 @@ struct callchain_node {
struct rb_root rb_root_in; /* input tree of children */
struct rb_root rb_root;/* sorted output tree of children */
unsigned intval_nr;
+ unsigned intcount;
+ unsigned intchildren_count;
u64 hit;
u64 children_hit;
};
@@ -145,6 +147,11 @@ static inline u64 callchain_cumul_hits(struct
callchain_node *node)
return node->hit + node->children_hit;
}
+static inline int callchain_cumul_counts(struct callchain_node *node)
+{
+ return node->count + node->children_count;
+}
+
int callchain_register_param(struct callchain_param *param);
int callchain_append(struct callchain_root *root,
struct callchain_cursor *cursor,
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel oops on mmotm-2015-10-15-15-20
On Tue, Nov 03, 2015 at 12:02:58PM +0900, Minchan Kim wrote: > Hello Kirill, > > On Mon, Nov 02, 2015 at 02:57:49PM +0200, Kirill A. Shutemov wrote: > > On Fri, Oct 30, 2015 at 04:03:50PM +0900, Minchan Kim wrote: > > > On Thu, Oct 29, 2015 at 11:52:06AM +0200, Kirill A. Shutemov wrote: > > > > On Thu, Oct 29, 2015 at 04:58:29PM +0900, Minchan Kim wrote: > > > > > On Thu, Oct 29, 2015 at 02:25:24AM +0200, Kirill A. Shutemov wrote: > > > > > > On Thu, Oct 22, 2015 at 06:00:51PM +0900, Minchan Kim wrote: > > > > > > > On Thu, Oct 22, 2015 at 10:21:36AM +0900, Minchan Kim wrote: > > > > > > > > Hello Hugh, > > > > > > > > > > > > > > > > On Wed, Oct 21, 2015 at 05:59:59PM -0700, Hugh Dickins wrote: > > > > > > > > > On Thu, 22 Oct 2015, Minchan Kim wrote: > > > > > > > > > > > > > > > > > > > > I added the code to check it and queued it again but I had > > > > > > > > > > another oops > > > > > > > > > > in this time but symptom is related to anon_vma, too. > > > > > > > > > > (kernel is based on recent mmotm + unconditional mkdirty > > > > > > > > > > for bug fix) > > > > > > > > > > It seems page_get_anon_vma returns NULL since the page was > > > > > > > > > > not page_mapped > > > > > > > > > > at that time but second check of page_mapped right before > > > > > > > > > > try_to_unmap seems > > > > > > > > > > to be true. > > > > > > > > > > > > > > > > > > > > Adding 4191228k swap on /dev/vda5. Priority:-1 extents:1 > > > > > > > > > > across:4191228k FS > > > > > > > > > > Adding 4191228k swap on /dev/vda5. Priority:-1 extents:1 > > > > > > > > > > across:4191228k FS > > > > > > > > > > page:ea0001cfbfc0 count:3 mapcount:1 > > > > > > > > > > mapping:88007f1b5f51 index:0x60aff > > > > > > > > > > flags: > > > > > > > > > > 0x40048019(locked|uptodate|dirty|swapcache|swapbacked) > > > > > > > > > > page dumped because: VM_BUG_ON_PAGE(PageAnon(page) && > > > > > > > > > > !PageKsm(page) && !anon_vma) > > > > > > > > > > > > > > > > > > That's interesting, that's one I added in my page migration > > > > > > > > > series. > > > > > > > > > Let me think on it, but it could well relate to the one you > > > > > > > > > got before. > > > > > > > > > > > > > > > > I will roll back to mm/madv_free-v4.3-rc5-mmotm-2015-10-15-15-20 > > > > > > > > instead of next-20151021 to remove noise from your migration > > > > > > > > cleanup > > > > > > > > series and will test it again. > > > > > > > > If it is fixed, I will test again with your migration patchset, > > > > > > > > then. > > > > > > > > > > > > > > I tested mmotm-2015-10-15-15-20 with test program I attach for a > > > > > > > long time. > > > > > > > Therefore, there is no patchset from Hugh's migration patch in > > > > > > > there. > > > > > > > And I added below debug code with request from Kirill to all test > > > > > > > kernels. > > > > > > > > > > > > It took too long time (and a lot of printk()), but I think I track > > > > > > it down > > > > > > finally. > > > > > > > > > > > > The patch below seems fixes issue for me. It's not yet properly > > > > > > tested, but > > > > > > looks like it works. > > > > > > > > > > > > The problem was my wrong assumption on how migration works: I > > > > > > thought that > > > > > > kernel would wait migration to finish on before deconstruction > > > > > > mapping. > > > > > > > > > > > > But turn out that's not true. > > > > > > > > > > > > As result if zap_pte_range() races with split_huge_page(), we can > > > > > > end up > > > > > > with page which is not mapped anymore but has _count and _mapcount > > > > > > elevated. The page is on LRU too. So it's still reachable by vmscan > > > > > > and by > > > > > > pfn scanners (Sasha showed few similar traces from compaction too). > > > > > > It's likely that page->mapping in this case would point to freed > > > > > > anon_vma. > > > > > > > > > > > > BOOM! > > > > > > > > > > > > The patch modify freeze/unfreeze_page() code to match normal > > > > > > migration > > > > > > entries logic: on setup we remove page from rmap and drop pin, on > > > > > > removing > > > > > > we get pin back and put page on rmap. This way even if migration > > > > > > entry > > > > > > will be removed under us we don't corrupt page's state. > > > > > > > > > > > > Please, test. > > > > > > > > > > > > > > > > kernel: On mmotm-2015-10-15-15-20 + pte_mkdirty patch + your new > > > > > patch, I tested > > > > > one I sent to you(ie, oops.c + memcg_test.sh) > > > > > > > > > > page:ea00016a count:3 mapcount:0 mapping:88007f49d001 > > > > > index:0x61800 compound_mapcount: 0 > > > > > flags: 0x40044009(locked|uptodate|head|swapbacked) > > > > > page dumped because: VM_BUG_ON_PAGE(!page_mapcount(page)) > > > > > page->mem_cgroup:88007f613c00 > > > > > > > > Ignore my previous answer. Still sleeping. > > > > > > > > The right way to fix I think is something like: > > > > > > > > diff --git a/mm/rmap.c
Re: [PATCHv2] rtc: Add a driver for Micro Crystal RV8803
It looks like it is worth a check. julia On Tue, 3 Nov 2015, kbuild test robot wrote: > CC: kbuild-...@01.org > In-Reply-To: > <1446504512-9079-1-git-send-email-alexandre.bell...@free-electrons.com> > TO: Alexandre Belloni > CC: Alessandro Zummo , rtc-li...@googlegroups.com, > linux-kernel@vger.kernel.org, Alexandre Belloni > > CC: rtc-li...@googlegroups.com, linux-kernel@vger.kernel.org, Alexandre > Belloni > > Hi Alexandre, > > [auto build test WARNING on abelloni/rtc-next -- if it's inappropriate base, > please suggest rules for selecting the more suitable base] > > url: > https://github.com/0day-ci/linux/commits/Alexandre-Belloni/rtc-Add-a-driver-for-Micro-Crystal-RV8803/20151103-065235 > :: branch date: 51 minutes ago > :: commit date: 51 minutes ago > > >> drivers/rtc/rtc-rv8803.c:244:2-8: preceding lock on line 240 > > git remote add linux-review https://github.com/0day-ci/linux > git remote update linux-review > git checkout f8c59e6bf4a130cb2f46cad981771dddecc406ff > vim +244 drivers/rtc/rtc-rv8803.c > > f8c59e6b Alexandre Belloni 2015-11-02 234time64_t alarm_time = > rtc_tm_to_time64(>time); > f8c59e6b Alexandre Belloni 2015-11-02 235 > f8c59e6b Alexandre Belloni 2015-11-02 236alarm_time += 60 - > alrm->time.tm_sec; > f8c59e6b Alexandre Belloni 2015-11-02 237 > rtc_time64_to_tm(alarm_time, >time); > f8c59e6b Alexandre Belloni 2015-11-02 238} > f8c59e6b Alexandre Belloni 2015-11-02 239 > f8c59e6b Alexandre Belloni 2015-11-02 @240 > spin_lock_irqsave(>flags_lock, irqflags); > f8c59e6b Alexandre Belloni 2015-11-02 241 > f8c59e6b Alexandre Belloni 2015-11-02 242ret = > i2c_smbus_read_i2c_block_data(client, RV8803_FLAG, 2, ctrl); > f8c59e6b Alexandre Belloni 2015-11-02 243if (ret != 2) > f8c59e6b Alexandre Belloni 2015-11-02 @244return ret < 0 ? ret : > -EIO; > f8c59e6b Alexandre Belloni 2015-11-02 245 > f8c59e6b Alexandre Belloni 2015-11-02 246alarmvals[0] = > bin2bcd(alrm->time.tm_min); > f8c59e6b Alexandre Belloni 2015-11-02 247alarmvals[1] = > bin2bcd(alrm->time.tm_hour); > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation > -- 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 1/1] usb:serial: Add Fintek F81532/534 driver
Hi Peter, [auto build test ERROR on usb/usb-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Peter-Hung/usb-serial-Add-Fintek-F81532-534-driver/20151103-115336 config: tile-allyesconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=tile All errors (new ones prefixed by >>): drivers/usb/serial/f81534.c:504:1: warning: data definition has no type or storage class [enabled by default] drivers/usb/serial/f81534.c:504:1: error: type defaults to 'int' in declaration of 'MODULE_DEVICE_TABLE' drivers/usb/serial/f81534.c:504:1: warning: parameter names (without types) in function declaration [enabled by default] drivers/usb/serial/f81534.c:522:19: error: field 'f81534_gpio_chip' has incomplete type drivers/usb/serial/f81534.c: In function 'f81534_gpio_get': drivers/usb/serial/f81534.c:849:4: error: dereferencing pointer to incomplete type drivers/usb/serial/f81534.c: In function 'f81534_gpio_set': drivers/usb/serial/f81534.c:886:33: error: dereferencing pointer to incomplete type drivers/usb/serial/f81534.c: In function 'f81534_gpio_request': drivers/usb/serial/f81534.c:926:33: error: dereferencing pointer to incomplete type drivers/usb/serial/f81534.c: In function 'f81534_gpio_free': drivers/usb/serial/f81534.c:937:33: error: dereferencing pointer to incomplete type drivers/usb/serial/f81534.c: At top level: drivers/usb/serial/f81534.c:960:15: error: variable 'f81534_gpio_chip_templete' has initializer but incomplete type drivers/usb/serial/f81534.c:961:2: error: unknown field 'owner' specified in initializer drivers/usb/serial/f81534.c:961:11: warning: excess elements in struct initializer [enabled by default] drivers/usb/serial/f81534.c:961:11: warning: (near initialization for 'f81534_gpio_chip_templete') [enabled by default] drivers/usb/serial/f81534.c:962:2: error: unknown field 'get_direction' specified in initializer drivers/usb/serial/f81534.c:962:2: warning: excess elements in struct initializer [enabled by default] drivers/usb/serial/f81534.c:962:2: warning: (near initialization for 'f81534_gpio_chip_templete') [enabled by default] drivers/usb/serial/f81534.c:963:2: error: unknown field 'get' specified in initializer drivers/usb/serial/f81534.c:963:2: warning: excess elements in struct initializer [enabled by default] drivers/usb/serial/f81534.c:963:2: warning: (near initialization for 'f81534_gpio_chip_templete') [enabled by default] drivers/usb/serial/f81534.c:964:2: error: unknown field 'direction_input' specified in initializer drivers/usb/serial/f81534.c:964:2: warning: excess elements in struct initializer [enabled by default] drivers/usb/serial/f81534.c:964:2: warning: (near initialization for 'f81534_gpio_chip_templete') [enabled by default] drivers/usb/serial/f81534.c:965:2: error: unknown field 'set' specified in initializer drivers/usb/serial/f81534.c:965:2: warning: excess elements in struct initializer [enabled by default] drivers/usb/serial/f81534.c:965:2: warning: (near initialization for 'f81534_gpio_chip_templete') [enabled by default] drivers/usb/serial/f81534.c:966:2: error: unknown field 'direction_output' specified in initializer drivers/usb/serial/f81534.c:966:2: warning: excess elements in struct initializer [enabled by default] drivers/usb/serial/f81534.c:966:2: warning: (near initialization for 'f81534_gpio_chip_templete') [enabled by default] drivers/usb/serial/f81534.c:967:2: error: unknown field 'request' specified in initializer drivers/usb/serial/f81534.c:967:2: warning: excess elements in struct initializer [enabled by default] drivers/usb/serial/f81534.c:967:2: warning: (near initialization for 'f81534_gpio_chip_templete') [enabled by default] drivers/usb/serial/f81534.c:968:2: error: unknown field 'free' specified in initializer drivers/usb/serial/f81534.c:968:2: warning: excess elements in struct initializer [enabled by default] drivers/usb/serial/f81534.c:968:2: warning: (near initialization for 'f81534_gpio_chip_templete') [enabled by default] drivers/usb/serial/f81534.c:969:2: error: unknown field 'ngpio' specified in initializer drivers/usb/serial/f81534.c:969:2: warning: excess elements in struct initializer [enabled by default] drivers/usb/serial/f81534.c:969:2: warning: (near initialization for 'f81534_gpio_chip_templete') [enabled by default] drivers/usb/serial/f81534.c:970:2: error: unknown field 'base' specified in initializer drivers/usb/serial/f81534.c:970:2: warning: excess elements in struct initializer [enabled by default] drivers/usb/serial/f81534.c:970:2: warning: (near
Re: [PATCH RESEND 02/16] Documentation: dt-bindings: backlight: add TI LMU backlight binding information
On 11/3/2015 12:02 AM, Rob Herring wrote: On Sun, Nov 1, 2015 at 11:24 PM, Milo Kim wrote: LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697 use common dt-bindings for describing device. Cc: devicet...@vger.kernel.org Cc: Jingoo Han Cc: Lee Jones Cc: linux-kernel@vger.kernel.org Signed-off-by: Milo Kim --- .../bindings/video/backlight/ti-lmu-backlight.txt | 67 ++ Please move to bindings/leds/backlight/ There are backlight bindings under video/backlight. I'd like to know why this 'led' location is preferred. My guess is most of properties are from common LED properties. Any other reasons? 1 file changed, 67 insertions(+) create mode 100644 Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt diff --git a/Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt b/Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt new file mode 100644 index 000..27b0036 --- /dev/null +++ b/Documentation/devicetree/bindings/video/backlight/ti-lmu-backlight.txt @@ -0,0 +1,67 @@ +TI LMU backlight device tree bindings + +Required properties: + - compatible: Should be one of lists below. +"ti,lm3532-backlight" +"ti,lm3631-backlight" +"ti,lm3632-backlight" +"ti,lm3633-backlight" +"ti,lm3695-backlight" +"ti,lm3697-backlight" + +Optional properties: + There are two backlight control mode. One is I2C, the other is PWM mode. + Following properties are only specified in PWM mode. + Please note that LMU backlight device can have only one PWM channel. + + - pwms: OF device-tree PWM specification. + - pwm-names: a list of names for the PWM devices specified in the "pwms" + property. + + For the PWM user nodes, please refer to [1]. + +Child nodes: + LMU backlight is represented as sub-nodes of the TI LMU device [2]. + So, LMU backlight should have more than one backlight child node. + Each node exactly matches with backlight control bank configuration. + Maximum numbers of child nodes depend on the device. + 1 = LM3631, LM3632, LM3695 + 2 = LM3633, LM3697 + 3 = LM3532 + + Required property of a child node: + - hvled1-used, hvled2-used, hvled3-used: +High voltage backlight strings configuration. Type is . +Please describe which output backlight string is used. +Please refer to the datasheets [3]. Use led-sources. OK. + + Optional properties of a child node: + - backlight-name: Name string for backlight device identification. +It is used for creating backlight sysfs, +/sys/class/backlight//. Use label. Got it. + - backlight-max-microamp: Max current setting. Type is . +Unit is microampere. +Range is from 5000 to 3. Use led-max-microamp OK. + - initial-brightness: Backlight initial brightness value. Type is . +It is set as soon as backlight device is created. +0 ~ 2047 = LM3631, LM3632, LM3633, LM3695 and LM3697 +0 ~ 255 = LM3532 Use default-brightness-level I'll update the bindings and drivers based on your 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/
Re: Documentation: update of USB_CHIPIDEA_DEBUG
On Mon, Nov 02, 2015 at 05:15:08PM +0800, Valentin Rothberg wrote:
> Hi Peter,
>
> your commit 2fb2884ed856 ("usb: chipidea: delete static debug support")
> has shown up in today's Linux next tree (i.e., next-20151102) and
> removes the Kconfig option USB_CHIPIDEA_DEBUG in favor of dynamic debug
> support. However, there are some documentary references on this option
> still left in the code that may need to be updated:
>
> Documentation/usb/chipidea.txt-9-If you want to check some internal variables
> for otg fsm,
> Documentation/usb/chipidea.txt:10:select CONFIG_USB_CHIPIDEA_DEBUG, there are
> 2 files which
> ^
> Documentation/usb/chipidea.txt-11-can show otg fsm variables and some
> controller registers value:
> --
> drivers/usb/chipidea/core.c-25- * Compile Options
> drivers/usb/chipidea/core.c:26: * - CONFIG_USB_CHIPIDEA_DEBUG: enable debug
> facilities
> ^
> drivers/usb/chipidea/core.c-27- * - STALL_IN: non-empty bulk-in pipes cannot
> be halted
>
>
> I'm just pointing to those references, since I don't know if you want to
> keep them in the code or not. I found the issue and your commit with
> scipts/checkkconfigsymbols.py.
Thanks, Valentin. I will change them.
>
> Kind regards,
> Valentin
--
Best Regards,
Peter Chen
--
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/7] spi: imx: Fix DMA transfer
On Sun, Nov 01, 2015 at 03:41:35PM +0100, Anton Bondarenko wrote:
> From: Anton Bondarenko
>
> RX DMA tail data handling doesn't work correctly in many cases with
> current implementation. It happens because SPI core was setup
> to generates both RX watermark level and RX DATA TAIL events
> incorrectly. SPI transfer triggering for DMA also done in wrong way.
>
> SPI client wants to transfer 70 words for example. The old DMA
> implementation setup RX DATA TAIL equal 6 words. In this case
> RX DMA event will be generated after 6 words read from RX FIFO.
> The garbage can be read out from RX FIFO because SPI HW does
> not receive all required words to trigger RX watermark event.
>
> New implementation change handling of RX data tail. DMA is used to process
> all TX data and only full chunks of RX data with size aligned to FIFO/2.
> Driver is waiting until both TX and RX DMA transaction done and all
> TX data are pushed out. At that moment there is only RX data tail in
> the RX FIFO. This data read out using PIO.
>
> Transfer triggering changed to avoid RX data loss.
>
> Signed-off-by: Anton Bondarenko
> ---
> drivers/spi/spi-imx.c | 115
> +-
> 1 file changed, 76 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index 0e5723a..bd7b721 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -53,6 +53,7 @@
> /* generic defines to abstract from the different register layouts */
> #define MXC_INT_RR (1 << 0) /* Receive data ready interrupt */
> #define MXC_INT_TE (1 << 1) /* Transmit FIFO empty interrupt */
> +#define MXC_INT_TCEN BIT(7) /* Transfer complete */
>
> /* The maximum bytes that a sdma BD can transfer.*/
> #define MAX_SDMA_BD_BYTES (1 << 15)
> @@ -104,9 +105,7 @@ struct spi_imx_data {
> unsigned int dma_is_inited;
> unsigned int dma_finished;
> bool usedma;
> - u32 rx_wml;
> - u32 tx_wml;
> - u32 rxt_wml;
> + u32 wml;
> struct completion dma_rx_completion;
> struct completion dma_tx_completion;
>
> @@ -201,9 +200,7 @@ static bool spi_imx_can_dma(struct spi_master *master,
> struct spi_device *spi,
> {
> struct spi_imx_data *spi_imx = spi_master_get_devdata(master);
>
> - if (spi_imx->dma_is_inited
> - && transfer->len > spi_imx->rx_wml * sizeof(u32)
> - && transfer->len > spi_imx->tx_wml * sizeof(u32))
> + if (spi_imx->dma_is_inited && transfer->len > spi_imx->wml)
> return true;
> return false;
> }
> @@ -228,6 +225,7 @@ static bool spi_imx_can_dma(struct spi_master *master,
> struct spi_device *spi,
> #define MX51_ECSPI_INT 0x10
> #define MX51_ECSPI_INT_TEEN (1 << 0)
> #define MX51_ECSPI_INT_RREN (1 << 3)
> +#define MX51_ECSPI_INT_TCEN BIT(7)
>
> #define MX51_ECSPI_DMA 0x14
> #define MX51_ECSPI_DMA_TX_WML_OFFSET 0
> @@ -292,6 +290,9 @@ static void __maybe_unused mx51_ecspi_intctrl(struct
> spi_imx_data *spi_imx, int
> if (enable & MXC_INT_RR)
> val |= MX51_ECSPI_INT_RREN;
>
> + if (enable & MXC_INT_TCEN)
> + val |= MX51_ECSPI_INT_TCEN;
> +
> writel(val, spi_imx->base + MX51_ECSPI_INT);
> }
>
> @@ -311,8 +312,9 @@ static void __maybe_unused mx51_ecspi_trigger(struct
> spi_imx_data *spi_imx)
> static int __maybe_unused mx51_ecspi_config(struct spi_imx_data *spi_imx,
> struct spi_imx_config *config)
> {
> - u32 ctrl = MX51_ECSPI_CTRL_ENABLE, cfg = 0, dma = 0;
> - u32 tx_wml_cfg, rx_wml_cfg, rxt_wml_cfg;
> + u32 ctrl = MX51_ECSPI_CTRL_ENABLE, dma = 0;
> + u32 cfg = readl(spi_imx->base + MX51_ECSPI_CONFIG);
> +
> u32 clk = config->speed_hz, delay;
>
> /*
> @@ -376,19 +378,9 @@ static int __maybe_unused mx51_ecspi_config(struct
> spi_imx_data *spi_imx,
>* and enable DMA request.
>*/
> if (spi_imx->dma_is_inited) {
> - dma = readl(spi_imx->base + MX51_ECSPI_DMA);
> -
> - spi_imx->rxt_wml = spi_imx_get_fifosize(spi_imx) / 2;
> - rx_wml_cfg = spi_imx->rx_wml << MX51_ECSPI_DMA_RX_WML_OFFSET;
> - tx_wml_cfg = spi_imx->tx_wml << MX51_ECSPI_DMA_TX_WML_OFFSET;
> - rxt_wml_cfg = spi_imx->rxt_wml << MX51_ECSPI_DMA_RXT_WML_OFFSET;
> - dma = (dma & ~MX51_ECSPI_DMA_TX_WML_MASK
> -& ~MX51_ECSPI_DMA_RX_WML_MASK
> -& ~MX51_ECSPI_DMA_RXT_WML_MASK)
> -| rx_wml_cfg | tx_wml_cfg | rxt_wml_cfg
> -|(1 << MX51_ECSPI_DMA_TEDEN_OFFSET)
> -|(1 << MX51_ECSPI_DMA_RXDEN_OFFSET)
> -|(1 << MX51_ECSPI_DMA_RXTDEN_OFFSET);
> + dma = (spi_imx->wml - 1) << MX51_ECSPI_DMA_RX_WML_OFFSET
> + | (1 << MX51_ECSPI_DMA_TEDEN_OFFSET)
> + | (1 << MX51_ECSPI_DMA_RXDEN_OFFSET);
>
>
Re: [PATCH] regulator: Use regulator_lock_supply() for get_voltage() too
Hi Mark,
[auto build test WARNING on regulator/for-next -- if it's inappropriate base,
please suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Mark-Brown/regulator-Use-regulator_lock_supply-for-get_voltage-too/20151103-144509
config: x86_64-randconfig-x013-11022153 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
drivers/regulator/core.c: In function '_regulator_get_voltage':
>> drivers/regulator/core.c:3113:32: warning: passing argument 1 of
>> '_regulator_get_voltage' from incompatible pointer type
>> [-Wincompatible-pointer-types]
ret = _regulator_get_voltage(rdev->supply);
^
drivers/regulator/core.c:3097:12: note: expected 'struct regulator_dev *'
but argument is of type 'struct regulator *'
static int _regulator_get_voltage(struct regulator_dev *rdev)
^
drivers/regulator/core.c: In function 'regulator_get_voltage':
>> drivers/regulator/core.c:3140:26: warning: passing argument 1 of
>> 'regulator_unlock_supply' from incompatible pointer type
>> [-Wincompatible-pointer-types]
regulator_unlock_supply(>rdev->mutex);
^
drivers/regulator/core.c:159:13: note: expected 'struct regulator_dev *' but
argument is of type 'struct mutex *'
static void regulator_unlock_supply(struct regulator_dev *rdev)
^
vim +/_regulator_get_voltage +3113 drivers/regulator/core.c
3107 ret = rdev->desc->ops->get_voltage(rdev);
3108 } else if (rdev->desc->ops->list_voltage) {
3109 ret = rdev->desc->ops->list_voltage(rdev, 0);
3110 } else if (rdev->desc->fixed_uV && (rdev->desc->n_voltages ==
1)) {
3111 ret = rdev->desc->fixed_uV;
3112 } else if (rdev->supply) {
> 3113 ret = _regulator_get_voltage(rdev->supply);
3114 } else {
3115 return -EINVAL;
3116 }
3117
3118 if (ret < 0)
3119 return ret;
3120 return ret - rdev->constraints->uV_offset;
3121 }
3122
3123 /**
3124 * regulator_get_voltage - get regulator output voltage
3125 * @regulator: regulator source
3126 *
3127 * This returns the current regulator voltage in uV.
3128 *
3129 * NOTE: If the regulator is disabled it will return the voltage value.
This
3130 * function should not be used to determine regulator state.
3131 */
3132 int regulator_get_voltage(struct regulator *regulator)
3133 {
3134 int ret;
3135
3136 regulator_lock_supply(regulator->rdev);
3137
3138 ret = _regulator_get_voltage(regulator->rdev);
3139
> 3140 regulator_unlock_supply(>rdev->mutex);
3141
3142 return ret;
3143 }
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH v2 4/4] ocfs2: check/fix inode block for online file check
Hi Gang,
This is not like a right patch.
First, online file check only checks inode's block number, valid flag,
fs generation value, and meta ecc. I never see a real corruption
happened only on this field, if these fields are corrupted, that means
something bad may happen on other place. So fix this field may not help
and even cause corruption more hard.
Second, the repair way is wrong. In
ocfs2_filecheck_repair_inode_block(), if these fields in disk don't
match the ones in memory, the ones in memory are used to update the disk
fields. The question is how do you know these field in memory are
right(they may be the real corrupted ones)?
Thanks,
Junxiao.
On 10/28/2015 02:26 PM, Gang He wrote:
> +static int ocfs2_filecheck_repair_inode_block(struct super_block *sb,
> +struct buffer_head *bh)
> +{
> + int rc;
> + int changed = 0;
> + struct ocfs2_dinode *di = (struct ocfs2_dinode *)bh->b_data;
> +
> + rc = ocfs2_filecheck_validate_inode_block(sb, bh);
> + /* Can't fix invalid inode block */
> + if (!rc || rc == -OCFS2_FILECHECK_ERR_INVALIDINO)
> + return rc;
> +
> + trace_ocfs2_filecheck_repair_inode_block(
> + (unsigned long long)bh->b_blocknr);
> +
> + if (ocfs2_is_hard_readonly(OCFS2_SB(sb)) ||
> + ocfs2_is_soft_readonly(OCFS2_SB(sb))) {
> + mlog(ML_ERROR,
> + "Filecheck: try to repair dinode #%llu on readonly
> filesystem\n",
> + (unsigned long long)bh->b_blocknr);
> + return -OCFS2_FILECHECK_ERR_READONLY;
> + }
> +
> + if (le64_to_cpu(di->i_blkno) != bh->b_blocknr) {
> + di->i_blkno = cpu_to_le64(bh->b_blocknr);
> + changed = 1;
> + mlog(ML_ERROR,
> + "Filecheck: reset dinode #%llu: i_blkno to %llu\n",
> + (unsigned long long)bh->b_blocknr,
> + (unsigned long long)le64_to_cpu(di->i_blkno));
> + }
> +
> + if (!(di->i_flags & cpu_to_le32(OCFS2_VALID_FL))) {
> + di->i_flags |= cpu_to_le32(OCFS2_VALID_FL);
> + changed = 1;
> + mlog(ML_ERROR,
> + "Filecheck: reset dinode #%llu: OCFS2_VALID_FL is
> set\n",
> + (unsigned long long)bh->b_blocknr);
> + }
> +
> + if (le32_to_cpu(di->i_fs_generation) !=
> + OCFS2_SB(sb)->fs_generation) {
> + di->i_fs_generation = cpu_to_le32(OCFS2_SB(sb)->fs_generation);
> + changed = 1;
> + mlog(ML_ERROR,
> + "Filecheck: reset dinode #%llu: fs_generation to %u\n",
> + (unsigned long long)bh->b_blocknr,
> + le32_to_cpu(di->i_fs_generation));
> + }
> +
> + if (changed ||
> + ocfs2_validate_meta_ecc(sb, bh->b_data, >i_check)) {
> + ocfs2_compute_meta_ecc(sb, bh->b_data, >i_check);
> + mark_buffer_dirty(bh);
> + mlog(ML_ERROR,
> + "Filecheck: reset dinode #%llu: compute meta ecc\n",
> + (unsigned long long)bh->b_blocknr);
> + }
> +
> + return 0;
> +}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 00/16] Support TI LMU devices
Hi Lee, On 11/2/2015 6:00 PM, Lee Jones wrote: Is it just me, or have you missed lots of people off Cc? Ah, that's what I was hesitating... What is the best way to submit MFD code patches? Cc for all people from get_maintainer.pl? 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] clocksource: dw_apb_timer_of: support timer-based delay
Dear Arnd, On Mon, 2 Nov 2015 22:56:02 +0100 Arnd Bergmann wrote: > On Monday 02 November 2015 11:03:34 Jisheng Zhang wrote: > > On Fri, 30 Oct 2015 13:42:01 +0100 Arnd Bergmann wrote: > > > > > > This is not ideal from an overall maintenance perspective. We want to > > > be able to have a kernel with all drivers enabled that gives us the > > > best behavior on all platforms. > > > > > > The current behavior appears to be that we override all previous > > > registrations as long as the new one is higher resolution. Is that > > > the case here? I.e. does the arch timer have a lower resultion than > > > the dw-apb timer but have some other advantages? > > > > Take one Marvell Berlin platform for example, the arch timer freq is 25MHZ, > > whose resolution is lower than the dw apb timer at 100MHZ. But dw apb timer > > is on the APB bus while arch timer sits in CPU, so I guess the cost of > > accessing the apb timer is higher than arch timer. > > Ok, I see. > > > I have a solution for this case: in platforms with arch timer, I can mark > > the dw apb timer as "disabled" in the dts even though the timer sits there. > > Then I could make DW_APB_TIMER_BASED_DELAY non-optional but selected by the > > the ARCH_XYZ. Is this acceptable? > > That would do the right thing, but doesn't look ideal: The DW_APB timer > on those platforms is fully functional, and a future Linux version or > another OS might decide to use both timers for one reason or another. > > I'd be happier with a solution that keeps the DT describing the hardware > and not the way we expect Linux to use it, and instead has some heuristic > in the selection of the delay timer. At the moment, we purely base this > on the frequency, which as you say is suboptimal. > > One possible way to improve this would be to add an optional 'latency' > property to the DT nodes (or the driver), and use a combination of latency > and resolution to make the decision. Got it. Thanks for the suggestions. The 'latency' here seems a 'rating' similar as the one in clocksource. I will cook a series for review: patch 1 to make register_current_timer_delay() aware of 'rating' patch 2 to set rating of arch timer as 400 patch 3 to add timer based delay support to dw_apb_timer whose rating is 300 Thanks a lot, Jisheng > A simpler way would be to always prefer the arch timer on ARM if that > is present, even if another timer has a higher resolution. This should > be only a few additional lines in register_current_timer_delay(), or > possibly an additional function argument. > -- 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 1/4] Documentation: dt-bindings: Describe SROMc configuration
Hello!
> >>> --- cut exynos5410.dtsi ---
> >>> sromc: sromc@1225 {
> >>> #address-cells = <2>;
> >>> #size-cells = <1>;
> >>> ranges = <0 0 0x0400 0x2
> >>> 1 0 0x0500 0x2
> >>> 2 0 0x0600 0x2
> >>> 3 0 0x0700 0x2>;
> >>
> >> Do you have to use 2 cells for address? Cannot it be:
> >>ranges = <0 0x0400 0x2
> >> 1 0x0500 0x2
> >> 2 0x0600 0x2
> >> 3 0x0700 0x2>;
> >
> > I tried this first, but it didn't work, and ranges translation
> > gave me something really weird (like addr = 0x80 and
> > size = 0x0404).
>
> Did you change the address-cells to <1>?
Of course i did.
I don't quote the rest because i simply agree to what you've said. Will respin
with these changes.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
--
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 04/16] Documentation: dt-bindings: leds: add LM3633 LED binding information
Hi Rob, On 11/2/2015 11:53 PM, Rob Herring wrote: On Sun, Nov 1, 2015 at 11:01 PM, Milo Kim wrote: LM3633 LED device is one of TI LMU device list. Cc: devicet...@vger.kernel.org Cc: Jacek Anaszewski Cc: Lee Jones Cc: linux-kernel@vger.kernel.org Cc: linux-l...@vger.kernel.org Signed-off-by: Milo Kim --- .../devicetree/bindings/leds/leds-lm3633.txt | 28 ++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3633.txt diff --git a/Documentation/devicetree/bindings/leds/leds-lm3633.txt b/Documentation/devicetree/bindings/leds/leds-lm3633.txt new file mode 100644 index 000..bb7f213 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-lm3633.txt @@ -0,0 +1,28 @@ +TI LMU LM3633 LED device tree bindings + +Required properties: + - compatible: "ti,lm3633-leds" + +Child nodes: + Each node matches with LED control bank. + Please refer to the datasheet [1]. + + Required properties of a child node: + - lvled1-used, lvled2-used, lvled3-used, +lvled4-used, lvled5-used, lvled6-used: +Low voltage LED string configuration. Type is . +Please describe which output LED string is used. What is "LED string"? Let me replace these properties with 'led-sources'. We have properties for which LED driver/channel of the parent to use and "status" can be used to disable child nodes. + + Optional properties of a child node: + - channel-name: Name string for LED channel identification + It is used for creating LED sysfs, + /sys/class/leds//. + If this property is empty, then default name is set to + "indicator:" by the driver. I believe "label" already provides this function. Yep, got it. 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/
Re: [PATCH RESEND 14/16] hwmon: add TI LMU hardware fault monitoring driver
Hi Guenter, On 11/2/2015 11:27 PM, Guenter Roeck wrote: On 11/01/2015 09:24 PM, Milo Kim wrote: LM3633 and LM3697 are TI LMU MFD device. Those device have hardware monitoring feature which detects opened or shorted circuit case. Sure, but it only makes sense if you provide standard hwmon attributes which can be interpreted by the "sensors" command. Which is not the case here. You neither have a standard device type (light is not handled by hwmon), nor standard attributes, nor do the attributes return standard values. I think there may be a basic misunderstanding. hwmon is not intended to monitor a specific chip on the board. Its scope is to monitor the system (such as temperature, voltages, or current). In your case, it might be better to attach the attributes to the mfd device. OK, got your point. Thanks a lot for your suggestion. 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 kernel] rcu: Define lockless version of list_for_each_entry_rcu
This defines list_for_each_entry_lockless. This allows safe list traversing in cases when lockdep() invocation is unwanted like real mode (MMU is off). Signed-off-by: Alexey Kardashevskiy --- This is for VFIO acceleration in POWERKVM for pSeries guests. There is a KVM instance. There also can be some VFIO (PCI passthru) devices attached to a KVM guest. To perform DMA, a pSeries guest registers DMA memory by calling some hypercalls explicitely at the rate close to one-two hcalls per a network packet, i.e. very often. When a guest does a hypercall (which is just an assembly instruction), the host kernel receives it in the real mode (MMU is off). When real mode fails to handle it, it enables MMU and tries handling a hcall in virtual mode. A logical bus ID (LIOBN) is a tagret id for these hypecalls. Each VFIO device belongs to an IOMMU group. Each group has an address translation table. It is allowed to have multiple IOMMU groups (i.e. multiple tables) under the same LIOBN. So effectively every DMA hcall has to update one or more TCE tables attached to the same LIOBN. RCU is used to update/traverse this list safely. Using RCU as is in virtual mode is fine. Lockdep works, etc. list_add_rcu() is used to populate the list; list_del_rcu() + call_rcu() used to remove groups from a list. These operations can happen in runtim as a result of PCI hotplug/unplug in guests. Using RCU as is in real mode is not fine as some RCU checks can lock up the system and in real mode we won't even have a chance to see any debug. This is why rcu_read_lock() and rcu_read_unlock() are NOT used. Previous version of this used to define list_for_each_entry_rcu_notrace() but it was proposed to use list_entry_lockless() instead. However the comment for lockless_dereference() suggests this is a good idea if "lifetime is managed by something other than RCU" but it is in my case. So what would be the correct approach here? Thanks. --- include/linux/rculist.h | 16 1 file changed, 16 insertions(+) diff --git a/include/linux/rculist.h b/include/linux/rculist.h index 17c6b1f..a83a924 100644 --- a/include/linux/rculist.h +++ b/include/linux/rculist.h @@ -308,6 +308,22 @@ static inline void list_splice_init_rcu(struct list_head *list, pos = list_entry_rcu(pos->member.next, typeof(*pos), member)) /** + * list_for_each_entry_lockless - iterate over rcu list of given type + * @pos: the type * to use as a loop cursor. + * @head: the head for your list. + * @member:the name of the list_struct within the struct. + * + * This list-traversal primitive may safely run concurrently + */ +#define list_entry_lockless(ptr, type, member) \ + container_of((typeof(ptr))lockless_dereference(ptr), type, member) + +#define list_for_each_entry_lockless(pos, head, member) \ + for (pos = list_entry_lockless((head)->next, typeof(*pos), member); \ + >member != (head); \ + pos = list_entry_lockless(pos->member.next, typeof(*pos), member)) + +/** * list_for_each_entry_continue_rcu - continue iteration over list of given type * @pos: the type * to use as a loop cursor. * @head: the head for your list. -- 2.5.0.rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 16/16] regulator: add LM363X driver
On 11/2/2015 9:26 PM, Mark Brown wrote: On Mon, Nov 02, 2015 at 02:24:35PM +0900, Milo Kim wrote: LM363X regulator driver supports LM3631 and LM3632. LM3631 has 5 regulators. LM3632 provides 3 regulators. One boost output and LDOs are used for the display module. Boost voltage is configurable but always on. Supported operations for LDOs are enabled/disabled and voltage change. As far as I can tell this is another partial resend of a series you originally sent about 15 minutes previously - what's going on here? My apologies, I did send patches without --thread and --no-chain-reply-to options. So I've resent the patch-set. 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 RESEND 00/16] Support TI LMU devices
Hi Lee, On 11/2/2015 5:59 PM, Lee Jones wrote: drivers/video/backlight/Kconfig| 62 ++ > drivers/video/backlight/Makefile | 7 + > drivers/video/backlight/lm3532_bl.c| 183 + > drivers/video/backlight/lm3631_bl.c| 129 > drivers/video/backlight/lm3632_bl.c| 125 > drivers/video/backlight/lm3633_bl.c| 210 ++ > drivers/video/backlight/lm3695_bl.c| 91 +++ > drivers/video/backlight/lm3697_bl.c| 187 + > drivers/video/backlight/ti-lmu-backlight.c | 429 > drivers/video/backlight/ti-lmu-backlight.h | 152 + How different are all of these drivers? Can you create one driver that supports them all instead? Thanks for your suggestion. 'ti-lmu-backlight' is the common part of lm_bl drivers. And each lmxxx_bl has its own operation functions by using ti_lmu_bl_ops. I've tried to make consolidated driver but it contained too much device specific code in one file. So I prefer simple drivers structure - 'common part' and 'device specific operations'. It would be appreciated if you could introduce better idea. 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 V6 1/1] usb:serial: Add Fintek F81532/534 driver
Hi Peter,
[auto build test ERROR on usb/usb-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Peter-Hung/usb-serial-Add-Fintek-F81532-534-driver/20151103-115336
config: m68k-allyesconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k
All error/warnings (new ones prefixed by >>):
>> drivers/usb/serial/f81534.c:504:1: warning: data definition has no type or
>> storage class
MODULE_DEVICE_TABLE(usb, id_table);
^
>> drivers/usb/serial/f81534.c:504:1: error: type defaults to 'int' in
>> declaration of 'MODULE_DEVICE_TABLE' [-Werror=implicit-int]
>> drivers/usb/serial/f81534.c:504:1: warning: parameter names (without types)
>> in function declaration
>> drivers/usb/serial/f81534.c:522:19: error: field 'f81534_gpio_chip' has
>> incomplete type
struct gpio_chip f81534_gpio_chip;
^
In file included from include/linux/list.h:8:0,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from drivers/usb/serial/f81534.c:99:
drivers/usb/serial/f81534.c: In function 'f81534_gpio_get':
>> drivers/usb/serial/f81534.c:849:21: error: dereferencing pointer to
>> incomplete type
container_of(chip->dev, struct usb_serial_port, dev);
^
include/linux/kernel.h:811:49: note: in definition of macro 'container_of'
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
drivers/usb/serial/f81534.c: In function 'f81534_gpio_set':
drivers/usb/serial/f81534.c:887:8: error: dereferencing pointer to
incomplete type
chip->dev, struct usb_serial_port, dev);
^
include/linux/kernel.h:811:49: note: in definition of macro 'container_of'
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
drivers/usb/serial/f81534.c: In function 'f81534_gpio_request':
drivers/usb/serial/f81534.c:927:8: error: dereferencing pointer to
incomplete type
chip->dev, struct usb_serial_port, dev);
^
include/linux/kernel.h:811:49: note: in definition of macro 'container_of'
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
drivers/usb/serial/f81534.c: In function 'f81534_gpio_free':
drivers/usb/serial/f81534.c:938:8: error: dereferencing pointer to
incomplete type
chip->dev, struct usb_serial_port, dev);
^
include/linux/kernel.h:811:49: note: in definition of macro 'container_of'
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
drivers/usb/serial/f81534.c: At top level:
>> drivers/usb/serial/f81534.c:960:15: error: variable
>> 'f81534_gpio_chip_templete' has initializer but incomplete type
static struct gpio_chip f81534_gpio_chip_templete = {
^
>> drivers/usb/serial/f81534.c:961:2: error: unknown field 'owner' specified in
>> initializer
.owner = THIS_MODULE,
^
In file included from include/linux/linkage.h:6:0,
from include/linux/preempt.h:9,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:5,
from include/linux/slab.h:14,
from drivers/usb/serial/f81534.c:99:
include/linux/export.h:36:30: warning: excess elements in struct initializer
#define THIS_MODULE ((struct module *)0)
^
>> drivers/usb/serial/f81534.c:961:11: note: in expansion of macro 'THIS_MODULE'
.owner = THIS_MODULE,
^
include/linux/export.h:36:30: warning: (near initialization for
'f81534_gpio_chip_templete')
#define THIS_MODULE ((struct module *)0)
^
>> drivers/usb/serial/f81534.c:961:11: note: in expansion of macro 'THIS_MODULE'
.owner = THIS_MODULE,
^
>> drivers/usb/serial/f81534.c:962:2: error: unknown field 'get_direction'
>> specified in initializer
.get_direction = f81534_gpio_get_direction,
^
>> drivers/usb/serial/f81534.c:962:2: warning: excess elements in struct
>> initializer
drivers/usb/serial/f81534.c:962:2: warning: (near initialization for
'f81534_gpio_chip_templete')
>> drivers/usb/serial/f81534.c:963:2: error: unknown field 'get' specified in
>> initializer
.get = f81534_gpio_get,
^
[PATCH V3 2/3] perf/powerpc :add support for sampling intr machine state
The perf infrastructure uses a bit mask to find out
valid registers to display. Define a register mask
for supported registers defined in asm/perf_regs.h.
The bit positions also correspond to register IDs
which is used by perf infrastructure to fetch the register
values.CONFIG_HAVE_PERF_REGS enables
sampling of the interrupted machine state.
Signed-off-by: Anju T
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/perf/Makefile| 2 +
arch/powerpc/perf/perf_regs.c | 92 +++
3 files changed, 95 insertions(+)
create mode 100644 arch/powerpc/perf/perf_regs.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9a7057e..c4ce60d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -119,6 +119,7 @@ config PPC
select GENERIC_ATOMIC64 if PPC32
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select HAVE_PERF_EVENTS
+ select HAVE_PERF_REGS
select HAVE_REGS_AND_STACK_ACCESS_API
select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
select ARCH_WANT_IPC_PARSE_VERSION
diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
index f9c083a..cbae78a 100644
--- a/arch/powerpc/perf/Makefile
+++ b/arch/powerpc/perf/Makefile
@@ -7,6 +7,8 @@ obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o
power5-pmu.o \
power5+-pmu.o power6-pmu.o power7-pmu.o \
power8-pmu.o
obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o
+obj-$(CONFIG_PERF_EVENTS) += perf_regs.o
+
obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o
obj-$(CONFIG_FSL_EMB_PERF_EVENT_E500) += e500-pmu.o e6500-pmu.o
diff --git a/arch/powerpc/perf/perf_regs.c b/arch/powerpc/perf/perf_regs.c
new file mode 100644
index 000..0520492
--- /dev/null
+++ b/arch/powerpc/perf/perf_regs.c
@@ -0,0 +1,92 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PT_REGS_OFFSET(id, r) [id] = offsetof(struct pt_regs, r)
+
+#define REG_RESERVED (~((1ULL << PERF_REG_POWERPC_MAX) - 1))
+
+static unsigned int pt_regs_offset[PERF_REG_POWERPC_MAX] = {
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR0, gpr[0]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR1, gpr[1]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR2, gpr[2]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR3, gpr[3]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR4, gpr[4]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR5, gpr[5]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR6, gpr[6]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR7, gpr[7]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR8, gpr[8]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR9, gpr[9]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR10, gpr[10]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR11, gpr[11]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR12, gpr[12]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR13, gpr[13]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR14, gpr[14]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR15, gpr[15]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR16, gpr[16]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR17, gpr[17]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR18, gpr[18]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR19, gpr[19]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR20, gpr[20]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR21, gpr[21]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR22, gpr[22]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR23, gpr[23]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR24, gpr[24]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR25, gpr[25]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR26, gpr[26]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR27, gpr[27]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR28, gpr[28]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR29, gpr[29]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR30, gpr[30]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_GPR31, gpr[31]),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_NIP, nip),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_MSR, msr),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_ORIG_R3, orig_gpr3),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_CTR, ctr),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_LNK, link),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_XER, xer),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_CCR, ccr),
+#ifdef __powerpc64__
+ PT_REGS_OFFSET(PERF_REG_POWERPC_SOFTE, softe),
+#else
+ PT_REGS_OFFSET(PERF_REG_POWERPC_MQ, mq),
+#endif
+ PT_REGS_OFFSET(PERF_REG_POWERPC_TRAP, trap),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_DAR, dar),
+ PT_REGS_OFFSET(PERF_REG_POWERPC_DSISR, dsisr),
+};
+
+u64 perf_reg_value(struct pt_regs *regs, int idx)
+{
+ if (WARN_ON_ONCE(idx >= PERF_REG_POWERPC_MAX))
+ return 0;
+ return regs_get_register(regs, pt_regs_offset[idx]);
+}
+
+int perf_reg_validate(u64 mask)
+{
+ if (!mask || mask & REG_RESERVED)
+ return -EINVAL;
+ return 0;
+}
+
+u64
[PATCH v2 1/2] watchdog: add WDIOC_SETPRETIMEOUT and WDIOC_GETPRETIMEOUT
Since the watchdog common framework centrialize the IOCTL interfaces of
device driver now, the SETPRETIMEOUT and GETPRETIMEOUT need to be added
in the common code.
Signed-off-by: Robin Gong
---
drivers/watchdog/watchdog_dev.c | 37 +
include/linux/watchdog.h| 10 ++
2 files changed, 47 insertions(+)
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 6aaefba..f4a02e5 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -218,6 +218,37 @@ out_timeout:
}
/*
+ * watchdog_set_pretimeout: set the watchdog timer pretimeout
+ * @wddev: the watchdog device to set the timeout for
+ * @timeout: pretimeout to set in seconds
+ */
+
+static int watchdog_set_pretimeout(struct watchdog_device *wddev,
+ unsigned int timeout)
+{
+ int err;
+
+ if (!wddev->ops->set_pretimeout ||
+ !(wddev->info->options & WDIOF_PRETIMEOUT))
+ return -EOPNOTSUPP;
+ if (watchdog_pretimeout_invalid(wddev, timeout))
+ return -EINVAL;
+
+ mutex_lock(>lock);
+
+ if (test_bit(WDOG_UNREGISTERED, >status)) {
+ err = -ENODEV;
+ goto out_timeout;
+ }
+
+ err = wddev->ops->set_pretimeout(wddev, timeout);
+
+out_timeout:
+ mutex_unlock(>lock);
+ return err;
+}
+
+/*
* watchdog_get_timeleft: wrapper to get the time left before a reboot
* @wddev: the watchdog device to get the remaining time from
* @timeleft: the time that's left
@@ -393,6 +424,12 @@ static long watchdog_ioctl(struct file *file, unsigned int
cmd,
if (err)
return err;
return put_user(val, p);
+ case WDIOC_SETPRETIMEOUT:
+ if (get_user(val, p))
+ return -EFAULT;
+ return watchdog_set_pretimeout(wdd, val);
+ case WDIOC_GETPRETIMEOUT:
+ return put_user(wdd->pretimeout, p);
default:
return -ENOTTY;
}
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index d74a0e9..f936152 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -25,6 +25,7 @@ struct watchdog_device;
* @ping: The routine that sends a keepalive ping to the watchdog device.
* @status:The routine that shows the status of the watchdog device.
* @set_timeout:The routine for setting the watchdog devices timeout value.
+ * @set_pretimeout:The routine for setting the watchdog devices pretimeout.
* @get_timeleft:The routine that get's the time that's left before a reset.
* @ref: The ref operation for dyn. allocated watchdog_device structs
* @unref: The unref operation for dyn. allocated watchdog_device structs
@@ -44,6 +45,7 @@ struct watchdog_ops {
int (*ping)(struct watchdog_device *);
unsigned int (*status)(struct watchdog_device *);
int (*set_timeout)(struct watchdog_device *, unsigned int);
+ int (*set_pretimeout)(struct watchdog_device *, unsigned int);
unsigned int (*get_timeleft)(struct watchdog_device *);
void (*ref)(struct watchdog_device *);
void (*unref)(struct watchdog_device *);
@@ -86,6 +88,7 @@ struct watchdog_device {
const struct watchdog_ops *ops;
unsigned int bootstatus;
unsigned int timeout;
+ unsigned int pretimeout;
unsigned int min_timeout;
unsigned int max_timeout;
void *driver_data;
@@ -123,6 +126,13 @@ static inline bool watchdog_timeout_invalid(struct
watchdog_device *wdd, unsigne
(t < wdd->min_timeout || t > wdd->max_timeout));
}
+/* Use the following function to check if a pretimeout value is invalid */
+static inline bool watchdog_pretimeout_invalid(struct watchdog_device *wdd,
+ unsigned int t)
+{
+ return wdd->timeout && t >= wdd->timeout;
+}
+
/* Use the following functions to manipulate watchdog driver specific data */
static inline void watchdog_set_drvdata(struct watchdog_device *wdd, void
*data)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 0/3] perf/powerpc:Add ability to sample intr machine state in powerpc
This short patch series adds the ability to sample the interrupted machine state for each hardware sample. To test this patchset, Eg: $perf record -I ls // record machine state at interrupt $perf script -D //read the perf.data file Sample output obtained for this patchset/ output looks like as follows: 331557004666 0x1988 [0x188]: PERF_RECORD_SAMPLE(IP, 0x1): 4807/4807: 0xc01ddf60 period: 1 addr: 0 ... intr regs: mask 0x7ff ABI 64-bit gpr0 0xc01e6a74 gpr1 0xc000ff33b9a0 gpr2 0xc1523000 gpr3 0xc00ffa9deb60 gpr4 0xc000ff971e00 gpr5 0x4d32564532 gpr6 0x1e00 gpr7 0x0 gpr8 0x0 gpr9 0x0 gpr10 0x1 gpr11 0x0 gpr12 0x24022822 gpr13 0xcfeeaf80 gpr14 0x0 gpr15 0xc000fbc21000 gpr16 0x0 gpr17 0xc00ffa9c5000 gpr18 0xc000ff33b8a0 gpr19 0xc1523000 gpr20 0xc00a097c gpr21 0xc00fcac65600 gpr22 0xc01e55a8 gpr23 0xc1523000 gpr24 0xc000ff33b850 gpr25 0xc00fcac65600 gpr26 0xc01e4b378210 gpr27 0xfead gpr28 0x1 gpr29 0xc00fcac65600 gpr30 0x1 gpr31 0x0 nip 0xc01ddf68 msr 0x90009032 orig_r3 0xc01e5fcc ctr 0xc009e1b0 link 0xc01e6a74 xer 0x0 ccr 0x84022882 softe 0x0 trap 0xf01 dar 0x0 dsisr 0xf0004006004 ... thread: :4807:4807 .. dso: /root/.debug/.build-id/1c/011201a1082e91b8449e6dd528f224d7a16535 :4807 4807 331.557004: 1 cycles: c01ddf60 .perf_ctx_unlock (/boot/vmlinux) 0x1b10 [0x188]: event: 9 Changes from V2: - tools/perf/config/Makefile is moved to the patch tools/perf. - The patchset is reordered. - perf_regs_load() function is used for the dwarf unwind test.Since it is not required here, it is removed from tools/perf/arch/powerpc/include/perf_regs.h - PERF_REGS_POWERPC_RESULT is removed. Anju T (3): perf/powerpc:add ability to sample intr machine state in power perf/powerpc :add support for sampling intr machine state tools/perf:Map the ID values with register names arch/powerpc/Kconfig| 1 + arch/powerpc/include/uapi/asm/perf_regs.h | 54 + arch/powerpc/perf/Makefile | 2 + arch/powerpc/perf/perf_regs.c | 92 ++ tools/perf/arch/powerpc/include/perf_regs.h | 114 tools/perf/config/Makefile | 5 ++ 6 files changed, 268 insertions(+) create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h create mode 100644 arch/powerpc/perf/perf_regs.c create mode 100644 tools/perf/arch/powerpc/include/perf_regs.h -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] AVR32 update for 4.3
Hello Linus, please pull git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32.git for-linus to receive the following AVR32 update for 4.3 Alexandre Belloni (1): avr32: atngw100: remove useless include arch/avr32/boards/atngw100/mrmt.c | 1 - 1 file changed, 1 deletion(-) -- Best regards, Hans-Christian Egtvedt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/3] dmaselftest: add memcpy selftest support functions
On Mon, Nov 02, 2015 at 11:18:37PM -0500, Sinan Kaya wrote: > > > On 11/2/2015 11:15 PM, Vinod Koul wrote: > >On Mon, Nov 02, 2015 at 01:07:38AM -0500, Sinan Kaya wrote: > >>This patch adds supporting utility functions > >>for selftest. The intention is to share the self > >>test code between different drivers. > >> > >>Supported test cases include: > >>1. dma_map_single > >>2. streaming DMA > >>3. coherent DMA > >>4. scatter-gather DMA > > > >This seems quite similar to dmatest, any reason why you cannot use/enhance > >that? > > > Dmatest is a standalone kernel module intended for stress testing > DMA engines from userspace with N number of threads and M size > combinations etc. > > This one; on the other hand, is selftest to verify hardware is > working as expected during power up. > > Almost all DMA engine drivers come with some sort of selftest code > called from probe. I followed the same design pattern. which ones ? > > I think the goal is to remove the duplicate self test code in all > drivers over time. and what prevents us from having common selftest plus dmatest code. Most of the code here to do selftest is _same_ dmaengine routine code used in dmatest We can have common code which is used for dmatest as well as selftest. I do not want to see same code duplicated.. -- ~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 V3 3/3] tools/perf:Map the ID values with register names
Map ID values with corresponding register names.These names are then
displayed when user issues perf record with the -I option
followed by perf report/script with -D option.
Signed-off-by: Anju T
---
tools/perf/arch/powerpc/include/perf_regs.h | 114
tools/perf/config/Makefile | 5 ++
2 files changed, 119 insertions(+)
create mode 100644 tools/perf/arch/powerpc/include/perf_regs.h
diff --git a/tools/perf/arch/powerpc/include/perf_regs.h
b/tools/perf/arch/powerpc/include/perf_regs.h
new file mode 100644
index 000..47307ca
--- /dev/null
+++ b/tools/perf/arch/powerpc/include/perf_regs.h
@@ -0,0 +1,114 @@
+#ifndef ARCH_PERF_REGS_H
+#define ARCH_PERF_REGS_H
+
+#include
+#include
+#include
+
+#define PERF_REGS_MASK ((1ULL << PERF_REG_POWERPC_MAX) - 1)
+#define PERF_REGS_MAX PERF_REG_POWERPC_MAX
+#define PERF_SAMPLE_REGS_ABI PERF_SAMPLE_REGS_ABI_64
+
+#define PERF_REG_IP PERF_REG_POWERPC_NIP
+#define PERF_REG_SP PERF_REG_POWERPC_R1
+
+static inline const char *perf_reg_name(int id)
+{
+ switch (id) {
+ case PERF_REG_POWERPC_GPR0:
+ return "gpr0";
+ case PERF_REG_POWERPC_GPR1:
+ return "gpr1";
+ case PERF_REG_POWERPC_GPR2:
+ return "gpr2";
+ case PERF_REG_POWERPC_GPR3:
+ return "gpr3";
+ case PERF_REG_POWERPC_GPR4:
+ return "gpr4";
+ case PERF_REG_POWERPC_GPR5:
+ return "gpr5";
+ case PERF_REG_POWERPC_GPR6:
+ return "gpr6";
+ case PERF_REG_POWERPC_GPR7:
+ return "gpr7";
+ case PERF_REG_POWERPC_GPR8:
+ return "gpr8";
+ case PERF_REG_POWERPC_GPR9:
+ return "gpr9";
+ case PERF_REG_POWERPC_GPR10:
+ return "gpr10";
+ case PERF_REG_POWERPC_GPR11:
+ return "gpr11";
+ case PERF_REG_POWERPC_GPR12:
+ return "gpr12";
+ case PERF_REG_POWERPC_GPR13:
+ return "gpr13";
+ case PERF_REG_POWERPC_GPR14:
+ return "gpr14";
+ case PERF_REG_POWERPC_GPR15:
+ return "gpr15";
+ case PERF_REG_POWERPC_GPR16:
+ return "gpr16";
+ case PERF_REG_POWERPC_GPR17:
+ return "gpr17";
+ case PERF_REG_POWERPC_GPR18:
+ return "gpr18";
+ case PERF_REG_POWERPC_GPR19:
+ return "gpr19";
+ case PERF_REG_POWERPC_GPR20:
+ return "gpr20";
+ case PERF_REG_POWERPC_GPR21:
+ return "gpr21";
+ case PERF_REG_POWERPC_GPR22:
+ return "gpr22";
+ case PERF_REG_POWERPC_GPR23:
+ return "gpr23";
+ case PERF_REG_POWERPC_GPR24:
+ return "gpr24";
+ case PERF_REG_POWERPC_GPR25:
+ return "gpr25";
+ case PERF_REG_POWERPC_GPR26:
+ return "gpr26";
+ case PERF_REG_POWERPC_GPR27:
+ return "gpr27";
+ case PERF_REG_POWERPC_GPR28:
+ return "gpr28";
+ case PERF_REG_POWERPC_GPR29:
+ return "gpr29";
+ case PERF_REG_POWERPC_GPR30:
+ return "gpr30";
+ case PERF_REG_POWERPC_GPR31:
+ return "gpr31";
+ case PERF_REG_POWERPC_NIP:
+ return "nip";
+ case PERF_REG_POWERPC_MSR:
+ return "msr";
+ case PERF_REG_POWERPC_ORIG_R3:
+ return "orig_r3";
+ case PERF_REG_POWERPC_CTR:
+ return "ctr";
+ case PERF_REG_POWERPC_LNK:
+ return "link";
+ case PERF_REG_POWERPC_XER:
+ return "xer";
+ case PERF_REG_POWERPC_CCR:
+ return "ccr";
+#ifdef __powerpc64__
+ case PERF_REG_POWERPC_SOFTE:
+ return "softe";
+#else
+ case PERF_REG_POWERPC_MQ:
+ return "mq";
+#endif
+ case PERF_REG_POWERPC_TRAP:
+ return "trap";
+ case PERF_REG_POWERPC_DAR:
+ return "dar";
+ case PERF_REG_POWERPC_DSISR:
+ return "dsisr";
+ default:
+ return NULL;
+ }
+ return NULL;
+}
+#endif /*ARCH_PERF_REGS_H */
diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile
index 38a0853..3db9b5d 100644
--- a/tools/perf/config/Makefile
+++ b/tools/perf/config/Makefile
@@ -23,6 +23,11 @@ $(call detected_var,ARCH)
NO_PERF_REGS := 1
+#Additional ARCH settings for ppc64
+ifeq ($(ARCH),powerpc)
+ NO_PERF_REGS := 0
+endif
+
# Additional ARCH settings for x86
ifeq ($(ARCH),x86)
$(call detected,CONFIG_X86)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/2] watchdog: imx2_wdt: add set_pretimeout interface
Enable set_pretimeout interface and trigger the pretimeout interrupt before
watchdog timeout event happen.
Signed-off-by: Robin Gong
---
drivers/watchdog/imx2_wdt.c | 58 -
1 file changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 0bb1a1d..bd42857 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -52,12 +53,18 @@
#define IMX2_WDT_WRSR 0x04/* Reset Status Register */
#define IMX2_WDT_WRSR_TOUT (1 << 1)/* -> Reset due to Timeout */
+#define IMX2_WDT_WICR 0x06/*Interrupt Control Register*/
+#define IMX2_WDT_WICR_WIE (1 << 15) /* -> Interrupt Enable */
+#define IMX2_WDT_WICR_WTIS (1 << 14) /* -> Interrupt Status */
+#define IMX2_WDT_WICR_WICT (0xFF) /* Watchdog Interrupt Timeout */
+
#define IMX2_WDT_WMCR 0x08/* Misc Register */
#define IMX2_WDT_MAX_TIME 128
#define IMX2_WDT_DEFAULT_TIME 60 /* in seconds */
#define WDOG_SEC_TO_COUNT(s) ((s * 2 - 1) << 8)
+#define WDOG_SEC_TO_PRECOUNT(s)((s) * 2) /* set WDOG pre timeout
count*/
struct imx2_wdt_device {
struct clk *clk;
@@ -80,7 +87,8 @@ MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds
(default="
static const struct watchdog_info imx2_wdt_info = {
.identity = "imx2+ watchdog",
- .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE,
+ .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE
+ | WDIOF_PRETIMEOUT,
};
static int imx2_restart_handler(struct notifier_block *this, unsigned long
mode,
@@ -207,12 +215,49 @@ static inline void imx2_wdt_ping_if_active(struct
watchdog_device *wdog)
}
}
+static int imx2_wdt_set_pretimeout(struct watchdog_device *wdog,
+ unsigned int new_timeout)
+{
+ struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+ u32 val;
+
+ regmap_read(wdev->regmap, IMX2_WDT_WICR, );
+ /* set the new pre-timeout value in the WSR */
+ val &= ~IMX2_WDT_WICR_WICT;
+ val |= WDOG_SEC_TO_PRECOUNT(new_timeout);
+
+ regmap_write(wdev->regmap, IMX2_WDT_WICR, val | IMX2_WDT_WICR_WIE);
+
+ wdog->pretimeout = new_timeout;
+
+ return 0;
+}
+
+static irqreturn_t imx2_wdt_isr(int irq, void *dev_id)
+{
+ struct platform_device *pdev = dev_id;
+ struct watchdog_device *wdog = platform_get_drvdata(pdev);
+ struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+ u32 val;
+
+ regmap_read(wdev->regmap, IMX2_WDT_WICR, );
+ if (val & IMX2_WDT_WICR_WTIS) {
+ /*clear interrupt status bit*/
+ regmap_write(wdev->regmap, IMX2_WDT_WICR, val);
+ panic("pre-timeout:%d, %d Seconds remained\n", wdog->pretimeout,
+ wdog->timeout - wdog->pretimeout);
+ }
+
+ return IRQ_HANDLED;
+}
+
static const struct watchdog_ops imx2_wdt_ops = {
.owner = THIS_MODULE,
.start = imx2_wdt_start,
.stop = imx2_wdt_stop,
.ping = imx2_wdt_ping,
.set_timeout = imx2_wdt_set_timeout,
+ .set_pretimeout = imx2_wdt_set_pretimeout,
};
static const struct regmap_config imx2_wdt_regmap_config = {
@@ -229,6 +274,7 @@ static int __init imx2_wdt_probe(struct platform_device
*pdev)
struct resource *res;
void __iomem *base;
int ret;
+ int irq;
u32 val;
wdev = devm_kzalloc(>dev, sizeof(*wdev), GFP_KERNEL);
@@ -294,6 +340,16 @@ static int __init imx2_wdt_probe(struct platform_device
*pdev)
goto disable_clk;
}
+ irq = platform_get_irq(pdev, 0);
+ if (irq > 0) {
+ ret = devm_request_irq(>dev, irq, imx2_wdt_isr, 0,
+ dev_name(>dev), pdev);
+ if (ret) {
+ dev_err(>dev, "can't get irq %d\n", irq);
+ goto disable_clk;
+ }
+ }
+
wdev->restart_handler.notifier_call = imx2_restart_handler;
wdev->restart_handler.priority = 128;
ret = register_restart_handler(>restart_handler);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] regulator: Use regulator_lock_supply() for get_voltage() too
Since we need to read voltages of parents as part of setting supply
voltages we need to be able to do get_voltage() internally without
taking locks so reorganize the locking to take locks on the full tree on
entry rather than as we recurse when called externally.
Reported-by: John Stultz
Signed-off-by: Mark Brown
---
drivers/regulator/core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index ff9cc3a6895f..97749c3330a4 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3110,7 +3110,7 @@ static int _regulator_get_voltage(struct regulator_dev
*rdev)
} else if (rdev->desc->fixed_uV && (rdev->desc->n_voltages == 1)) {
ret = rdev->desc->fixed_uV;
} else if (rdev->supply) {
- ret = regulator_get_voltage(rdev->supply);
+ ret = _regulator_get_voltage(rdev->supply);
} else {
return -EINVAL;
}
@@ -3133,11 +3133,11 @@ int regulator_get_voltage(struct regulator *regulator)
{
int ret;
- mutex_lock(>rdev->mutex);
+ regulator_lock_supply(regulator->rdev);
ret = _regulator_get_voltage(regulator->rdev);
- mutex_unlock(>rdev->mutex);
+ regulator_unlock_supply(>rdev->mutex);
return ret;
}
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 1/3] perf/powerpc:add ability to sample intr machine state in power
The enum definition assigns an 'id' to each register in "struct pt_regs"
of arch/powerpc.The order of these values in the enum definition are
based on the corresponding macros in
arch/powerpc/include/uapi/asm/ptrace.h .
Signed-off-by: Anju T
---
arch/powerpc/include/uapi/asm/perf_regs.h | 54 +++
1 file changed, 54 insertions(+)
create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h
diff --git a/arch/powerpc/include/uapi/asm/perf_regs.h
b/arch/powerpc/include/uapi/asm/perf_regs.h
new file mode 100644
index 000..30fb601
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/perf_regs.h
@@ -0,0 +1,54 @@
+#ifndef _ASM_POWERPC_PERF_REGS_H
+#define _ASM_POWERPC_PERF_REGS_H
+
+enum perf_event_powerpc_regs {
+ PERF_REG_POWERPC_GPR0,
+ PERF_REG_POWERPC_GPR1,
+ PERF_REG_POWERPC_GPR2,
+ PERF_REG_POWERPC_GPR3,
+ PERF_REG_POWERPC_GPR4,
+ PERF_REG_POWERPC_GPR5,
+ PERF_REG_POWERPC_GPR6,
+ PERF_REG_POWERPC_GPR7,
+ PERF_REG_POWERPC_GPR8,
+ PERF_REG_POWERPC_GPR9,
+ PERF_REG_POWERPC_GPR10,
+ PERF_REG_POWERPC_GPR11,
+ PERF_REG_POWERPC_GPR12,
+ PERF_REG_POWERPC_GPR13,
+ PERF_REG_POWERPC_GPR14,
+ PERF_REG_POWERPC_GPR15,
+ PERF_REG_POWERPC_GPR16,
+ PERF_REG_POWERPC_GPR17,
+ PERF_REG_POWERPC_GPR18,
+ PERF_REG_POWERPC_GPR19,
+ PERF_REG_POWERPC_GPR20,
+ PERF_REG_POWERPC_GPR21,
+ PERF_REG_POWERPC_GPR22,
+ PERF_REG_POWERPC_GPR23,
+ PERF_REG_POWERPC_GPR24,
+ PERF_REG_POWERPC_GPR25,
+ PERF_REG_POWERPC_GPR26,
+ PERF_REG_POWERPC_GPR27,
+ PERF_REG_POWERPC_GPR28,
+ PERF_REG_POWERPC_GPR29,
+ PERF_REG_POWERPC_GPR30,
+ PERF_REG_POWERPC_GPR31,
+ PERF_REG_POWERPC_NIP,
+ PERF_REG_POWERPC_MSR,
+ PERF_REG_POWERPC_ORIG_R3,
+ PERF_REG_POWERPC_CTR,
+ PERF_REG_POWERPC_LNK,
+ PERF_REG_POWERPC_XER,
+ PERF_REG_POWERPC_CCR,
+#ifdef __powerpc64__
+ PERF_REG_POWERPC_SOFTE,
+#else
+ PERF_REG_POWERPC_MQ,
+#endif
+ PERF_REG_POWERPC_TRAP,
+ PERF_REG_POWERPC_DAR,
+ PERF_REG_POWERPC_DSISR,
+ PERF_REG_POWERPC_MAX,
+};
+#endif /* _ASM_POWERPC_PERF_REGS_H */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 3/4] ARM: dts: rockchip: Add Crypto drivers for rk3288
Add Crypto drivers for rk3288 including crypto controller and dma clk.
Signed-off-by: Zain Wang
---
arch/arm/boot/dts/rk3288.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 6a79c9c..7b7914e 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -170,6 +170,21 @@
};
};
+ crypto: cypto-controller@ff8a {
+ compatible = "rockchip,rk3288-crypto";
+ reg = <0xff8a 0x4000>;
+ interrupts = ;
+ clocks = < ACLK_CRYPTO>,
+< HCLK_CRYPTO>,
+< SCLK_CRYPTO>,
+< ACLK_DMAC1>;
+ clock-names = "aclk",
+ "hclk",
+ "sclk",
+ "apb_pclk";
+ status = "okay";
+ };
+
reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v1 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288
Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher
mode.
The names registered are:
ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
You can alloc tags above in your case.
And other algorithms and platforms will be added later on.
Signed-off-by: Zain Wang
---
drivers/crypto/Kconfig | 11 +
drivers/crypto/Makefile| 1 +
drivers/crypto/rockchip/Makefile | 3 +
drivers/crypto/rockchip/rk3288_crypto.c| 383
drivers/crypto/rockchip/rk3288_crypto.h| 290
drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 501 +
6 files changed, 1189 insertions(+)
create mode 100644 drivers/crypto/rockchip/Makefile
create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c
create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h
create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 2569e04..d1e42cf 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -498,4 +498,15 @@ config CRYPTO_DEV_SUN4I_SS
To compile this driver as a module, choose M here: the module
will be called sun4i-ss.
+config CRYPTO_DEV_ROCKCHIP
+ tristate "Rockchip's Cryptographic Engine driver"
+
+ select CRYPTO_AES
+ select CRYPTO_DES
+ select CRYPTO_BLKCIPHER
+
+ help
+ This driver interfaces with the hardware crypto accelerator.
+ Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
+
endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index c3ced6f..713de9d 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
+obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/
diff --git a/drivers/crypto/rockchip/Makefile b/drivers/crypto/rockchip/Makefile
new file mode 100644
index 000..7051c6c
--- /dev/null
+++ b/drivers/crypto/rockchip/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rk_crypto.o
+rk_crypto-objs := rk3288_crypto.o \
+ rk3288_crypto_ablkcipher.o \
diff --git a/drivers/crypto/rockchip/rk3288_crypto.c
b/drivers/crypto/rockchip/rk3288_crypto.c
new file mode 100644
index 000..02830f2
--- /dev/null
+++ b/drivers/crypto/rockchip/rk3288_crypto.c
@@ -0,0 +1,383 @@
+/*
+ *Crypto acceleration support for Rockchip RK3288
+ *
+ * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Author: Zain Wang
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * Some ideas are from marvell-cesa.c and s5p-sss.c driver.
+ */
+
+#include "rk3288_crypto.h"
+#include
+#include
+#include
+#include
+#include
+
+struct crypto_info_t *crypto_p;
+
+static int rk_crypto_enable_clk(struct crypto_info_t *dev)
+{
+ int err;
+
+ err = clk_prepare_enable(dev->sclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'sclk'\n",
+ __func__, __LINE__);
+ goto err_return;
+ }
+ err = clk_prepare_enable(dev->aclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
+ __func__, __LINE__);
+ goto err_aclk;
+ }
+ err = clk_prepare_enable(dev->hclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
+ __func__, __LINE__);
+ goto err_hclk;
+ }
+
+ err = clk_prepare_enable(dev->dmaclk);
+ if (err) {
+ dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'dmaclk'\n",
+ __func__, __LINE__);
+ goto err_dmaclk;
+ }
+ return err;
+err_dmaclk:
+ clk_disable_unprepare(dev->hclk);
+err_hclk:
+ clk_disable_unprepare(dev->aclk);
+err_aclk:
+ clk_disable_unprepare(dev->sclk);
+err_return:
+ return err;
+}
+
+static void rk_crypto_disable_clk(struct crypto_info_t *dev)
+{
+ clk_disable_unprepare(dev->dmaclk);
+ clk_disable_unprepare(dev->hclk);
+ clk_disable_unprepare(dev->aclk);
+ clk_disable_unprepare(dev->sclk);
+}
+
+static int check_alignment(struct scatterlist *sg_src,
+ struct scatterlist *sg_dst,
+ int align_mask)
+{
+ int in, out, align;
+
+ in = IS_ALIGNED((uint32_t)sg_src->offset, 4) &&
+IS_ALIGNED(sg_src->length, align_mask);
+ if (sg_dst
[PATCH v1 2/4] clk: rockchip: set an id for crypto clk
set an id for crypto clk, so that it can be called in other part.
Signed-off-by: Zain Wang
---
drivers/clk/rockchip/clk-rk3288.c | 2 +-
include/dt-bindings/clock/rk3288-cru.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c
b/drivers/clk/rockchip/clk-rk3288.c
index 9040878..3fceda1 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -295,7 +295,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[]
__initdata = {
RK3288_CLKGATE_CON(0), 4, GFLAGS),
GATE(0, "c2c_host", "aclk_cpu_src", 0,
RK3288_CLKGATE_CON(13), 8, GFLAGS),
- COMPOSITE_NOMUX(0, "crypto", "aclk_cpu_pre", 0,
+ COMPOSITE_NOMUX(SCLK_CRYPTO, "crypto", "aclk_cpu_pre", 0,
RK3288_CLKSEL_CON(26), 6, 2, DFLAGS,
RK3288_CLKGATE_CON(5), 4, GFLAGS),
GATE(0, "aclk_bus_2pmu", "aclk_cpu_pre", CLK_IGNORE_UNUSED,
diff --git a/include/dt-bindings/clock/rk3288-cru.h
b/include/dt-bindings/clock/rk3288-cru.h
index c719aac..30dcd60 100644
--- a/include/dt-bindings/clock/rk3288-cru.h
+++ b/include/dt-bindings/clock/rk3288-cru.h
@@ -86,6 +86,7 @@
#define SCLK_USBPHY480M_SRC122
#define SCLK_PVTM_CORE 123
#define SCLK_PVTM_GPU 124
+#define SCLK_CRYPTO125
#define SCLK_MAC 151
#define SCLK_MACREF_OUT152
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 02/15] dax: increase granularity of dax_clear_blocks() operations
On Mon, Nov 02, 2015 at 09:31:11PM -0800, Dan Williams wrote: > On Mon, Nov 2, 2015 at 8:48 PM, Dave Chinner wrote: > > On Mon, Nov 02, 2015 at 07:27:26PM -0800, Dan Williams wrote: > >> On Mon, Nov 2, 2015 at 4:51 PM, Dave Chinner wrote: > >> > On Sun, Nov 01, 2015 at 11:29:53PM -0500, Dan Williams wrote: > >> > The zeroing (and the data, for that matter) doesn't need to be > >> > committed to persistent store until the allocation is written and > >> > committed to the journal - that will happen with a REQ_FLUSH|REQ_FUA > >> > write, so it makes sense to deploy the big hammer and delay the > >> > blocking CPU cache flushes until the last possible moment in cases > >> > like this. > >> > >> In pmem terms that would be a non-temporal memset plus a delayed > >> wmb_pmem at REQ_FLUSH time. Better to write around the cache than > >> loop over the dirty-data issuing flushes after the fact. We'll bump > >> the priority of the non-temporal memset implementation. > > > > Why is it better to do two synchronous physical writes to memory > > within a couple of microseconds of CPU time rather than writing them > > through the cache and, in most cases, only doing one physical write > > to memory in a separate context that expects to wait for a flush > > to complete? > > With a switch to non-temporal writes they wouldn't be synchronous, > although it's doubtful that the subsequent writes after zeroing would > also hit the store buffer. > > If we had a method to flush by physical-cache-way rather than a > virtual address then it would indeed be better to save up for one > final flush, but when we need to resort to looping through all the > virtual addresses that might have touched it gets expensive. msync() is for flushing userspace mmap ranges addresses back to physical memory. fsync() is for flushing kernel addresses (i.e. as returned by bdev_direct_access()) back to physical addresses. msync() calls ->fsync() as part of it's operation, fsync() does not care about whether mmap has been sync'd first or not. i.e. we don't care about random dirty userspace virtual mappings in fsync() - if you have them then you need to call msync() first. So we shouldn't ever be having to walk virtual addresses in fsync - just the kaddr returned by bdev_direct_access() is all that fsync needs to flush... 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/
[PATCH v1 0/4] Crypto: add crypto accelerator support for rk3288
This commit support three cipher(AES/DES/DES3) and two chainmode(ecb/cbc), and the more algorithms and new hash drivers will be added later on. Zain Wang (4): Crypto: Crypto driver support aes/des/des3 for rk3288 clk: rockchip: set an id for crypto clk ARM: dts: rockchip: Add Crypto drivers for rk3288 crypto: rk_crypto - add DT bindings documentation .../devicetree/bindings/crypto/rockchip-crypto.txt | 29 ++ arch/arm/boot/dts/rk3288.dtsi | 15 + drivers/clk/rockchip/clk-rk3288.c | 2 +- drivers/crypto/Kconfig | 11 + drivers/crypto/Makefile| 1 + drivers/crypto/rockchip/Makefile | 3 + drivers/crypto/rockchip/rk3288_crypto.c| 383 drivers/crypto/rockchip/rk3288_crypto.h| 290 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 501 + include/dt-bindings/clock/rk3288-cru.h | 1 + 10 files changed, 1235 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/crypto/rockchip-crypto.txt create mode 100644 drivers/crypto/rockchip/Makefile create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V5 1/9] ACPI: Honor ACPI _CCA attribute setting
On Mon, Nov 02, 2015 at 09:51:46AM -0600, Suravee Suthikulanit wrote:
> Hi Dennis / Hanjun,
>
> On 11/2/2015 5:58 AM, Hanjun Guo wrote:
> >Hi Dennis,
> >
> >On 11/02/2015 12:02 PM, Dennis Chen wrote:
> >>On Thu, Oct 29, 2015 at 6:50 AM, Suravee Suthikulpanit
> >> wrote:
> >>>From: Jeremy Linton
> >>>
> >>>ACPI configurations can now mark devices as noncoherent,
> >>>support that choice.
> >>>
> >>>NOTE: This is required to support USB on ARM Juno Development Board.
> >>>
> >>>Signed-off-by: Jeremy Linton
> >>>Signed-off-by: Suravee Suthikulpanit
> >>>CC: Bjorn Helgaas
> >>>CC: Catalin Marinas
> >>>CC: Rob Herring
> >>>CC: Will Deacon
> >>>CC: Rafael J. Wysocki
> >>>---
> >>> include/acpi/acpi_bus.h | 5 +++--
> >>> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>>diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> >>>index d11eff8..0f131d2 100644
> >>>--- a/include/acpi/acpi_bus.h
> >>>+++ b/include/acpi/acpi_bus.h
> >>>@@ -407,7 +407,7 @@ static inline bool acpi_check_dma(struct
> >>>acpi_device *adev, bool *coherent)
> >>> * case 1. Do not support and disable DMA.
> >>> * case 2. Support but rely on arch-specific cache maintenance for
> >>> * non-coherence DMA operations.
> >>>- * Currently, we implement case 1 above.
> >>>+ * Currently, we implement case 2 above.
> >>> *
> >>> * For the case when _CCA is missing (i.e. cca_seen=0) and
> >>> * platform specifies ACPI_CCA_REQUIRED, we do not support DMA,
> >>>@@ -415,7 +415,8 @@ static inline bool acpi_check_dma(struct
> >>>acpi_device *adev, bool *coherent)
> >>> *
> >>> * See acpi_init_coherency() for more info.
> >>> */
> >>>-if (adev->flags.coherent_dma) {
> >>>+if (adev->flags.coherent_dma ||
> >>>+(adev->flags.cca_seen && IS_ENABLED(CONFIG_ARM64))) {
> >>> ret = true;
> >>> if (coherent)
> >>> *coherent = adev->flags.coherent_dma;
> >>
> >>Hi Suravee,
> >>
> >>The acpi_check_dma function has been removed in patch 6 of this patch
> >>set, why it is still be used
> >>here, am I missing something? If the acpi_check_dma will be used in
> >>the future, personally I'd like
> >
> >I think this patch just to let people know that there is
> >case that arch-specific cache maintenance is still needed
> >for ACPI (such as Juno board), and in the later patches will
> >cover this case.
> >
> >acpi_check_dma() will be replaced by acpi_get_dma_attr(),
> >and in acpi_get_dma_attr() will cover that case and will
> >be easily understood. (Suravee, correct me if I'm wrong :) )
>
> Thanks Hanjun for filling in the info.
>
> Yes, this is mainly to document the logic changes required by Juno,
> which would be more clear than just merging this change in the later
> patch.
>
Clear.
> >>to use IS_ENABLED(CONFIG_ACPI_CCA_REQUIRED) while not CONFIG_ARM64
> >>macro here,
>
> We could have used CONFIG_ACPI_CCA_REQUIRED here, but this will be
> replaced by logic in patch 5, and removed in patch 6 anyways. So, I
> think it is okay. Eventually, the rest of the logic will be using
> CONFIG_ACPI_CCA_REQUIRED.
>
> or since _CCA attribute
> >>is arch-specific, it's reasonable to leave the _CCA handling policy to
> >>the arch-specific code. For example,
> >>with a link weak function like acpi_arch_check_dma() as a default
> >>handling if no arch-specific code
> >>provided, the actual _CCA handling will be implemented in the ARM,
> >>Intel or other Arch if required.
> >
> >Actually Intel platform don't need _CCA and it's coherent
> >in default, since _CCA is in ACPI spec, I would like it's
> >handled in ACPI core.
> >
> >Thanks
> >Hanjun
>
> I also agree with Hanjun that the CCA parsing should be handled by
> the ACPI core driver. Since we are using the
> CONFIG_ACPI_CCA_REQUIRED, we should not need to have arch-specific
> code. If the ACPI spec gets more complicate in the future, we can
> revisit this. :)
>
Hmm, seems I have no objection currently if we only think about intel and
arm arch. Things maybe a little bit complicated if more Archs becomes
ACPI awareness, if any. Good to see the patch set upstream soon :) Thank you
Suravee and Hanjun.
> Thanks,
> Suravee
>
--
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 v1 4/4] crypto: rk_crypto - add DT bindings documentation
Add DT bindings documentation for the rk3288 crypto drivers.
Signed-off-by: Zain Wang
---
.../devicetree/bindings/crypto/rockchip-crypto.txt | 29 ++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
diff --git a/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
new file mode 100644
index 000..d27e203
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/rockchip-crypto.txt
@@ -0,0 +1,29 @@
+Rockchip Electronics And Security Accelerator
+
+Required properties:
+- compatible: Should be "rockchip,rk3288-crypto"
+- reg: base physical address of the engine and length of memory mapped
+ region
+- interrupts: interrupt number
+- clocks: reference to the clocks about crypto
+- clock-names: "aclk" used to clock data
+ "hclk" used to clock data
+ "srst" used to clock crypto accelerator
+ "apb_pclk" used to clock dma
+
+Examples:
+
+ crypto: cypto-controller@ff8a {
+ compatible = "rockchip,rk3288-crypto";
+ reg = <0xff8a 0x4000>;
+ interrupts = ;
+ clocks = < ACLK_CRYPTO>,
+< HCLK_CRYPTO>,
+< SCLK_CRYPTO>,
+< ACLK_DMAC1>;
+ clock-names = "aclk",
+ "hclk",
+ "sclk",
+ "apb_pclk";
+ status = "okay";
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/5] media: atmel-isi: prepare for the support of preview path
Atmel ISI support a preview path which can output RGB data.
So this patch introduces a bool variable to choose which path is
enabled currently. And also we need setup corresponding path registers.
By default the preview path is disabled. We only use Codec path.
Signed-off-by: Josh Wu
---
Changes in v2: None
drivers/media/platform/soc_camera/atmel-isi.c | 72 ++-
1 file changed, 49 insertions(+), 23 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index ce87a16..24501a4 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -79,6 +79,7 @@ struct atmel_isi {
dma_addr_t fb_descriptors_phys;
struct list_head dma_desc_head;
struct isi_dma_desc dma_desc[MAX_BUFFER_NUM];
+ boolenable_preview_path;
struct completion complete;
/* ISI peripherial clock */
@@ -195,11 +196,19 @@ static irqreturn_t atmel_isi_handle_streaming(struct
atmel_isi *isi)
/* start next dma frame. */
isi->active = list_entry(isi->video_buffer_list.next,
struct frame_buffer, list);
- isi_writel(isi, ISI_DMA_C_DSCR,
- (u32)isi->active->p_dma_desc->fbd_phys);
- isi_writel(isi, ISI_DMA_C_CTRL,
- ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
- isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_C_CH);
+ if (!isi->enable_preview_path) {
+ isi_writel(isi, ISI_DMA_C_DSCR,
+ (u32)isi->active->p_dma_desc->fbd_phys);
+ isi_writel(isi, ISI_DMA_C_CTRL,
+ ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
+ isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_C_CH);
+ } else {
+ isi_writel(isi, ISI_DMA_P_DSCR,
+ (u32)isi->active->p_dma_desc->fbd_phys);
+ isi_writel(isi, ISI_DMA_P_CTRL,
+ ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
+ isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_P_CH);
+ }
}
return IRQ_HANDLED;
}
@@ -226,7 +235,8 @@ static irqreturn_t isi_interrupt(int irq, void *dev_id)
isi_writel(isi, ISI_INTDIS, ISI_CTRL_DIS);
ret = IRQ_HANDLED;
} else {
- if (likely(pending & ISI_SR_CXFR_DONE))
+ if (likely(pending & ISI_SR_CXFR_DONE) ||
+ likely(pending & ISI_SR_PXFR_DONE))
ret = atmel_isi_handle_streaming(isi);
}
@@ -368,21 +378,35 @@ static void start_dma(struct atmel_isi *isi, struct
frame_buffer *buffer)
ISI_SR_CXFR_DONE | ISI_SR_PXFR_DONE);
/* Check if already in a frame */
- if (isi_readl(isi, ISI_STATUS) & ISI_CTRL_CDC) {
- dev_err(isi->soc_host.icd->parent, "Already in frame
handling.\n");
- return;
- }
+ if (!isi->enable_preview_path) {
+ if (isi_readl(isi, ISI_STATUS) & ISI_CTRL_CDC) {
+ dev_err(isi->soc_host.icd->parent, "Already in frame
handling.\n");
+ return;
+ }
- isi_writel(isi, ISI_DMA_C_DSCR, (u32)buffer->p_dma_desc->fbd_phys);
- isi_writel(isi, ISI_DMA_C_CTRL, ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
- isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_C_CH);
+ isi_writel(isi, ISI_DMA_C_DSCR,
+ (u32)buffer->p_dma_desc->fbd_phys);
+ isi_writel(isi, ISI_DMA_C_CTRL,
+ ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
+ isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_C_CH);
+ } else {
+ isi_writel(isi, ISI_DMA_P_DSCR,
+ (u32)buffer->p_dma_desc->fbd_phys);
+ isi_writel(isi, ISI_DMA_P_CTRL,
+ ISI_DMA_CTRL_FETCH | ISI_DMA_CTRL_DONE);
+ isi_writel(isi, ISI_DMA_CHER, ISI_DMA_CHSR_P_CH);
+ }
cfg1 &= ~ISI_CFG1_FRATE_DIV_MASK;
/* Enable linked list */
cfg1 |= isi->pdata.frate | ISI_CFG1_DISCR;
- /* Enable codec path and ISI */
- ctrl = ISI_CTRL_CDC | ISI_CTRL_EN;
+ /* Enable ISI */
+ ctrl = ISI_CTRL_EN;
+
+ if (!isi->enable_preview_path)
+ ctrl |= ISI_CTRL_CDC;
+
isi_writel(isi, ISI_CTRL, ctrl);
isi_writel(isi, ISI_CFG1, cfg1);
}
@@ -458,15 +482,17 @@ static void stop_streaming(struct vb2_queue *vq)
}
spin_unlock_irq(>lock);
- timeout = jiffies + FRAME_INTERVAL_MILLI_SEC * HZ;
- /* Wait until the end of the
Re: MMC/regulator boot hang in -next
On Mon, Nov 02, 2015 at 03:04:29PM -0800, John Stultz wrote:
> On Mon, Nov 2, 2015 at 2:58 PM, Mark Brown wrote:
> > No, the internal get voltage call shouldn't be locking in the first
> > place (and indeed it doesn't do so AFAICT?).
> } else if (rdev->supply) {
> ret = regulator_get_voltage(rdev->supply);<-
> } else {
> Where _regulator_get_voltage() is called from
> regulator_set_voltage_unlocked(), called from regulator_set_voltage().
>
Well, that's the issue then - get_voltage() needs to be locking the
supplies like set_voltage() does.
signature.asc
Description: PGP signature
[PATCH v2 0/5] media: atmel-isi: enable preview path to output RGB565 format
This series will enable preview path support in atmel-isi. Which can make atmel-isi convert the YUV format (from sensor) to RGB565 format. Changes in v2: - remove the duplicated variable: cfg2_yuv_swap. - correct the comment style - According to Guennadi's suggestion, remove the is_output_rgb() function which only used once. Also move the code into the for loop. Josh Wu (5): media: atmel-isi: correct yuv swap according to different sensor outputs media: atmel-isi: prepare for the support of preview path media: atmel-isi: add code to setup correct resolution for preview path media: atmel-isi: setup YCC_SWAP correctly when using preview path media: atmel-isi: support RGB565 output when sensor output YUV formats drivers/media/platform/soc_camera/atmel-isi.c | 162 +++--- drivers/media/platform/soc_camera/atmel-isi.h | 10 ++ 2 files changed, 132 insertions(+), 40 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/5] media: atmel-isi: add code to setup correct resolution for preview path
Not like codec path, preview path can do downsampling, so we should setup
a extra preview width, height for it.
This patch add preview resolution setup without down sampling. So currently
preview path will output same size as sensor output size.
Signed-off-by: Josh Wu
---
Changes in v2: None
drivers/media/platform/soc_camera/atmel-isi.c | 12 +++-
drivers/media/platform/soc_camera/atmel-isi.h | 10 ++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 24501a4..ae82068 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -131,7 +131,7 @@ static u32 setup_cfg2_yuv_swap(struct atmel_isi *isi,
static void configure_geometry(struct atmel_isi *isi, u32 width,
u32 height, const struct soc_camera_format_xlate *xlate)
{
- u32 cfg2;
+ u32 cfg2, psize;
/* According to sensor's output format to set cfg2 */
switch (xlate->code) {
@@ -159,6 +159,16 @@ static void configure_geometry(struct atmel_isi *isi, u32
width,
cfg2 |= ((height - 1) << ISI_CFG2_IM_VSIZE_OFFSET)
& ISI_CFG2_IM_VSIZE_MASK;
isi_writel(isi, ISI_CFG2, cfg2);
+
+ /* No down sampling, preview size equal to sensor output size */
+ psize = ((width - 1) << ISI_PSIZE_PREV_HSIZE_OFFSET) &
+ ISI_PSIZE_PREV_HSIZE_MASK;
+ psize |= ((height - 1) << ISI_PSIZE_PREV_VSIZE_OFFSET) &
+ ISI_PSIZE_PREV_VSIZE_MASK;
+ isi_writel(isi, ISI_PSIZE, psize);
+ isi_writel(isi, ISI_PDECF, ISI_PDECF_NO_SAMPLING);
+
+ return;
}
static bool is_supported(struct soc_camera_device *icd,
diff --git a/drivers/media/platform/soc_camera/atmel-isi.h
b/drivers/media/platform/soc_camera/atmel-isi.h
index 5acc771..0acb32a 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.h
+++ b/drivers/media/platform/soc_camera/atmel-isi.h
@@ -79,6 +79,16 @@
#define ISI_CFG2_IM_VSIZE_MASK (0x7FF << ISI_CFG2_IM_VSIZE_OFFSET)
#define ISI_CFG2_IM_HSIZE_MASK (0x7FF << ISI_CFG2_IM_HSIZE_OFFSET)
+/* Bitfields in PSIZE */
+#define ISI_PSIZE_PREV_VSIZE_OFFSET0
+#define ISI_PSIZE_PREV_HSIZE_OFFSET16
+#define ISI_PSIZE_PREV_VSIZE_MASK (0x3FF << ISI_PSIZE_PREV_VSIZE_OFFSET)
+#define ISI_PSIZE_PREV_HSIZE_MASK (0x3FF << ISI_PSIZE_PREV_HSIZE_OFFSET)
+
+/* Bitfields in PDECF */
+#define ISI_PDECF_DEC_FACTOR_MASK (0xFF << 0)
+#defineISI_PDECF_NO_SAMPLING (16)
+
/* Bitfields in CTRL */
/* Also using in SR(ISI_V2) */
#define ISI_CTRL_EN(1 << 0)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] do_div(): generic optimization for constant divisor on 32-bit machines
Hi Nicolas,
[auto build test WARNING on asm-generic/master -- if it's inappropriate base,
please suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Nicolas-Pitre/div64-h-optimize-do_div-for-power-of-two-constant-divisors/20151103-065348
config: parisc-allyesconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=parisc
All warnings (new ones prefixed by >>):
net/can/bcm.c: In function 'bcm_proc_show':
>> net/can/bcm.c:223:1: warning: the frame size of 1156 bytes is larger than
>> 1024 bytes [-Wframe-larger-than=]
}
^
vim +223 net/can/bcm.c
6755aeba Eric Dumazet2009-11-06 207
op->can_id,
6755aeba Eric Dumazet2009-11-06 208
bcm_proc_getifname(ifname, op->ifindex),
ffd980f9 Oliver Hartkopp 2007-11-16 209
op->nframes);
ffd980f9 Oliver Hartkopp 2007-11-16 210
73e87e02 Oliver Hartkopp 2008-04-15 211if (op->kt_ival1.tv64)
ea00b8e2 Alexey Dobriyan 2009-08-28 212seq_printf(m,
"t1=%lld ",
73e87e02 Oliver Hartkopp 2008-04-15 213
(long long) ktime_to_us(op->kt_ival1));
73e87e02 Oliver Hartkopp 2008-04-15 214
73e87e02 Oliver Hartkopp 2008-04-15 215if (op->kt_ival2.tv64)
ea00b8e2 Alexey Dobriyan 2009-08-28 216seq_printf(m,
"t2=%lld ",
73e87e02 Oliver Hartkopp 2008-04-15 217
(long long) ktime_to_us(op->kt_ival2));
ffd980f9 Oliver Hartkopp 2007-11-16 218
ea00b8e2 Alexey Dobriyan 2009-08-28 219seq_printf(m, "# sent
%ld\n", op->frames_abs);
ffd980f9 Oliver Hartkopp 2007-11-16 220}
ea00b8e2 Alexey Dobriyan 2009-08-28 221seq_putc(m, '\n');
ea00b8e2 Alexey Dobriyan 2009-08-28 222return 0;
ffd980f9 Oliver Hartkopp 2007-11-16 @223 }
ffd980f9 Oliver Hartkopp 2007-11-16 224
ea00b8e2 Alexey Dobriyan 2009-08-28 225 static int bcm_proc_open(struct inode
*inode, struct file *file)
ea00b8e2 Alexey Dobriyan 2009-08-28 226 {
d9dda78b Al Viro 2013-03-31 227return single_open(file,
bcm_proc_show, PDE_DATA(inode));
ffd980f9 Oliver Hartkopp 2007-11-16 228 }
ffd980f9 Oliver Hartkopp 2007-11-16 229
ea00b8e2 Alexey Dobriyan 2009-08-28 230 static const struct file_operations
bcm_proc_fops = {
ea00b8e2 Alexey Dobriyan 2009-08-28 231.owner = THIS_MODULE,
:: The code at line 223 was first introduced by commit
:: ffd980f976e7fd666c2e61bf8ab35107efd11828 [CAN]: Add broadcast manager
(bcm) protocol
:: TO: Oliver Hartkopp
:: CC: David S. Miller
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
[PATCH v2 5/5] media: atmel-isi: support RGB565 output when sensor output YUV formats
This patch enable Atmel ISI preview path to convert the YUV to RGB format.
Signed-off-by: Josh Wu
---
Changes in v2:
- According to Guennadi's suggestion, remove the is_output_rgb() function
which only used once. Also move the code into the for loop.
drivers/media/platform/soc_camera/atmel-isi.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 826d04e..8abeeeb 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -146,6 +146,10 @@ static void configure_geometry(struct atmel_isi *isi, u32
width,
u32 height, const struct soc_camera_format_xlate *xlate)
{
u32 cfg2, psize;
+ u32 fourcc = xlate->host_fmt->fourcc;
+
+ isi->enable_preview_path = (fourcc == V4L2_PIX_FMT_RGB565 ||
+ fourcc == V4L2_PIX_FMT_RGB32);
/* According to sensor's output format to set cfg2 */
switch (xlate->code) {
@@ -195,8 +199,9 @@ static bool is_supported(struct soc_camera_device *icd,
case V4L2_PIX_FMT_UYVY:
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_VYUY:
+ /* RGB */
+ case V4L2_PIX_FMT_RGB565:
return true;
- /* RGB, TODO */
default:
return false;
}
@@ -682,6 +687,14 @@ static const struct soc_mbus_pixelfmt isi_camera_formats[]
= {
.order = SOC_MBUS_ORDER_LE,
.layout = SOC_MBUS_LAYOUT_PACKED,
},
+ {
+ .fourcc = V4L2_PIX_FMT_RGB565,
+ .name = "RGB565",
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ .layout = SOC_MBUS_LAYOUT_PACKED,
+ },
};
/* This will be corrected as we get more formats */
@@ -738,7 +751,7 @@ static int isi_camera_get_formats(struct soc_camera_device
*icd,
struct soc_camera_format_xlate *xlate)
{
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
- int formats = 0, ret;
+ int formats = 0, ret, i, n;
/* sensor format */
struct v4l2_subdev_mbus_code_enum code = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
@@ -772,11 +785,11 @@ static int isi_camera_get_formats(struct
soc_camera_device *icd,
case MEDIA_BUS_FMT_VYUY8_2X8:
case MEDIA_BUS_FMT_YUYV8_2X8:
case MEDIA_BUS_FMT_YVYU8_2X8:
- formats++;
- if (xlate) {
- xlate->host_fmt = _camera_formats[0];
+ n = ARRAY_SIZE(isi_camera_formats);
+ formats += n;
+ for (i = 0; xlate && i < n; i++, xlate++) {
+ xlate->host_fmt = _camera_formats[i];
xlate->code = code.code;
- xlate++;
dev_dbg(icd->parent, "Providing format %s using code
%d\n",
isi_camera_formats[0].name, code.code);
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/5] media: atmel-isi: correct yuv swap according to different sensor outputs
we need to configure the YCC_SWAP bits in ISI_CFG2 according to current
sensor output and Atmel ISI output format.
Current there are two cases Atmel ISI supported:
1. Atmel ISI outputs YUYV format.
This case we need to setup YCC_SWAP according to sensor output
format.
2. Atmel ISI output a pass-through formats, which means no swap.
Just setup YCC_SWAP as default with no swap.
Signed-off-by: Josh Wu
---
Changes in v2:
- remove the duplicated variable: cfg2_yuv_swap.
drivers/media/platform/soc_camera/atmel-isi.c | 39 ---
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index 45e304a..ce87a16 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -103,13 +103,37 @@ static u32 isi_readl(struct atmel_isi *isi, u32 reg)
return readl(isi->regs + reg);
}
+static u32 setup_cfg2_yuv_swap(struct atmel_isi *isi,
+ const struct soc_camera_format_xlate *xlate)
+{
+ if (xlate->host_fmt->fourcc == V4L2_PIX_FMT_YUYV) {
+ /* all convert to YUYV */
+ switch (xlate->code) {
+ case MEDIA_BUS_FMT_VYUY8_2X8:
+ return ISI_CFG2_YCC_SWAP_MODE_3;
+ case MEDIA_BUS_FMT_UYVY8_2X8:
+ return ISI_CFG2_YCC_SWAP_MODE_2;
+ case MEDIA_BUS_FMT_YVYU8_2X8:
+ return ISI_CFG2_YCC_SWAP_MODE_1;
+ }
+ }
+
+ /*
+* By default, no swap for the codec path of Atmel ISI. So codec
+* output is same as sensor's output.
+* For instance, if sensor's output is YUYV, then codec outputs YUYV.
+* And if sensor's output is UYVY, then codec outputs UYVY.
+*/
+ return ISI_CFG2_YCC_SWAP_DEFAULT;
+}
+
static void configure_geometry(struct atmel_isi *isi, u32 width,
- u32 height, u32 code)
+ u32 height, const struct soc_camera_format_xlate *xlate)
{
u32 cfg2;
/* According to sensor's output format to set cfg2 */
- switch (code) {
+ switch (xlate->code) {
default:
/* Grey */
case MEDIA_BUS_FMT_Y8_1X8:
@@ -117,16 +141,11 @@ static void configure_geometry(struct atmel_isi *isi, u32
width,
break;
/* YUV */
case MEDIA_BUS_FMT_VYUY8_2X8:
- cfg2 = ISI_CFG2_YCC_SWAP_MODE_3 | ISI_CFG2_COL_SPACE_YCbCr;
- break;
case MEDIA_BUS_FMT_UYVY8_2X8:
- cfg2 = ISI_CFG2_YCC_SWAP_MODE_2 | ISI_CFG2_COL_SPACE_YCbCr;
- break;
case MEDIA_BUS_FMT_YVYU8_2X8:
- cfg2 = ISI_CFG2_YCC_SWAP_MODE_1 | ISI_CFG2_COL_SPACE_YCbCr;
- break;
case MEDIA_BUS_FMT_YUYV8_2X8:
- cfg2 = ISI_CFG2_YCC_SWAP_DEFAULT | ISI_CFG2_COL_SPACE_YCbCr;
+ cfg2 = ISI_CFG2_COL_SPACE_YCbCr |
+ setup_cfg2_yuv_swap(isi, xlate);
break;
/* RGB, TODO */
}
@@ -407,7 +426,7 @@ static int start_streaming(struct vb2_queue *vq, unsigned
int count)
isi_writel(isi, ISI_INTDIS, (u32)~0UL);
configure_geometry(isi, icd->user_width, icd->user_height,
- icd->current_fmt->code);
+ icd->current_fmt);
spin_lock_irq(>lock);
/* Clear any pending interrupt */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/5] media: atmel-isi: setup YCC_SWAP correctly when using preview path
The preview path only can convert UYVY format to RGB data.
To make preview path work correctly, we need to set up YCC_SWAP
according to sensor output and convert them to UYVY.
Signed-off-by: Josh Wu
---
Changes in v2:
- remove cfg2_yuv_swap for rgb format
- correct the comment style
drivers/media/platform/soc_camera/atmel-isi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c
index ae82068..826d04e 100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -117,6 +117,20 @@ static u32 setup_cfg2_yuv_swap(struct atmel_isi *isi,
case MEDIA_BUS_FMT_YVYU8_2X8:
return ISI_CFG2_YCC_SWAP_MODE_1;
}
+ } else if (xlate->host_fmt->fourcc == V4L2_PIX_FMT_RGB565) {
+ /*
+* Preview path is enabled, it will convert UYVY to RGB format.
+* But if sensor output format is not UYVY, we need to set
+* YCC_SWAP_MODE to convert it as UYVY.
+*/
+ switch (xlate->code) {
+ case MEDIA_BUS_FMT_VYUY8_2X8:
+ return ISI_CFG2_YCC_SWAP_MODE_1;
+ case MEDIA_BUS_FMT_YUYV8_2X8:
+ return ISI_CFG2_YCC_SWAP_MODE_2;
+ case MEDIA_BUS_FMT_YVYU8_2X8:
+ return ISI_CFG2_YCC_SWAP_MODE_3;
+ }
}
/*
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 14/15] dax: dirty extent notification
On Mon, Nov 02, 2015 at 08:56:24PM -0800, Dan Williams wrote: > On Mon, Nov 2, 2015 at 5:16 PM, Dave Chinner wrote: > > On Sun, Nov 01, 2015 at 11:30:58PM -0500, Dan Williams wrote: > >> DAX-enabled block device drivers can use hints from fs/dax.c to > >> optimize their internal tracking of potentially dirty cpu cache lines. > >> If a DAX mapping is being used for synchronous operations, dax_do_io(), > >> a dax-enabled block-driver knows that fs/dax.c will handle immediate > >> flushing. For asynchronous mappings, i.e. returned to userspace via > >> mmap, the driver can track active extents of the media for flushing. > > > > So, essentially, you are marking the calls into the mapping calls > > with BLKDAX_F_DIRTY when the mapping is requested for a write page > > fault? Hence allowing the block device to track "dirty pages" > > exactly? > > Not pages, but larger extents (1 extent = 1/NUM_DAX_EXTENTS of the > total storage capacity), because tracking dirty mappings should be > temporary compatibility hack and not a first class citizen. > > > But, really, if we're going to use Ross's mapping tree patches that > > use exceptional entries to track dirty pfns, why do we need to this > > special interface from DAX to the block device? Ross's changes will > > track mmap'd ranges that are dirtied at the filesytem inode level, > > and the fsync/writeback will trigger CPU cache writeback of those > > dirty ranges. This will work for block devices that are mapped by > > DAX, too, because they have a inode+mapping tree, too. > > > > And if we are going to use Ross's infrastructure (which, when we > > work the kinks out of, I think we will), we really should change > > dax_do_io() to track pfns that are dirtied this way, too. That will > > allow us to get rid of all the cache flushing from the DAX layer > > (they'll get pushed into fsync/writeback) and so we only take the > > CPU cache flushing penalties when synchronous operations are > > requested by userspace... > > No, we definitely can't do that. I think your mental model of the > cache flushing is similar to the disk model where a small buffer is > flushed after a large streaming write. Both Ross' patches and my > approach suffer from the same horror that the cache flushing is O(N) > currently, so we don't want to make it responsible for more data > ranges areas than is strictly necessary. I didn't see anything that was O(N) in Ross's patches. What part of the fsync algorithm that Ross proposed are you refering to here? > >> We can later extend the DAX paths to indicate when an async mapping is > >> "closed" allowing the active extents to be marked clean. > > > > Yes, that's a basic feature of Ross's patches. Hence I think this > > special case DAX<->bdev interface is the wrong direction to be > > taking. > > So here's my problem with the "track dirty mappings" in the core > mm/vfs approach, it's harder to unwind and delete when it turns out no > application actually needs it, or the platform gives us an O(1) flush > method that is independent of dirty pte tracking. > > We have the NVML [1] library as the recommended method for > applications to interact with persistent memory and it is not using > fsync/msync for its synchronization primitives, it's managing the > cache directly. The *only* user for tracking dirty DAX mappings is > unmodified legacy applications that do mmap I/O and call fsync/msync. I'm pretty sure there are going to be many people still writing new applications that use POSIX APIs they expect to work correctly on pmem because, well, it's going to take 10 years before persistent memory is common enough for most application developers to only target storage via NVML. The whole world is not crazy HFT applications that need to bypass the kernel for *everything* because even a few nanoseconds of extra latency matters. > DAX in my opinion is not a transparent accelerator of all existing > apps, it's a targeted mechanism for applications ready to take > advantage of byte addressable persistent memory. And this is where we disagree. DAX is a method of allowing POSIX compliant applications get the best of both worlds - portability with existing storage and filesystems, yet with the speed and byte addressiblity of persistent storage through the use of mmap. Applications designed specifically for persistent memory don't want a general purpose, POSIX compatible filesystem underneath them. The should be interacting directly with, and only with, your NVML library. If the NVML library is implemented by using DAX on a POSIX compatible, general purpose filesystem, then you're just going to have to live with everything we need to do to make DAX work with general purpose POSIX compatible applications. DAX has always been intended as a *stopgap measure* designed to bridge the gap between existing POSIX based storage APIs and PMEM native filesystem implementations. You're advocating that DAX should only be used by PMEM native applications
Re: [PATCH v3 02/15] dax: increase granularity of dax_clear_blocks() operations
On Mon, Nov 2, 2015 at 8:48 PM, Dave Chinner wrote: > On Mon, Nov 02, 2015 at 07:27:26PM -0800, Dan Williams wrote: >> On Mon, Nov 2, 2015 at 4:51 PM, Dave Chinner wrote: >> > On Sun, Nov 01, 2015 at 11:29:53PM -0500, Dan Williams wrote: >> > The zeroing (and the data, for that matter) doesn't need to be >> > committed to persistent store until the allocation is written and >> > committed to the journal - that will happen with a REQ_FLUSH|REQ_FUA >> > write, so it makes sense to deploy the big hammer and delay the >> > blocking CPU cache flushes until the last possible moment in cases >> > like this. >> >> In pmem terms that would be a non-temporal memset plus a delayed >> wmb_pmem at REQ_FLUSH time. Better to write around the cache than >> loop over the dirty-data issuing flushes after the fact. We'll bump >> the priority of the non-temporal memset implementation. > > Why is it better to do two synchronous physical writes to memory > within a couple of microseconds of CPU time rather than writing them > through the cache and, in most cases, only doing one physical write > to memory in a separate context that expects to wait for a flush > to complete? With a switch to non-temporal writes they wouldn't be synchronous, although it's doubtful that the subsequent writes after zeroing would also hit the store buffer. If we had a method to flush by physical-cache-way rather than a virtual address then it would indeed be better to save up for one final flush, but when we need to resort to looping through all the virtual addresses that might have touched it gets expensive. -- 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: add Qualcomm Technologies HIDMA channel driver
On 11/2/2015 3:55 PM, Arnd Bergmann wrote: Are you using message signaled interrupts then? Typically MSI guarantees ordering against DMA, but level or edge triggered interrupts by definition cannot (at least on PCI, but most other buses are the same way), because the DMA master has no insight into when a DMA is actually complete. If you use MSI, please add a comment to the readl_relaxed() that it is safe because of that, otherwise the next person who tries to debug a problem with your driver has to look into this. No, using regular GIC SPI interrupts at this moment. I know that HW doesn't use any of the typical AHB/AXI ARM buses. I'm familiar with how PCI endpoints works. While the first read in a typical PCI endpoint ISR flushes all outstanding requests traditionally to the destination, this concept does not apply here for this HW. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 2/2] watchdog: imx2_wdt: add set_pretimeout interface
On 11/02/2015 08:55 PM, Robin Gong wrote:
On Mon, Nov 02, 2015 at 08:19:12PM -0800, Guenter Roeck wrote:
On 11/02/2015 07:29 PM, Robin Gong wrote:
Enable set_pretimeout interface and trigger the pretimeout interrupt before
watchdog timeout event happen.
Signed-off-by: Robin Gong
---
drivers/watchdog/imx2_wdt.c | 67 -
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 0bb1a1d..d3c6b07 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -24,7 +24,9 @@
#include
#include
#include
+#include
#include
+#include
Are those two new includes both needed ?
Yes, irq.h is not needed.
#include
#include
#include
@@ -52,12 +54,18 @@
#define IMX2_WDT_WRSR 0x04/* Reset Status Register */
#define IMX2_WDT_WRSR_TOUT(1 << 1) /* -> Reset due to Timeout */
+#define IMX2_WDT_WICR 0x06/*Interrupt Control Register*/
+#define IMX2_WDT_WICR_WIE (1 << 15) /* -> Interrupt Enable */
+#define IMX2_WDT_WICR_WTIS (1 << 14) /* -> Interrupt Status */
+#define IMX2_WDT_WICR_WICT (0xFF << 0) /* Watchdog Interrupt Timeout
*/
+
"<< 0" doesn't really add any value here.
Accept.
#define IMX2_WDT_WMCR 0x08/* Misc Register */
#define IMX2_WDT_MAX_TIME 128
#define IMX2_WDT_DEFAULT_TIME 60 /* in seconds */
#define WDOG_SEC_TO_COUNT(s) ((s * 2 - 1) << 8)
+#define WDOG_SEC_TO_PRECOUNT(s)(s * 2) /* set WDOG pre timeout
count*/
((s) * 2)
Ah yes, WDOG_SEC_TO_COUNT should also use (s).
struct imx2_wdt_device {
struct clk *clk;
@@ -80,7 +88,8 @@ MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds
(default="
static const struct watchdog_info imx2_wdt_info = {
.identity = "imx2+ watchdog",
- .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE,
+ .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE
+ | WDIOF_PRETIMEOUT,
};
static int imx2_restart_handler(struct notifier_block *this, unsigned long
mode,
@@ -207,12 +216,59 @@ static inline void imx2_wdt_ping_if_active(struct
watchdog_device *wdog)
}
}
+static int imx2_wdt_check_pretimeout_set(struct imx2_wdt_device *wdev)
+{
+ u32 val;
+
+ regmap_read(wdev->regmap, IMX2_WDT_WICR, );
+ return (val & IMX2_WDT_WICR_WIE) ? 1 : 0;
I don't understand the point of this function.
You check if IMX2_WDT_WICR_WIE is set,
Yes, looks no need check,just directly set this bit.
+}
+
+static int imx2_wdt_set_pretimeout(struct watchdog_device *wdog,
+ unsigned int new_timeout)
+{
+ struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+ u32 val;
+
+ regmap_read(wdev->regmap, IMX2_WDT_WICR, );
+ /* set the new pre-timeout value in the WSR */
+ val &= ~IMX2_WDT_WICR_WICT;
+ val |= WDOG_SEC_TO_PRECOUNT(new_timeout);
+
What is the time here ? Is pretimeout the number of seconds
until the interrupt occurs, or the number of seconds before the actual
timeout (as per API) ?
The latter is.
+ if (!imx2_wdt_check_pretimeout_set(wdev))
+ val |= IMX2_WDT_WICR_WIE; /*enable*/
if IMX2_WDT_WICR_WIE is not set, you set it,
+
+ regmap_write(wdev->regmap, IMX2_WDT_WICR, val);
+
and write the result unconditionally. Unless I am missing something,
regmap_write, wdev->regmap, IMX2_WDT_WICR, val | IMX2_WDT_WICR_WIE);
would accomplish exactly the same.
+ wdog->pretimeout = new_timeout;
+
+ return 0;
+}
+
+static irqreturn_t imx2_wdt_isr(int irq, void *dev_id)
+{
+ struct platform_device *pdev = dev_id;
+ struct watchdog_device *wdog = platform_get_drvdata(pdev);
+ struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+ u32 val;
+
+ regmap_read(wdev->regmap, IMX2_WDT_WICR, );
+ if (val & IMX2_WDT_WICR_WTIS) {
+ /*clear interrupt status bit*/
+ regmap_write(wdev->regmap, IMX2_WDT_WICR, val);
+ dev_warn(>dev, "pre-timeout:%d, %d Seconds remained\n",
+wdog->pretimeout, wdog->timeout - wdog->pretimeout);
The idea here is that this should trigger a panic.
Just add a print message, our customer will add what they want here.
We should follow kernel expectations and guidelines, and not expect customers
to make changes. After all, this is for the upstream kernel, not for a vendor
kernel. You can as well call panic here and let your customers change that
if they don't like it.
Guenter
+ }
+ return IRQ_HANDLED;
+}
+
static const struct watchdog_ops imx2_wdt_ops = {
.owner = THIS_MODULE,
.start = imx2_wdt_start,
.stop = imx2_wdt_stop,
.ping = imx2_wdt_ping,
.set_timeout =
Re: [PATCH 1/2] x86 smpboot: fix cpu_init_udelay=10000
> Is this really what you intended? The else is commented out so if init_udelay > is quirked > to be 0 it will always be reset to UDELAY_10MS_DEFAULT. Also init_udelay is > unsigned, so > would UINT_MAX be a better choice? Hi Shane, Thanks for pointing out this flaw. Seems it will make 4.3 10ms slower than 4.2 on these boxes, by default. We'll send an incremental patch for 4.4. Len Brown, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 2/2] watchdog: imx2_wdt: add set_pretimeout interface
On Mon, Nov 02, 2015 at 08:19:12PM -0800, Guenter Roeck wrote:
> On 11/02/2015 07:29 PM, Robin Gong wrote:
> >Enable set_pretimeout interface and trigger the pretimeout interrupt before
> >watchdog timeout event happen.
> >
> >Signed-off-by: Robin Gong
> >---
> > drivers/watchdog/imx2_wdt.c | 67
> > -
> > 1 file changed, 66 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
> >index 0bb1a1d..d3c6b07 100644
> >--- a/drivers/watchdog/imx2_wdt.c
> >+++ b/drivers/watchdog/imx2_wdt.c
> >@@ -24,7 +24,9 @@
> > #include
> > #include
> > #include
> >+#include
> > #include
> >+#include
>
> Are those two new includes both needed ?
>
Yes, irq.h is not needed.
> > #include
> > #include
> > #include
> >@@ -52,12 +54,18 @@
> > #define IMX2_WDT_WRSR 0x04/* Reset Status
> > Register */
> > #define IMX2_WDT_WRSR_TOUT (1 << 1)/* -> Reset due to Timeout */
> >
> >+#define IMX2_WDT_WICR 0x06/*Interrupt Control
> >Register*/
> >+#define IMX2_WDT_WICR_WIE (1 << 15) /* -> Interrupt Enable */
> >+#define IMX2_WDT_WICR_WTIS (1 << 14) /* -> Interrupt Status */
> >+#define IMX2_WDT_WICR_WICT (0xFF << 0) /* Watchdog Interrupt Timeout */
> >+
>
> "<< 0" doesn't really add any value here.
>
Accept.
> > #define IMX2_WDT_WMCR 0x08/* Misc Register */
> >
> > #define IMX2_WDT_MAX_TIME 128
> > #define IMX2_WDT_DEFAULT_TIME 60 /* in seconds */
> >
> > #define WDOG_SEC_TO_COUNT(s) ((s * 2 - 1) << 8)
> >+#define WDOG_SEC_TO_PRECOUNT(s) (s * 2) /* set WDOG pre timeout
> >count*/
> >
> ((s) * 2)
>
> Ah yes, WDOG_SEC_TO_COUNT should also use (s).
>
> > struct imx2_wdt_device {
> > struct clk *clk;
> >@@ -80,7 +88,8 @@ MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds
> >(default="
> >
> > static const struct watchdog_info imx2_wdt_info = {
> > .identity = "imx2+ watchdog",
> >-.options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE,
> >+.options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE
> >+ | WDIOF_PRETIMEOUT,
> > };
> >
> > static int imx2_restart_handler(struct notifier_block *this, unsigned long
> > mode,
> >@@ -207,12 +216,59 @@ static inline void imx2_wdt_ping_if_active(struct
> >watchdog_device *wdog)
> > }
> > }
> >
> >+static int imx2_wdt_check_pretimeout_set(struct imx2_wdt_device *wdev)
> >+{
> >+u32 val;
> >+
> >+regmap_read(wdev->regmap, IMX2_WDT_WICR, );
> >+return (val & IMX2_WDT_WICR_WIE) ? 1 : 0;
>
> I don't understand the point of this function.
> You check if IMX2_WDT_WICR_WIE is set,
>
Yes, looks no need check,just directly set this bit.
> >+}
> >+
> >+static int imx2_wdt_set_pretimeout(struct watchdog_device *wdog,
> >+ unsigned int new_timeout)
> >+{
> >+struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
> >+u32 val;
> >+
> >+regmap_read(wdev->regmap, IMX2_WDT_WICR, );
> >+/* set the new pre-timeout value in the WSR */
> >+val &= ~IMX2_WDT_WICR_WICT;
> >+val |= WDOG_SEC_TO_PRECOUNT(new_timeout);
> >+
>
> What is the time here ? Is pretimeout the number of seconds
> until the interrupt occurs, or the number of seconds before the actual
> timeout (as per API) ?
>
The latter is.
> >+if (!imx2_wdt_check_pretimeout_set(wdev))
> >+val |= IMX2_WDT_WICR_WIE; /*enable*/
>
> if IMX2_WDT_WICR_WIE is not set, you set it,
>
> >+
> >+regmap_write(wdev->regmap, IMX2_WDT_WICR, val);
> >+
>
> and write the result unconditionally. Unless I am missing something,
>
> regmap_write, wdev->regmap, IMX2_WDT_WICR, val | IMX2_WDT_WICR_WIE);
>
> would accomplish exactly the same.
>
> >+wdog->pretimeout = new_timeout;
> >+
> >+return 0;
> >+}
> >+
> >+static irqreturn_t imx2_wdt_isr(int irq, void *dev_id)
> >+{
> >+struct platform_device *pdev = dev_id;
> >+struct watchdog_device *wdog = platform_get_drvdata(pdev);
> >+struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
> >+u32 val;
> >+
> >+regmap_read(wdev->regmap, IMX2_WDT_WICR, );
> >+if (val & IMX2_WDT_WICR_WTIS) {
> >+/*clear interrupt status bit*/
> >+regmap_write(wdev->regmap, IMX2_WDT_WICR, val);
> >+dev_warn(>dev, "pre-timeout:%d, %d Seconds remained\n",
> >+ wdog->pretimeout, wdog->timeout - wdog->pretimeout);
>
> The idea here is that this should trigger a panic.
>
Just add a print message, our customer will add what they want here.
> >+}
> >+return IRQ_HANDLED;
> >+}
> >+
> > static const struct watchdog_ops imx2_wdt_ops = {
> > .owner = THIS_MODULE,
> > .start = imx2_wdt_start,
> > .stop = imx2_wdt_stop,
> > .ping = imx2_wdt_ping,
> > .set_timeout =
Re: [PATCH V2 1/3] dma: add Qualcomm Technologies HIDMA management driver
On 11/2/2015 10:57 AM, Rob Herring wrote:
On Mon, Nov 2, 2015 at 12:07 AM, Sinan Kaya wrote:
The Qualcomm Technologies HIDMA device has been designed
to support virtualization technology. The driver has been
divided into two to follow the hardware design. The management
driver is executed in hypervisor context and is the main
management entity for all channels provided by the device.
The channel driver is executed in the hypervisor/guest OS
context.
All channel devices get probed in the hypervisor
context during power up. They show up as DMA engine
channels. Then, before starting the virtualization; each
channel device is unbound from the hypervisor by VFIO
and assigned to the guest machine for control.
This management driver will be used by the system
admin to monitor/reset the execution state of the DMA
channels. This will be the management interface.
Signed-off-by: Sinan Kaya
---
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt| 56 ++
drivers/dma/Kconfig| 11 +
drivers/dma/Makefile | 1 +
drivers/dma/qcom_hidma_mgmt.c | 747 +
4 files changed, 815 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
create mode 100644 drivers/dma/qcom_hidma_mgmt.c
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
new file mode 100644
index 000..514d37d
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -0,0 +1,56 @@
+Qualcomm Technologies HIDMA Management interface
+
+The Qualcomm Technologies HIDMA device has been designed
+to support virtualization technology. The driver has been
+divided into two to follow the hardware design. The management
+driver is executed in hypervisor context and is the main
+management entity for all channels provided by the device.
Let me try one more time. Hope this helps.
Each HIDMA HW consists of multiple channels. These channels share
some set of common parameters. These parameters are initialized
by the management driver during power up. Same management driver is used
for monitoring the execution of the channels. Management driver
can change the performance behaviors dynamically such as bandwidth
allocation and prioritization.
This doesn't really explain what the block is.
+All channel devices get probed in the hypervisor
+context during power up. They show up as DMA engine
+DMA channels. Then, before starting the virtualization; each
+channel device is unbound from the hypervisor by VFIO
+and assign to the guest machine for control.
+
+This management driver will be used by the system
+admin to monitor/reset the execution state of the DMA
+channels. This will be the management interface.
+
+
+Required properties:
+- compatible: must contain "qcom,hidma-mgmt"
Please make this more specific. It doesn't match your example either.
Unless "1.0" type versioning is tightly controlled and defined,
version numbers are usually not a good practice.
+- reg: Address range for DMA device
+- dma-channels: Number of channels supported by this DMA controller.
+- max-write-burst-bytes: Maximum write burst in bytes. A memcpy requested is
+ fragmented to multiples of this amount.
+- max-read-burst-bytes: Maximum read burst in bytes. A memcpy request is
+ fragmented to multiples of this amount.
+- max-write-transactions: Maximum write transactions to perform in a burst
+- max-read-transactions: Maximum read transactions to perform in a burst
This would be a function of burst-bytes and bus width. Are you sure
you don't me number of outstanding transactions which is a common
parameter for AXI bus peripherals.
These are all the available HW knobs for performance at this moment.
max-write-transactions corresponds to the max number of outstanding
transactions.
+- channel-reset-timeout: Channel reset timeout for this SOC.
Please add units to property name.
ok, changed to channel-reset-timeout-cycles
+- channel-priority: Priority of the channel.
+ Each dma channel share the same HW bandwidth with other dma channels.
+ If two requests reach to the HW at the same time from a low priority and
+ high priority channel, high priority channel will claim the bus.
+ 0=low priority, 1=high priority
+- channel-weight: Round robin weight of the channel
+ Since there are only two priority levels supported, scheduling among
+ the equal priority channels is done via weights.
+
+Example:
+
+ hidma-mgmt@f9984000 = {
+ compatible = "qcom,hidma-mgmt-1.0";
+ reg = <0xf9984000 0x15000>;
+ dma-channels = 6;
+ max-write-burst-bytes = 1024;
+ max-read-burst-bytes = 1024;
+ max-write-transactions = 31;
+ max-read-transactions = 31;
+ channel-reset-timeout = 0x500;
+ channel-priority = <
Re: [PATCH v1 1/2] watchdog: add WDIOC_SETPRETIMEOUT and WDIOC_GETPRETIMEOUT
On Mon, Nov 02, 2015 at 08:04:20PM -0800, Guenter Roeck wrote:
> On 11/02/2015 07:29 PM, Robin Gong wrote:
> >Since the watchdog common framework centrialize the IOCTL interfaces of
> >device driver now, the SETPRETIMEOUT and GETPRETIMEOUT need to be added
> >in the common code.
> >
> >Signed-off-by: Robin Gong
> >---
> > drivers/watchdog/watchdog_dev.c | 38 ++
> > include/linux/watchdog.h| 9 +
> > 2 files changed, 47 insertions(+)
> >
> >diff --git a/drivers/watchdog/watchdog_dev.c
> >b/drivers/watchdog/watchdog_dev.c
> >index 6aaefba..02632fe 100644
> >--- a/drivers/watchdog/watchdog_dev.c
> >+++ b/drivers/watchdog/watchdog_dev.c
> >@@ -218,6 +218,37 @@ out_timeout:
> > }
> >
> > /*
> >+ * watchdog_set_pretimeout: set the watchdog timer pretimeout
> >+ * @wddev: the watchdog device to set the timeout for
> >+ * @timeout: pretimeout to set in seconds
> >+ */
> >+
> >+static int watchdog_set_pretimeout(struct watchdog_device *wddev,
> >+unsigned int timeout)
>
> Please align with "(".
Will fix in v2.
>
> >+{
> >+int err;
> >+
> >+if ((wddev->ops->set_pretimeout == NULL) ||
>
> Unnecessary ( ), and "== NULL" is unnecessary as well.
>
why? It's useful if other device driver didn't implement set_pretimeout.
> >+!(wddev->info->options & WDIOF_PRETIMEOUT))
> >+return -EOPNOTSUPP;
> >+if (watchdog_pretimeout_invalid(wddev, timeout))
> >+return -EINVAL;
> >+
> >+mutex_lock(>lock);
> >+
> >+if (test_bit(WDOG_UNREGISTERED, >status)) {
> >+err = -ENODEV;
> >+goto out_timeout;
> >+}
> >+
> >+err = wddev->ops->set_pretimeout(wddev, timeout);
> >+
> >+out_timeout:
> >+mutex_unlock(>lock);
> >+return err;
> >+}
> >+
> >+/*
> > * watchdog_get_timeleft: wrapper to get the time left before a reboot
> > * @wddev: the watchdog device to get the remaining time from
> > * @timeleft: the time that's left
> >@@ -393,6 +424,13 @@ static long watchdog_ioctl(struct file *file, unsigned
> >int cmd,
> > if (err)
> > return err;
> > return put_user(val, p);
> >+case WDIOC_SETPRETIMEOUT:
> >+if (get_user(val, p))
> >+return -EFAULT;
> >+err = watchdog_set_pretimeout(wdd, val);
> >+return err;
>
> return watchdog_set_pretimeout(wdd, val);
>
> >+case WDIOC_GETPRETIMEOUT:
> >+return put_user(wdd->pretimeout, p);
> > default:
> > return -ENOTTY;
> > }
> >diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
> >index d74a0e9..6ddb2d6 100644
> >--- a/include/linux/watchdog.h
> >+++ b/include/linux/watchdog.h
> >@@ -25,6 +25,7 @@ struct watchdog_device;
> > * @ping: The routine that sends a keepalive ping to the watchdog device.
> > * @status:The routine that shows the status of the watchdog
> > device.
> > * @set_timeout:The routine for setting the watchdog devices timeout value.
> >+ * @set_pretimeout:The routine for setting the watchdog devices pretimeout.
> > * @get_timeleft:The routine that get's the time that's left before a
> > reset.
> > * @ref: The ref operation for dyn. allocated watchdog_device structs
> > * @unref: The unref operation for dyn. allocated watchdog_device structs
> >@@ -44,6 +45,7 @@ struct watchdog_ops {
> > int (*ping)(struct watchdog_device *);
> > unsigned int (*status)(struct watchdog_device *);
> > int (*set_timeout)(struct watchdog_device *, unsigned int);
> >+int (*set_pretimeout)(struct watchdog_device *, unsigned int);
> > unsigned int (*get_timeleft)(struct watchdog_device *);
> > void (*ref)(struct watchdog_device *);
> > void (*unref)(struct watchdog_device *);
> >@@ -86,6 +88,7 @@ struct watchdog_device {
> > const struct watchdog_ops *ops;
> > unsigned int bootstatus;
> > unsigned int timeout;
> >+unsigned int pretimeout;
>
> Description (further below) missing.
>
I describe it in the ahead of this structure as the above.
> > unsigned int min_timeout;
> > unsigned int max_timeout;
> > void *driver_data;
> >@@ -123,6 +126,12 @@ static inline bool watchdog_timeout_invalid(struct
> >watchdog_device *wdd, unsigne
> > (t < wdd->min_timeout || t > wdd->max_timeout));
> > }
> >
> >+/* Use the following function to check if a pretimeout value is invalid */
> >+static inline bool watchdog_pretimeout_invalid(struct watchdog_device *wdd,
> >unsigned int t)
>
> Please fix checkpatch warnings.
>
You mean over 80 characters? Will fix in v2.
> >+{
> >+return ((wdd->timeout != 0) && (t >= wdd->timeout));
>
> Unnecessary ( ), and "!= 0" is unnecessary.
>
I think t >= wdd->timeout is need, since it's a pre-timeout.
> >+}
> >+
> > /* Use the following functions to manipulate watchdog driver specific data
> > */
> > static inline void
Re: [PATCH v1 1/2] watchdog: add WDIOC_SETPRETIMEOUT and WDIOC_GETPRETIMEOUT
On 11/02/2015 08:47 PM, Robin Gong wrote:
On Mon, Nov 02, 2015 at 08:04:20PM -0800, Guenter Roeck wrote:
On 11/02/2015 07:29 PM, Robin Gong wrote:
Since the watchdog common framework centrialize the IOCTL interfaces of
device driver now, the SETPRETIMEOUT and GETPRETIMEOUT need to be added
in the common code.
Signed-off-by: Robin Gong
---
drivers/watchdog/watchdog_dev.c | 38 ++
include/linux/watchdog.h| 9 +
2 files changed, 47 insertions(+)
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 6aaefba..02632fe 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -218,6 +218,37 @@ out_timeout:
}
/*
+ * watchdog_set_pretimeout: set the watchdog timer pretimeout
+ * @wddev: the watchdog device to set the timeout for
+ * @timeout: pretimeout to set in seconds
+ */
+
+static int watchdog_set_pretimeout(struct watchdog_device *wddev,
+ unsigned int timeout)
Please align with "(".
Will fix in v2.
+{
+ int err;
+
+ if ((wddev->ops->set_pretimeout == NULL) ||
Unnecessary ( ), and "== NULL" is unnecessary as well.
why? It's useful if other device driver didn't implement set_pretimeout.
if (!wddev->ops->set_pretimeout ||
+ !(wddev->info->options & WDIOF_PRETIMEOUT))
+ return -EOPNOTSUPP;
+ if (watchdog_pretimeout_invalid(wddev, timeout))
+ return -EINVAL;
+
+ mutex_lock(>lock);
+
+ if (test_bit(WDOG_UNREGISTERED, >status)) {
+ err = -ENODEV;
+ goto out_timeout;
+ }
+
+ err = wddev->ops->set_pretimeout(wddev, timeout);
+
+out_timeout:
+ mutex_unlock(>lock);
+ return err;
+}
+
+/*
*watchdog_get_timeleft: wrapper to get the time left before a reboot
*@wddev: the watchdog device to get the remaining time from
*@timeleft: the time that's left
@@ -393,6 +424,13 @@ static long watchdog_ioctl(struct file *file, unsigned int
cmd,
if (err)
return err;
return put_user(val, p);
+ case WDIOC_SETPRETIMEOUT:
+ if (get_user(val, p))
+ return -EFAULT;
+ err = watchdog_set_pretimeout(wdd, val);
+ return err;
return watchdog_set_pretimeout(wdd, val);
+ case WDIOC_GETPRETIMEOUT:
+ return put_user(wdd->pretimeout, p);
default:
return -ENOTTY;
}
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index d74a0e9..6ddb2d6 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -25,6 +25,7 @@ struct watchdog_device;
* @ping: The routine that sends a keepalive ping to the watchdog device.
* @status: The routine that shows the status of the watchdog device.
* @set_timeout:The routine for setting the watchdog devices timeout value.
+ * @set_pretimeout:The routine for setting the watchdog devices pretimeout.
* @get_timeleft:The routine that get's the time that's left before a reset.
* @ref: The ref operation for dyn. allocated watchdog_device structs
* @unref:The unref operation for dyn. allocated watchdog_device structs
@@ -44,6 +45,7 @@ struct watchdog_ops {
int (*ping)(struct watchdog_device *);
unsigned int (*status)(struct watchdog_device *);
int (*set_timeout)(struct watchdog_device *, unsigned int);
+ int (*set_pretimeout)(struct watchdog_device *, unsigned int);
unsigned int (*get_timeleft)(struct watchdog_device *);
void (*ref)(struct watchdog_device *);
void (*unref)(struct watchdog_device *);
@@ -86,6 +88,7 @@ struct watchdog_device {
const struct watchdog_ops *ops;
unsigned int bootstatus;
unsigned int timeout;
+ unsigned int pretimeout;
Description (further below) missing.
I describe it in the ahead of this structure as the above.
unsigned int min_timeout;
unsigned int max_timeout;
void *driver_data;
@@ -123,6 +126,12 @@ static inline bool watchdog_timeout_invalid(struct
watchdog_device *wdd, unsigne
(t < wdd->min_timeout || t > wdd->max_timeout));
}
+/* Use the following function to check if a pretimeout value is invalid */
+static inline bool watchdog_pretimeout_invalid(struct watchdog_device *wdd,
unsigned int t)
Please fix checkpatch warnings.
You mean over 80 characters? Will fix in v2.
+{
+ return ((wdd->timeout != 0) && (t >= wdd->timeout));
Unnecessary ( ), and "!= 0" is unnecessary.
I think t >= wdd->timeout is need, since it's a pre-timeout.
return wdd->timeout && t >= wdd->timeout;
+}
+
/* Use the following functions to manipulate watchdog driver specific data */
static inline void watchdog_set_drvdata(struct watchdog_device *wdd, void
*data)
{
Re: [PATCH 1/3] ibmvsci: make parameters max_id and max_channel read-only
> "Laurent" == Laurent Vivier writes: Laurent> Ping ? >> this series has been reviewed and ack'ed, as SCSI maintainer, could >> you take it ? My mailbox doesn't reach quite far enough back in time to pick this up and I'd rather not have to deal with mail archive-mangled versions. Please apply the relevant Reviewed-by tags and repost. Thank you! -- Martin K. Petersen Oracle Linux Engineering -- 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] sg: Fix double-free when drives detach during SG_IO
> "Doug" == Douglas Gilbert writes: >> In sg_common_write(), we free the block request and return -ENODEV if >> the device is detached in the middle of the SG_IO ioctl(). >> >> Unfortunately, sg_finish_rem_req() also tries to free srp->rq, so we >> end up freeing rq->cmd in the already free rq object, and then free >> the object itself out from under the current user. >> >> This ends up corrupting random memory via the list_head on the rq >> object. The most common crash trace I saw is this: >> Signed-off-by: Calvin Owens Doug> Acked-by: Douglas Gilbert Applied. -- Martin K. Petersen Oracle Linux Engineering -- 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 14/15] dax: dirty extent notification
On Mon, Nov 2, 2015 at 5:16 PM, Dave Chinner wrote: > On Sun, Nov 01, 2015 at 11:30:58PM -0500, Dan Williams wrote: >> DAX-enabled block device drivers can use hints from fs/dax.c to >> optimize their internal tracking of potentially dirty cpu cache lines. >> If a DAX mapping is being used for synchronous operations, dax_do_io(), >> a dax-enabled block-driver knows that fs/dax.c will handle immediate >> flushing. For asynchronous mappings, i.e. returned to userspace via >> mmap, the driver can track active extents of the media for flushing. > > So, essentially, you are marking the calls into the mapping calls > with BLKDAX_F_DIRTY when the mapping is requested for a write page > fault? Hence allowing the block device to track "dirty pages" > exactly? Not pages, but larger extents (1 extent = 1/NUM_DAX_EXTENTS of the total storage capacity), because tracking dirty mappings should be temporary compatibility hack and not a first class citizen. > But, really, if we're going to use Ross's mapping tree patches that > use exceptional entries to track dirty pfns, why do we need to this > special interface from DAX to the block device? Ross's changes will > track mmap'd ranges that are dirtied at the filesytem inode level, > and the fsync/writeback will trigger CPU cache writeback of those > dirty ranges. This will work for block devices that are mapped by > DAX, too, because they have a inode+mapping tree, too. > > And if we are going to use Ross's infrastructure (which, when we > work the kinks out of, I think we will), we really should change > dax_do_io() to track pfns that are dirtied this way, too. That will > allow us to get rid of all the cache flushing from the DAX layer > (they'll get pushed into fsync/writeback) and so we only take the > CPU cache flushing penalties when synchronous operations are > requested by userspace... No, we definitely can't do that. I think your mental model of the cache flushing is similar to the disk model where a small buffer is flushed after a large streaming write. Both Ross' patches and my approach suffer from the same horror that the cache flushing is O(N) currently, so we don't want to make it responsible for more data ranges areas than is strictly necessary. >> We can later extend the DAX paths to indicate when an async mapping is >> "closed" allowing the active extents to be marked clean. > > Yes, that's a basic feature of Ross's patches. Hence I think this > special case DAX<->bdev interface is the wrong direction to be > taking. So here's my problem with the "track dirty mappings" in the core mm/vfs approach, it's harder to unwind and delete when it turns out no application actually needs it, or the platform gives us an O(1) flush method that is independent of dirty pte tracking. We have the NVML [1] library as the recommended method for applications to interact with persistent memory and it is not using fsync/msync for its synchronization primitives, it's managing the cache directly. The *only* user for tracking dirty DAX mappings is unmodified legacy applications that do mmap I/O and call fsync/msync. DAX in my opinion is not a transparent accelerator of all existing apps, it's a targeted mechanism for applications ready to take advantage of byte addressable persistent memory. This is why I'm a big supporter of your per-inode DAX control proposal. The fact that fsync is painful for large amounts of dirty data is a feature. It detects inodes that should have had DAX-disabled in the first instance. The only advantage of the radix approach is that the second fsync after the big hit may be faster, but that still can't beat either targeted disabling of DAX or updating the app to use NVML. So, again, I remain to be convinced that we need to carry complexity in the core kernel when we have the page cache to cover those cases. The driver solution is a minimal extension of the data bdev_direct_access() is already sending down to the driver, and covers the gap without mm/fs entanglements while we figure out a longer term solution. [1]: https://github.com/pmem/nvml -- 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 02/15] dax: increase granularity of dax_clear_blocks() operations
On Mon, Nov 02, 2015 at 07:27:26PM -0800, Dan Williams wrote: > On Mon, Nov 2, 2015 at 4:51 PM, Dave Chinner wrote: > > On Sun, Nov 01, 2015 at 11:29:53PM -0500, Dan Williams wrote: > > The zeroing (and the data, for that matter) doesn't need to be > > committed to persistent store until the allocation is written and > > committed to the journal - that will happen with a REQ_FLUSH|REQ_FUA > > write, so it makes sense to deploy the big hammer and delay the > > blocking CPU cache flushes until the last possible moment in cases > > like this. > > In pmem terms that would be a non-temporal memset plus a delayed > wmb_pmem at REQ_FLUSH time. Better to write around the cache than > loop over the dirty-data issuing flushes after the fact. We'll bump > the priority of the non-temporal memset implementation. Why is it better to do two synchronous physical writes to memory within a couple of microseconds of CPU time rather than writing them through the cache and, in most cases, only doing one physical write to memory in a separate context that expects to wait for a flush to complete? 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 1/2] dma: add Qualcomm Technologies HIDMA management driver
On 11/2/2015 4:30 PM, Arnd Bergmann wrote:
On Saturday 31 October 2015 02:51:46 Sinan Kaya wrote:
On 10/30/2015 5:34 AM, Arnd Bergmann wrote:
On Thursday 29 October 2015 23:08:12 Sinan Kaya wrote:
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
+
+static int qcom_hidma_mgmt_err_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, qcom_hidma_mgmt_err, inode->i_private);
+}
+
+static const struct file_operations qcom_hidma_mgmt_err_fops = {
+ .open = qcom_hidma_mgmt_err_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static ssize_t qcom_hidma_mgmt_mhiderr_clr(struct file *file,
+ const char __user *user_buf, size_t count, loff_t *ppos)
+{
+ struct qcom_hidma_mgmt_dev *mgmtdev = file->f_inode->i_private;
+
+ HIDMA_RUNTIME_GET(mgmtdev);
+ writel(1, mgmtdev->dev_virtaddr + MHID_BUS_ERR_CLR_OFFSET);
+ HIDMA_RUNTIME_SET(mgmtdev);
+ return count;
+}
+
+static const struct file_operations qcom_hidma_mgmt_mhiderr_clrfops = {
+ .write = qcom_hidma_mgmt_mhiderr_clr,
+};
Is this really just a debugging interface? If anyone would do this
for normal operation, it needs to be a proper API.
This will be used by the system admin to monitor/reset the execution
state of the DMA channels. This will be the management interface.
Debugfs is probably not the right choice. I originally had sysfs but
than had some doubts. I'm open to suggestions.
User interface design is unfortunately always hard, and I don't have
an obvious answer for you.
Using debugfs by definition means that you don't expect users to
rely on ABI stability, so they should not write any automated scripts
against the contents of the files.
With sysfs, the opposite is true: you need to maintain compatibility
for as long as anyone might rely on the current interface, and it
needs to be reviewed properly and documented in Documentation/ABI/.
Other options are to use ioctl(), netlink or your own virtual file
system, but each of them has the same ABI requirements as sysfs.
Regardless of what you pick, you also need to consider how other drivers
would use the same interface: If someone else has hardware that does
the same thing, we want to be able to use the same tools to access
it, so you should avoid having any hardware specific data in it and
keep it as generic and extensible as possible. In this particular
case, that probably means you should implement the user interfaces in
the dmaengine core driver, and let the specific DMA driver provide
callback function pointers along with the normal ones to fill that
data.
Thanks, I'll think about this. I'm inclined towards sysfs.
+ dev_info(>dev,
+ "HI-DMA engine management driver registration complete\n");
+ platform_set_drvdata(pdev, mgmtdev);
+ HIDMA_RUNTIME_SET(mgmtdev);
+ return 0;
+out:
+ pm_runtime_disable(>dev);
+ pm_runtime_put_sync_suspend(>dev);
+ return rc;
+}
The rest of the probe function does not register any user interface aside from
the debugging stuff. Can you explain in the changelog how you expect the
driver to be used in a real system? Is there another driver coming?
I expect this driver to grow in functionality over time. Right now, it
does the global init for the DMA. After that all channels execute on
their own without depending on each other. Global init has to be done
first before attempting to do any channel initialization.
There is also implied startup ordering requirements. I was doing this by
using channel driver with the late binding to guarantee that.
As soon as I use module_platform_driver, the ordering gets reversed for
some reason.
For the ordering requirements, it's probably best to export a symbol
with the entry point and let the normal driver call into that. Using
separate initcall levels is not something you should do in a normal
device driver like this.
I figured this out. If the channel driver starts before the management
driver; then channel reset fails. I'm handling this in the channel
driver and am returning -EPROBE_DEFER. After that, management driver
gets its chance to work. Then, the channel driver again. This change is
in the v2 series.
What is the relation between the device nodes for the two kinds of
devices? Does it make sense to model the other one as a child device
of this one? That way you would trivially do the ordering by not marking
this one as 'compatible="simple-bus"' and triggering the registration
of the child from the parent probe function.
The required order is management driver first, channel drivers next. If
the order is reversed, channel init fails. I handle this with deferred
probing.
I tried to keep loose binding between the management driver due to QEMU.
QEMU auto-generates the devicetree entries. The guest machine just sees
one devicetree object
Re: [PATCH v2 net-next] net/core: generic support for disabling netdev features down stack
From: Jarod Wilson Date: Mon, 2 Nov 2015 21:55:59 -0500 > There are some netdev features, which when disabled on an upper device, > such as a bonding master or a bridge, must be disabled and cannot be > re-enabled on underlying devices. > > This is a rework of an earlier more heavy-handed appraoch, which simply > disables and prevents re-enabling of netdev features listed in a new > define in include/net/netdev_features.h, NETIF_F_UPPER_DISABLES. Any upper > device that disables a flag in that feature mask, the disabling will > propagate down the stack, and any lower device that has any upper device > with one of those flags disabled should not be able to enable said flag. > > Initially, only LRO is included for proof of concept, and because this > code effectively does the same thing as dev_disable_lro(), though it will > also activate from the ethtool path, which was one of the goals here. ... > This has been successfully tested with bnx2x, qlcnic and netxen network > cards as slaves in a bond interface. Turning LRO on or off on the master > also turns it on or off on each of the slaves, new slaves are added with > LRO in the same state as the master, and LRO can't be toggled on the > slaves. > > Also, this should largely remove the need for dev_disable_lro(), and most, > if not all, of its call sites can be replaced by simply making sure > NETIF_F_LRO isn't included in the relevant device's feature flags. > > Note that this patch is driven by bug reports from users saying it was > confusing that bonds and slaves had different settings for the same > features, and while it won't be 100% in sync if a lower device doesn't > support a feature like LRO, I think this is a good step in the right > direction. ... > Signed-off-by: Jarod Wilson Looks good to me, applied, thanks Jarod. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 10/17] phy: Add driver for rockchip Display Port PHY
Hi Yakir,
On Thu, Oct 29, 2015 at 09:58:38AM +0800, Yakir Yang wrote:
> Add phy driver for the Rockchip DisplayPort PHY module. This
> is required to get DisplayPort working in Rockchip SoCs.
>
> Reviewed-by: Heiko Stuebner
> Signed-off-by: Yakir Yang
> ---
...
> diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
> new file mode 100644
> index 000..f3e0058
> --- /dev/null
> +++ b/drivers/phy/phy-rockchip-dp.c
> @@ -0,0 +1,151 @@
> +/*
> + * Rockchip DP PHY driver
> + *
> + * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
> + * Author: Yakir Yang
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define GRF_SOC_CON12 0x0274
> +
> +#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK BIT(4)
> +#define GRF_EDP_REF_CLK_SEL_INTER BIT(4)
Why are the above two macros the same? Judging by the RK3288 manual and
other downstream drivers, it seems like you want the _MASK one to be
shifted left by 16 (i.e., BIT(20)).
> +
> +#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK BIT(21)
> +#define GRF_EDP_PHY_SIDDQ_ON0
> +#define GRF_EDP_PHY_SIDDQ_OFF BIT(5)
> +
...
> + ret = regmap_write(dp->grf, GRF_SOC_CON12, GRF_EDP_REF_CLK_SEL_INTER |
> +GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK);
IOW, the above is writing:
BIT(4) | BIT(4)
whereas I think you want:
BIT(4) | BIT(20)
> + if (ret != 0) {
> + dev_err(dp->dev, "Could not config GRF edp ref clk: %d\n", ret);
> + return ret;
> + }
> +
...
(FYI, I came across this by inspection when comparing Heiko's
'somewhat-stable' branch [1] with this series. The former brings up eDP
fine on veyron-jaq, whereas this one doesn't yet, even with the above
change. Still debugging the issue.)
Brian
[1] https://github.com/mmind/linux-rockchip/tree/devel/somewhat-stable
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures
On Mon, Nov 02, 2015 at 10:36:52PM -0500, David Miller wrote: > From: Minchan Kim > Date: Tue, 3 Nov 2015 11:36:51 +0900 > > > For the convenience for Dave, I found this. > > > > commit ec98c6b9b47df6df1c1fa6cf3d427414f8c2cf16 > > Author: David S. Miller > > Date: Sun Apr 20 02:14:23 2008 -0700 > > > > [SPARC]: Remove SunOS and Solaris binary support. > > > > As per Documentation/feature-removal-schedule.txt > > > > Signed-off-by: David S. Miller > > > > Hello Dave, > > Could you confirm it? > > I don't understand what you want me to confirm. Sorry for lacking of the information. Is it okay to use number 8 for upcoming madvise(addr, len, MADV_FREE) feature in sparc arch? The reason to ask is that Darrick pointed out earlier that dietlibc has a Solaris #define MADV_FREE 0x5 in its mman.h and Hugh pointed out that was in the kernel's sparc mman.h up until 2.6.25 but disappeared now so I guess it's okay to use the number 8 for MADV_FREE in sparc but want to confirm from you. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 2/2] watchdog: imx2_wdt: add set_pretimeout interface
On 11/02/2015 07:29 PM, Robin Gong wrote:
Enable set_pretimeout interface and trigger the pretimeout interrupt before
watchdog timeout event happen.
Signed-off-by: Robin Gong
---
drivers/watchdog/imx2_wdt.c | 67 -
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 0bb1a1d..d3c6b07 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -24,7 +24,9 @@
#include
#include
#include
+#include
#include
+#include
Are those two new includes both needed ?
#include
#include
#include
@@ -52,12 +54,18 @@
#define IMX2_WDT_WRSR 0x04/* Reset Status Register */
#define IMX2_WDT_WRSR_TOUT(1 << 1) /* -> Reset due to Timeout */
+#define IMX2_WDT_WICR 0x06/*Interrupt Control Register*/
+#define IMX2_WDT_WICR_WIE (1 << 15) /* -> Interrupt Enable */
+#define IMX2_WDT_WICR_WTIS (1 << 14) /* -> Interrupt Status */
+#define IMX2_WDT_WICR_WICT (0xFF << 0) /* Watchdog Interrupt Timeout
*/
+
"<< 0" doesn't really add any value here.
#define IMX2_WDT_WMCR 0x08/* Misc Register */
#define IMX2_WDT_MAX_TIME 128
#define IMX2_WDT_DEFAULT_TIME 60 /* in seconds */
#define WDOG_SEC_TO_COUNT(s) ((s * 2 - 1) << 8)
+#define WDOG_SEC_TO_PRECOUNT(s)(s * 2) /* set WDOG pre timeout
count*/
((s) * 2)
Ah yes, WDOG_SEC_TO_COUNT should also use (s).
struct imx2_wdt_device {
struct clk *clk;
@@ -80,7 +88,8 @@ MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds
(default="
static const struct watchdog_info imx2_wdt_info = {
.identity = "imx2+ watchdog",
- .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE,
+ .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE
+ | WDIOF_PRETIMEOUT,
};
static int imx2_restart_handler(struct notifier_block *this, unsigned long
mode,
@@ -207,12 +216,59 @@ static inline void imx2_wdt_ping_if_active(struct
watchdog_device *wdog)
}
}
+static int imx2_wdt_check_pretimeout_set(struct imx2_wdt_device *wdev)
+{
+ u32 val;
+
+ regmap_read(wdev->regmap, IMX2_WDT_WICR, );
+ return (val & IMX2_WDT_WICR_WIE) ? 1 : 0;
I don't understand the point of this function.
You check if IMX2_WDT_WICR_WIE is set,
+}
+
+static int imx2_wdt_set_pretimeout(struct watchdog_device *wdog,
+ unsigned int new_timeout)
+{
+ struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+ u32 val;
+
+ regmap_read(wdev->regmap, IMX2_WDT_WICR, );
+ /* set the new pre-timeout value in the WSR */
+ val &= ~IMX2_WDT_WICR_WICT;
+ val |= WDOG_SEC_TO_PRECOUNT(new_timeout);
+
What is the time here ? Is pretimeout the number of seconds
until the interrupt occurs, or the number of seconds before the actual
timeout (as per API) ?
+ if (!imx2_wdt_check_pretimeout_set(wdev))
+ val |= IMX2_WDT_WICR_WIE; /*enable*/
if IMX2_WDT_WICR_WIE is not set, you set it,
+
+ regmap_write(wdev->regmap, IMX2_WDT_WICR, val);
+
and write the result unconditionally. Unless I am missing something,
regmap_write, wdev->regmap, IMX2_WDT_WICR, val | IMX2_WDT_WICR_WIE);
would accomplish exactly the same.
+ wdog->pretimeout = new_timeout;
+
+ return 0;
+}
+
+static irqreturn_t imx2_wdt_isr(int irq, void *dev_id)
+{
+ struct platform_device *pdev = dev_id;
+ struct watchdog_device *wdog = platform_get_drvdata(pdev);
+ struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+ u32 val;
+
+ regmap_read(wdev->regmap, IMX2_WDT_WICR, );
+ if (val & IMX2_WDT_WICR_WTIS) {
+ /*clear interrupt status bit*/
+ regmap_write(wdev->regmap, IMX2_WDT_WICR, val);
+ dev_warn(>dev, "pre-timeout:%d, %d Seconds remained\n",
+wdog->pretimeout, wdog->timeout - wdog->pretimeout);
The idea here is that this should trigger a panic.
+ }
+ return IRQ_HANDLED;
+}
+
static const struct watchdog_ops imx2_wdt_ops = {
.owner = THIS_MODULE,
.start = imx2_wdt_start,
.stop = imx2_wdt_stop,
.ping = imx2_wdt_ping,
.set_timeout = imx2_wdt_set_timeout,
+ .set_pretimeout = imx2_wdt_set_pretimeout,
};
static const struct regmap_config imx2_wdt_regmap_config = {
@@ -229,6 +285,7 @@ static int __init imx2_wdt_probe(struct platform_device
*pdev)
struct resource *res;
void __iomem *base;
int ret;
+ int irq;
u32 val;
wdev = devm_kzalloc(>dev, sizeof(*wdev), GFP_KERNEL);
@@ -253,6 +310,14 @@ static int __init imx2_wdt_probe(struct platform_device
*pdev)
return PTR_ERR(wdev->clk);
}
+ irq =
Re: [v7, 2/6] fsl/fman: Add FMan support
From:
Date: Mon, 2 Nov 2015 14:30:12 +0200
> +static int clear_iram(struct fman *fman)
> +{
> + struct fman_iram_regs __iomem *iram;
> + int i, count;
> +
> + iram = (struct fman_iram_regs __iomem *)(fman->base_addr + IMEM_OFFSET);
"fman->base_addr" is of type "void __iomem *", therefore no cast should
be necessary at all.
Please audit your entire driver submission for this problem.
THanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/3] dmaselftest: add memcpy selftest support functions
On 11/2/2015 11:15 PM, Vinod Koul wrote: On Mon, Nov 02, 2015 at 01:07:38AM -0500, Sinan Kaya wrote: This patch adds supporting utility functions for selftest. The intention is to share the self test code between different drivers. Supported test cases include: 1. dma_map_single 2. streaming DMA 3. coherent DMA 4. scatter-gather DMA This seems quite similar to dmatest, any reason why you cannot use/enhance that? Dmatest is a standalone kernel module intended for stress testing DMA engines from userspace with N number of threads and M size combinations etc. This one; on the other hand, is selftest to verify hardware is working as expected during power up. Almost all DMA engine drivers come with some sort of selftest code called from probe. I followed the same design pattern. I think the goal is to remove the duplicate self test code in all drivers over time. -- Sinan Kaya Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 2/3] dmaselftest: add memcpy selftest support functions
On Mon, Nov 02, 2015 at 01:07:38AM -0500, Sinan Kaya wrote: > This patch adds supporting utility functions > for selftest. The intention is to share the self > test code between different drivers. > > Supported test cases include: > 1. dma_map_single > 2. streaming DMA > 3. coherent DMA > 4. scatter-gather DMA This seems quite similar to dmatest, any reason why you cannot use/enhance that? -- ~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 v1 1/2] watchdog: add WDIOC_SETPRETIMEOUT and WDIOC_GETPRETIMEOUT
On 11/02/2015 07:29 PM, Robin Gong wrote:
Since the watchdog common framework centrialize the IOCTL interfaces of
device driver now, the SETPRETIMEOUT and GETPRETIMEOUT need to be added
in the common code.
Signed-off-by: Robin Gong
---
drivers/watchdog/watchdog_dev.c | 38 ++
include/linux/watchdog.h| 9 +
2 files changed, 47 insertions(+)
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 6aaefba..02632fe 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -218,6 +218,37 @@ out_timeout:
}
/*
+ * watchdog_set_pretimeout: set the watchdog timer pretimeout
+ * @wddev: the watchdog device to set the timeout for
+ * @timeout: pretimeout to set in seconds
+ */
+
+static int watchdog_set_pretimeout(struct watchdog_device *wddev,
+ unsigned int timeout)
Please align with "(".
+{
+ int err;
+
+ if ((wddev->ops->set_pretimeout == NULL) ||
Unnecessary ( ), and "== NULL" is unnecessary as well.
+ !(wddev->info->options & WDIOF_PRETIMEOUT))
+ return -EOPNOTSUPP;
+ if (watchdog_pretimeout_invalid(wddev, timeout))
+ return -EINVAL;
+
+ mutex_lock(>lock);
+
+ if (test_bit(WDOG_UNREGISTERED, >status)) {
+ err = -ENODEV;
+ goto out_timeout;
+ }
+
+ err = wddev->ops->set_pretimeout(wddev, timeout);
+
+out_timeout:
+ mutex_unlock(>lock);
+ return err;
+}
+
+/*
*watchdog_get_timeleft: wrapper to get the time left before a reboot
*@wddev: the watchdog device to get the remaining time from
*@timeleft: the time that's left
@@ -393,6 +424,13 @@ static long watchdog_ioctl(struct file *file, unsigned int
cmd,
if (err)
return err;
return put_user(val, p);
+ case WDIOC_SETPRETIMEOUT:
+ if (get_user(val, p))
+ return -EFAULT;
+ err = watchdog_set_pretimeout(wdd, val);
+ return err;
return watchdog_set_pretimeout(wdd, val);
+ case WDIOC_GETPRETIMEOUT:
+ return put_user(wdd->pretimeout, p);
default:
return -ENOTTY;
}
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index d74a0e9..6ddb2d6 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -25,6 +25,7 @@ struct watchdog_device;
* @ping: The routine that sends a keepalive ping to the watchdog device.
* @status: The routine that shows the status of the watchdog device.
* @set_timeout:The routine for setting the watchdog devices timeout value.
+ * @set_pretimeout:The routine for setting the watchdog devices pretimeout.
* @get_timeleft:The routine that get's the time that's left before a reset.
* @ref: The ref operation for dyn. allocated watchdog_device structs
* @unref:The unref operation for dyn. allocated watchdog_device structs
@@ -44,6 +45,7 @@ struct watchdog_ops {
int (*ping)(struct watchdog_device *);
unsigned int (*status)(struct watchdog_device *);
int (*set_timeout)(struct watchdog_device *, unsigned int);
+ int (*set_pretimeout)(struct watchdog_device *, unsigned int);
unsigned int (*get_timeleft)(struct watchdog_device *);
void (*ref)(struct watchdog_device *);
void (*unref)(struct watchdog_device *);
@@ -86,6 +88,7 @@ struct watchdog_device {
const struct watchdog_ops *ops;
unsigned int bootstatus;
unsigned int timeout;
+ unsigned int pretimeout;
Description (further below) missing.
unsigned int min_timeout;
unsigned int max_timeout;
void *driver_data;
@@ -123,6 +126,12 @@ static inline bool watchdog_timeout_invalid(struct
watchdog_device *wdd, unsigne
(t < wdd->min_timeout || t > wdd->max_timeout));
}
+/* Use the following function to check if a pretimeout value is invalid */
+static inline bool watchdog_pretimeout_invalid(struct watchdog_device *wdd,
unsigned int t)
Please fix checkpatch warnings.
+{
+ return ((wdd->timeout != 0) && (t >= wdd->timeout));
Unnecessary ( ), and "!= 0" is unnecessary.
+}
+
/* Use the following functions to manipulate watchdog driver specific data */
static inline void watchdog_set_drvdata(struct watchdog_device *wdd, void
*data)
{
--
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/5] ARM: asm/div64.h: adjust to generic codde
[added Mike/linux-clk and David/dri-devel] A patch I produced is now highlighting existing bugs in the drivers listed below. On Tue, 3 Nov 2015, kbuild test robot wrote: > Hi Nicolas, > > [auto build test WARNING on asm-generic/master -- if it's inappropriate base, > please suggest rules for selecting the more suitable base] > > url: > https://github.com/0day-ci/linux/commits/Nicolas-Pitre/div64-h-optimize-do_div-for-power-of-two-constant-divisors/20151103-065348 > config: arm-multi_v7_defconfig (attached as .config) > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=arm > > All warnings (new ones prefixed by >>): > >In file included from arch/arm/include/asm/div64.h:126:0, > from include/linux/kernel.h:136, > from include/asm-generic/bug.h:13, > from arch/arm/include/asm/bug.h:62, > from include/linux/bug.h:4, > from include/linux/io.h:23, > from include/linux/clk-provider.h:14, > from drivers/clk/imx/clk-pllv1.c:1: >drivers/clk/imx/clk-pllv1.c: In function 'clk_pllv1_recalc_rate': >include/asm-generic/div64.h:217:28: warning: comparison of distinct > pointer types lacks a cast > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ >^ > >> drivers/clk/imx/clk-pllv1.c:99:2: note: in expansion of macro 'do_div' > do_div(ll, mfd + 1); > ^ Here the problem is in clk-pllv1.c where the ll variable is declared as a long long. It should be an unsigned long long, or better yet an uint64_t or u64. > -- >In file included from arch/arm/include/asm/div64.h:126:0, > from include/linux/kernel.h:136, > from drivers/clk/imx/clk-pllv2.c:1: >drivers/clk/imx/clk-pllv2.c: In function '__clk_pllv2_recalc_rate': >include/asm-generic/div64.h:217:28: warning: comparison of distinct > pointer types lacks a cast > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ >^ > >> drivers/clk/imx/clk-pllv2.c:103:2: note: in expansion of macro 'do_div' > do_div(temp, mfd + 1); > ^ Same thing: temp is declared as a s64. It should be u64. >drivers/clk/imx/clk-pllv2.c: In function '__clk_pllv2_set_rate': >include/asm-generic/div64.h:217:28: warning: comparison of distinct > pointer types lacks a cast > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ >^ >drivers/clk/imx/clk-pllv2.c:145:2: note: in expansion of macro 'do_div' > do_div(temp64, quad_parent_rate / 100); > ^ Ditto here. > -- >In file included from arch/arm/include/asm/div64.h:126:0, > from include/linux/kernel.h:136, > from drivers/clk/tegra/clk-divider.c:17: >drivers/clk/tegra/clk-divider.c: In function 'get_div': >include/asm-generic/div64.h:217:28: warning: comparison of distinct > pointer types lacks a cast > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ >^ > >> drivers/clk/tegra/clk-divider.c:50:2: note: in expansion of macro 'do_div' > do_div(divider_ux1, rate); > ^ Ditto here. > -- >In file included from arch/arm/include/asm/div64.h:126:0, > from include/linux/kernel.h:136, > from drivers/clk/ti/clkt_dpll.c:17: >drivers/clk/ti/clkt_dpll.c: In function 'omap2_get_dpll_rate': >include/asm-generic/div64.h:217:28: warning: comparison of distinct > pointer types lacks a cast > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ >^ > >> drivers/clk/ti/clkt_dpll.c:266:2: note: in expansion of macro 'do_div' > do_div(dpll_clk, dpll_div + 1); > ^ Ditto here. > -- >In file included from arch/arm/include/asm/div64.h:126:0, > from include/linux/kernel.h:136, > from include/linux/clk.h:16, > from drivers/clk/ti/fapll.c:12: >drivers/clk/ti/fapll.c: In function 'ti_fapll_recalc_rate': >include/asm-generic/div64.h:217:28: warning: comparison of distinct > pointer types lacks a cast > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ >^ > >> drivers/clk/ti/fapll.c:182:3: note: in expansion of macro 'do_div' > do_div(rate, fapll_p); > ^ Ditto here. >drivers/clk/ti/fapll.c: In function 'ti_fapll_synth_recalc_rate': >include/asm-generic/div64.h:217:28: warning: comparison of distinct > pointer types lacks a cast > (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ >^ >drivers/clk/ti/fapll.c:346:3: note: in expansion of macro 'do_div' >
[BUG, bisect] i2c: designware: Move common probe code into i2c_dw_probe()
Jarkko, all, Commit d80d134182ba5 introduced a bug which causes a cyapa based touch pad on an Acer C720 Chromebook to become inoperative. This is present in the latest linux-next (20151101). The patch description is repeated below. From d80d134182ba536ececab8d5fca50d779befc9a6 Mon Sep 17 00:00:00 2001 From: Jarkko Nikula Date: Mon, 12 Oct 2015 16:55:35 +0300 Subject: [PATCH] i2c: designware: Move common probe code into i2c_dw_probe() There is some code duplication in i2c-designware-platdrv and i2c-designware-pcidrv probe functions. What is even worse that duplication requires i2c_dw_xfer(), i2c_dw_func() and i2c_dw_isr() i2c-designware-core functions to be exported. Therefore move common code into new i2c_dw_probe() and make functions above local to i2c-designware-core. While merging the code patch does following functional changes: - I2C Adapter name will be "Synopsys DesignWare I2C adapter". Previously it was used for platform and ACPI devices but PCI device used "i2c-designware-pci". - Using device name for interrupt name. Previous it was platform device name, ACPI device name or "i2c-designware-pci". - Error code from devm_request_irq() and i2c_add_numbered_adapter() will be printed in case of error. Signed-off-by: Jarkko Nikula Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-designware-core.c| 49 + drivers/i2c/busses/i2c-designware-core.h| 5 +-- drivers/i2c/busses/i2c-designware-pcidrv.c | 30 ++ drivers/i2c/busses/i2c-designware-platdrv.c | 28 ++--- 4 files changed, 49 insertions(+), 63 deletions(-) -- - Jeremiah Mahler -- 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: Resource leak in unshare
From: Eric Dumazet Date: Mon, 02 Nov 2015 17:16:44 -0800 > On Mon, 2015-11-02 at 17:08 -0800, Eric Dumazet wrote: >> From: Eric Dumazet > > Erm, patch title would be : > > [PATCH] sit: fix sit0 percpu double allocations :-) Applied and queued up for -stable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 1/1] usb:serial: Add Fintek F81532/534 driver
This driver is for Fintek F81532/F81534 USB to Serial Ports IC. Features: 1. F81534 is 1-to-4 & F81532 is 1-to-2 serial ports IC 2. Support Baudrate from B50 to B150 (excluding B100). 3. The RTS signal can be transformed their behavior with configuration by ioctl TIOCGRS485/TIOCSRS485 If the driver setting with SER_RS485_ENABLED, the RTS signal will high with not in TX and low with in TX. If the driver setting with SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND, the RTS signal will low with not in TX and high with in TX. 4. The 4x3 output-only open-drain pins for F81532/534 is designed for control outer devices (with our EVB for examples, the 4 sets of pins are designed to control transceiver mode). So it implements as gpiolib interface with output-only function. 5. It'll save the configuration in internal storage when uart/pins mode changed. Please reference https://bitbucket.org/hpeter/fintek-general/src/ with f81534/tools to get set_gpio.c & set_mode.c to change F81532/534 setting. Please use it carefully. Signed-off-by: Peter Hung --- Changelog: v6 1. Re-implement the write()/resume() function. Due to this device cant be suitable with generic write(), we'll do the submit write URB when write()/received tx empty/set_termios()/resume() 2. Logic/Phy Port mapping rewrite in f81534_port_probe() & f81534_phy_to_logic_port(). 3. Introduced "Port Hide" function. Some customer use F81532 reference design for HW layout, but really use F81534 IC. We'll check F81534_PORT_CONF_DISABLE_PORT flag with in uart mode field to do port hide with port not used. It can be avoid end-user to use not layouted port. 4. The 4x3 output-only open-drain pins for F81532/534 is designed for control outer devices (with our EVB for examples, the 4 sets of pins are designed to control transceiver mode). So we decide to implement with gpiolib interface. v5 1. Change the configure data address F81534_CUSTOM_ADDRESS_START from 0x4000 to 0x2f00 (for MP F/W ver:AA66) 2. Change f81534_port_disable/enable() from H/W mode to S/W mode It'll skip all rx data when port is not opened. 3. Some function modifier add with static (Thanks for Paul Bolle) 4. It's will direct return when count=0 in f81534_write() to reduce spin_lock usage. v4 1. clearify f81534_process_read_urb() with f81534_process_per_serial_block(). (referenced from mxuport.c) 2. We limited f81534_write() max tx kfifo with 124Bytes. Original subsystem is designed for auto tranmiting fifo data if available. But we must wait for tx_empty for next tx data (H/W design). With this kfifo size limit, we can use generic subsystem api with f81534_write(). When usb_serial_generic_write_start() called after first write URB complete, the fifo will no data. The generic subsystem of write will go to idle state. Until we received TX_EMPTY and release write spinlock, the fifo will fill max 124Bytes by following f81534_write(). v3 1. Migrate read, write and some routine from custom code to usbserial subsystem callback function. 2. Use more defines to replece magic numbers to make it meaningful 3. Make more comments as document in source code. v2 1. v1 version submit to staging tree, but Greg KH advised me to cleanup source code & re-submit it to correct subsystem 2. Remove all custom ioctl commands drivers/usb/serial/Kconfig | 10 + drivers/usb/serial/Makefile |1 + drivers/usb/serial/f81534.c | 2991 +++ 3 files changed, 3002 insertions(+) create mode 100644 drivers/usb/serial/f81534.c diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig index 56ecb8b..0642864 100644 --- a/drivers/usb/serial/Kconfig +++ b/drivers/usb/serial/Kconfig @@ -255,6 +255,16 @@ config USB_SERIAL_F81232 To compile this driver as a module, choose M here: the module will be called f81232. +config USB_SERIAL_F8153X + tristate "USB Fintek F81532/534 Multi-Ports Serial Driver" + help + Say Y here if you want to use the Fintek F81532/534 Multi-Ports + usb to serial adapter. + + To compile this driver as a module, choose M here: the + module will be called f81534. + + config USB_SERIAL_GARMIN tristate "USB Garmin GPS driver" help diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile index 349d9df..9e43b7b 100644 --- a/drivers/usb/serial/Makefile +++ b/drivers/usb/serial/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_USB_SERIAL_EDGEPORT) += io_edgeport.o obj-$(CONFIG_USB_SERIAL_EDGEPORT_TI) += io_ti.o obj-$(CONFIG_USB_SERIAL_EMPEG) += empeg.o obj-$(CONFIG_USB_SERIAL_F81232)+= f81232.o +obj-$(CONFIG_USB_SERIAL_F8153X)
Re: [PATCH net-next v2 0/5] BPF updates
From: Daniel Borkmann Date: Thu, 29 Oct 2015 14:58:05 +0100 > This set adds support for persistent maps/progs. Please see > individual patches for further details. A man-page update > to bpf(2) will be sent later on, also a iproute2 patch for > support in tc. ... > v1 -> v2: > - Reworked most of patch 4 and 5 > - Rebased to latest net-next Series applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Nov 3
Hi all,
Please do *not* add any material intended for v4.5 to your linux-next
included branches until after v4.4-rc1 has been released.
Changes since 20151102:
The pci tree lost its build failure.
The net-next tree gained a conflict against the net tree.
The battery tree still had its build failure so I used the version from
next-20150925.
The mailbox tree still had its build failure so I used the version from
next-20151022.
The akpm tree lost a patch that turned up elsewhere.
Non-merge commits (relative to Linus' tree): 10572
8630 files changed, 406901 insertions(+), 191700 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log
files in the Next directory. Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final
link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig.
Below is a summary of the state of the merge.
I am currently merging 229 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master (e86328c489d7 Merge tag 'gpio-v4.4-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio)
Merging fixes/master (25cb62b76430 Linux 4.3-rc5)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on
module install)
Merging arc-current/for-curr (049e6dde7e57 Linux 4.3-rc4)
Merging arm-current/fixes (38850d786a79 ARM: 8449/1: fix bug in vdsomunge
swab32 macro)
Merging m68k-current/for-linus (95bc06ef049b m68k/defconfig: Update defconfigs
for v4.3-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (977bf062bba3 powerpc/dma: dma_set_coherent_mask()
should not be GPL only)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (4ab42d78e37a ppp, slip: Validate VJ compression slot
parameters completely)
Merging ipsec/master (ca064bd89363 xfrm: Fix pmtu discovery for local generated
packets.)
Merging ipvs/master (6ece90f9a13e netfilter: fix Kconfig dependencies for
nf_dup_ipv{4,6})
Merging sound-current/for-linus (de1ab6af5c3d ALSA: hda - Fix lost 4k BDL
boundary workaround)
Merging pci-current/for-linus (1266963170f5 PCI: Prevent out of bounds access
in numa_node override)
Merging wireless-drivers/master (de28a05ee28e Merge tag
'iwlwifi-for-kalle-2015-10-05' of
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (9ffecb102835 Linux 4.3-rc3)
Merging tty.current/tty-linus (f235f664a8af fbcon: initialize blink interval
before calling fb_set_par)
Merging usb.current/usb-linus (32b88194f71d Linux 4.3-rc7)
Merging usb-gadget-fixes/fixes (25cb62b76430 Linux 4.3-rc5)
Merging usb-serial-fixes/usb-linus (32b88194f71d Linux 4.3-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (f256896afdb6 usb: chipidea: otg:
gadget module load and unload support)
Merging staging.current/staging-linus (32b88194f71d Linux 4.3-rc7)
Merging char-misc.current/char-misc-linus (25cb62b76430 Linux 4.3-rc5)
Merging input-current/for-linus (195562194aad Input: alps - only the Dell
Latitude D420/430/620/630 have separate stick button bits)
Merging crypto-current/master (4afa5f961792 crypto: algif_hash - Only export
and import on sockets with data)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr()
[RFC PATCH 2/2] PCI: pciehp: Implement support for delayed poweron
Some oddball devices may experience PCIe link flaps after power-on.
This may result in the following sequence of events.
fpc0 kernel: pciehp :02:08.0:pcie24: Card present on Slot(0)
fpc0 kernel: pciehp :02:08.0:pcie24: slot(0): Link Up event
fpc0 kernel: pciehp :02:08.0:pcie24:
Link Up event ignored on slot(0): already powering on
fpc0 kernel: pciehp :02:08.0:pcie24: slot(0): Link Down event
fpc0 kernel: pciehp :02:08.0:pcie24:
Link Down event queued on slot(0): currently getting powered on
fpc0 kernel: pciehp :02:08.0:pcie24: slot(0): Link Up event
fpc0 kernel: pciehp :02:08.0:pcie24:
Link Up event queued on slot(0): currently getting powered off
This causes the driver for affected devices to be instantiated, removed,
and re-instantiated. While commit 'PCI: pciehp: Implement hotplug event
folding' reduces the scope of the problem, it can still occur. In some
cases, device insertion followed by immediate removal can result errors
such as the following.
fpc0 kernel: remove_proc_entry: removing non-empty directory 'irq/148',
leaking at least 'pic0'
fpc0 kernel: [ cut here ]
fpc0 kernel: WARNING: at fs/proc/generic.c:575
This can for example happen if the removed device provides gpio pins
and/or interrupts used by other drivers, if those other drivers are still
instantiated.
Add support for per-port power-on delay to avoid this situation. This can
be enabled globally with the pciehp_poweron_delay module parameter, or
per port (using a quirks function) with a new poweron_delay flag in
struct pci_dev.
With this patch, the link flap still occurs, but because of the delayed
insertion the driver is not immediately instantiated, and the above error
is no longer seen.
Signed-off-by: Guenter Roeck
---
drivers/pci/hotplug/pciehp.h | 4 +++-
drivers/pci/hotplug/pciehp_core.c | 3 +++
drivers/pci/hotplug/pciehp_ctrl.c | 30 +++---
drivers/pci/hotplug/pciehp_hpc.c | 5 -
include/linux/pci.h | 1 +
5 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
index 364b6fa32978..0d44b1691431 100644
--- a/drivers/pci/hotplug/pciehp.h
+++ b/drivers/pci/hotplug/pciehp.h
@@ -40,6 +40,7 @@
#define MY_NAME"pciehp"
+extern bool pciehp_poweron_delay;
extern bool pciehp_poll_mode;
extern int pciehp_poll_time;
extern bool pciehp_debug;
@@ -78,7 +79,7 @@ struct slot {
struct mutex lock;
struct mutex hotplug_lock;
struct workqueue_struct *wq;
- struct work_struct hotplug_work;
+ struct delayed_work hotplug_work;
u32 hotplug_req;
bool disable; /* true to disable before enable */
};
@@ -101,6 +102,7 @@ struct controller {
unsigned int cmd_busy:1;
unsigned int link_active_reporting:1;
unsigned int notification_enabled:1;
+ unsigned int poweron_delay:1;
unsigned int power_fault_detected;
};
diff --git a/drivers/pci/hotplug/pciehp_core.c
b/drivers/pci/hotplug/pciehp_core.c
index 612b21a14df5..cc69fd10d884 100644
--- a/drivers/pci/hotplug/pciehp_core.c
+++ b/drivers/pci/hotplug/pciehp_core.c
@@ -38,6 +38,7 @@
#include
/* Global variables */
+bool pciehp_poweron_delay;
bool pciehp_debug;
bool pciehp_poll_mode;
int pciehp_poll_time;
@@ -51,10 +52,12 @@ MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL");
+module_param(pciehp_poweron_delay, bool, 0644);
module_param(pciehp_debug, bool, 0644);
module_param(pciehp_poll_mode, bool, 0644);
module_param(pciehp_poll_time, int, 0644);
module_param(pciehp_force, bool, 0644);
+MODULE_PARM_DESC(pciehp_poweron_delay, "Delay port power-on");
MODULE_PARM_DESC(pciehp_debug, "Debugging mode enabled or not");
MODULE_PARM_DESC(pciehp_poll_mode, "Using polling mechanism for hot-plug
events or not");
MODULE_PARM_DESC(pciehp_poll_time, "Polling mechanism frequency, in seconds");
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c
b/drivers/pci/hotplug/pciehp_ctrl.c
index ad1321e91546..0c5b2e5965ce 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -169,7 +169,8 @@ static int remove_board(struct slot *p_slot)
*/
void pciehp_power_thread(struct work_struct *work)
{
- struct slot *p_slot = container_of(work, struct slot, hotplug_work);
+ struct slot *p_slot = container_of(work, struct slot,
+ hotplug_work.work);
int ret, req;
bool disable;
@@ -205,17 +206,21 @@ void pciehp_power_thread(struct work_struct *work)
}
}
-static void pciehp_queue_power_work(struct slot *p_slot, int req)
+static void pciehp_queue_power_work(struct slot *p_slot, int req, bool delay)
{
+ int delay_hz = 0;
+
if (req == ENABLE_REQ) {
p_slot->state = POWERON_STATE;
+ if (delay)
+
[RFC PATCH 1/2] PCI: pciehp: Merge hotplug work requests
Some oddball devices may experience a PCIe link flap after power-on.
This may result in the following sequence of events.
fpc0 kernel: pciehp :02:08.0:pcie24: Card present on Slot(0)
fpc0 kernel: pciehp :02:08.0:pcie24: slot(0): Link Up event
fpc0 kernel: pciehp :02:08.0:pcie24:
Link Up event ignored on slot(0): already powering on
fpc0 kernel: pciehp :02:08.0:pcie24: slot(0): Link Down event
fpc0 kernel: pciehp :02:08.0:pcie24:
Link Down event queued on slot(0): currently getting powered on
fpc0 kernel: pciehp :02:08.0:pcie24: slot(0): Link Up event
fpc0 kernel: pciehp :02:08.0:pcie24:
Link Up event queued on slot(0): currently getting powered off
This causes the driver for affected devices to be instantiated, removed,
and re-instantiated.
An even worse problem is a device which resets itself continuously.
This can result in the following endless sequence of messages.
pciehp :02:0a.0:pcie24: Card present on Slot(10)
pciehp :02:0a.0:pcie24: Card not present on Slot(10)
pciehp :02:0a.0:pcie24: Card present on Slot(10)
pciehp :02:0a.0:pcie24: Card not present on Slot(10)
pciehp :02:0a.0:pcie24: Card present on Slot(10)
pciehp :02:0a.0:pcie24: Card not present on Slot(10)
The problem in the both cases is that all events are enqueued as hotplug
work requests and executed in sequence, which can overwhelm the system
and even result in "hung task" tracebacks in pciehp_power_thread().
This exposes an underlying limitation of the hotplug state machine: It
executes all received requests, even though only the most recent request
really needs to be handled. As a result, by the time a request is handled,
it may well be obsolete and have been superseded by many other enable /
disable requests which have been enqueued in the meantime.
To solve the problem, fold hotplug work requests into a single request.
Store the request as well as the work data structure in 'struct slot',
thus eliminating the need to allocate memory for each request.
Handle a sequence of requests by setting a 'disable' flag when needed,
indicating that a link needs to be disabled prior to re-enabling it.
With this change, requests and request sequences are handled as follows.
enable (single request):enable link
disable (single request): disable link
... disable-enable-disable...disable: disable link
... disable-enable-disable...enable:disable link, then enable it
Signed-off-by: Guenter Roeck
---
This is a different approach to solve the problem I tried to address
earlier with with "PCI: pciehp: Add support for delayed power-on" [1].
While the earlier patch implemented an additional state in the hotplug
state machine to solve the problem, the approach taken here is a bit
simpler and more straightfoward. By folding multiple requests into one,
the follow-up patch can use delayed work to implement power-on delays.
An additional advantage is that this patch can be applied separately
to simplify the state machine.
While working on this patch, I also tried to drop multiple "disable"
requests, and only disable a slot if it was already disabled, to reduce
overhead. Unfortunately, this did not always work. In some instances,
I ended up in a situation where a device could not be enabled
because the system thought that it already existed. I don't know
if this is a weakness in this patch or some state change I did not catch.
This may be left for further study.
[1] https://lkml.org/lkml/2015/10/12/686
drivers/pci/hotplug/pciehp.h | 4 +++
drivers/pci/hotplug/pciehp_ctrl.c | 52 ++-
drivers/pci/hotplug/pciehp_hpc.c | 1 +
3 files changed, 29 insertions(+), 28 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
index 62d6fe6c3714..364b6fa32978 100644
--- a/drivers/pci/hotplug/pciehp.h
+++ b/drivers/pci/hotplug/pciehp.h
@@ -78,6 +78,9 @@ struct slot {
struct mutex lock;
struct mutex hotplug_lock;
struct workqueue_struct *wq;
+ struct work_struct hotplug_work;
+ u32 hotplug_req;
+ bool disable; /* true to disable before enable */
};
struct event_info {
@@ -130,6 +133,7 @@ void pciehp_queue_interrupt_event(struct slot *slot, u32
event_type);
int pciehp_configure_device(struct slot *p_slot);
int pciehp_unconfigure_device(struct slot *p_slot);
void pciehp_queue_pushbutton_work(struct work_struct *work);
+void pciehp_power_thread(struct work_struct *work);
struct controller *pcie_init(struct pcie_device *dev);
int pcie_init_notification(struct controller *ctrl);
int pciehp_enable_slot(struct slot *p_slot);
diff --git a/drivers/pci/hotplug/pciehp_ctrl.c
b/drivers/pci/hotplug/pciehp_ctrl.c
index 880978b6d534..ad1321e91546 100644
--- a/drivers/pci/hotplug/pciehp_ctrl.c
+++ b/drivers/pci/hotplug/pciehp_ctrl.c
@@ -156,13 +156,9 @@ static int remove_board(struct slot *p_slot)
return 0;
}
[GIT PULL] Power management and ACPI updates for v4.4-rc1, part 1
Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm+acpi-4.4-rc1-1 to receive the first batch of power management and ACPI updates for v4.4-rc1 with top-most commit 1ab68460b1d0671968b35e04f21efcf1ce051916 Merge branches 'pm-avs', 'pm-clk' and 'powercap' on top of commit 32b88194f71d6ae7768a29f87fbba454728273ee Linux 4.3-rc7 Quite a new features are included this time. First off, the Collaborative Processor Performance Control interface (version 2) defined by ACPI will now be supported on ARM64 along with a cpufreq frontend for CPU performance scaling. Second, ACPI gets a new infrastructure for the early probing of IRQ chips and clock sources (along the lines of the existing similar mechanism for DT). Next, the ACPI core and the generic device properties API will now support a recently introduced hierarchical properties extension of the _DSD (Device Specific Data) ACPI device configuration object. If the ACPI platform firmware uses that extension to organize device properties in a hierarchical way, the kernel will automatically handle it and make those properties available to device drivers via the generic device properties API. It also will be possible to build the ACPICA's AML interpreter debugger into the kernel now and use that to diagnose AML-related problems more efficiently. In the future, this should make it possible to single-step AML execution and do similar things. Interesting stuff, although somewhat experimental at this point. Finally, the PM core gets a new mechanism that can be used by device drivers to distinguish between suspend-to-RAM (based on platform firmware support) and suspend-to-idle (or other variants of system suspend the platform firmware is not involved in) and possibly optimize their device suspend/resume handling accordingly. In addition to that, some existing features are re-organized quite substantially. First, the ACPI-based handling of PCI host bridges on x86 and ia64 is unified and the common code goes into the ACPI core (so as to reduce code duplication and eliminate non-essential differences between the two architectures in that area). Second, the Operating Performance Points (OPP) framework is reorganized to make the code easier to find and follow. Next, the cpufreq core's sysfs interface is reorganized to get rid of the "primary CPU" concept for configurations in which the same performance scaling settings are shared between multiple CPUs. Finally, some interfaces that aren't necessary any more are dropped from the generic power domains framework. On top of the above we have some minor extensions, cleanups and bug fixes in multiple places, as usual. Specifics: - ACPICA update to upstream revision 20150930 (Bob Moore, Lv Zheng). The most significant change is to allow the AML debugger to be built into the kernel. On top of that there is an update related to the NFIT table (the ACPI persistent memory interface) and a few fixes and cleanups. - ACPI CPPC2 (Collaborative Processor Performance Control v2) support along with a cpufreq frontend (Ashwin Chaugule). This can only be enabled on ARM64 at this point. - New ACPI infrastructure for the early probing of IRQ chips and clock sources (Marc Zyngier). - Support for a new hierarchical properties extension of the ACPI _DSD (Device Specific Data) device configuration object allowing the kernel to handle hierarchical properties (provided by the platform firmware this way) automatically and make them available to device drivers via the generic device properties interface (Rafael Wysocki). - Generic device properties API extension to obtain an index of certain string value in an array of strings, along the lines of of_property_match_string(), but working for all of the supported firmware node types, and support for the "dma-names" device property based on it (Mika Westerberg). - ACPI core fix to parse the MADT (Multiple APIC Description Table) entries in the order expected by platform firmware (and mandated by the specification) to avoid confusion on systems with more than 255 logical CPUs (Lukasz Anaczkowski). - Consolidation of the ACPI-based handling of PCI host bridges on x86 and ia64 (Jiang Liu). - ACPI core fixes to ensure that the correct IRQ number is used to represent the SCI (System Control Interrupt) in the cases when it has been re-mapped (Chen Yu). - New ACPI backlight quirk for Lenovo IdeaPad S405 (Hans de Goede). - ACPI EC driver fixes (Lv Zheng). - Assorted ACPI fixes and cleanups (Dan Carpenter, Insu Yun, Jiri Kosina, Rami Rosen, Rasmus Villemoes). - New mechanism in the PM core allowing drivers to check if the platform firmware is going to be involved in the upcoming system suspend or if it has been involved in the suspend the system is resuming from at the moment (Rafael Wysocki). This should allow drivers to optimize their
[PATCH v1 2/2] watchdog: imx2_wdt: add set_pretimeout interface
Enable set_pretimeout interface and trigger the pretimeout interrupt before
watchdog timeout event happen.
Signed-off-by: Robin Gong
---
drivers/watchdog/imx2_wdt.c | 67 -
1 file changed, 66 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 0bb1a1d..d3c6b07 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -24,7 +24,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -52,12 +54,18 @@
#define IMX2_WDT_WRSR 0x04/* Reset Status Register */
#define IMX2_WDT_WRSR_TOUT (1 << 1)/* -> Reset due to Timeout */
+#define IMX2_WDT_WICR 0x06/*Interrupt Control Register*/
+#define IMX2_WDT_WICR_WIE (1 << 15) /* -> Interrupt Enable */
+#define IMX2_WDT_WICR_WTIS (1 << 14) /* -> Interrupt Status */
+#define IMX2_WDT_WICR_WICT (0xFF << 0) /* Watchdog Interrupt Timeout */
+
#define IMX2_WDT_WMCR 0x08/* Misc Register */
#define IMX2_WDT_MAX_TIME 128
#define IMX2_WDT_DEFAULT_TIME 60 /* in seconds */
#define WDOG_SEC_TO_COUNT(s) ((s * 2 - 1) << 8)
+#define WDOG_SEC_TO_PRECOUNT(s)(s * 2) /* set WDOG pre timeout
count*/
struct imx2_wdt_device {
struct clk *clk;
@@ -80,7 +88,8 @@ MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds
(default="
static const struct watchdog_info imx2_wdt_info = {
.identity = "imx2+ watchdog",
- .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE,
+ .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE
+ | WDIOF_PRETIMEOUT,
};
static int imx2_restart_handler(struct notifier_block *this, unsigned long
mode,
@@ -207,12 +216,59 @@ static inline void imx2_wdt_ping_if_active(struct
watchdog_device *wdog)
}
}
+static int imx2_wdt_check_pretimeout_set(struct imx2_wdt_device *wdev)
+{
+ u32 val;
+
+ regmap_read(wdev->regmap, IMX2_WDT_WICR, );
+ return (val & IMX2_WDT_WICR_WIE) ? 1 : 0;
+}
+
+static int imx2_wdt_set_pretimeout(struct watchdog_device *wdog,
+ unsigned int new_timeout)
+{
+ struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+ u32 val;
+
+ regmap_read(wdev->regmap, IMX2_WDT_WICR, );
+ /* set the new pre-timeout value in the WSR */
+ val &= ~IMX2_WDT_WICR_WICT;
+ val |= WDOG_SEC_TO_PRECOUNT(new_timeout);
+
+ if (!imx2_wdt_check_pretimeout_set(wdev))
+ val |= IMX2_WDT_WICR_WIE; /*enable*/
+
+ regmap_write(wdev->regmap, IMX2_WDT_WICR, val);
+
+ wdog->pretimeout = new_timeout;
+
+ return 0;
+}
+
+static irqreturn_t imx2_wdt_isr(int irq, void *dev_id)
+{
+ struct platform_device *pdev = dev_id;
+ struct watchdog_device *wdog = platform_get_drvdata(pdev);
+ struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+ u32 val;
+
+ regmap_read(wdev->regmap, IMX2_WDT_WICR, );
+ if (val & IMX2_WDT_WICR_WTIS) {
+ /*clear interrupt status bit*/
+ regmap_write(wdev->regmap, IMX2_WDT_WICR, val);
+ dev_warn(>dev, "pre-timeout:%d, %d Seconds remained\n",
+wdog->pretimeout, wdog->timeout - wdog->pretimeout);
+ }
+ return IRQ_HANDLED;
+}
+
static const struct watchdog_ops imx2_wdt_ops = {
.owner = THIS_MODULE,
.start = imx2_wdt_start,
.stop = imx2_wdt_stop,
.ping = imx2_wdt_ping,
.set_timeout = imx2_wdt_set_timeout,
+ .set_pretimeout = imx2_wdt_set_pretimeout,
};
static const struct regmap_config imx2_wdt_regmap_config = {
@@ -229,6 +285,7 @@ static int __init imx2_wdt_probe(struct platform_device
*pdev)
struct resource *res;
void __iomem *base;
int ret;
+ int irq;
u32 val;
wdev = devm_kzalloc(>dev, sizeof(*wdev), GFP_KERNEL);
@@ -253,6 +310,14 @@ static int __init imx2_wdt_probe(struct platform_device
*pdev)
return PTR_ERR(wdev->clk);
}
+ irq = platform_get_irq(pdev, 0);
+ ret = devm_request_irq(>dev, irq, imx2_wdt_isr, 0,
+ dev_name(>dev), pdev);
+ if (ret) {
+ dev_err(>dev, "can't get irq %d\n", irq);
+ return ret;
+ }
+
wdog= >wdog;
wdog->info = _wdt_info;
wdog->ops = _wdt_ops;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] lib/string_helpers: change blk_size to u32 for string_get_size() interface
On Mon, 2015-11-02 at 16:58 +0100, Vitaly Kuznetsov wrote:
> James Bottomley writes:
>
> > On Fri, 2015-10-30 at 11:46 +0100, Vitaly Kuznetsov wrote:
> >> James Bottomley writes:
> >>
> >> > On Thu, 2015-10-29 at 17:30 +0100, Vitaly Kuznetsov wrote:
> >> >> string_get_size() can't really handle huge block sizes, especially
> >> >> blk_size > U32_MAX but string_get_size() interface states the opposite.
> >> >> Change blk_size from u64 to u32 to reflect the reality.
> >> >
> >> > What is the actual evidence for this? The calculation is designed to be
> >> > a symmetric 128 bit multiply. When I wrote and tested it, it worked
> >> > fine for huge block sizes.
> >>
> >> We have 'u32 remainder' and then we do:
> >>
> >> exp = divisor[units] / (u32)blk_size;
> >> ...
> >> remainder = do_div(size, divisor[units]);
> >> remainder *= blk_size;
> >>
> >> I'm pretty sure it will overflow for some inputs.
> >
> > It shouldn't; the full code snippet does this:
> >
> > while (blk_size >= divisor[units]) {
> > remainder = do_div(blk_size, divisor[units]);
> > i++;
> > }
> >
> > exp = divisor[units] / (u32)blk_size;
> >
> > So by the time it reaches the statement you complain about, blk_size is
> > already less than or equal to the divisor (which is 1000 or 1024) so
> > truncating to 32 bits is always correct.
> >
>
> I overlooked, sorry!
>
> > I'm sort of getting the impression you don't quite understand the
> > mathematics: i is the logarithm to the base divisor[units]. We reduce
> > both operands to exponents of the logarithm base (adding the two bases
> > together in i), which means they are by definition in a range between
> > zero and the base and then multiply the remaining exponents correcting
> > the result for a base overflow (so the result is always a correct
> > exponent and i is the logarithm to the base). It's actually simply
> > Napier's algorithm.
> >
> > The reason we're getting the up to 2.5% rounding errors you complain
> > about is because at each logarithm until the last one, we throw away the
> > remainder (it's legitimate because it's always 1000x smaller than the
> > exponent), but in the case of a large remainder it provides a small
> > correction to the final operation which we don't account for. If you
> > want to make a true correction, you save the penultimate residue in each
> > case, multiply each by the *other* exponent add them together, divide by
> > the base and increment the final result by the remainder.
>
> My assumption was that we don't really need to support blk_sizes >
> U32_MAX and we can simplify string_get_size() instead of adding
> additional complexity. Apparently, the assumption was wrong.
>
> >
> > However, for 2.5% the physicist in me says the above is way overkill.
> >
>
> It is getting was over 2.5% if blk_size is not a power of 2. While it is
> probably never the case for block subsystem the function is in lib and
> pretends to be general-enough. I'll try to make proper correction and
> let's see if it's worth the effort.
OK, this is the full calculation. It also includes an arithmetic
rounding to the final figure print. I suppose it's not that much more
complexity than the original, and it does make the algorithm easier to
understand.
We could do with running the comments by some other non-mathematician,
now I've explained it in detail to you two, to see if they actually give
an understanding of the algorithm.
James
---
diff --git a/lib/string_helpers.c b/lib/string_helpers.c
index 5939f63..1ec7e77a 100644
--- a/lib/string_helpers.c
+++ b/lib/string_helpers.c
@@ -44,7 +44,7 @@ void string_get_size(u64 size, u64 blk_size, const enum
string_size_units units,
[STRING_UNITS_2] = 1024,
};
int i, j;
- u32 remainder = 0, sf_cap, exp;
+ u32 remainder = 0, sf_cap, r1 = 0, r2 = 0, round;
char tmp[8];
const char *unit;
@@ -53,27 +53,46 @@ void string_get_size(u64 size, u64 blk_size, const enum
string_size_units units,
if (!size)
goto out;
+ /* This is napier's algorithm. Reduce the original block size to
+*
+* co * divisor[units]^i
+*
+* where co = blk_size + r1/divisor[units];
+*
+* and the same for size. We simply add to the exponent i, because
+* the final calculation we're looking for is
+*
+* (co1 * co2) * divisor[units]^i
+*/
+
+
while (blk_size >= divisor[units]) {
- remainder = do_div(blk_size, divisor[units]);
+ r1 = do_div(blk_size, divisor[units]);
i++;
}
- exp = divisor[units] / (u32)blk_size;
- /*
-* size must be strictly greater than exp here to ensure that remainder
-* is greater than divisor[units] coming out of the if below.
-*/
- if (size > exp) {
- remainder =
Re: [PATCH 0/3] PM, vfs: use filesystem freezing instead of kthread freezer
On Tuesday, November 03, 2015 11:10:53 AM Dave Chinner wrote: > On Mon, Nov 02, 2015 at 03:43:07AM +0100, Rafael J. Wysocki wrote: > > I guess it may also helps to address the case when a device is removed from > > a > > suspended system, written to on another system in the meantime and inserted > > back into the (still suspended) original system which then is resumed. > > Today > > this is an almost guaranteed data corruption scenario, but if the > > filesystem in > > question is properly frozen during suspend, the driver should be able to > > detect > > superblock changes during unfreeze. > > Never going to work. There is no guarantee that a write to a > filesystem by a third party device is going to change the superblock > (or any metadata in the rest of the filesystem) in any detectable > way. Hence freezing filesystems will not prevent Bad Things > Happening if you do this while your system is suspended. OK, thanks for the clarification. Cheers, Rafael -- 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/8] arch: uapi: asm: mman.h: Let MADV_FREE have same value for all architectures
From: Minchan Kim Date: Tue, 3 Nov 2015 11:36:51 +0900 > For the convenience for Dave, I found this. > > commit ec98c6b9b47df6df1c1fa6cf3d427414f8c2cf16 > Author: David S. Miller > Date: Sun Apr 20 02:14:23 2008 -0700 > > [SPARC]: Remove SunOS and Solaris binary support. > > As per Documentation/feature-removal-schedule.txt > > Signed-off-by: David S. Miller > > Hello Dave, > Could you confirm it? I don't understand what you want me to confirm. -- 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 v1 1/2] watchdog: add WDIOC_SETPRETIMEOUT and WDIOC_GETPRETIMEOUT
Since the watchdog common framework centrialize the IOCTL interfaces of
device driver now, the SETPRETIMEOUT and GETPRETIMEOUT need to be added
in the common code.
Signed-off-by: Robin Gong
---
drivers/watchdog/watchdog_dev.c | 38 ++
include/linux/watchdog.h| 9 +
2 files changed, 47 insertions(+)
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 6aaefba..02632fe 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -218,6 +218,37 @@ out_timeout:
}
/*
+ * watchdog_set_pretimeout: set the watchdog timer pretimeout
+ * @wddev: the watchdog device to set the timeout for
+ * @timeout: pretimeout to set in seconds
+ */
+
+static int watchdog_set_pretimeout(struct watchdog_device *wddev,
+ unsigned int timeout)
+{
+ int err;
+
+ if ((wddev->ops->set_pretimeout == NULL) ||
+ !(wddev->info->options & WDIOF_PRETIMEOUT))
+ return -EOPNOTSUPP;
+ if (watchdog_pretimeout_invalid(wddev, timeout))
+ return -EINVAL;
+
+ mutex_lock(>lock);
+
+ if (test_bit(WDOG_UNREGISTERED, >status)) {
+ err = -ENODEV;
+ goto out_timeout;
+ }
+
+ err = wddev->ops->set_pretimeout(wddev, timeout);
+
+out_timeout:
+ mutex_unlock(>lock);
+ return err;
+}
+
+/*
* watchdog_get_timeleft: wrapper to get the time left before a reboot
* @wddev: the watchdog device to get the remaining time from
* @timeleft: the time that's left
@@ -393,6 +424,13 @@ static long watchdog_ioctl(struct file *file, unsigned int
cmd,
if (err)
return err;
return put_user(val, p);
+ case WDIOC_SETPRETIMEOUT:
+ if (get_user(val, p))
+ return -EFAULT;
+ err = watchdog_set_pretimeout(wdd, val);
+ return err;
+ case WDIOC_GETPRETIMEOUT:
+ return put_user(wdd->pretimeout, p);
default:
return -ENOTTY;
}
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index d74a0e9..6ddb2d6 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -25,6 +25,7 @@ struct watchdog_device;
* @ping: The routine that sends a keepalive ping to the watchdog device.
* @status:The routine that shows the status of the watchdog device.
* @set_timeout:The routine for setting the watchdog devices timeout value.
+ * @set_pretimeout:The routine for setting the watchdog devices pretimeout.
* @get_timeleft:The routine that get's the time that's left before a reset.
* @ref: The ref operation for dyn. allocated watchdog_device structs
* @unref: The unref operation for dyn. allocated watchdog_device structs
@@ -44,6 +45,7 @@ struct watchdog_ops {
int (*ping)(struct watchdog_device *);
unsigned int (*status)(struct watchdog_device *);
int (*set_timeout)(struct watchdog_device *, unsigned int);
+ int (*set_pretimeout)(struct watchdog_device *, unsigned int);
unsigned int (*get_timeleft)(struct watchdog_device *);
void (*ref)(struct watchdog_device *);
void (*unref)(struct watchdog_device *);
@@ -86,6 +88,7 @@ struct watchdog_device {
const struct watchdog_ops *ops;
unsigned int bootstatus;
unsigned int timeout;
+ unsigned int pretimeout;
unsigned int min_timeout;
unsigned int max_timeout;
void *driver_data;
@@ -123,6 +126,12 @@ static inline bool watchdog_timeout_invalid(struct
watchdog_device *wdd, unsigne
(t < wdd->min_timeout || t > wdd->max_timeout));
}
+/* Use the following function to check if a pretimeout value is invalid */
+static inline bool watchdog_pretimeout_invalid(struct watchdog_device *wdd,
unsigned int t)
+{
+ return ((wdd->timeout != 0) && (t >= wdd->timeout));
+}
+
/* Use the following functions to manipulate watchdog driver specific data */
static inline void watchdog_set_drvdata(struct watchdog_device *wdd, void
*data)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
