[PATCH] media: tvp514x: remove field description
This patch removes the field description of fields that no
longer exists, along side aligns the field description of
fields.
Signed-off-by: Lad, Prabhakar
---
include/media/tvp514x.h |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/include/media/tvp514x.h b/include/media/tvp514x.h
index 74387e8..86ed7e8 100644
--- a/include/media/tvp514x.h
+++ b/include/media/tvp514x.h
@@ -96,12 +96,9 @@ enum tvp514x_output {
/**
* struct tvp514x_platform_data - Platform data values and access functions.
- * @power_set: Power state access function, zero is off, non-zero is on.
- * @ifparm: Interface parameters access function.
- * @priv_data_set: Device private data (pointer) access function.
* @clk_polarity: Clock polarity of the current interface.
- * @ hs_polarity: HSYNC Polarity configuration for current interface.
- * @ vs_polarity: VSYNC Polarity configuration for current interface.
+ * @hs_polarity: HSYNC Polarity configuration for current interface.
+ * @vs_polarity: VSYNC Polarity configuration for current interface.
*/
struct tvp514x_platform_data {
/* Interface control params */
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] svcrpc: fix compile warning about unused variable 'buf'
Commit 7032a3dd923 (svcrpc: demote some printks to a dprintk) changed the
printk to a dprintk() macro. Since the macro is not always available we get
following compile warning:
net/sunrpc/svc.c: In function ‘svc_printk’:
net/sunrpc/svc.c:1050:8: warning: unused variable ‘buf’ [-Wunused-variable]
Fix this by marking the 'buf' with __maybe_unused.
In addition make checkpatch.pl happy by removing space before tab after
'char'.
Signed-off-by: Mika Westerberg
---
net/sunrpc/svc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
index dbf12ac..2387ec8 100644
--- a/net/sunrpc/svc.c
+++ b/net/sunrpc/svc.c
@@ -1047,7 +1047,7 @@ void svc_printk(struct svc_rqst *rqstp, const char *fmt,
...)
{
struct va_format vaf;
va_list args;
- charbuf[RPC_MAX_ADDRBUFLEN];
+ charbuf[RPC_MAX_ADDRBUFLEN] __maybe_unused;
va_start(args, fmt);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] nfsd: fix compile warning about unused variable 'nn'
Commit c9a4962881 (nfsd: make client_lock per net) added
lockdep_assert_held() call to function free_client(). However, if lockdep
is disabled we get following compiler warning:
fs/nfsd/nfs4state.c: In function ‘free_client’:
fs/nfsd/nfs4state.c:1051:19: warning: unused variable ‘nn’ [-Wunused-variable]
Fix this by marking the 'nn' with __maybe_unused.
Signed-off-by: Mika Westerberg
---
fs/nfsd/nfs4state.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
index ac8ed96..2d3011c 100644
--- a/fs/nfsd/nfs4state.c
+++ b/fs/nfsd/nfs4state.c
@@ -1048,7 +1048,7 @@ static struct nfs4_client *alloc_client(struct xdr_netobj
name)
static inline void
free_client(struct nfs4_client *clp)
{
- struct nfsd_net *nn = net_generic(clp->net, nfsd_net_id);
+ struct nfsd_net *nn __maybe_unused = net_generic(clp->net, nfsd_net_id);
lockdep_assert_held(&nn->client_lock);
while (!list_empty(&clp->cl_sessions)) {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] avr32: boards/atngw100/mrmt.c: fix build error
Around Mon 14 Jan 2013 22:43:51 +0100 or thereabout, Cong Ding wrote:
> there is an extra "} in the file, so we delete it.
>
> Signed-off-by: Cong Ding
Acked-by: Hans-Christian Egtvedt
> ---
> arch/avr32/boards/atngw100/mrmt.c |1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/avr32/boards/atngw100/mrmt.c
> b/arch/avr32/boards/atngw100/mrmt.c
> index f914319..7de083d 100644
> --- a/arch/avr32/boards/atngw100/mrmt.c
> +++ b/arch/avr32/boards/atngw100/mrmt.c
> @@ -150,7 +150,6 @@ static struct ac97c_platform_data __initdata ac97c0_data
> = {
> static struct platform_device rmt_ts_device = {
> .name = "ucb1400_ts",
> .id = -1,
> - }
> };
> #endif
>
--
mvh
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/
[PATCH 2/3] irq: Add hw continuous IRQs map to virtual continuous IRQs support
Adding a function irq_create_mapping_many() which can associate
multiple MSIs to a continous irq mapping.
This is needed to enable multiple MSI support for pSeries.
Signed-off-by: Mike Qiu
---
include/linux/irq.h |2 +
include/linux/irqdomain.h |3 ++
kernel/irq/irqdomain.c| 61 +
3 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 60ef45b..e00a7ec 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -592,6 +592,8 @@ int __irq_alloc_descs(int irq, unsigned int from, unsigned
int cnt, int node,
#define irq_alloc_desc_from(from, node)\
irq_alloc_descs(-1, from, 1, node)
+#define irq_alloc_desc_n(nevc, node) \
+ irq_alloc_descs(-1, 0, nevc, node)
void irq_free_descs(unsigned int irq, unsigned int cnt);
int irq_reserve_irqs(unsigned int from, unsigned int cnt);
diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 0d5b17b..831dded 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -168,6 +168,9 @@ extern int irq_create_strict_mappings(struct irq_domain
*domain,
unsigned int irq_base,
irq_hw_number_t hwirq_base, int count);
+extern int irq_create_mapping_many(struct irq_domain *domain,
+ irq_hw_number_t hwirq_base, int count);
+
static inline int irq_create_identity_mapping(struct irq_domain *host,
irq_hw_number_t hwirq)
{
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 96f3a1d..38648e6 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -636,6 +636,67 @@ int irq_create_strict_mappings(struct irq_domain *domain,
unsigned int irq_base,
}
EXPORT_SYMBOL_GPL(irq_create_strict_mappings);
+/**
+ * irq_create_mapping_many - Map a range of hw IRQs to a range of virtual IRQs
+ * @domain: domain owning the interrupt range
+ * @hwirq_base: beginning of continuous hardware IRQ range
+ * @count: Number of interrupts to map
+ *
+ * This routine is used for allocating and mapping a range of hardware
+ * irqs to virtual IRQs where the virtual irq numbers are not at pre-defined
+ * locations.
+ *
+ * Greater than 0 is returned upon success, while any failure to establish a
+ * static mapping is treated as an error.
+ */
+int irq_create_mapping_many(struct irq_domain *domain,
+ irq_hw_number_t hwirq_base, int count)
+{
+ int ret, irq_base;
+ int virq, i;
+
+ pr_debug("irq_create_mapping(0x%p, 0x%lx)\n", domain, hwirq_base);
+
+ /* Look for default domain if nececssary */
+ if (!domain)
+ domain = irq_default_domain;
+ if (!domain) {
+ pr_warn("irq_create_mapping called for NULL domain, hwirq=%lx\n"
+ , hwirq_base);
+ WARN_ON(1);
+ return 0;
+ }
+ pr_debug("-> using domain @%p\n", domain);
+
+ /* For IRQ_DOMAIN_MAP_LEGACY, get the first virtual interrupt number */
+ if (domain->revmap_type == IRQ_DOMAIN_MAP_LEGACY)
+ return irq_domain_legacy_revmap(domain, hwirq_base);
+
+ /* Check if mapping already exists */
+ for (i = 0; i < count; i++) {
+ virq = irq_find_mapping(domain, hwirq_base+i);
+ if (virq) {
+ pr_debug("existing mapping on virq %d,"
+ " now dispose it first\n", virq);
+ irq_dispose_mapping(virq);
+ }
+ }
+
+ /* Allocate the continuous virtual interrupt numbers */
+ irq_base = irq_alloc_desc_n(count, of_node_to_nid(domain->of_node));
+ if (unlikely(irq_base < 0))
+ return irq_base;
+
+ ret = irq_domain_associate_many(domain, irq_base, hwirq_base, count);
+ if (unlikely(ret < 0)) {
+ irq_free_descs(irq_base, count);
+ return ret;
+ }
+
+ return irq_base;
+}
+EXPORT_SYMBOL_GPL(irq_create_mapping_many);
+
unsigned int irq_create_of_mapping(struct device_node *controller,
const u32 *intspec, unsigned int intsize)
{
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] Enable multiple MSI feature in pSeries
Currently, multiple MSI feature hasn't been enabled in pSeries, These patches try to enbale this feature. These patches have been tested by using ipr driver, and the driver patch has been made by Wen Xiong : [PATCH 0/7] Add support for new IBM SAS controllers Test platform: One partition of pSeries with one cpu core(4 SMTs) and RAID bus controller: IBM PCI-E IPR SAS Adapter (ASIC) in POWER7 OS version: SUSE Linux Enterprise Server 11 SP2 (ppc64) with 3.8-rc3 kernel IRQ 21 and 22 are assigned to the ipr device which support 2 mutiple MSI. The test results is shown by 'cat /proc/interrups': CPU0 CPU1 CPU2 CPU3 16: 240458 261601 226310 200425 XICS Level IPI 17: 0 0 0 0 XICS Level RAS_EPOW 18: 10 0 3 2 XICS Level hvc_console 19: 122182 28481 28527 28864 XICS Level ibmvscsi 20:5067388226108118 XICS Level eth0 21: 6 5 5 5 XICS Level host1-0 22:817814816813 XICS Level host1-1 LOC: 398077 316725 231882 203049 Local timer interrupts SPU: 1659919961903 Spurious interrupts CNT: 0 0 0 0 Performance monitoring interrupts MCE: 0 0 0 0 Machine check exceptions Mike Qiu (3): irq: Set multiple MSI descriptor data for multiple IRQs irq: Add hw continuous IRQs map to virtual continuous IRQs support powerpc/pci: Enable pSeries multiple MSI feature arch/powerpc/kernel/msi.c|4 -- arch/powerpc/platforms/pseries/msi.c | 62 - include/linux/irq.h |4 ++ include/linux/irqdomain.h|3 ++ kernel/irq/chip.c| 40 - kernel/irq/irqdomain.c | 61 + 6 files changed, 158 insertions(+), 16 deletions(-) -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] irq: Set multiple MSI descriptor data for multiple IRQs
Multiple MSI only requires the IRQ in msi_desc entry to be set as
the value of irq_base.
This patch implements the above mentioned technique.
Signed-off-by: Mike Qiu
---
include/linux/irq.h |2 ++
kernel/irq/chip.c | 40 ++--
2 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index fdf2c4a..60ef45b 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -528,6 +528,8 @@ extern int irq_set_handler_data(unsigned int irq, void
*data);
extern int irq_set_chip_data(unsigned int irq, void *data);
extern int irq_set_irq_type(unsigned int irq, unsigned int type);
extern int irq_set_msi_desc(unsigned int irq, struct msi_desc *entry);
+extern int irq_set_multiple_msi_desc(unsigned int irq_base, unsigned int nvec,
+ struct msi_desc *entry);
extern struct irq_data *irq_get_irq_data(unsigned int irq);
static inline struct irq_chip *irq_get_chip(unsigned int irq)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 3aca9f2..c4c39d3 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -90,6 +90,35 @@ int irq_set_handler_data(unsigned int irq, void *data)
EXPORT_SYMBOL(irq_set_handler_data);
/**
+ * irq_set_multiple_msi_desc - set Multiple MSI descriptor data
+ * for multiple IRQs
+ * @irq_base: Interrupt number base
+ * @nvec: The number of interrupts
+ * @entry: Pointer to MSI descriptor data
+ *
+ * Set IRQ descriptors for multiple MSIs
+ */
+int irq_set_multiple_msi_desc(unsigned int irq_base, unsigned int nvec,
+ struct msi_desc *entry)
+{
+ unsigned long flags, i;
+ struct irq_desc *desc;
+
+ for (i = 0; i < nvec; i++) {
+ desc = irq_get_desc_lock(irq_base + i, &flags,
+ IRQ_GET_DESC_CHECK_GLOBAL);
+ if (!desc)
+ return -EINVAL;
+ desc->irq_data.msi_desc = entry;
+ if (i == 0 && entry)
+ entry->irq = irq_base;
+ irq_put_desc_unlock(desc, flags);
+ }
+
+ return 0;
+}
+
+/**
* irq_set_msi_desc - set MSI descriptor data for an irq
* @irq: Interrupt number
* @entry: Pointer to MSI descriptor data
@@ -98,16 +127,7 @@ EXPORT_SYMBOL(irq_set_handler_data);
*/
int irq_set_msi_desc(unsigned int irq, struct msi_desc *entry)
{
- unsigned long flags;
- struct irq_desc *desc = irq_get_desc_lock(irq, &flags,
IRQ_GET_DESC_CHECK_GLOBAL);
-
- if (!desc)
- return -EINVAL;
- desc->irq_data.msi_desc = entry;
- if (entry)
- entry->irq = irq;
- irq_put_desc_unlock(desc, flags);
- return 0;
+ return irq_set_multiple_msi_desc(irq, 1, entry);
}
/**
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] powerpc/pci: Enable pSeries multiple MSI feature
PCI devices support MSI, MSIX as well as multiple MSI.
But pSeries does not support multiple MSI yet.
This patch enable multiple MSI feature in pSeries.
Signed-off-by: Mike Qiu
---
arch/powerpc/kernel/msi.c|4 --
arch/powerpc/platforms/pseries/msi.c | 62 -
2 files changed, 60 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/msi.c b/arch/powerpc/kernel/msi.c
index 8bbc12d..46b1470 100644
--- a/arch/powerpc/kernel/msi.c
+++ b/arch/powerpc/kernel/msi.c
@@ -20,10 +20,6 @@ int arch_msi_check_device(struct pci_dev* dev, int nvec, int
type)
return -ENOSYS;
}
- /* PowerPC doesn't support multiple MSI yet */
- if (type == PCI_CAP_ID_MSI && nvec > 1)
- return 1;
-
if (ppc_md.msi_check_device) {
pr_debug("msi: Using platform check routine.\n");
return ppc_md.msi_check_device(dev, nvec, type);
diff --git a/arch/powerpc/platforms/pseries/msi.c
b/arch/powerpc/platforms/pseries/msi.c
index e5b0847..6633b18 100644
--- a/arch/powerpc/platforms/pseries/msi.c
+++ b/arch/powerpc/platforms/pseries/msi.c
@@ -132,13 +132,17 @@ static int rtas_query_irq_number(struct pci_dn *pdn, int
offset)
static void rtas_teardown_msi_irqs(struct pci_dev *pdev)
{
struct msi_desc *entry;
+ int nvec, i;
list_for_each_entry(entry, &pdev->msi_list, list) {
if (entry->irq == NO_IRQ)
continue;
irq_set_msi_desc(entry->irq, NULL);
- irq_dispose_mapping(entry->irq);
+ nvec = entry->msi_attrib.is_msix ? 1 : 1 <<
+ entry->msi_attrib.multiple;
+ for (i = 0; i < nvec; i++)
+ irq_dispose_mapping(entry->irq + i);
}
rtas_disable_msi(pdev);
@@ -392,6 +396,55 @@ static int check_msix_entries(struct pci_dev *pdev)
return 0;
}
+static int setup_multiple_msi_irqs(struct pci_dev *pdev, int nvec)
+{
+ struct pci_dn *pdn;
+ int hwirq, virq_base, i, hwirq_base = 0;
+ struct msi_desc *entry;
+ struct msi_msg msg;
+
+ pdn = get_pdn(pdev);
+ entry = list_entry(pdev->msi_list.next, typeof(*entry), list);
+
+ /*
+* Get the hardware IRQ base and ensure the retrieved
+* hardware IRQs are continuous
+*/
+ for (i = 0; i < nvec; i++) {
+ hwirq = rtas_query_irq_number(pdn, i);
+ if (i == 0)
+ hwirq_base = hwirq;
+
+ if (hwirq < 0 || hwirq != (hwirq_base + i)) {
+ pr_debug("rtas_msi: Failure to get %d IRQs on"
+ "PCI device %04x:%02x:%02x.%01x\n", nvec,
+ pci_domain_nr(pdev->bus), pdev->bus->number,
+ PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
+ return hwirq;
+ }
+ }
+
+ virq_base = irq_create_mapping_many(NULL, hwirq_base, nvec);
+ if (virq_base <= 0) {
+ pr_debug("rtas_msi: Failure to map IRQs (%d, %d) "
+ "for PCI device %04x:%02x:%02x.%01x\n",
+ hwirq_base, nvec, pci_domain_nr(pdev->bus),
+ pdev->bus->number, PCI_SLOT(pdev->devfn),
+ PCI_FUNC(pdev->devfn));
+ return -ENOSPC;
+ }
+
+ entry->msi_attrib.multiple = ilog2(nvec & 0x3f);
+ irq_set_multiple_msi_desc(virq_base, nvec, entry);
+ for (i = 0; i < nvec; i++) {
+ /* Read config space back so we can restore after reset */
+ read_msi_msg(virq_base + i, &msg);
+ entry->msg = msg;
+ }
+
+ return 0;
+}
+
static int rtas_setup_msi_irqs(struct pci_dev *pdev, int nvec_in, int type)
{
struct pci_dn *pdn;
@@ -444,11 +497,16 @@ again:
return rc;
}
+ if (type == PCI_CAP_ID_MSI && nvec > 1) {
+ rc = setup_multiple_msi_irqs(pdev, nvec);
+ return rc;
+ }
+
i = 0;
list_for_each_entry(entry, &pdev->msi_list, list) {
hwirq = rtas_query_irq_number(pdn, i++);
if (hwirq < 0) {
- pr_debug("rtas_msi: error (%d) getting hwirq\n", rc);
+ pr_debug("rtas_msi: error (%d) getting hwirq\n", nvec);
return hwirq;
}
--
1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/13] perf header: Add HEADER_GROUP_DESC feature
From: Namhyung Kim
Save group relationship information so that it can be restored when perf
report is running.
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1355726345-29553-5-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-record.c | 3 +
tools/perf/util/header.c| 164
tools/perf/util/header.h| 2 +
3 files changed, 169 insertions(+)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index 2ac690cad411..774c90713a53 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -486,6 +486,9 @@ static int __cmd_record(struct perf_record *rec, int argc,
const char **argv)
goto out_delete_session;
}
+ if (!evsel_list->nr_groups)
+ perf_header__clear_feat(&session->header, HEADER_GROUP_DESC);
+
/*
* perf_session__delete(session) will be called at perf_record__exit()
*/
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index fccd69d9..b614c9638fd5 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -1082,6 +1082,52 @@ static int write_pmu_mappings(int fd, struct perf_header
*h __maybe_unused,
}
/*
+ * File format:
+ *
+ * struct group_descs {
+ * u32 nr_groups;
+ * struct group_desc {
+ * charname[];
+ * u32 leader_idx;
+ * u32 nr_members;
+ * }[nr_groups];
+ * };
+ */
+static int write_group_desc(int fd, struct perf_header *h __maybe_unused,
+ struct perf_evlist *evlist)
+{
+ u32 nr_groups = evlist->nr_groups;
+ struct perf_evsel *evsel;
+ int ret;
+
+ ret = do_write(fd, &nr_groups, sizeof(nr_groups));
+ if (ret < 0)
+ return ret;
+
+ list_for_each_entry(evsel, &evlist->entries, node) {
+ if (perf_evsel__is_group_leader(evsel) &&
+ evsel->nr_members > 1) {
+ const char *name = evsel->group_name ?: "{anon_group}";
+ u32 leader_idx = evsel->idx;
+ u32 nr_members = evsel->nr_members;
+
+ ret = do_write_string(fd, name);
+ if (ret < 0)
+ return ret;
+
+ ret = do_write(fd, &leader_idx, sizeof(leader_idx));
+ if (ret < 0)
+ return ret;
+
+ ret = do_write(fd, &nr_members, sizeof(nr_members));
+ if (ret < 0)
+ return ret;
+ }
+ }
+ return 0;
+}
+
+/*
* default get_cpuid(): nothing gets recorded
* actual implementation must be in arch/$(ARCH)/util/header.c
*/
@@ -1444,6 +1490,31 @@ error:
fprintf(fp, "# pmu mappings: unable to read\n");
}
+static void print_group_desc(struct perf_header *ph, int fd __maybe_unused,
+FILE *fp)
+{
+ struct perf_session *session;
+ struct perf_evsel *evsel;
+ u32 nr = 0;
+
+ session = container_of(ph, struct perf_session, header);
+
+ list_for_each_entry(evsel, &session->evlist->entries, node) {
+ if (perf_evsel__is_group_leader(evsel) &&
+ evsel->nr_members > 1) {
+ fprintf(fp, "# group: %s{%s", evsel->group_name ?: "",
+ perf_evsel__name(evsel));
+
+ nr = evsel->nr_members - 1;
+ } else if (nr) {
+ fprintf(fp, ",%s", perf_evsel__name(evsel));
+
+ if (--nr == 0)
+ fprintf(fp, "}\n");
+ }
+ }
+}
+
static int __event_process_build_id(struct build_id_event *bev,
char *filename,
struct perf_session *session)
@@ -1958,6 +2029,98 @@ error:
return -1;
}
+static int process_group_desc(struct perf_file_section *section __maybe_unused,
+ struct perf_header *ph, int fd,
+ void *data __maybe_unused)
+{
+ size_t ret = -1;
+ u32 i, nr, nr_groups;
+ struct perf_session *session;
+ struct perf_evsel *evsel, *leader = NULL;
+ struct group_desc {
+ char *name;
+ u32 leader_idx;
+ u32 nr_members;
+ } *desc;
+
+ if (readn(fd, &nr_groups, sizeof(nr_groups)) != sizeof(nr_groups))
+ return -1;
+
+ if (ph->needs_swap)
+ nr_groups = bswap_32(nr_groups);
+
+ ph->env.nr_groups = nr_groups;
+ if (!nr_groups) {
+ pr_debug("group desc not available\n");
+ return 0;
+ }
+
[PATCH 01/13] perf tools: Keep group information
From: Namhyung Kim
Add a few of group-related field in struct perf_{evlist,evsel} so that
the group information in a evlist can be known easily. It only counts
groups which have more than 1 members since leader-only groups are
treated as non-group events.
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1355726345-29553-2-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evlist.c | 7 ++-
tools/perf/util/evlist.h | 1 +
tools/perf/util/evsel.h| 6 ++
tools/perf/util/parse-events.c | 1 +
tools/perf/util/parse-events.h | 1 +
tools/perf/util/parse-events.y | 10 ++
6 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index dc8aee97a488..eddd5ebcd690 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -117,6 +117,9 @@ void __perf_evlist__set_leader(struct list_head *list)
struct perf_evsel *evsel, *leader;
leader = list_entry(list->next, struct perf_evsel, node);
+ evsel = list_entry(list->prev, struct perf_evsel, node);
+
+ leader->nr_members = evsel->idx - leader->idx + 1;
list_for_each_entry(evsel, list, node) {
if (evsel != leader)
@@ -126,8 +129,10 @@ void __perf_evlist__set_leader(struct list_head *list)
void perf_evlist__set_leader(struct perf_evlist *evlist)
{
- if (evlist->nr_entries)
+ if (evlist->nr_entries) {
+ evlist->nr_groups = evlist->nr_entries > 1 ? 1 : 0;
__perf_evlist__set_leader(&evlist->entries);
+ }
}
int perf_evlist__add_default(struct perf_evlist *evlist)
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 457e2350d21d..73579a25a93e 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -21,6 +21,7 @@ struct perf_evlist {
struct list_head entries;
struct hlist_head heads[PERF_EVLIST__HLIST_SIZE];
int nr_entries;
+ int nr_groups;
int nr_fds;
int nr_mmaps;
int mmap_len;
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index c68d1b82e843..f5d22f12ccd8 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -73,6 +73,7 @@ struct perf_evsel {
boolneeds_swap;
/* parse modifier helper */
int exclude_GH;
+ int nr_members;
struct perf_evsel *leader;
char*group_name;
};
@@ -257,4 +258,9 @@ bool perf_evsel__fallback(struct perf_evsel *evsel, int err,
int perf_evsel__open_strerror(struct perf_evsel *evsel,
struct perf_target *target,
int err, char *msg, size_t size);
+
+static inline int perf_evsel__group_idx(struct perf_evsel *evsel)
+{
+ return evsel->idx - evsel->leader->idx;
+}
#endif /* __PERF_EVSEL_H */
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 626c120f00da..64d663192495 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -885,6 +885,7 @@ int parse_events(struct perf_evlist *evlist, const char
*str,
if (!ret) {
int entries = data.idx - evlist->nr_entries;
perf_evlist__splice_list_tail(evlist, &data.list, entries);
+ evlist->nr_groups += data.nr_groups;
return 0;
}
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index b7af80b8bdda..330b8896876b 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -65,6 +65,7 @@ struct parse_events__term {
struct parse_events_data__events {
struct list_head list;
int idx;
+ int nr_groups;
};
struct parse_events_data__terms {
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index 0f9914ae6bac..7f2d63afcf38 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -23,6 +23,14 @@ do { \
YYABORT; \
} while (0)
+static inc_group_count(struct list_head *list,
+ struct parse_events_data__events *data)
+{
+ /* Count groups only have more than 1 members */
+ if (!list_is_last(list->next, list))
+ data->nr_groups++;
+}
+
%}
%token PE_START_EVENTS PE_START_TERMS
@@ -123,6 +131,7 @@ PE_NAME '{' events '}'
{
struct list_head *list = $3;
+ inc_group_count(list, _data);
parse_events__set_leader($1, list);
$$ = list;
}
@@ -131,6 +140,7 @@ PE_NAME '{' events '}'
{
struct list_head *list = $2;
+ inc_group_count(list, _data);
parse_events__set_leader(NULL, list);
$$ = li
[PATCH] tools, vm: add .gitignore to ignore built binaries
There is no .gitignore in tools/vm, so 'git status' always show built binaries. To ignore this, add .gitignore. Signed-off-by: Joonsoo Kim diff --git a/tools/vm/.gitignore b/tools/vm/.gitignore new file mode 100644 index 000..44f095f --- /dev/null +++ b/tools/vm/.gitignore @@ -0,0 +1,2 @@ +slabinfo +page-types -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/13] perf tests: Add group test conditions
From: Namhyung Kim
As some new fields for handling groups added, check them to be sure to
have valid values in test__group* cases.
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1355726345-29553-3-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/parse-events.c | 28
1 file changed, 28 insertions(+)
diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
index e7eb708da32c..257d60f5cfc7 100644
--- a/tools/perf/tests/parse-events.c
+++ b/tools/perf/tests/parse-events.c
@@ -23,6 +23,7 @@ static int test__checkevent_tracepoint(struct perf_evlist
*evlist)
struct perf_evsel *evsel = perf_evlist__first(evlist);
TEST_ASSERT_VAL("wrong number of entries", 1 == evlist->nr_entries);
+ TEST_ASSERT_VAL("wrong number of groups", 0 == evlist->nr_groups);
TEST_ASSERT_VAL("wrong type", PERF_TYPE_TRACEPOINT == evsel->attr.type);
TEST_ASSERT_VAL("wrong sample_type",
PERF_TP_SAMPLE_TYPE == evsel->attr.sample_type);
@@ -35,6 +36,7 @@ static int test__checkevent_tracepoint_multi(struct
perf_evlist *evlist)
struct perf_evsel *evsel;
TEST_ASSERT_VAL("wrong number of entries", evlist->nr_entries > 1);
+ TEST_ASSERT_VAL("wrong number of groups", 0 == evlist->nr_groups);
list_for_each_entry(evsel, &evlist->entries, node) {
TEST_ASSERT_VAL("wrong type",
@@ -510,6 +512,7 @@ static int test__group1(struct perf_evlist *evlist)
struct perf_evsel *evsel, *leader;
TEST_ASSERT_VAL("wrong number of entries", 2 == evlist->nr_entries);
+ TEST_ASSERT_VAL("wrong number of groups", 1 == evlist->nr_groups);
/* instructions:k */
evsel = leader = perf_evlist__first(evlist);
@@ -523,6 +526,8 @@ static int test__group1(struct perf_evlist *evlist)
TEST_ASSERT_VAL("wrong exclude host", !evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
TEST_ASSERT_VAL("wrong leader", perf_evsel__is_group_leader(evsel));
+ TEST_ASSERT_VAL("wrong nr_members", evsel->nr_members == 2);
+ TEST_ASSERT_VAL("wrong group_idx", perf_evsel__group_idx(evsel) == 0);
/* cycles:upp */
evsel = perf_evsel__next(evsel);
@@ -537,6 +542,7 @@ static int test__group1(struct perf_evlist *evlist)
TEST_ASSERT_VAL("wrong exclude host", !evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", evsel->attr.precise_ip == 2);
TEST_ASSERT_VAL("wrong leader", evsel->leader == leader);
+ TEST_ASSERT_VAL("wrong group_idx", perf_evsel__group_idx(evsel) == 1);
return 0;
}
@@ -546,6 +552,7 @@ static int test__group2(struct perf_evlist *evlist)
struct perf_evsel *evsel, *leader;
TEST_ASSERT_VAL("wrong number of entries", 3 == evlist->nr_entries);
+ TEST_ASSERT_VAL("wrong number of groups", 1 == evlist->nr_groups);
/* faults + :ku modifier */
evsel = leader = perf_evlist__first(evlist);
@@ -559,6 +566,8 @@ static int test__group2(struct perf_evlist *evlist)
TEST_ASSERT_VAL("wrong exclude host", !evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
TEST_ASSERT_VAL("wrong leader", perf_evsel__is_group_leader(evsel));
+ TEST_ASSERT_VAL("wrong nr_members", evsel->nr_members == 2);
+ TEST_ASSERT_VAL("wrong group_idx", perf_evsel__group_idx(evsel) == 0);
/* cache-references + :u modifier */
evsel = perf_evsel__next(evsel);
@@ -572,6 +581,7 @@ static int test__group2(struct perf_evlist *evlist)
TEST_ASSERT_VAL("wrong exclude host", !evsel->attr.exclude_host);
TEST_ASSERT_VAL("wrong precise_ip", !evsel->attr.precise_ip);
TEST_ASSERT_VAL("wrong leader", evsel->leader == leader);
+ TEST_ASSERT_VAL("wrong group_idx", perf_evsel__group_idx(evsel) == 1);
/* cycles:k */
evsel = perf_evsel__next(evsel);
@@ -594,6 +604,7 @@ static int test__group3(struct perf_evlist *evlist
__maybe_unused)
struct perf_evsel *evsel, *leader;
TEST_ASSERT_VAL("wrong number of entries", 5 == evlist->nr_entries);
+ TEST_ASSERT_VAL("wrong number of groups", 2 == evlist->nr_groups);
/* group1 syscalls:sys_enter_open:H */
evsel = leader = perf_evlist__first(evlist);
@@ -610,6 +621,8 @@ static int test__group3(struct perf_evlist *evlist
__maybe_unused)
TEST_ASSERT_VAL("wrong leader", perf_evsel__is_group_leader(evsel));
TEST_ASSERT_VAL("wrong group name",
!strcmp(leader->group_name, "group1"));
+ TEST_ASSERT_VAL("wrong nr_members", evsel->nr_members == 2);
+ TEST_ASSERT_VAL("wrong group_idx", perf_evsel__group_idx(evsel) == 0);
/* group1 cycles:kppp */
ev
[PATCH 05/13] perf hists: Resort hist entries using group members for output
From: Namhyung Kim
When event group is enabled, sorting hist entries on periods for output
should consider groups members' period also. To do that, build period
table using link/pair information and compare the table.
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1355726345-29553-7-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/evsel.h | 2 ++
tools/perf/util/hist.c | 59 -
2 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
index f5d22f12ccd8..24225d728ba4 100644
--- a/tools/perf/util/evsel.h
+++ b/tools/perf/util/evsel.h
@@ -78,6 +78,8 @@ struct perf_evsel {
char*group_name;
};
+#define hists_to_evsel(h) container_of(h, struct perf_evsel, hists)
+
struct cpu_map;
struct thread_map;
struct perf_evlist;
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index 8170a3d11ffa..f855941bebea 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -4,6 +4,7 @@
#include "hist.h"
#include "session.h"
#include "sort.h"
+#include "evsel.h"
#include
static bool hists__filter_entry_by_dso(struct hists *hists,
@@ -540,6 +541,62 @@ void hists__collapse_resort_threaded(struct hists *hists)
* reverse the map, sort on period.
*/
+static int period_cmp(u64 period_a, u64 period_b)
+{
+ if (period_a > period_b)
+ return 1;
+ if (period_a < period_b)
+ return -1;
+ return 0;
+}
+
+static int hist_entry__sort_on_period(struct hist_entry *a,
+ struct hist_entry *b)
+{
+ int ret;
+ int i, nr_members;
+ struct perf_evsel *evsel;
+ struct hist_entry *pair;
+ u64 *periods_a, *periods_b;
+
+ ret = period_cmp(a->stat.period, b->stat.period);
+ if (ret || !symbol_conf.event_group)
+ return ret;
+
+ evsel = hists_to_evsel(a->hists);
+ nr_members = evsel->nr_members;
+ if (nr_members <= 1)
+ return ret;
+
+ periods_a = zalloc(sizeof(periods_a) * nr_members);
+ periods_b = zalloc(sizeof(periods_b) * nr_members);
+
+ if (!periods_a || !periods_b)
+ goto out;
+
+ list_for_each_entry(pair, &a->pairs.head, pairs.node) {
+ evsel = hists_to_evsel(pair->hists);
+ periods_a[perf_evsel__group_idx(evsel)] = pair->stat.period;
+ }
+
+ list_for_each_entry(pair, &b->pairs.head, pairs.node) {
+ evsel = hists_to_evsel(pair->hists);
+ periods_b[perf_evsel__group_idx(evsel)] = pair->stat.period;
+ }
+
+ for (i = 1; i < nr_members; i++) {
+ ret = period_cmp(periods_a[i], periods_b[i]);
+ if (ret)
+ break;
+ }
+
+out:
+ free(periods_a);
+ free(periods_b);
+
+ return ret;
+}
+
static void __hists__insert_output_entry(struct rb_root *entries,
struct hist_entry *he,
u64 min_callchain_hits)
@@ -556,7 +613,7 @@ static void __hists__insert_output_entry(struct rb_root
*entries,
parent = *p;
iter = rb_entry(parent, struct hist_entry, rb_node);
- if (he->stat.period > iter->stat.period)
+ if (hist_entry__sort_on_period(he, iter) > 0)
p = &(*p)->rb_left;
else
p = &(*p)->rb_right;
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/13] perf ui/hist: Add support for event group view
From: Namhyung Kim
Show group members' overhead also when showing the leader's if event
group is enabled. Use macro for defining hpp functions which looks
almost identical.
Thanks to Arnaldo for suggesting a better way to print group members
without allocating temporary array.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/ui/hist.c | 311 +++--
tools/perf/ui/stdio/hist.c | 2 +
2 files changed, 164 insertions(+), 149 deletions(-)
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index 1889c12ca81f..ec14335a9713 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -3,151 +3,190 @@
#include "../util/hist.h"
#include "../util/util.h"
#include "../util/sort.h"
-
+#include "../util/evsel.h"
/* hist period print (hpp) functions */
-static int hpp__header_overhead(struct perf_hpp *hpp)
-{
- return scnprintf(hpp->buf, hpp->size, "Overhead");
-}
-static int hpp__width_overhead(struct perf_hpp *hpp __maybe_unused)
-{
- return 8;
-}
+typedef int (*hpp_snprint_fn)(char *buf, size_t size, const char *fmt, ...);
-static int hpp__color_overhead(struct perf_hpp *hpp, struct hist_entry *he)
+static int __hpp__percent_fmt(struct perf_hpp *hpp, struct hist_entry *he,
+ u64 (*get_field)(struct hist_entry *),
+ const char *fmt, hpp_snprint_fn print_fn)
{
+ int ret;
+ double percent = 0.0;
struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period / hists->stats.total_period;
- return percent_color_snprintf(hpp->buf, hpp->size, " %6.2f%%", percent);
-}
+ if (hists->stats.total_period)
+ percent = 100.0 * get_field(he) / hists->stats.total_period;
-static int hpp__entry_overhead(struct perf_hpp *hpp, struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period / hists->stats.total_period;
- const char *fmt = symbol_conf.field_sep ? "%.2f" : " %6.2f%%";
+ ret = print_fn(hpp->buf, hpp->size, fmt, percent);
- return scnprintf(hpp->buf, hpp->size, fmt, percent);
-}
+ if (symbol_conf.event_group) {
+ int prev_idx, idx_delta, i;
+ struct perf_evsel *evsel = hists_to_evsel(hists);
+ struct hist_entry *pair;
+ int nr_members = evsel->nr_members;
-static int hpp__header_overhead_sys(struct perf_hpp *hpp)
-{
- const char *fmt = symbol_conf.field_sep ? "%s" : "%7s";
+ if (nr_members <= 1)
+ return ret;
- return scnprintf(hpp->buf, hpp->size, fmt, "sys");
-}
+ prev_idx = perf_evsel__group_idx(evsel);
-static int hpp__width_overhead_sys(struct perf_hpp *hpp __maybe_unused)
-{
- return 7;
-}
+ list_for_each_entry(pair, &he->pairs.head, pairs.node) {
+ u64 period = get_field(pair);
+ u64 total = pair->hists->stats.total_period;
-static int hpp__color_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period_sys /
hists->stats.total_period;
+ if (!total)
+ continue;
- return percent_color_snprintf(hpp->buf, hpp->size, "%6.2f%%", percent);
-}
+ evsel = hists_to_evsel(pair->hists);
+ idx_delta = perf_evsel__group_idx(evsel) - prev_idx - 1;
-static int hpp__entry_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
-{
- struct hists *hists = he->hists;
- double percent = 100.0 * he->stat.period_sys /
hists->stats.total_period;
- const char *fmt = symbol_conf.field_sep ? "%.2f" : "%6.2f%%";
+ for (i = 0; i < idx_delta; i++) {
+ ret += print_fn(hpp->buf + ret, hpp->size - ret,
+ fmt, 0.0);
+ }
- return scnprintf(hpp->buf, hpp->size, fmt, percent);
-}
+ ret += print_fn(hpp->buf + ret, hpp->size - ret,
+ fmt, 100.0 * period / total);
-static int hpp__header_overhead_us(struct perf_hpp *hpp)
-{
- const char *fmt = symbol_conf.field_sep ? "%s" : "%7s";
+ prev_idx += 1 + idx_delta;
+ }
- return scnprintf(hpp->buf, hpp->size, fmt, "user");
-}
+ idx_delta = nr_members - prev_idx - 1;
-static int hpp__width_overhead_us(struct perf_hpp *hpp __maybe_unused)
-{
- return 7;
+ for (i = 0; i < idx_delta; i++) {
+ ret += print_fn(hpp->buf + ret, hpp->size - ret,
+ fmt, 0.0);
+ }
+ }
+ return ret;
}
-static int hpp__color_overhead_us(struct perf_hpp *hpp, struct hist
[GIT PULL] extcon for 3.8-rc4
Hi Greg, This is the extcon pull request for Linux 3.8-rc4. Please pull extcon with following updates: Update to max77693/max8997 extcon driver: - Using MHL_TA cable for charging. - Support JIG cable. - Support Dock-Audio device for playing music and button of device. - Support Dock-Smart device for desktop mode with mouse/keyboard. - Set default UART/USB path on probe(). - Check the state/type of cable after completing initialization. - Code clean to remove duplicate code and bug fix related to sequence of interrupt. - Fix irq_flag of max8997/max77693 driver. Update to arizona extcon driver: - Headphone measurements. - Alternative detection mechanism for non-default system designs. - Microphone clamp integration. - Support for additional detection pin. - MICBIAS rise time configuration. Thanks in advance for pulling, Best regards, Chanwoo Choi The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20: Linux 3.8-rc3 (2013-01-09 18:59:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-3.8-rc4 for you to fetch changes up to 689557d3c7045320958d5bc4141088f7b4dff7ba: mfd: wm5102: Add microphone clamp control registers (2013-01-15 15:42:18 +0900) Chanwoo Choi (9): extcon: max77693: Remove duplicate code by making function extcon: max77693: Add support MHL_TA cable for charging battery extcon: max77693: Add support jig cable extcon: max77693: Add support dock device and buttons extcon: max77693: Check the state/type of cable after boot completed extcon: max8997/max77693: Support IRQF_NO_SUSPEND flag for interrupt extcon: max77693: Set default uart/usb path by using platform data extcon: max77693: Fix bug when detecting MHL/Dock-Audio with USB/TA cable extcon: max77693: Add support Dock-Smart device for desktop mode Mark Brown (11): extcon: arizona: Convert to devm_input_allocate_device() extcon: arizona: Remove duplicate mic ramp configuration extcon: arizona: Only set GPIO if it has been requested extcon: arizona: Allow configuration of MICBIAS rise time extcon: arizona: Use microphone clamp function if available extcon: arizona: Support use of GPIO5 as an input to jack detection extcon: arizona: Enable basic headphone identification extcon: Simple code motion supporting future work. extcon: arizona: Support HPDET based accessory identification extcon: arizona: Support direct microphone measurement via HPDET mfd: wm5102: Add microphone clamp control registers drivers/extcon/extcon-arizona.c | 634 +-- drivers/extcon/extcon-max77693.c | 920 +- drivers/extcon/extcon-max8997.c | 6 +- drivers/mfd/wm5102-tables.c | 10 + include/linux/mfd/arizona/core.h | 4 +- include/linux/mfd/arizona/pdata.h | 12 + include/linux/mfd/arizona/registers.h | 48 ++ include/linux/mfd/max77693-private.h | 86 include/linux/mfd/max77693.h | 9 + 9 files changed, 1439 insertions(+), 290 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/13] perf gtk/browser: Trim column header string when event group enabled
From: Namhyung Kim
When event group feature is enabled, each column header is expanded to
match with the whole group column width. But this is not needed for
GTK+ browser since it usually use variable-width fonts. So trim it.
As we have ltrim() implementation in builtin-script.c move it to the
more generic location of util/string.c.
Cc: Jiri Olsa
Cc: Stephane Eranian
Cc: Pekka Enberg
Cc: Feng Tang
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-script.c | 12
tools/perf/ui/gtk/hists.c | 2 +-
tools/perf/util/string.c| 18 ++
tools/perf/util/util.h | 1 +
4 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 3314ef2ec83e..fee4c9a8aee5 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -909,18 +909,6 @@ static const char *ends_with(const char *str, const char
*suffix)
return NULL;
}
-static char *ltrim(char *str)
-{
- int len = strlen(str);
-
- while (len && isspace(*str)) {
- len--;
- str++;
- }
-
- return str;
-}
-
static int read_script_info(struct script_desc *desc, const char *filename)
{
char line[BUFSIZ], *p;
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index a4d951ea919a..8ab2c492a6fd 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -166,7 +166,7 @@ static void perf_gtk__show_hists(GtkWidget *window, struct
hists *hists)
perf_hpp__for_each_format(fmt) {
fmt->header(&hpp);
gtk_tree_view_insert_column_with_attributes(GTK_TREE_VIEW(view),
- -1, s,
+ -1, ltrim(s),
renderer, "markup",
col_idx++, NULL);
}
diff --git a/tools/perf/util/string.c b/tools/perf/util/string.c
index 346707df04b9..29c7b2cb2521 100644
--- a/tools/perf/util/string.c
+++ b/tools/perf/util/string.c
@@ -332,6 +332,24 @@ char *strxfrchar(char *s, char from, char to)
}
/**
+ * ltrim - Removes leading whitespace from @s.
+ * @s: The string to be stripped.
+ *
+ * Return pointer to the first non-whitespace character in @s.
+ */
+char *ltrim(char *s)
+{
+ int len = strlen(s);
+
+ while (len && isspace(*s)) {
+ len--;
+ s++;
+ }
+
+ return s;
+}
+
+/**
* rtrim - Removes trailing whitespace from @s.
* @s: The string to be stripped.
*
diff --git a/tools/perf/util/util.h b/tools/perf/util/util.h
index ec5de5e3330c..09b4c26b71aa 100644
--- a/tools/perf/util/util.h
+++ b/tools/perf/util/util.h
@@ -265,6 +265,7 @@ bool is_power_of_2(unsigned long n)
size_t hex_width(u64 v);
int hex2u64(const char *ptr, u64 *val);
+char *ltrim(char *s);
char *rtrim(char *s);
void dump_stack(void);
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/13] perf report: Make another loop for linking group hists
From: Namhyung Kim
Now the event grouping viewing requires linking all member hists in a
group to the leader's. Thus hists__output_resort should be called after
linking all events in evlist.
Introduce symbol_conf.event_group flag to determine whether the feature
is enabled or not.
Signed-off-by: Namhyung Kim
Acked-by: Jiri Olsa
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Paul Mackerras
Cc: Peter Zijlstra
Cc: Stephane Eranian
Link:
http://lkml.kernel.org/r/1355726345-29553-6-git-send-email-namhy...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/builtin-report.c | 13 -
tools/perf/util/symbol.h| 3 ++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 47a864478543..fd2503a5f876 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -416,8 +416,16 @@ static int __cmd_report(struct perf_report *rep)
hists->symbol_filter_str = rep->symbol_filter_str;
hists__collapse_resort(hists);
- hists__output_resort(hists);
nr_samples += hists->stats.nr_events[PERF_RECORD_SAMPLE];
+
+ /* Non-group events are considered as leader */
+ if (symbol_conf.event_group &&
+ !perf_evsel__is_group_leader(pos)) {
+ struct hists *leader_hists = &pos->leader->hists;
+
+ hists__match(leader_hists, hists);
+ hists__link(leader_hists, hists);
+ }
}
if (nr_samples == 0) {
@@ -425,6 +433,9 @@ static int __cmd_report(struct perf_report *rep)
goto out_delete;
}
+ list_for_each_entry(pos, &session->evlist->entries, node)
+ hists__output_resort(&pos->hists);
+
if (use_browser > 0) {
if (use_browser == 1) {
perf_evlist__tui_browse_hists(session->evlist, help,
diff --git a/tools/perf/util/symbol.h b/tools/perf/util/symbol.h
index d97377ac2f16..b62ca37c4b77 100644
--- a/tools/perf/util/symbol.h
+++ b/tools/perf/util/symbol.h
@@ -96,7 +96,8 @@ struct symbol_conf {
initialized,
kptr_restrict,
annotate_asm_raw,
- annotate_src;
+ annotate_src,
+ event_group;
const char *vmlinux_name,
*kallsyms_name,
*source_prefix,
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/13] perf hist browser: Add support for event group view
From: Namhyung Kim
Show group members' overhead also when showing the leader's if event
group is enabled. Use macro for defining hpp functions which looks
almost identical.
Also move coloring logic into the hpp function so that each value can
be colored independently.
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 153 -
tools/perf/ui/hist.c | 5 +-
2 files changed, 126 insertions(+), 32 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 57b82c26cd05..65e6c005f8e9 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -567,23 +567,126 @@ static int hist_browser__show_callchain(struct
hist_browser *browser,
return row - first_row;
}
-#define HPP__COLOR_FN(_name, _field) \
-static int hist_browser__hpp_color_ ## _name(struct perf_hpp *hpp, \
-struct hist_entry *he) \
+struct hpp_arg {
+ struct ui_browser *b;
+ char folded_sign;
+ bool current_entry;
+};
+
+static int hist_browser__hpp_color_callchain(struct hpp_arg *arg)
+{
+ if (!symbol_conf.use_callchain)
+ return 0;
+
+ slsmg_printf("%c ", arg->folded_sign);
+ return 2;
+}
+
+static int __hpp__color_fmt(struct perf_hpp *hpp, struct hist_entry *he,
+ u64 (*get_field)(struct hist_entry *),
+ int (*callchain_cb)(struct hpp_arg *))
+{
+ int ret = 0;
+ double percent = 0.0;
+ struct hists *hists = he->hists;
+ struct hpp_arg *arg = hpp->ptr;
+
+ if (hists->stats.total_period)
+ percent = 100.0 * get_field(he) / hists->stats.total_period;
+
+ ui_browser__set_percent_color(arg->b, percent, arg->current_entry);
+
+ if (callchain_cb)
+ ret += callchain_cb(arg);
+
+ ret += scnprintf(hpp->buf, hpp->size, "%6.2f%%", percent);
+ slsmg_printf("%s", hpp->buf);
+
+ if (symbol_conf.event_group) {
+ int prev_idx, idx_delta, i;
+ struct perf_evsel *evsel = hists_to_evsel(hists);
+ struct hist_entry *pair;
+ int nr_members = evsel->nr_members;
+
+ if (nr_members <= 1)
+ goto out;
+
+ prev_idx = perf_evsel__group_idx(evsel);
+
+ list_for_each_entry(pair, &he->pairs.head, pairs.node) {
+ u64 period = get_field(pair);
+ u64 total = pair->hists->stats.total_period;
+
+ if (!total)
+ continue;
+
+ evsel = hists_to_evsel(pair->hists);
+ idx_delta = perf_evsel__group_idx(evsel) - prev_idx - 1;
+
+ for (i = 0; i < idx_delta; i++) {
+ ui_browser__set_percent_color(arg->b, 0.0,
+ arg->current_entry);
+ ret += scnprintf(hpp->buf, hpp->size,
+" %6.2f%%", 0.0);
+ slsmg_printf("%s", hpp->buf);
+ }
+
+ percent = 100.0 * period / total;
+ ui_browser__set_percent_color(arg->b, percent,
+ arg->current_entry);
+ ret += scnprintf(hpp->buf, hpp->size,
+" %6.2f%%", percent);
+ slsmg_printf("%s", hpp->buf);
+
+ prev_idx += 1 + idx_delta;
+ }
+
+ idx_delta = nr_members - prev_idx - 1;
+
+ for (i = 0; i < idx_delta; i++) {
+ ui_browser__set_percent_color(arg->b, 0.0,
+ arg->current_entry);
+ ret += scnprintf(hpp->buf, hpp->size, " %6.2f%%", 0.0);
+ slsmg_printf("%s", hpp->buf);
+ }
+ }
+out:
+ if (!arg->current_entry || !arg->b->navkeypressed)
+ ui_browser__set_color(arg->b, HE_COLORSET_NORMAL);
+
+ return ret;
+}
+
+static u64 __hpp_get_period(struct hist_entry *he)
+{
+ return he->stat.period;
+}
+
+static int hist_browser__hpp_color_overhead(struct perf_hpp *hpp,
+ struct hist_entry *he)
+{
+ return __hpp__color_fmt(hpp, he, __hpp_get_period,
+ hist_browser__hpp_color_callchain);
+}
+
+#define __HPP_COLOR_PERCENT_FN(_type, _field) \
+static u64 __hpp_get_##_field(struct hist_entry *he) \
+{ \
+ return he->stat._field;
[PATCH 10/13] perf report: Bypass non-leader events when event group is enabled
From: Namhyung Kim
Since we have all necessary information in the leader events and
other members don't, bypass members. Member events will be shown
along with the leaders if event group is enabled.
Cc: Jiri Olsa
Cc: Stephane Eranian
Cc: Pekka Enberg
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c| 4
tools/perf/ui/browsers/hists.c | 41 +++--
tools/perf/ui/gtk/hists.c | 4
3 files changed, 43 insertions(+), 6 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index fd2503a5f876..9cc768ecacad 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -319,6 +319,10 @@ static int perf_evlist__tty_browse_hists(struct
perf_evlist *evlist,
struct hists *hists = &pos->hists;
const char *evname = perf_evsel__name(pos);
+ if (symbol_conf.event_group &&
+ !perf_evsel__is_group_leader(pos))
+ continue;
+
hists__fprintf_nr_sample_events(hists, evname, stdout);
hists__fprintf(hists, true, 0, 0, stdout);
fprintf(stdout, "\n\n");
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 65e6c005f8e9..17c1753d5fe1 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1699,8 +1699,19 @@ out:
return key;
}
+static bool filter_group_entries(struct ui_browser *self __maybe_unused,
+void *entry)
+{
+ struct perf_evsel *evsel = list_entry(entry, struct perf_evsel, node);
+
+ if (symbol_conf.event_group && !perf_evsel__is_group_leader(evsel))
+ return true;
+
+ return false;
+}
+
static int __perf_evlist__tui_browse_hists(struct perf_evlist *evlist,
- const char *help,
+ int nr_entries, const char *help,
struct hist_browser_timer *hbt,
struct perf_session_env *env)
{
@@ -1711,7 +1722,8 @@ static int __perf_evlist__tui_browse_hists(struct
perf_evlist *evlist,
.refresh= ui_browser__list_head_refresh,
.seek = ui_browser__list_head_seek,
.write = perf_evsel_menu__write,
- .nr_entries = evlist->nr_entries,
+ .filter = filter_group_entries,
+ .nr_entries = nr_entries,
.priv = evlist,
},
.env = env,
@@ -1727,20 +1739,37 @@ static int __perf_evlist__tui_browse_hists(struct
perf_evlist *evlist,
menu.b.width = line_len;
}
- return perf_evsel_menu__run(&menu, evlist->nr_entries, help, hbt);
+ return perf_evsel_menu__run(&menu, nr_entries, help, hbt);
}
int perf_evlist__tui_browse_hists(struct perf_evlist *evlist, const char *help,
struct hist_browser_timer *hbt,
struct perf_session_env *env)
{
- if (evlist->nr_entries == 1) {
+ int nr_entries = evlist->nr_entries;
+
+single_entry:
+ if (nr_entries == 1) {
struct perf_evsel *first = list_entry(evlist->entries.next,
struct perf_evsel, node);
const char *ev_name = perf_evsel__name(first);
- return perf_evsel__hists_browse(first, evlist->nr_entries, help,
+
+ return perf_evsel__hists_browse(first, nr_entries, help,
ev_name, false, hbt, env);
}
- return __perf_evlist__tui_browse_hists(evlist, help, hbt, env);
+ if (symbol_conf.event_group) {
+ struct perf_evsel *pos;
+
+ nr_entries = 0;
+ list_for_each_entry(pos, &evlist->entries, node)
+ if (perf_evsel__is_group_leader(pos))
+ nr_entries++;
+
+ if (nr_entries == 1)
+ goto single_entry;
+ }
+
+ return __perf_evlist__tui_browse_hists(evlist, nr_entries, help,
+ hbt, env);
}
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index 8ab2c492a6fd..d6eb50d2aa26 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -267,6 +267,10 @@ int perf_evlist__gtk_browse_hists(struct perf_evlist
*evlist,
GtkWidget *scrolled_window;
GtkWidget *tab_label;
+ if (symbol_conf.event_group &&
+ !perf_evsel__is_group_leader(pos))
+ continue;
+
scrolled_window = gtk_scrolled_window_new(NULL, NULL);
gtk_scrolled_window
[PATCH 11/13] perf report: Show group description when event group is enabled
From: Namhyung Kim
When using event group viewer, it's better to show the group
description rather than the leader information alone.
If a leader did not contain any member, it's a non-group event.
Cc: Jiri Olsa
Cc: Stephane Eranian
Cc: Pekka Enberg
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c| 15 +++
tools/perf/ui/browsers/hists.c | 25 +
tools/perf/ui/gtk/hists.c | 14 +++---
tools/perf/util/evsel.c| 25 +
tools/perf/util/evsel.h| 8
5 files changed, 84 insertions(+), 3 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 9cc768ecacad..ce518c48a525 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -299,6 +299,21 @@ static size_t hists__fprintf_nr_sample_events(struct hists
*self,
char unit;
unsigned long nr_samples = self->stats.nr_events[PERF_RECORD_SAMPLE];
u64 nr_events = self->stats.total_period;
+ struct perf_evsel *evsel = hists_to_evsel(self);
+ char buf[512];
+ size_t size = sizeof(buf);
+
+ if (symbol_conf.event_group && evsel->nr_members > 1) {
+ struct perf_evsel *pos;
+
+ perf_evsel__group_desc(evsel, buf, size);
+ evname = buf;
+
+ for_each_group_member(pos, evsel) {
+ nr_samples +=
pos->hists.stats.nr_events[PERF_RECORD_SAMPLE];
+ nr_events += pos->hists.stats.total_period;
+ }
+ }
nr_samples = convert_unit(nr_samples, &unit);
ret = fprintf(fp, "# Samples: %lu%c", nr_samples, unit);
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 17c1753d5fe1..7a132fc3a4c9 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1193,6 +1193,21 @@ static int hists__browser_title(struct hists *hists,
char *bf, size_t size,
const struct thread *thread = hists->thread_filter;
unsigned long nr_samples = hists->stats.nr_events[PERF_RECORD_SAMPLE];
u64 nr_events = hists->stats.total_period;
+ struct perf_evsel *evsel = hists_to_evsel(hists);
+ char buf[512];
+ size_t buflen = sizeof(buf);
+
+ if (symbol_conf.event_group && evsel->nr_members > 1) {
+ struct perf_evsel *pos;
+
+ perf_evsel__group_desc(evsel, buf, buflen);
+ ev_name = buf;
+
+ for_each_group_member(pos, evsel) {
+ nr_samples +=
pos->hists.stats.nr_events[PERF_RECORD_SAMPLE];
+ nr_events += pos->hists.stats.total_period;
+ }
+ }
nr_samples = convert_unit(nr_samples, &unit);
printed = scnprintf(bf, size,
@@ -1589,6 +1604,16 @@ static void perf_evsel_menu__write(struct ui_browser
*browser,
ui_browser__set_color(browser, current_entry ? HE_COLORSET_SELECTED :
HE_COLORSET_NORMAL);
+ if (symbol_conf.event_group && evsel->nr_members > 1) {
+ struct perf_evsel *pos;
+
+ ev_name = perf_evsel__group_name(evsel);
+
+ for_each_group_member(pos, evsel) {
+ nr_events +=
pos->hists.stats.nr_events[PERF_RECORD_SAMPLE];
+ }
+ }
+
nr_events = convert_unit(nr_events, &unit);
printed = scnprintf(bf, sizeof(bf), "%lu%c%s%s", nr_events,
unit, unit == ' ' ? "" : " ", ev_name);
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index d6eb50d2aa26..101a208e1b95 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -266,10 +266,18 @@ int perf_evlist__gtk_browse_hists(struct perf_evlist
*evlist,
const char *evname = perf_evsel__name(pos);
GtkWidget *scrolled_window;
GtkWidget *tab_label;
+ char buf[512];
+ size_t size = sizeof(buf);
- if (symbol_conf.event_group &&
- !perf_evsel__is_group_leader(pos))
- continue;
+ if (symbol_conf.event_group) {
+ if (!perf_evsel__is_group_leader(pos))
+ continue;
+
+ if (pos->nr_members > 1) {
+ perf_evsel__group_desc(pos, buf, size);
+ evname = buf;
+ }
+ }
scrolled_window = gtk_scrolled_window_new(NULL, NULL);
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index e45332d08a58..35b2a0a0a490 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -434,6 +434,31 @@ const char *perf_evsel__name(struct perf_evsel *evsel)
return evsel->name ?: "unknown";
}
+const char *perf_evsel__group_name(struct perf
[PATCH 13/13] perf report: Add report.group config option
From: Namhyung Kim
Add report.group config option for setting default value of event
group view. It affects the report output only if perf.data contains
event group info.
A user can write .perfconfig file like below to enable group view by
default:
$ cat ~/.perfconfig
[report]
group = true
And it can be disabled through command line:
$ perf report --no-group
Cc: Jiri Olsa
Cc: Stephane Eranian
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 9ef38424f7c3..0d221870561a 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -8,6 +8,7 @@
#include "builtin.h"
#include "util/util.h"
+#include "util/cache.h"
#include "util/annotate.h"
#include "util/color.h"
@@ -54,6 +55,16 @@ struct perf_report {
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
};
+static int perf_report_config(const char *var, const char *value, void *cb)
+{
+ if (!strcmp(var, "report.group")) {
+ symbol_conf.event_group = perf_config_bool(var, value);
+ return 0;
+ }
+
+ return perf_default_config(var, value, cb);
+}
+
static int perf_report__add_branch_hist_entry(struct perf_tool *tool,
struct addr_location *al,
struct perf_sample *sample,
@@ -677,6 +688,8 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
OPT_END()
};
+ perf_config(perf_report_config, NULL);
+
argc = parse_options(argc, argv, options, report_usage, 0);
if (report.use_stdio)
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/13] perf gtk/browser: Add support for event group view
From: Namhyung Kim
Show group members' overhead also when showing the leader's if event
group is enabled. Use macro for defining hpp functions which looks
almost identical.
Unlike other hpp backend, GTK+ needs to print dummy 0.00% output since
it's displayed with variable width fonts. So that simply skipping
with %*s trick won't work well here.
Cc: Jiri Olsa
Cc: Stephane Eranian
Cc: Pekka Enberg
Signed-off-by: Namhyung Kim
---
tools/perf/ui/gtk/hists.c | 114 +-
1 file changed, 92 insertions(+), 22 deletions(-)
diff --git a/tools/perf/ui/gtk/hists.c b/tools/perf/ui/gtk/hists.c
index c03da79d524f..a4d951ea919a 100644
--- a/tools/perf/ui/gtk/hists.c
+++ b/tools/perf/ui/gtk/hists.c
@@ -8,32 +8,102 @@
#define MAX_COLUMNS32
-#define HPP__COLOR_FN(_name, _field)
\
-static int perf_gtk__hpp_color_ ## _name(struct perf_hpp *hpp,
\
-struct hist_entry *he)
\
+static int perf_gtk__percent_color_snprintf(char *buf, size_t size,
+ double percent)
+{
+ int ret = 0;
+ const char *markup;
+
+ markup = perf_gtk__get_percent_color(percent);
+ if (markup)
+ ret += scnprintf(buf, size, markup);
+
+ ret += scnprintf(buf + ret, size - ret, "%6.2f%%", percent);
+
+ if (markup)
+ ret += scnprintf(buf + ret, size - ret, "");
+
+ return ret;
+}
+
+
+static int __hpp__color_fmt(struct perf_hpp *hpp, struct hist_entry *he,
+ u64 (*get_field)(struct hist_entry *))
+{
+ int ret;
+ double percent = 0.0;
+ struct hists *hists = he->hists;
+
+ if (hists->stats.total_period)
+ percent = 100.0 * get_field(he) / hists->stats.total_period;
+
+ ret = perf_gtk__percent_color_snprintf(hpp->buf, hpp->size, percent);
+
+ if (symbol_conf.event_group) {
+ int prev_idx, idx_delta;
+ struct perf_evsel *evsel = hists_to_evsel(hists);
+ struct hist_entry *pair;
+ int nr_members = evsel->nr_members;
+
+ if (nr_members <= 1)
+ return ret;
+
+ prev_idx = perf_evsel__group_idx(evsel);
+
+ list_for_each_entry(pair, &he->pairs.head, pairs.node) {
+ u64 period = get_field(pair);
+ u64 total = pair->hists->stats.total_period;
+
+ evsel = hists_to_evsel(pair->hists);
+ idx_delta = perf_evsel__group_idx(evsel) - prev_idx - 1;
+
+ while (idx_delta--) {
+ ret += scnprintf(hpp->buf + ret, hpp->size
-ret, " ");
+ ret +=
perf_gtk__percent_color_snprintf(hpp->buf + ret,
+
hpp->size - ret,
+ 0.0);
+ }
+
+ percent = 100.0 * period / total;
+ ret += scnprintf(hpp->buf + ret, hpp->size -ret, " ");
+ ret += perf_gtk__percent_color_snprintf(hpp->buf + ret,
+ hpp->size - ret,
+ percent);
+
+ prev_idx = perf_evsel__group_idx(evsel);
+ }
+
+ idx_delta = nr_members - prev_idx - 1;
+
+ while (idx_delta--) {
+ ret += scnprintf(hpp->buf + ret, hpp->size -ret, " ");
+ ret += perf_gtk__percent_color_snprintf(hpp->buf + ret,
+ hpp->size - ret,
+ 0.0);
+ }
+ }
+ return ret;
+}
+
+#define __HPP_COLOR_PERCENT_FN(_type, _field)
\
+static u64 he_get_##_field(struct hist_entry *he)
\
{
\
- struct hists *hists = he->hists;
\
- double percent = 100.0 * he->stat._field / hists->stats.total_period;
\
- const char *markup;
\
- int ret = 0;
\
+ return he->stat._field;
\
+}
\
\
- markup = perf_gtk__get_percent_color(percent);
\
- if (markup)
[PATCH 12/13] perf report: Add --group option
From: Namhyung Kim
Add --group option to enable event grouping. When enabled, all the
group members information will be shown together with the leader.
Cc: Jiri Olsa
Cc: Stephane Eranian
Acked-by: Jiri Olsa
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-report.txt | 3 +++
tools/perf/builtin-report.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/tools/perf/Documentation/perf-report.txt
b/tools/perf/Documentation/perf-report.txt
index 848a0dcb6dfd..02284a0067f0 100644
--- a/tools/perf/Documentation/perf-report.txt
+++ b/tools/perf/Documentation/perf-report.txt
@@ -203,6 +203,9 @@ OPTIONS
--objdump=::
Path to objdump binary.
+--group::
+ Show event group information together.
+
SEE ALSO
linkperf:perf-stat[1], linkperf:perf-annotate[1]
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index ce518c48a525..9ef38424f7c3 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -668,6 +668,8 @@ int cmd_report(int argc, const char **argv, const char
*prefix __maybe_unused)
"Specify disassembler style (e.g. -M intel for intel
syntax)"),
OPT_BOOLEAN(0, "show-total-period", &symbol_conf.show_total_period,
"Show a column with the sum of periods"),
+ OPT_BOOLEAN(0, "group", &symbol_conf.event_group,
+ "Show event group information together"),
OPT_CALLBACK_NOOPT('b', "branch-stack", &sort__branch_mode, "",
"use branch records for histogram filling",
parse_branch_mode),
OPT_STRING(0, "objdump", &objdump_path, "path",
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHSET 00/13] perf report: Add support for event group view (v8)
Hi,
This is my 8th attempt to enable the event group view for perf report.
For basic idea and usage example, please see my initial post [1].
This version is rebased on the current acme/perf/core and it's mainly
changed due to a refactoring of gtk browser.
You can get this via 'perf/group-v8' branch on my tree:
git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
Any comments are welcome, thanks,
Namhyung
v7 -> v8:
* rebase onto acme/perf/core
* patch 3 in the previous version is merged
* add Jiri's Acked-by's
v6 -> v7:
* hists__{match,link} changes are merged separately
* factor out inc_group_count() from parsing group_def (Jiri)
* add checking for group fields in evlist/evsel (Jiri)
* check return value of during header processing (Arnaldo)
* get rid of a temporal array in hpp functions (Arnaldo)
* convert hpp macros to static inline functions (Jiri)
v5 -> v6:
* set ->leader alse for leader evsel (Arnaldo)
* use hists__{match,link} (Arnaldo)
v4 -> v5:
* rebase onto acme/perf/core
v3 -> v4:
* patch 1-9 in previous post are merged.
* add Jiri's Acked-by
* add report.group config option
v2 -> v3:
* drop patch 1 since it's merged into acme/perf/core
* cherry-pick Jiri's hpp changes
* add missing bswap_32 on reading nr_groups (Jiri)
* remove perf_evlist__recalc_nr_groups() in favor of list_is_last (Jiri)
v1 -> v2:
* save group relation to header (Jiri)
[1] https://lkml.org/lkml/2012/7/24/81
Namhyung Kim (13):
perf tools: Keep group information
perf tests: Add group test conditions
perf header: Add HEADER_GROUP_DESC feature
perf report: Make another loop for linking group hists
perf hists: Resort hist entries using group members for output
perf ui/hist: Add support for event group view
perf hist browser: Add support for event group view
perf gtk/browser: Add support for event group view
perf gtk/browser: Trim column header string when event group enabled
perf report: Bypass non-leader events when event group is enabled
perf report: Show group description when event group is enabled
perf report: Add --group option
perf report: Add report.group config option
tools/perf/Documentation/perf-report.txt | 3 +
tools/perf/builtin-record.c | 3 +
tools/perf/builtin-report.c | 47 -
tools/perf/builtin-script.c | 12 --
tools/perf/tests/parse-events.c | 28 +++
tools/perf/ui/browsers/hists.c | 219 +
tools/perf/ui/gtk/hists.c| 128 ++---
tools/perf/ui/hist.c | 316 ---
tools/perf/ui/stdio/hist.c | 2 +
tools/perf/util/evlist.c | 7 +-
tools/perf/util/evlist.h | 1 +
tools/perf/util/evsel.c | 25 +++
tools/perf/util/evsel.h | 16 ++
tools/perf/util/header.c | 164
tools/perf/util/header.h | 2 +
tools/perf/util/hist.c | 59 +-
tools/perf/util/parse-events.c | 1 +
tools/perf/util/parse-events.h | 1 +
tools/perf/util/parse-events.y | 10 +
tools/perf/util/string.c | 18 ++
tools/perf/util/symbol.h | 3 +-
tools/perf/util/util.h | 1 +
22 files changed, 840 insertions(+), 226 deletions(-)
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] f2fs: add blk plugging support in f2fs
2013/1/15, Jaegeuk Kim : > 2013-01-14 (월), 20:10 +0900, Namjae Jeon: >> 2013/1/14, Jaegeuk Kim : >> > 2013-01-12 (토), 14:42 +0900, Namjae Jeon: >> >> From: Namjae Jeon >> >> >> >> With f2fs having different writepages support for data, node and >> >> metapages. >> >> It will not be covered under the generic blk plug support. >> > >> > Could you show any improvement points with this patch? >> > >> > Currently, there is no reason to use blk plugging, since f2fs itself >> > gathers bios and then submit one big bio. >> > >> > Thanks, >> Hi Jaegeuk, >> >> There is no performance difference after introducing the block >> plugging in F2FS. > > Well, this patch is not a bug fix, but an enhancement patch. > Therefore we need to come up with how exactly the blk plugging support > makes an effect on the performance. > >> We introduced this to reduced block lock contention for f2fs also. > >> For every BIO request queuing part to the request queue: it needs to >> acquire lock-> >> spin_lock_irq(q->queue_lock); >> >> Even though the F2FS - already is handling the requests part very >> well. But still we can make use of blk_plug to reduce the block lock >> contention. >> >> When we introduce block plugging to F2FS part - all the requests will >> first be maintained on TASK basis and then pushed to the request >> queue. So, we do not have contention for the “queue lock”. >> > > What I concern is how much block lock contention would be serious. > Let's see the following operational differences. > > 1. Merging bios prior to grabing "queue lock" > The f2fs merges consecutive IOs in the file system level before > submitting any bios, which is similar with the back merge by the > plugging mechanism in attempt_plug_merge(). Both of them need to acquire > no queue lock. > > 2. Merging policy with respect to tasks > The f2fs merges IOs as much as possible regardless of tasks, while > blk-plugging is conducted on a basis of tasks. As we can understand > there are trade-offs, f2fs tries to maximize the write performance with > well-merged bios. > > As a result, if f2fs produces many consecutive but separated bios in > writepages(), it would be good to use blk-plugging. Since as you said, > f2fs would be able to avoid queue lock contention in the block layer by > merging them. > But, f2fs merges IOs and submit one bio, which means that there are not > much chances to merge bios by attempt_plug_merge(). > > How do you think? Hi Jaegeuk. Yes, You're right. I agree block plug is not needed in f2fs. So plz ignore this patch. note => Regardless of the intent in the patch, it has already been used in writepages (f2fs uses generic_writepages). So to make the overall code consistent, either we should remove blk plug from entire F2FS write part or change f2fs_write_data_pages to include blk plug properly - like the code change for this part we share in the patch. Let me know your opinion. Thanks. > > Thanks, > > -- > Jaegeuk Kim > Samsung > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3 RFT] ARM: tegra: dts: seaboard: enable keyboard
Enable tegra based keyboard controller and populate the key matrix for
seaboard. The key matrix was originally on driver code which is removed
to have clean driver. The key mapping is now passed through dts file.
Signed-off-by: Laxman Dewangan
---
Added the configuration of kbc parameter as suggested by Stephen and
corrected type for LEFTCTRL.
arch/arm/boot/dts/tegra20-seaboard.dts | 139
1 files changed, 139 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-seaboard.dts
b/arch/arm/boot/dts/tegra20-seaboard.dts
index f9e3ad4..2e87330 100644
--- a/arch/arm/boot/dts/tegra20-seaboard.dts
+++ b/arch/arm/boot/dts/tegra20-seaboard.dts
@@ -612,6 +612,145 @@
};
};
+ kbc {
+ status = "okay";
+ nvidia,debounce-delay-ms = <32>;
+ nvidia,repeat-delay-ms = <160>;
+ nvidia,ghost-filter;
+ nvidia,kbc-row-pins = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15>;
+ nvidia,kbc-col-pins = <16 17 18 19 20 21 22 23>;
+ linux,keymap = <0x00020011 /* KEY_W */
+ 0x0003001F /* KEY_S */
+ 0x0004001E /* KEY_A */
+ 0x0005002C /* KEY_Z */
+ 0x000701d0 /* KEY_FN */
+
+ 0x0107007D /* KEY_LEFTMETA */
+ 0x02060064 /* KEY_RIGHTALT */
+ 0x02070038 /* KEY_LEFTALT */
+
+ 0x0306 /* KEY_5 */
+ 0x03010005 /* KEY_4 */
+ 0x03020013 /* KEY_R */
+ 0x03030012 /* KEY_E */
+ 0x03040021 /* KEY_F */
+ 0x03050020 /* KEY_D */
+ 0x0306002D /* KEY_X */
+
+ 0x0408 /* KEY_7 */
+ 0x04010007 /* KEY_6 */
+ 0x04020014 /* KEY_T */
+ 0x04030023 /* KEY_H */
+ 0x04040022 /* KEY_G */
+ 0x0405002F /* KEY_V */
+ 0x0406002E /* KEY_C */
+ 0x04070039 /* KEY_SPACE */
+
+ 0x050A /* KEY_9 */
+ 0x05010009 /* KEY_8 */
+ 0x05020016 /* KEY_U */
+ 0x05030015 /* KEY_Y */
+ 0x05040024 /* KEY_J */
+ 0x05050031 /* KEY_N */
+ 0x05060030 /* KEY_B */
+ 0x0507002B /* KEY_BACKSLASH */
+
+ 0x060C /* KEY_MINUS */
+ 0x0601000B /* KEY_0 */
+ 0x06020018 /* KEY_O */
+ 0x06030017 /* KEY_I */
+ 0x06040026 /* KEY_L */
+ 0x06050025 /* KEY_K */
+ 0x06060033 /* KEY_COMMA */
+ 0x06070032 /* KEY_M */
+
+ 0x0701000D /* KEY_EQUAL */
+ 0x0702001B /* KEY_RIGHTBRACE */
+ 0x0703001C /* KEY_ENTER */
+ 0x0707008B /* KEY_MENU */
+
+ 0x08040036 /* KEY_RIGHTSHIFT */
+ 0x0805002A /* KEY_LEFTSHIFT */
+
+ 0x09050061 /* KEY_RIGHTCTRL */
+ 0x0907001D /* KEY_LEFTCTRL */
+
+ 0x0B1A /* KEY_LEFTBRACE */
+ 0x0B010019 /* KEY_P */
+ 0x0B020028 /* KEY_APOSTROPHE */
+ 0x0B030027 /* KEY_SEMICOLON */
+ 0x0B040035 /* KEY_SLASH */
+ 0x0B050034 /* KEY_DOT */
+
+ 0x0C44 /* KEY_F10 */
+ 0x0C010043 /* KEY_F9 */
+ 0x0C02000E /* KEY_BACKSPACE */
+ 0x0C030004 /* KEY_3 */
+ 0x0C040003 /* KEY_2 */
+ 0x0C050067 /* KEY_UP */
+ 0x0C0600D2 /* KEY_PRINT */
+ 0x0C070077 /* KEY_PAUSE */
+
+ 0x0D6E /* KEY_INSERT */
+ 0
rtc: vt8500: Fix year field in vt8500_rtc_set_time
Alessandro, This patch was sent out at the same time as two other RTC fixes for vt8500 but this one seems to have stopped somewhere along the way while the other two have been accepted. The patch is showing in the RTC patch system along with the other two: http://patchwork.ozlabs.org/patch/208756/ Greg, How did the first two patches find their way to you - did you pick them up off one of the lists? patch 1 - rtc: vt8500: Fix handling of data passed in struct rtc_time patch 2 - [fix-3.8] rtc: vt8500: Correct handling of CR_24H bitfield Hope this is enough information to help you figure out what I'm talking about :) Regards Tony P -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] slub: add 'likely' macro to inc_slabs_node()
After boot phase, 'n' always exist.
So add 'likely' macro for helping compiler.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slub.c b/mm/slub.c
index 830348b..6f82070 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1005,7 +1005,7 @@ static inline void inc_slabs_node(struct kmem_cache *s,
int node, int objects)
* dilemma by deferring the increment of the count during
* bootstrap (see early_kmem_cache_node_alloc).
*/
- if (n) {
+ if (likely(n)) {
atomic_long_inc(&n->nr_slabs);
atomic_long_add(objects, &n->total_objects);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] slub: correct bootstrap() for kmem_cache, kmem_cache_node
Current implementation of bootstrap() is not sufficient for kmem_cache
and kmem_cache_node.
First, for kmem_cache.
bootstrap() call kmem_cache_zalloc() at first. When kmem_cache_zalloc()
is called, kmem_cache's slab is moved to cpu slab for satisfying kmem_cache
allocation request. In current implementation, we only consider
n->partial slabs, so, we miss this cpu slab for kmem_cache.
Second, for kmem_cache_node.
When slab_state = PARTIAL, create_boot_cache() is called. And then,
kmem_cache_node's slab is moved to cpu slab for satisfying kmem_cache_node
allocation request. So, we also miss this slab.
These didn't make any error previously, because we normally don't free
objects which comes from kmem_cache's first slab and kmem_cache_node's.
Problem will be solved if we consider a cpu slab in bootstrap().
This patch implement it.
Signed-off-by: Joonsoo Kim
diff --git a/mm/slub.c b/mm/slub.c
index abef30e..830348b 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3613,11 +3613,22 @@ static int slab_memory_callback(struct notifier_block
*self,
static struct kmem_cache * __init bootstrap(struct kmem_cache *static_cache)
{
+ int cpu;
int node;
struct kmem_cache *s = kmem_cache_zalloc(kmem_cache, GFP_NOWAIT);
memcpy(s, static_cache, kmem_cache->object_size);
+ for_each_possible_cpu(cpu) {
+ struct kmem_cache_cpu *c;
+ struct page *p;
+
+ c = per_cpu_ptr(s->cpu_slab, cpu);
+ p = c->page;
+ if (p)
+ p->slab_cache = s;
+ }
+
for_each_node_state(node, N_NORMAL_MEMORY) {
struct kmem_cache_node *n = get_node(s, node);
struct page *p;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] slub: correct to calculate num of acquired objects in get_partial_node()
There is a subtle bug when calculating a number of acquired objects.
After acquire_slab() is executed at first, page->inuse is same as
page->objects, then, available is always 0. So, we always go next
iteration.
Correct it to stop a iteration when we find sufficient objects
at first iteration.
After that, we don't need return value of put_cpu_partial().
So remove it.
Signed-off-by: Joonsoo Kim
---
These are based on v3.8-rc3 and there is no dependency between each other.
If rebase is needed, please notify me.
diff --git a/mm/slub.c b/mm/slub.c
index ba2ca53..abef30e 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1493,7 +1493,7 @@ static inline void remove_partial(struct kmem_cache_node
*n,
*/
static inline void *acquire_slab(struct kmem_cache *s,
struct kmem_cache_node *n, struct page *page,
- int mode)
+ int mode, int *objects)
{
void *freelist;
unsigned long counters;
@@ -1506,6 +1506,7 @@ static inline void *acquire_slab(struct kmem_cache *s,
*/
freelist = page->freelist;
counters = page->counters;
+ *objects = page->objects - page->inuse;
new.counters = counters;
if (mode) {
new.inuse = page->objects;
@@ -1528,7 +1529,7 @@ static inline void *acquire_slab(struct kmem_cache *s,
return freelist;
}
-static int put_cpu_partial(struct kmem_cache *s, struct page *page, int drain);
+static void put_cpu_partial(struct kmem_cache *s, struct page *page, int
drain);
static inline bool pfmemalloc_match(struct page *page, gfp_t gfpflags);
/*
@@ -1539,6 +1540,8 @@ static void *get_partial_node(struct kmem_cache *s,
struct kmem_cache_node *n,
{
struct page *page, *page2;
void *object = NULL;
+ int available = 0;
+ int objects;
/*
* Racy check. If we mistakenly see no partial slabs then we
@@ -1552,22 +1555,21 @@ static void *get_partial_node(struct kmem_cache *s,
struct kmem_cache_node *n,
spin_lock(&n->list_lock);
list_for_each_entry_safe(page, page2, &n->partial, lru) {
void *t;
- int available;
if (!pfmemalloc_match(page, flags))
continue;
- t = acquire_slab(s, n, page, object == NULL);
+ t = acquire_slab(s, n, page, object == NULL, &objects);
if (!t)
break;
+ available += objects;
if (!object) {
c->page = page;
stat(s, ALLOC_FROM_PARTIAL);
object = t;
- available = page->objects - page->inuse;
} else {
- available = put_cpu_partial(s, page, 0);
+ put_cpu_partial(s, page, 0);
stat(s, CPU_PARTIAL_NODE);
}
if (kmem_cache_debug(s) || available > s->cpu_partial / 2)
@@ -1946,7 +1948,7 @@ static void unfreeze_partials(struct kmem_cache *s,
* If we did not find a slot then simply move all the partials to the
* per node partial list.
*/
-static int put_cpu_partial(struct kmem_cache *s, struct page *page, int drain)
+static void put_cpu_partial(struct kmem_cache *s, struct page *page, int drain)
{
struct page *oldpage;
int pages;
@@ -1984,7 +1986,6 @@ static int put_cpu_partial(struct kmem_cache *s, struct
page *page, int drain)
page->next = oldpage;
} while (this_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) !=
oldpage);
- return pobjects;
}
static inline void flush_slab(struct kmem_cache *s, struct kmem_cache_cpu *c)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 22/22] PCI: move device_add out of pci_bus_add_device()
On Sat, Jan 12, 2013 at 3:54 PM, Rafael J. Wysocki wrote: >> Move out device registering out of pci_bus_add_devices, so we could >> put new created pci devices in device tree early. >> >> new pci_bus_add_devices will do the device_attach work to load pci drivers >> instead. > > I wonder what problem it solves? we want to put created pci device in the device tree as soon as possible. so for_pci_dev will not miss them. but at that time, we can not load driver for them yet. need to after pci_assign_unsigned_resources etc to make sure all pci devices get resource allocated at first. so only move adding to device tree early, and leave loading driver on the old places. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 01/22] PCI, acpiphp: Add is_hotplug_bridge detection
On Mon, Jan 14, 2013 at 10:45 PM, Yijing Wang wrote:
>> + list_for_each_entry(func, &slot->funcs, sibling) {
>> + if (PCI_FUNC(dev->devfn) == func->function) {
>> + /* check if this bridge has ejectable slots */
>> + if ((detect_ejectable_slots(func->handle) > 0))
>> + dev->is_hotplug_bridge = 1;
>> + break;
>
> Hi Yinghai,
>Need to put the "break" in parentheses of "if"? If the first func which
> device number == dev->devfn has't ejectable slot,
> don't check the rest funcs whether have ejectable slots?
no, we should break when PCI_FUNC(dev->devfn) == func->function
that iteration is for find the func for dev.
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dw_dmac: don't exceed AHB master number in dwc_get_data_width
On Tue, Jan 15, 2013 at 3:54 AM, Viresh Kumar wrote:
> On Mon, Jan 14, 2013 at 7:50 PM, Andy Shevchenko
> wrote:
>> The driver's default assumes that hardware has two AHB masters which might be
>> not true. In such rare cases we have not to exceed a number of the AHB
>> masters
>> present in the hardware. Thus, the AHB master with highest possible number
>> will
>> be used to retrieve the data witdh value.
>>
>> The patch also changes the logic a bit when the master parameter of the
>> dwc_get_data_width() is out of range. Now the function will return a value
>> related to the first AHB master.
>>
>> Signed-off-by: Andy Shevchenko
>> ---
>> drivers/dma/dw_dmac.c |7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
>> index 30ff2a4..b2d564a 100644
>> --- a/drivers/dma/dw_dmac.c
>> +++ b/drivers/dma/dw_dmac.c
>> @@ -80,13 +80,14 @@ static inline unsigned int dwc_get_data_width(struct
>> dma_chan *chan, int master)
>> {
>> struct dw_dma *dw = to_dw_dma(chan->device);
>> struct dw_dma_slave *dws = chan->private;
>> + unsigned int m = 0;
>>
>> if (master == SRC_MASTER)
>> - return dw->data_width[dwc_get_sms(dws)];
>> + m = dwc_get_sms(dws);
>> else if (master == DST_MASTER)
>> - return dw->data_width[dwc_get_dms(dws)];
>> + m = dwc_get_dms(dws);
>>
>> - return 0;
>> + return dw->data_width[min_t(unsigned int, dw->nr_masters - 1, m)];
>
> The details of the patch are fine, but i didn't get how do you get
> master 1 selected
> on a system where you have only 1 master?
min_t(..., nr_masters - 1, m) defines this. m is returned value with
default settings, let's say 1. In that case if nr_masters is also 1
the min_t(..., 1-1, 1) returns 0.
The value of nr_masters itself is come from autoconfig or platform 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/
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] [regmap] [RESEND] Add "no-bus" option for regmap API
On Mon, Jan 14, 2013 at 09:08:27AM -0800, Andrey Smirnov wrote: > On Sun, Jan 13, 2013 at 3:18 PM, Mark Brown > > On Sat, Jan 12, 2013 at 12:54:14PM -0800, Andrey Smirnov wrote: > >> + bool cache_registers; > > I'm afraid I don't quite understand this... > From my understanding of the code it is done because the caching is > handled differently for cases when format_write() and format_reg(), > format_val() are provided. > In case of 'format_write' the regcache_write() is called in > _regmap_write() directly whereas when format_reg(), format_val() are > there _regmap_write() calls _regmap_raw_write() which in turn calls > regcache_write(). If I remove that variable and corresponding check > then regcache_write() would be called twice in the case of > format_reg(), format_val(), when _regmap_write() is called, would it > not? I apologise if I miss something obvious and that is not a case(or > issue). OK, in this case the variable is confusingly named - it has no effect on if we're going to cache, it's about where we cache. What's really driving the decision here is a combination of having block I/O support (this was done this way to support cache for block writes) and having the ability to read (which is what limits us). Not sure I can think of a good name right now though... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: 3.7-rc7: BUG: MAX_STACK_TRACE_ENTRIES too low!
On Sat, 2013-01-12 at 12:43 -0800, Christian Kujau wrote: > On Wed, 28 Nov 2012 at 16:41, Li Zhong wrote: > > On Tue, 2012-11-27 at 19:22 -0800, Christian Kujau wrote: > > > On Tue, 27 Nov 2012 at 19:06, Christian Kujau wrote: > > > > the same thing[0] happened again in 3.7-rc7, after ~20h uptime: > > > > > > I found the following on patchwork, but this seems to deal with powerpc64 > > > only, while this PowerBook G4 of mine is powerpc32: > > > > > > http://patchwork.ozlabs.org/patch/193414/ > > > > > > It looks related, but then again, I fail to parse assember... > > > > Hi Christian, > > > > Would you please help to try the following fix? I don't have a powerpc32 > > machine for test... > > The patch hasn't made it into mainline yet. Any chance that this will be > included in 3.8? I don't know... FYI, it is already in the next of ppc tree http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=shortlog;h=refs/heads/next I guess it would get into 3.9, at least. Thanks, Zhong > > Thanks, > Christian. > > > == > > diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S > > index 9499385..cadebfd 100644 > > --- a/arch/powerpc/kernel/entry_32.S > > +++ b/arch/powerpc/kernel/entry_32.S > > @@ -439,6 +439,8 @@ ret_from_fork: > > ret_from_kernel_thread: > > REST_NVGPRS(r1) > > bl schedule_tail > > + li r3,0 > > + stw r3,0(r1) > > mtlrr14 > > mr r3,r15 > > PPC440EP_ERR42 > > == > > > > > > > > Christian. > > > > > > > [40007.339487] [sched_delayed] sched: RT throttling activated > > > > [69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low! > > > > [69731.390371] turning off the locking correctness validator. > > > > [69731.391942] Call Trace: > > > > [69731.393525] [c9a61c10] [c0009064] show_stack+0x70/0x1bc (unreliable) > > > > [69731.395152] [c9a61c50] [c0077460] save_trace+0xfc/0x114 > > > > [69731.396735] [c9a61c60] [c007be20] __lock_acquire+0x1568/0x19b8 > > > > [69731.398296] [c9a61d00] [c007c2c0] lock_acquire+0x50/0x70 > > > > [69731.399857] [c9a61d20] [c0550e28] _raw_spin_lock_irq+0x5c/0x78 > > > > [69731.401419] [c9a61d40] [c054fb58] __schedule+0xd8/0x534 > > > > [69731.402972] [c9a61da0] [c0550094] _cond_resched+0x50/0x68 > > > > [69731.404527] [c9a61db0] [c0479908] dst_gc_task+0xbc/0x258 > > > > [69731.406070] [c9a61e40] [c004eeb8] process_one_work+0x1f4/0x49c > > > > [69731.407585] [c9a61e80] [c004f644] worker_thread+0x14c/0x400 > > > > [69731.409075] [c9a61eb0] [c0057634] kthread+0xbc/0xc0 > > > > [69731.410521] [c9a61f40] [c0011ad4] ret_from_kernel_thread+0x5c/0x64 > > > > [...repeated 54 times...] > > > > > > > > Anyone knows what this is about? > > > > > > > > Thanks, > > > > Christian. > > > > > > > > [0] http://lkml.indiana.edu/hypermail/linux/kernel/1211.0/03025.html > > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 17/22] PCI, ACPI: Add alloc_acpi_hp_work()
On Sat, Jan 12, 2013 at 3:45 PM, Rafael J. Wysocki wrote: > On Friday, January 11, 2013 02:40:44 PM Yinghai Lu wrote: >> Will use it with acpiphp and pci_root_hp events handling > > I think it would be better if you folded patches [17-20/22] together. just want to make move/split more simple. so could separate out old code in acpiphp is moved at first, then apply change etc. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 14/22] ACPI: update ej_event interface to take acpi_device
On Sat, Jan 12, 2013 at 3:40 PM, Rafael J. Wysocki wrote:
> On Friday, January 11, 2013 02:40:41 PM Yinghai Lu wrote:
>> Should use acpi_device pointer directly instead of use handle and
>> get the device pointer again later.
>
> Looks good.
>
> I can take this one right now if you want.
yes, in acpi-scan branch?
othewise i can not base on pci/next again.
>
> Thanks,
> Rafael
>
>
>> Signed-off-by: Yinghai Lu
>> ---
>> drivers/acpi/acpi_memhotplug.c |2 +-
>> drivers/acpi/processor_driver.c |2 +-
>> drivers/acpi/scan.c | 14 --
>> include/acpi/acpi_bus.h |2 +-
>> 4 files changed, 7 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
>> index 327ab44..eaddb7a 100644
>> --- a/drivers/acpi/acpi_memhotplug.c
>> +++ b/drivers/acpi/acpi_memhotplug.c
>> @@ -361,7 +361,7 @@ static void acpi_memory_device_notify(acpi_handle
>> handle, u32 event, void *data)
>> break;
>> }
>>
>> - ej_event->handle = handle;
>> + ej_event->device = device;
>> ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
>> acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
>> (void *)ej_event);
>> diff --git a/drivers/acpi/processor_driver.c
>> b/drivers/acpi/processor_driver.c
>> index 0777663..a24ee43 100644
>> --- a/drivers/acpi/processor_driver.c
>> +++ b/drivers/acpi/processor_driver.c
>> @@ -733,7 +733,7 @@ static void acpi_processor_hotplug_notify(acpi_handle
>> handle,
>> break;
>> }
>>
>> - ej_event->handle = handle;
>> + ej_event->device = device;
>> ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
>> acpi_os_hotplug_execute(acpi_bus_hot_remove_device,
>> (void *)ej_event);
>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> index 8883539..f4c6305 100644
>> --- a/drivers/acpi/scan.c
>> +++ b/drivers/acpi/scan.c
>> @@ -116,20 +116,14 @@ static DEVICE_ATTR(modalias, 0444,
>> acpi_device_modalias_show, NULL);
>> void acpi_bus_hot_remove_device(void *context)
>> {
>> struct acpi_eject_event *ej_event = (struct acpi_eject_event *)
>> context;
>> - struct acpi_device *device;
>> - acpi_handle handle = ej_event->handle;
>> + struct acpi_device *device = ej_event->device;
>> + acpi_handle handle = device->handle;
>> acpi_handle temp;
>> struct acpi_object_list arg_list;
>> union acpi_object arg;
>> acpi_status status = AE_OK;
>> u32 ost_code = ACPI_OST_SC_NON_SPECIFIC_FAILURE; /* default */
>>
>> - if (acpi_bus_get_device(handle, &device))
>> - goto err_out;
>> -
>> - if (!device)
>> - goto err_out;
>> -
>> ACPI_DEBUG_PRINT((ACPI_DB_INFO,
>> "Hot-removing device %s...\n", dev_name(&device->dev)));
>>
>> @@ -215,7 +209,7 @@ acpi_eject_store(struct device *d, struct
>> device_attribute *attr,
>> goto err;
>> }
>>
>> - ej_event->handle = acpi_device->handle;
>> + ej_event->device = acpi_device;
>> if (acpi_device->flags.eject_pending) {
>> /* event originated from ACPI eject notification */
>> ej_event->event = ACPI_NOTIFY_EJECT_REQUEST;
>> @@ -223,7 +217,7 @@ acpi_eject_store(struct device *d, struct
>> device_attribute *attr,
>> } else {
>> /* event originated from user */
>> ej_event->event = ACPI_OST_EC_OSPM_EJECT;
>> - (void) acpi_evaluate_hotplug_ost(ej_event->handle,
>> + (void) acpi_evaluate_hotplug_ost(acpi_device->handle,
>> ej_event->event, ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
>> }
>>
>> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
>> index 2246ba9..181ff2d 100644
>> --- a/include/acpi/acpi_bus.h
>> +++ b/include/acpi/acpi_bus.h
>> @@ -309,7 +309,7 @@ struct acpi_bus_event {
>> };
>>
>> struct acpi_eject_event {
>> - acpi_handle handle;
>> + struct acpi_device *device;
>> u32 event;
>> };
>>
>>
> --
> I speak only for myself.
> Rafael J. Wysocki, 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/
[PATCH] timer: vt8500: Convert vt8500 to use CLKSRC_OF
This patch converts arch-vt8500 to make use of CLKSRC_OF. Doing so
removes the need for include/linux/vt8500_timer.h as vt8500_timer_init
no longer needs to be visible outside vt8500_timer.c
Signed-off-by: Tony Prisk
---
Hi Olof,
Here is the fix as requested by Stephen Warren, based on vt8500/timer.
arch/arm/mach-vt8500/Kconfig |1 +
arch/arm/mach-vt8500/vt8500.c |4 ++--
drivers/clocksource/vt8500_timer.c |3 ++-
include/linux/vt8500_timer.h | 22 --
4 files changed, 5 insertions(+), 25 deletions(-)
delete mode 100644 include/linux/vt8500_timer.h
diff --git a/arch/arm/mach-vt8500/Kconfig b/arch/arm/mach-vt8500/Kconfig
index 570a801..d1cbda6 100644
--- a/arch/arm/mach-vt8500/Kconfig
+++ b/arch/arm/mach-vt8500/Kconfig
@@ -4,6 +4,7 @@ config ARCH_VT8500
select ARCH_HAS_CPUFREQ
select ARCH_REQUIRE_GPIOLIB
select CLKDEV_LOOKUP
+ select CLKSRC_OF
select CPU_ARM926T
select GENERIC_CLOCKEVENTS
select GENERIC_GPIO
diff --git a/arch/arm/mach-vt8500/vt8500.c b/arch/arm/mach-vt8500/vt8500.c
index b9fd9d3..fe99b70 100644
--- a/arch/arm/mach-vt8500/vt8500.c
+++ b/arch/arm/mach-vt8500/vt8500.c
@@ -18,9 +18,9 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#include
#include
#include
-#include
#include
#include
@@ -186,8 +186,8 @@ DT_MACHINE_START(WMT_DT, "VIA/Wondermedia SoC (Device Tree
Support)")
.dt_compat = vt8500_dt_compat,
.map_io = vt8500_map_io,
.init_irq = vt8500_init_irq,
- .init_time = vt8500_timer_init,
.init_machine = vt8500_init,
+ .init_time = clocksource_of_init,
.restart= vt8500_restart,
.handle_irq = vt8500_handle_irq,
MACHINE_END
diff --git a/drivers/clocksource/vt8500_timer.c
b/drivers/clocksource/vt8500_timer.c
index 3dd21a4..b75b8e3 100644
--- a/drivers/clocksource/vt8500_timer.c
+++ b/drivers/clocksource/vt8500_timer.c
@@ -134,7 +134,7 @@ static struct of_device_id vt8500_timer_ids[] = {
{ }
};
-void __init vt8500_timer_init(void)
+static void __init vt8500_timer_init(void)
{
struct device_node *np;
int timer_irq;
@@ -182,3 +182,4 @@ void __init vt8500_timer_init(void)
clockevents_register_device(&clockevent);
}
+CLOCKSOURCE_OF_DECLARE(vt8500, "via,vt8500-timer", vt8500_timer_init)
diff --git a/include/linux/vt8500_timer.h b/include/linux/vt8500_timer.h
deleted file mode 100644
index 33b0ee8..000
--- a/include/linux/vt8500_timer.h
+++ /dev/null
@@ -1,22 +0,0 @@
-/*
- * Copyright 2012 Tony Prisk
- *
- * 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, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-
-#ifndef __VT8500_TIMER_H
-#define __VT8500_TIMER_H
-
-#include
-
-void vt8500_timer_init(void);
-
-#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 01/22] PCI, acpiphp: Add is_hotplug_bridge detection
On 2013/1/12 6:40, Yinghai Lu wrote:
> When system support hotplug bridge with children hotplug slots, we need
> to make sure that parent bridge get preallocated resource so later when
> device is plugged into children slot, those children devices will get
> resource allocated.
>
> We do not meet this problem, because for pcie hotplug card, when acpiphp
> is used, pci_scan_bridge will set that for us when detect hotplug bit in
> slot cap.
>
> Reported-and-tested-by: Jason Baron
> Signed-off-by: Yinghai Lu
> Acked-by: Jason Baron
> ---
> drivers/pci/hotplug/acpiphp_glue.c | 27 ++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/hotplug/acpiphp_glue.c
> b/drivers/pci/hotplug/acpiphp_glue.c
> index 91b5ad8..1e5c5df 100644
> --- a/drivers/pci/hotplug/acpiphp_glue.c
> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> @@ -797,6 +797,29 @@ static void acpiphp_set_acpi_region(struct acpiphp_slot
> *slot)
> }
> }
>
> +static void check_hotplug_bridge(struct acpiphp_slot *slot, struct pci_dev
> *dev)
> +{
> + struct acpiphp_func *func;
> +
> + if (!dev->subordinate)
> + return;
> +
> + /* quirk, or pcie could set it already */
> + if (dev->is_hotplug_bridge)
> + return;
> +
> + if (PCI_SLOT(dev->devfn) != slot->device)
> + return;
> +
> + list_for_each_entry(func, &slot->funcs, sibling) {
> + if (PCI_FUNC(dev->devfn) == func->function) {
> + /* check if this bridge has ejectable slots */
> + if ((detect_ejectable_slots(func->handle) > 0))
> + dev->is_hotplug_bridge = 1;
> + break;
Hi Yinghai,
Need to put the "break" in parentheses of "if"? If the first func which
device number == dev->devfn has't ejectable slot,
don't check the rest funcs whether have ejectable slots?
> + }
> + }
> +}
> /**
> * enable_device - enable, configure a slot
> * @slot: slot to be enabled
> @@ -831,8 +854,10 @@ static int __ref enable_device(struct acpiphp_slot *slot)
> if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
> dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
> max = pci_scan_bridge(bus, dev, max, pass);
> - if (pass && dev->subordinate)
> + if (pass && dev->subordinate) {
> + check_hotplug_bridge(slot, dev);
> pci_bus_size_bridges(dev->subordinate);
> + }
> }
> }
> }
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] (xen) stable/for-jens-3.8 - bug-fixes.
On Mon, Jan 14 2013, Konrad Rzeszutek Wilk wrote: > Hey Jens, > > Please git pull the following branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > stable/for-jens-3.8 > > which has a couple of fixes that should have been pulled some time ago (my > mistake > on not posting this earlier). There is one serious fix in there from Roger > which allows the blkback to handle bio's with partial data. Without that patch > the LVM operations on guests can fail (and often do). Please pull! > > Thanks! > > drivers/block/xen-blkback/blkback.c | 18 -- > drivers/block/xen-blkback/xenbus.c | 49 > ++--- > drivers/block/xen-blkfront.c| 10 +--- > include/linux/llist.h | 25 +++ > 4 files changed, 66 insertions(+), 36 deletions(-) Did you forget to push it out? -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 09/22] PCI, ACPI: Add pci_root_hp hot removal notification support.
On Sat, Jan 12, 2013 at 3:26 PM, Rafael J. Wysocki wrote:
> On Friday, January 11, 2013 02:40:36 PM Yinghai Lu wrote:
>> Add missing hot_remove support for root device.
>>
>> How to test it?
>> Find out root bus number to acpi root name mapping from dmesg or /sys
>>
>> echo "\_SB.PCIB 3" > /sys/kernel/debug/acpi/sci_notify
>> to remove root bus
>>
>> -v2: separate stop and remove, so it will be safe for comingi
>> acpi_pci_bind_notify() changes.
>>
>> Signed-off-by: Yinghai Lu
>> Cc: Len Brown
>> Cc: linux-a...@vger.kernel.org
>> ---
>> drivers/acpi/pci_root.c | 67
>> +++
>> 1 file changed, 67 insertions(+)
>>
>> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
>> index 5c1f462c..5ae36d8 100644
>> --- a/drivers/acpi/pci_root.c
>> +++ b/drivers/acpi/pci_root.c
>> @@ -740,6 +740,12 @@ static void add_acpi_root_bridge(acpi_handle handle)
>> list_add(&bridge->list, &acpi_root_bridge_list);
>> }
>>
>> +static void remove_acpi_root_bridge(struct acpi_root_bridge *bridge)
>> +{
>> + list_del(&bridge->list);
>> + kfree(bridge);
>> +}
>> +
>> struct acpi_root_hp_work {
>> struct work_struct work;
>> acpi_handle handle;
>> @@ -800,6 +806,61 @@ static void handle_root_bridge_insertion(acpi_handle
>> handle)
>> printk(KERN_ERR "cannot add bridge to acpi list\n");
>> }
>>
>> +static int acpi_root_evaluate_object(acpi_handle handle, char *cmd, int val)
>> +{
>> + acpi_status status;
>> + struct acpi_object_list arg_list;
>> + union acpi_object arg;
>> +
>> + arg_list.count = 1;
>> + arg_list.pointer = &arg;
>> + arg.type = ACPI_TYPE_INTEGER;
>> + arg.integer.value = val;
>> +
>> + status = acpi_evaluate_object(handle, cmd, &arg_list, NULL);
>> + if (ACPI_FAILURE(status)) {
>> + pr_warn("%s: %s to %d failed\n",
>> + __func__, cmd, val);
>> + return -1;
>
> Please use a meaningful error code.
>
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static void handle_root_bridge_removal(acpi_handle handle,
>> + struct acpi_root_bridge *bridge)
>> +{
>> + u32 flags = 0;
>> + struct acpi_device *device;
>> +
>> + if (bridge) {
>> + flags = bridge->flags;
>> + remove_acpi_root_bridge(bridge);
>> + }
>> +
>> + if (!acpi_bus_get_device(handle, &device)) {
>> + int ret_val;
>> +
>> + /* remove pci devices at first */
>> + ret_val = acpi_bus_trim(device, 0);
>> + printk(KERN_DEBUG "acpi_bus_trim stop return %x\n", ret_val);
>> +
>> + /* remove acpi devices */
>> + ret_val = acpi_bus_trim(device, 1);
>> + printk(KERN_DEBUG "acpi_bus_trim remove return %x\n", ret_val);
>
> First of all, I don't agree with the way acpi_bus_trim() is used here, as
> I said in the previous message.
>
> Second, this code duplicates the code you're adding on [08/22] almost exactly.
> Please put it into a one separate function instead of duplicating it like
> this.
>
>> + }
>> +
>> + if (flags & ROOT_BRIDGE_HAS_PS3) {
>> + acpi_status status;
>> +
>> + status = acpi_evaluate_object(handle, "_PS3", NULL, NULL);
>> + if (ACPI_FAILURE(status))
>> + pr_warn("%s: _PS3 failed\n", __func__);
>
> No, please. acpi_device_set_power() is for that.
>
>> + }
>> + if (flags & ROOT_BRIDGE_HAS_EJ0)
>> + acpi_root_evaluate_object(handle, "_EJ0", 1);
>
> That seems to duplicate some code from scan.c.
yes, will address in the following patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] input: keyboard: tegra: use devm_* for resource allocation
On Mon, Jan 14, 2013 at 10:24:11PM +, Arnd Bergmann wrote: > On Monday 14 January 2013, Thierry Reding wrote: > > It certainly sounds like a less complicated way to do it. But it also > > involves adding a function with a made up name and drop a function with > > a perfectly good name instead. I wouldn't even know what name to choose > > for the new API. > > > > How about devm_ioremap_resource()? Sounds equally fitting, and is shorter. Yes, that sounds good. Thanks for the suggestion. Thierry pgpxUzaVP3sSj.pgp Description: PGP signature
Re: [next-20130114] Call-trace in LTP (lite) madvise02 test (block|mm|vfs related?)
On Mon, Jan 14 2013, Sedat Dilek wrote: > On Mon, Jan 14, 2013 at 8:28 PM, Sedat Dilek wrote: > > On Mon, Jan 14, 2013 at 7:56 PM, Jens Axboe wrote: > >> On 2013-01-14 19:33, Sedat Dilek wrote: > >>> Hi, > >>> > >>> while running LTP lite on my next-20130114 kernel I hit this > >>> call-trace (file attached). > >>> > >>> Looks to me like problem in the block layer, but not sure. > >>> Might one of the experts have look at it? > >> > >> Really? 600kb of data to look through? Can't you just paste the actual > >> error, I can't even find it... > >> > > > > $ cat call-trace_ltplite_madvise02_next-20130114.txt > > Jan 14 17:47:14 fambox kernel: [ 1263.965957] [ cut here > > ] > > Jan 14 17:47:14 fambox kernel: [ 1263.965989] Kernel BUG at > > 81328b2b [verbose debug info unavailable] > > Jan 14 17:47:14 fambox kernel: [ 1263.966022] invalid opcode: [#1] SMP > > Jan 14 17:47:14 fambox kernel: [ 1263.966046] Modules linked in: > > snd_hda_codec_hdmi snd_hda_codec_realtek joydev coretemp kvm_intel kvm > > snd_hda_intel snd_hda_codec arc4 iwldvm snd_hwdep snd_pcm > > ghash_clmulni_intel mac80211 aesni_intel i915 snd_page_alloc xts > > snd_seq_midi aes_x86_64 snd_seq_midi_event uvcvideo lrw gf128mul > > iwlwifi snd_rawmidi ablk_helper snd_seq i2c_algo_bit cryptd > > drm_kms_helper snd_timer videobuf2_vmalloc drm snd_seq_device > > videobuf2_memops psmouse parport_pc snd cfg80211 btusb rfcomm > > videobuf2_core bnep microcode ppdev soundcore videodev samsung_laptop > > wmi lp bluetooth serio_raw mei mac_hid hid_generic video lpc_ich > > parport usbhid hid r8169 > > Jan 14 17:47:14 fambox kernel: [ 1263.966377] CPU 3 > > Jan 14 17:47:14 fambox kernel: [ 1263.966388] Pid: 7803, comm: > > madvise02 Not tainted 3.8.0-rc3-next20130114-5-iniza-generic #1 > > SAMSUNG ELECTRONICS CO., LTD. > > 530U3BI/530U4BI/530U4BH/530U3BI/530U4BI/530U4BH > > Jan 14 17:47:14 fambox kernel: [ 1263.966450] RIP: > > 0010:[] [] > > blk_flush_plug_list+0x1eb/0x210 > > Jan 14 17:47:14 fambox kernel: [ 1263.966508] RSP: > > 0018:88000d933e58 EFLAGS: 00010287 > > Jan 14 17:47:14 fambox kernel: [ 1263.966532] RAX: 91827364 > > RBX: 88000d933e68 RCX: > > Jan 14 17:47:14 fambox kernel: [ 1263.966566] RDX: > > RSI: RDI: 88000d933f10 > > Jan 14 17:47:14 fambox kernel: [ 1263.966614] RBP: 88000d933eb8 > > R08: 0003 R09: > > Jan 14 17:47:14 fambox kernel: [ 1263.966656] R10: 7fff3d62c9b0 > > R11: 0206 R12: > > Jan 14 17:47:14 fambox kernel: [ 1263.966696] R13: 1000 > > R14: 88000d933f10 R15: 88000d933f10 > > Jan 14 17:47:14 fambox kernel: [ 1263.966736] FS: > > 7f56bcbc2700() GS:88011fac() > > knlGS: > > Jan 14 17:47:14 fambox kernel: [ 1263.966780] CS: 0010 DS: ES: > > CR0: 80050033 > > Jan 14 17:47:14 fambox kernel: [ 1263.966813] CR2: 7f56bc6ec060 > > CR3: 0bf66000 CR4: 000407e0 > > Jan 14 17:47:14 fambox kernel: [ 1263.966848] DR0: > > DR1: DR2: > > Jan 14 17:47:14 fambox kernel: [ 1263.966885] DR3: > > DR6: 0ff0 DR7: 0400 > > Jan 14 17:47:14 fambox kernel: [ 1263.966921] Process madvise02 (pid: > > 7803, threadinfo 88000d932000, task 88000d9f2e40) > > Jan 14 17:47:14 fambox kernel: [ 1263.966963] Stack: > > Jan 14 17:47:14 fambox kernel: [ 1263.966978] 0001 > > 0001 88000d933e68 88000d933e68 > > Jan 14 17:47:14 fambox kernel: [ 1263.967024] 88000d933ef8 > > 8114b77c 88000d933ec0 88000d933f10 > > Jan 14 17:47:14 fambox kernel: [ 1263.967071] > > 1000 0001 88000d933f10 > > Jan 14 17:47:14 fambox kernel: [ 1263.967118] Call Trace: > > Jan 14 17:47:14 fambox kernel: [ 1263.967137] [] ? > > vm_mmap_pgoff+0xbc/0xe0 > > Jan 14 17:47:14 fambox kernel: [ 1263.967173] [] > > blk_finish_plug+0x18/0x50 > > Jan 14 17:47:14 fambox kernel: [ 1263.967209] [] > > sys_madvise+0xc8/0x3a0 > > Jan 14 17:47:14 fambox kernel: [ 1263.967247] [] ? > > do_page_fault+0x39/0x50 > > Jan 14 17:47:14 fambox kernel: [ 1263.967288] [] > > system_call_fastpath+0x1a/0x1f > > Jan 14 17:47:14 fambox kernel: [ 1263.967331] Code: 4d 85 ff 74 0d 44 > >
Re: [PATCH v8 08/22] PCI, acpiphp: Separate out hot-add support of pci host bridge
On Sat, Jan 12, 2013 at 3:18 PM, Rafael J. Wysocki wrote:
>> @@ -673,3 +673,223 @@ int __init acpi_pci_root_init(void)
>>
>> return 0;
>> }
>> +
>> +/*
>> + * Separated from drivers/pci/hotplug/acpiphp_glue.c
>> + * only support root bridge
>> + */
>
> This comment will be useless after applying the patch.
>
>> +
>> +static LIST_HEAD(acpi_root_bridge_list);
>> +struct acpi_root_bridge {
>> + struct list_head list;
>> + acpi_handle handle;
>> + u32 flags;
>> +};
>
> We have struct acpi_pci_root already. Why do we need this in addition?
will address that in following patch.
>
> Also, we have acpi_pci_roots, so why do we need another list of root bridges?
>
>> +
>> +/* bridge flags */
>> +#define ROOT_BRIDGE_HAS_EJ0 (0x0002)
>> +#define ROOT_BRIDGE_HAS_PS3 (0x0080)
>
> What is that needed for?
will address that in following patch.
>
>> +
>> +#define ACPI_STA_FUNCTIONING (0x0008)
>> +
>> +static struct acpi_root_bridge *acpi_root_handle_to_bridge(acpi_handle
>> handle)
>> +{
>> + struct acpi_root_bridge *bridge;
>> +
>> + list_for_each_entry(bridge, &acpi_root_bridge_list, list)
>> + if (bridge->handle == handle)
>> + return bridge;
>> +
>> + return NULL;
>> +}
>> +
>> +/* allocate and initialize host bridge data structure */
>> +static void add_acpi_root_bridge(acpi_handle handle)
>> +{
>> + struct acpi_root_bridge *bridge;
>> + acpi_handle dummy_handle;
>> + acpi_status status;
>> +
>
> Why do we need to evaluate all of the methods directly here?
>
> Don't we have a struct acpi_device for handle already?
>
>> + /* if the bridge doesn't have _STA, we assume it is always there */
>> + status = acpi_get_handle(handle, "_STA", &dummy_handle);
>> + if (ACPI_SUCCESS(status)) {
>> + unsigned long long tmp;
>> +
>> + status = acpi_evaluate_integer(handle, "_STA", NULL, &tmp);
>> + if (ACPI_FAILURE(status)) {
>> + printk(KERN_DEBUG "%s: _STA evaluation failure\n",
>> + __func__);
>> + return;
>> + }
>> + if ((tmp & ACPI_STA_FUNCTIONING) == 0)
>> + /* don't register this object */
>> + return;
>> + }
>> +
>> + bridge = kzalloc(sizeof(struct acpi_root_bridge), GFP_KERNEL);
>> + if (!bridge)
>> + return;
>> +
>> + bridge->handle = handle;
>> +
>> + if (ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0", &dummy_handle)))
>> + bridge->flags |= ROOT_BRIDGE_HAS_EJ0;
>> + if (ACPI_SUCCESS(acpi_get_handle(handle, "_PS3", &dummy_handle)))
>> + bridge->flags |= ROOT_BRIDGE_HAS_PS3;
>
> All of this attempts to duplicate the scanning code from scan.c in a very
> incomplete and questionable way.
>
> For example, what if the root bridge has _PR0?
will address that in following patch
>
>> +
>> + list_add(&bridge->list, &acpi_root_bridge_list);
>> +}
>> +
>> +struct acpi_root_hp_work {
>> + struct work_struct work;
>> + acpi_handle handle;
>> + u32 type;
>> + void *context;
>> +};
>> +
>> +static void alloc_acpi_root_hp_work(acpi_handle handle, u32 type,
>> + void *context,
>> + void (*func)(struct work_struct *work))
>> +{
>> + struct acpi_root_hp_work *hp_work;
>> + int ret;
>> +
>> + hp_work = kmalloc(sizeof(*hp_work), GFP_KERNEL);
>> + if (!hp_work)
>> + return;
>> +
>> + hp_work->handle = handle;
>> + hp_work->type = type;
>> + hp_work->context = context;
>> +
>> + INIT_WORK(&hp_work->work, func);
>> + ret = queue_work(kacpi_hotplug_wq, &hp_work->work);
>> + if (!ret)
>> + kfree(hp_work);
>> +}
>
> The function above is called only once and used by __init stuff only.
> Why don't we move it to the caller and mark that caller as __init too?
will merge the function and shared with acpiphp
>
>> +
>> +static void handle_root_bridge_insertion(acpi_handle handle)
>> +{
>> + struct acpi_device *device, *pdevice;
>> + acpi_handle phandle;
>> + int ret_val;
>> +
>> + acpi_get_parent(handle, &phandle);
>> + if (acpi_bus_get_device(phandle, &pdevice)) {
>> + printk(KERN_DEBUG "no parent device, assuming NULL\n");
>> + pdevice = NULL;
>> + }
>> + if (!acpi_bus_get_device(handle, &device)) {
>> + /* check if pci root_bus is removed */
>> + struct acpi_pci_root *root = acpi_driver_data(device);
>> + if (pci_find_bus(root->segment, root->secondary.start))
>> + return;
>> +
>> + printk(KERN_DEBUG "bus exists... trim\n");
>> + /* this shouldn't be in here, so remove
>> + * the bus then re-add it...
>> + */
>
> Why? Shouldn't we just bail out here?
should be the same from acpiphp.
>
>> +
Re: [PATCHv2 1/4] clockevents: Add generic timer broadcast receiver
On Monday 14 January 2013 09:06 PM, Mark Rutland wrote:
On Mon, Jan 14, 2013 at 02:17:26PM +, Thomas Gleixner wrote:
On Mon, 14 Jan 2013, Mark Rutland wrote:
On Mon, Jan 14, 2013 at 11:50:55AM +, Thomas Gleixner wrote:
On Mon, 14 Jan 2013, Mark Rutland wrote:
On Mon, Jan 14, 2013 at 11:06:31AM +, Thomas Gleixner wrote:
On Wed, 9 Jan 2013, Mark Rutland wrote:
+#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
+extern int tick_receive_broadcast(void);
+#else
+static inline int tick_receive_broadcast(void)
+{
+ return 0;
+}
What's the inline function for? If an arch does not have broadcasting
support it should not have a receive broadcast function call either.
That was how this was originally structured [1], but Santosh suggested this
would break the build for !GENERIC_CLOCKEVENTS_BROADCAST [1]. It means that the
arch-specific receive path (i.e. IPI handler) doesn't have to be #ifdef'd,
which makes it less ugly.
Hmm. If you want to keep the IPI around unconditionally the inline
makes some sense, though the question is whether keeping an unused IPI
around makes sense in the first place. I'd rather see a warning that
an unexpected IPI happened than a silent inline function being called.
How about I add a warning (e.g. "Impossible timer broadcast received.") and
return -EOPNOTSUPP when !GENERIC_CLOCKEVENTS_BROADCAST?
You still need to do something with the return value in the arch IPI
code, right?
Good point. Having the stub when !CONFIG_GENERIC_CLOCKEVENTS_BROADCAST is
clearly problematic.
I'll go with your original suggestion, removing the tick_receive_broadcast stub
for !CONFIG_GENERIC_CLOCKEVENTS_BROADCAST and I'll #idef the IPI_TIMER handler.
That way it'll fall down to the standard warning for an unexpected/unknown IPI
for arch/arm at least.
The alternative is fine by me.
Regards
santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] i2c-core: dt: Pick i2c bus number from i2c alias if present
On Mon, Jan 14, 2013 at 10:53:21AM -0800, Doug Anderson wrote:
> This allows you to get the equivalent functionality of
> i2c_add_numbered_adapter() with all data in the device tree and no
> special case code in your driver. This is a common device tree
> technique.
>
> For quick reference, the FDT syntax for using an alias to provide an
> ID looks like:
> aliases {
> i2c0 = &i2c_0;
> i2c1 = &i2c_1;
> };
>
> Signed-off-by: Doug Anderson
> Acked-by: Haojian Zhuang
The call path for i2c_add_numbered_adapter() with nr == -1 is a little
awkward now, but I don't see much how it can be improved much.
Acked-by: Olof Johansson
-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[head.S] opening DEBUG ,kernel crashed
When I open the macro DEBUG in the front of file arch/arm/boot/decompressed/head.S,the kernel runs and stops at"Uncompressing Linux... done, booting the kernel." CONFIG_DEBUG_ICEDCC is closed by default, so I am sure the code runs tothe following branch: ... ... ... .macro kputc,val mov r0, \val bl putc .endm .macro kphex,val,len mov r0, \val mov r1, #\len bl phex .endm .macro debug_reloc_start #ifdef DEBUG kputc #'\n' kphex r6, 8 /* processor id */ kputc #':' kphex r7, 8 /* architecture id */ ... ... ... Problem is happened in a context like this: I have a board use cpu S5PV210,and an ok kernel provide by the factory anda kernel download from kernel.org which carshed after printing "starting kernel..." to dnw. To debug this,I want to test the macro kputc provided in this file¡ª¡ª using ok kernel. I add a line "kputc #'a' " after the tag ".text", then make error says "undefined reference to `putc' ",it seems that compiler cant find "putc" used in the definition of macro ¡°kputc¡±. This is an ok kernel,so I cant say the serial port is not open¡ª¡ªcan this mean "putc" is defined already?. So I open DEBUG hoping to see debugging info by kernel itself,but it stops at"Uncompressing Linux... done, booting the kernel." Opening DEBUG will lead to the call of ¡°kputc #'\n' ¡± in the code above which will also call putc! Here,my questions comes: 1¡¢Why the error " undefined reference to `putc' " disappeared? 2¡¢Why it stops at"Uncompressing Linux... done, booting the kernel."? 3¡¢Can this error ( undefined reference to `putc' ) mean the serial port is not open? Where is it defined ? Is it refer to the C function or just an assembly macro£¿ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 07/22] ACPI: Separate acpi_bus_trim to support two steps.
On Sat, Jan 12, 2013 at 2:40 PM, Rafael J. Wysocki wrote: > On Friday, January 11, 2013 02:40:34 PM Yinghai Lu wrote: >> Current all acpi_bus_trim callers have rmdevice to 1. >> that means it will remove all acpi devices. >> >> When 0, is passed, it will keep the parent. >> >> For root bus hotremove support, we need to have pci device to be >> removed before acpi devices. >> >> So try to keep all acpi devices, and only stop drivers with them. >> >> This change should be safe because all current callers all have 1 passed. > > I'm not sure how the chanelog is related to the patch itself. > > The patch modifies the behavior of acpi_bus_trim() to avoid removing all > devices (not just the start point) for rmdevice==0, which doesn't really > change > the functionality, because all callers pass rmdevice=1 anyway. > > Yes, we can make this change, but why is it necessary? > > And why don't we remove the rmdevice argument from acpi_bus_trim() altogether? this patch is not needed after your changes with acpi_bus_trim. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 06/22] PCI: split registration of PCI bus devices into two stages
On Sun, Jan 13, 2013 at 7:25 AM, Jiang Liu wrote: > On 01/13/2013 06:34 AM, Rafael J. Wysocki wrote: >> On Friday, January 11, 2013 02:40:33 PM Yinghai Lu wrote: >>> From: Jiang Liu >>> >>> When handling BUS_NOTIFY_ADD_DEVICE event for a PCI bridge device, >>> the notification handler can't hold reference count to the new PCI bus >>> because the device object for the new bus (pci_dev->subordinate->dev) >>> hasn't been initialized yet. >> >> It doesn't look like BUS_NOTIFY_ADD_DEVICE is used by the PCI bus type >> in the mainline. >> >> Is it in linux-next? >> >> If not, then I don't see why we need this patch. > Hi Rafael, > Originally it's a preparation patch for pci_slot/acpiphp/pci_bind > related fixups. With recent work from you to remove bind/unbind from struct > acpi_bus_type, we have no dependency on this patch anymore. ok, will drop this one. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 5/5] mmc: dw_mmc: Remove DW_MCI_QUIRK_NO_WRITE_PROTECT
On Fri, Jan 11, 2013 at 09:03:54AM -0800, Doug Anderson wrote: > The original quirk was added in the change 'mmc: dw_mmc: add quirk to > indicate missing write protect line'. The original quirk was added at > a controller level even though each slot has its own write protect (so > the quirk should be at the slot level). A recent change (mmc: dw_mmc: > Add "disable-wp" device tree property) added a slot-level quirk and > support for the quirk directly to dw_mmc. > > Signed-off-by: Doug Anderson Acked-by: Olof Johansson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/5] mmc: dw_mmc: Handle wp-gpios from device tree
On Fri, Jan 11, 2013 at 09:03:53AM -0800, Doug Anderson wrote: > On some SoCs (like exynos5250) you need to use an external GPIO for > write protect. Add support for wp-gpios to the core dw_mmc driver > since it could be useful across multiple SoCs. > > With this change I am able to make use of the write protect for the > external SD slot on exynos5250-snow. > > Signed-off-by: Doug Anderson > Acked-by: Seungwon Jeon Acked-by: Olof Johansson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/5] ARM: dts: Add disable-wp for sd card slot on smdk5250
On Fri, Jan 11, 2013 at 09:03:51AM -0800, Doug Anderson wrote: > The next change will remove the code from the dw_mmc-exynos that added > the DW_MCI_QUIRK_NO_WRITE_PROTECT. Keep existing functionality of > having no write protect pin on smdk5250 by adding the disable-wp > property. > > Signed-off-by: Doug Anderson > Acked-by: Seungwon Jeon Acked-by: Olof Johansson -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3/5] mmc: dw_mmc: exynos: Remove code for wp-gpios
On Fri, Jan 11, 2013 at 09:03:52AM -0800, Doug Anderson wrote: > The exynos code claimed the write protect with devm_gpio_request() but > never did anything with it. That meant that anyone using a write > protect GPIO would effectively be write protected all the time. > > The handling for wp-gpios belongs in the main dw_mmc driver and has > been moved there. > > Signed-off-by: Doug Anderson > Acked-by: Seungwon Jeon Acked-by: Olof Johansson -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] i2c: exynos5: add High Speed I2C controller driver
On 28 December 2012 22:06, Naveen Krishna Ch wrote: > On 28 December 2012 16:57, Naveen Krishna Chatradhi > wrote: >> Adds support for High Speed I2C driver found in Exynos5 and later >> SoCs from Samsung. This driver currently supports Auto mode. >> >> Driver only supports Device Tree method of passing platform data. >> Note: Added debugfs support for registers view, not tested. >> >> Signed-off-by: Taekgyun Ko >> Signed-off-by: Naveen Krishna Chatradhi >> --- >> Changes since v2: fixed comments from Felipe Balbi. >> And minor fixes for the return values in exynos5_i2c_doxfer() >> >> drivers/i2c/busses/Kconfig |7 + >> drivers/i2c/busses/Makefile |1 + >> drivers/i2c/busses/i2c-exynos5.c | 736 >> ++ >> 3 files changed, 744 insertions(+) >> create mode 100644 drivers/i2c/busses/i2c-exynos5.c >> >> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig >> index bdca511..4caea76 100644 >> --- a/drivers/i2c/busses/Kconfig >> +++ b/drivers/i2c/busses/Kconfig >> @@ -618,6 +618,13 @@ config I2C_S3C2410 >> Say Y here to include support for I2C controller in the >> Samsung SoCs. >> >> +config I2C_EXYNOS5 >> + tristate "Exynos5 high-speed I2C driver" >> + depends on ARCH_EXYNOS5 >> + help >> + Say Y here to include support for High-speed I2C controller in the >> + Exynos5 based Samsung SoCs. >> + >> config I2C_S6000 >> tristate "S6000 I2C support" >> depends on XTENSA_VARIANT_S6000 >> diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile >> index 6181f3f..4b1548c 100644 >> --- a/drivers/i2c/busses/Makefile >> +++ b/drivers/i2c/busses/Makefile >> @@ -61,6 +61,7 @@ obj-$(CONFIG_I2C_PUV3)+= i2c-puv3.o >> obj-$(CONFIG_I2C_PXA) += i2c-pxa.o >> obj-$(CONFIG_I2C_PXA_PCI) += i2c-pxa-pci.o >> obj-$(CONFIG_I2C_S3C2410) += i2c-s3c2410.o >> +obj-$(CONFIG_I2C_EXYNOS5) += i2c-exynos5.o >> obj-$(CONFIG_I2C_S6000)+= i2c-s6000.o >> obj-$(CONFIG_I2C_SH7760) += i2c-sh7760.o >> obj-$(CONFIG_I2C_SH_MOBILE)+= i2c-sh_mobile.o >> diff --git a/drivers/i2c/busses/i2c-exynos5.c >> b/drivers/i2c/busses/i2c-exynos5.c >> new file mode 100644 >> index 000..a5eb959 >> --- /dev/null >> +++ b/drivers/i2c/busses/i2c-exynos5.c >> @@ -0,0 +1,736 @@ >> +/** >> + * i2c-exynos5.c - Samsung Exynos5 I2C Controller Driver >> + * >> + * Copyright (C) 2012 Samsung Electronics Co., Ltd. >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> +*/ >> + >> +#include >> +#include >> +#include >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +/* Register Map */ >> +#define HSI2C_CTL 0x00 >> +#define HSI2C_FIFO_CTL 0x04 >> +#define HSI2C_TRAILIG_CTL 0x08 >> +#define HSI2C_CLK_CTL 0x0C >> +#define HSI2C_CLK_SLOT 0x10 >> +#define HSI2C_INT_ENABLE 0x20 >> +#define HSI2C_INT_STATUS 0x24 >> +#define HSI2C_ERR_STATUS 0x2C >> +#define HSI2C_FIFO_STATUS 0x30 >> +#define HSI2C_TX_DATA 0x34 >> +#define HSI2C_RX_DATA 0x38 >> +#define HSI2C_CONF 0x40 >> +#define HSI2C_AUTO_CONF0x44 >> +#define HSI2C_TIMEOUT 0x48 >> +#define HSI2C_MANUAL_CMD 0x4C >> +#define HSI2C_TRANS_STATUS 0x50 >> +#define HSI2C_TIMING_HS1 0x54 >> +#define HSI2C_TIMING_HS2 0x58 >> +#define HSI2C_TIMING_HS3 0x5C >> +#define HSI2C_TIMING_FS1 0x60 >> +#define HSI2C_TIMING_FS2 0x64 >> +#define HSI2C_TIMING_FS3 0x68 >> +#define HSI2C_TIMING_SLA 0x6C >> +#define HSI2C_ADDR 0x70 >> + >> +/* I2C_CTL Register bits */ >> +#define HSI2C_FUNC_MODE_I2C(1u << 0) >> +#define HSI2C_MASTER (1u << 3) >> +#define HSI2C_RXCHON (1u << 6) >> +#define HSI2C_TXCHON (1u << 7) >> +#define HSI2C_SW_RST (1u << 31) >> + >> +/* I2C_FIFO_CTL Register bits */ >> +#define HSI2C_RXFIFO_EN(1u << 0) >> +#define HSI2C_TXFIFO_EN(1u << 1) >> +#define HSI2C_TXFIFO_TRIGGER_LEVEL (0x20 << 16) >> +#define HSI2C_RXFIFO_TRIGGER_LEVEL (0x20 << 4) >> + >> +/* I2C_TRAILING_CTL Register bits */ >> +#define HSI2C_TRAILING_COUNT (0xf) >> + >> +/* I2C_INT_EN Register bits */ >> +#define HSI2C_INT_TX_ALMOSTEMPTY_EN(1u << 0) >> +#define HSI2C_INT_RX_ALMOSTFULL_EN (1u << 1) >> +#define HSI2C_INT_TRAILING_EN (1u << 6) >> +#define HS
Re: USB device cannot be reconnected and khubd "blocked for more than 120 seconds"
On Tue, Jan 15, 2013 at 9:53 AM, Ming Lei wrote:
>
> I will try to figure out one patch to address the scsi block async probe
> issue first, and see if it can fix the problem by moving add_disk()
> into sd_probe()
> and calling async_synchronize_full_domain(&scsi_sd_probe_domain)
> in the entry of sd_open().
Looks it isn't doable because the block partition device can only be created
inside the async things.
But I have another idea to address the problem, and let module code call
async_synchronize_full() only if the module requires that explicitly, so how
about the below draft patch?
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 7992635..c5106a0 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -3143,6 +3143,8 @@ static int __init init_sd(void)
if (err)
goto err_out_driver;
+ mod_init_async_wait(THIS_MODULE);
+
return 0;
err_out_driver:
diff --git a/include/linux/module.h b/include/linux/module.h
index 7760c6d..09bd4c5 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -300,6 +300,12 @@ struct module
unsigned int taints;/* same bits as kernel:tainted */
+ /*
+* set if the module wants to call async_synchronize_full
+* after its init() is complted.
+*/
+ unsigned int init_async_wait:1;
+
#ifdef CONFIG_GENERIC_BUG
/* Support for BUG */
unsigned num_bugs;
@@ -656,4 +662,16 @@ static inline void module_bug_finalize(const Elf_Ehdr *hdr,
static inline void module_bug_cleanup(struct module *mod) {}
#endif /* CONFIG_GENERIC_BUG */
+/*
+ * If one module wants to complete its all async code after
+ * its init() executed, the module can call this function in
+ * the entry of its init(), but the module's async function
+ * can't call request_module, otherwise deadlock will be caused.
+ */
+static inline void mod_init_async_wait(struct module *mod)
+{
+ if (mod)
+ mod->init_async_wait = 1;
+}
+
#endif /* _LINUX_MODULE_H */
diff --git a/kernel/module.c b/kernel/module.c
index 250092c..dc5d011 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3058,8 +3058,9 @@ static int do_init_module(struct module *mod)
blocking_notifier_call_chain(&module_notify_list,
MODULE_STATE_LIVE, mod);
- /* We need to finish all async code before the module init sequence is
done */
- async_synchronize_full();
+ /* Only complete all async code if the module requires that */
+ if (mod->init_async_wait)
+ async_synchronize_full();
mutex_lock(&module_mutex);
/* Drop initial reference. */
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 02/22] PCI: Add root bus children dev's res to fail list
On Sat, Jan 12, 2013 at 1:37 PM, Rafael J. Wysocki wrote: > On Friday, January 11, 2013 02:40:29 PM Yinghai Lu wrote: >> We can stop trying according to try number now and do not need to use >> root_bus checking as stop sign anymore. >> >> In extreme case we could need to reallocate resource for device just >> under root bus. > > Well, the above says that we _can_ do the change, but it doesn't explain why > it > is needed. So what's the reason why we need to do that? In extreme case we could need to reallocate resource for device just under root bus. otherwise, those devices just under root bus will not be assigned resources again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] PM / Runtime: return the right value when deferred_resume is true in rpm_suspend()
For the case that in rpm_suspend() and deferred_resume is true,
the rpm_resume() will be called, and if rpm_resume() return error,
at this time, the device is still in SUSPENDED state.
In this case it is still an suspend succeeding case, we should
return non-error instead of EAGAIN.
An example like below for this case:
CPU1: CPU2:
pm_runtime_get_sync()
pm_runtime_put_sync_suspend()
rpm_suspend()
__update_runtime_status(dev, RPM_SUSPENDING)
rpm_callback()
spin_unlock_irq()
... pm_runtime_get()
spin_lock_irqsave()
cb()rpm_resume()
...
dev->power.deferred_resume = true
spin_unlock_irqrestore()
spin_lock_irq()
__update_runtime_status(dev, RPM_SUSPENDED)
rpm_resume() is called due to deferred_resume is true
Here if rpm_resume() failed in CPU1, the runtime_status is still SUSPENDED,
we should return 0 in this case.
Signed-off-by: liu chuansheng
---
drivers/base/power/runtime.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 3148b10..0adc713 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -436,9 +436,11 @@ static int rpm_suspend(struct device *dev, int rpmflags)
if (dev->power.deferred_resume) {
dev->power.deferred_resume = false;
- rpm_resume(dev, 0);
- retval = -EAGAIN;
- goto out;
+ if (rpm_resume(dev, 0) >= 0) {
+ /* In case resuming succeeded, return EAGAIN error */
+ retval = -EAGAIN;
+ goto out;
+ }
}
/* Maybe the parent is now able to suspend. */
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/5] mmc: dw_mmc: Add "disable-wp" device tree property
On Fri, Jan 11, 2013 at 09:03:50AM -0800, Doug Anderson wrote: > The "disable-wp" property is used to specify that a given SD card slot > doesn't have a concept of write protect. This eliminates the need for > special case code for SD slots that should never be write protected > (like a micro SD slot or a dev board). > > The dw_mmc driver is special in needing to specify "disable-wp" > because the lack of a "wp-gpios" property means to use the special > purpose write protect line. On some other mmc devices the lack of > "wp-gpios" means that write protect should be disabled. > > Signed-off-by: Doug Anderson > Acked-by: Seungwon Jeon Acked-by: Olof Johansson Nit below. > @@ -825,7 +828,13 @@ static int dw_mci_get_ro(struct mmc_host *mmc) > struct dw_mci_board *brd = slot->host->pdata; > > /* Use platform get_ro function, else try on board write protect */ > - if (brd->quirks & DW_MCI_QUIRK_NO_WRITE_PROTECT) > + > + /* > + * NOTE: DW_MCI_QUIRK_NO_WRITE_PROTECT will be removed in a future > + * patch in the series once reference to it is removed. > + */ > + if ((brd->quirks & DW_MCI_QUIRK_NO_WRITE_PROTECT) || > + (slot->quirks & DW_MCI_SLOT_QUIRK_NO_WRITE_PROTECT)) Given that it never worked properly, you could have nuked it first and avoid the extra churn. Still, not a strong enough reason to respin the series, IMHO. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 v7u1 26/31] x86: Don't enable swiotlb if there is not enough ram for it
On Fri, Jan 11, 2013 at 9:49 AM, Yinghai Lu wrote: > On Fri, Jan 11, 2013 at 8:52 AM, Yinghai Lu wrote: >>> >>> I need to check this patch out and then also test-run them on IA64, AMD-VI, >>> Calgary-X >>> GART and Intel VT-d to make a sanity test. >> >> that will be great, and please check attached two patches, or you want >> to me update >> for-x86-boot branch and you test that instead? >> >> but if you want to check memmap=4095M$1M, then will need to test on >> newer branch. > > > I updated the for-x86-boot branch. > > git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > for-x86-boot > Konrad, Did you get chance to test that branch on your setups? Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7u1 22/31] x86, boot: add fields to support load bzImage and ramdisk above 4G
On Mon, Jan 14, 2013 at 12:05 PM, Yinghai Lu wrote: > On Mon, Jan 14, 2013 at 11:56 AM, H. Peter Anvin wrote: >> On 01/14/2013 11:50 AM, Yinghai Lu wrote: >>> On Mon, Jan 14, 2013 at 10:59 AM, H. Peter Anvin wrote: No, there were other fields that were also left uninitialized, per your analysis from last year. I don't remember the details, but I seem to recall they included the EFI and graphics-related fields. So yes, just zero them all out. >>> >>> ? >>> >> >> Yep. > > ok, will rebase -v7 branch this afternoon, and ask you and Borislav to > check if i missed anything. > > hope can send out v7u2 tomorrow ... I rebased the -v7 branch, and it should address the comments and change log request that I understand and agreed on. could be found at: git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-boot and it is on top of linus's tree 2013-01-14 plus tip:x86/mm, tip:x86/urgent, tip:x86/mm2 Please check if I miss anything that must be addressed. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] cpuset: return the return value of cgroup_path() to userspace
-EINVAL is improper, as we don't accept user inputs. Signed-off-by: Li Zefan --- kernel/cpuset.c | 1 - 1 file changed, 1 deletion(-) diff --git a/kernel/cpuset.c b/kernel/cpuset.c index 1a675e4..16be7c9 100644 --- a/kernel/cpuset.c +++ b/kernel/cpuset.c @@ -2677,7 +2677,6 @@ static int proc_cpuset_show(struct seq_file *m, void *unused_v) if (!tsk) goto out_free; - retval = -EINVAL; rcu_read_lock(); css = task_subsys_state(tsk, cpuset_subsys_id); retval = cgroup_path(css->cgroup, buf, PAGE_SIZE); -- 1.8.0.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 1/2] cpuset: fix RCU lockdep splat
Reading /proc//cpuset triggered RCU warning, and this bug was
introduced by Commit 5d21cc2db040d01f8c19b8602f6987813e1176b4
("cpuset: replace cgroup_mutex locking with cpuset internal locking")
Here we can retreive tsk->cgroups and call cgroup_path() inside RCU
read section.
Reported-by: Sasha Levin
Signed-off-by: Li Zefan
---
kernel/cpuset.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 6aa5bbb..1a675e4 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -2678,15 +2678,15 @@ static int proc_cpuset_show(struct seq_file *m, void
*unused_v)
goto out_free;
retval = -EINVAL;
- mutex_lock(&cpuset_mutex);
+ rcu_read_lock();
css = task_subsys_state(tsk, cpuset_subsys_id);
retval = cgroup_path(css->cgroup, buf, PAGE_SIZE);
+ rcu_read_unlock();
if (retval < 0)
- goto out_unlock;
+ goto out_put_task;
seq_puts(m, buf);
seq_putc(m, '\n');
-out_unlock:
- mutex_unlock(&cpuset_mutex);
+out_put_task:
put_task_struct(tsk);
out_free:
kfree(buf);
--
1.8.0.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 v7] usb: phy: samsung: Add support to set pmu isolation
Adding support to parse device node data in order to get
required properties to set pmu isolation for usb-phy.
Signed-off-by: Vivek Gautam
Reviewed-by: Sylwester Nawrocki
Reviewed-by: Doug Anderson
---
Changes from v6:
- Returning error code in samsung_usbphy_parse_dt() when
'usbphy-sys' sub-node is not present and thereby putting up
dev_err() instead of dev_warn()
.../devicetree/bindings/usb/samsung-usbphy.txt | 36 +
drivers/usb/phy/samsung-usbphy.c | 163 +---
2 files changed, 177 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
index 7b26e2d..22d06cf 100644
--- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -9,3 +9,39 @@ Required properties:
- compatible : should be "samsung,exynos4210-usbphy"
- reg : base physical address of the phy registers and length of memory mapped
region.
+
+Optional properties:
+- #address-cells: should be '1' when usbphy node has a child node with 'reg'
+ property.
+- #size-cells: should be '1' when usbphy node has a child node with 'reg'
+ property.
+- ranges: allows valid translation between child's address space and parent's
+ address space.
+
+- The child node 'usbphy-sys' to the node 'usbphy' is for the system controller
+ interface for usb-phy. It should provide the following information required
by
+ usb-phy controller to control phy.
+ - reg : base physical address of PHY_CONTROL registers.
+ The size of this register is the total sum of size of all PHY_CONTROL
+ registers that the SoC has. For example, the size will be
+ '0x4' in case we have only one PHY_CONTROL register (e.g.
+ OTHERS register in S3C64XX or USB_PHY_CONTROL register in S5PV210)
+ and, '0x8' in case we have two PHY_CONTROL registers (e.g.
+ USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers in exynos4x).
+ and so on.
+
+Example:
+ - Exynos4210
+
+ usbphy@125B {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "samsung,exynos4210-usbphy";
+ reg = <0x125B 0x100>;
+ ranges;
+
+ usbphy-sys {
+ /* USB device and host PHY_CONTROL registers */
+ reg = <0x10020704 0x8>;
+ };
+ };
diff --git a/drivers/usb/phy/samsung-usbphy.c b/drivers/usb/phy/samsung-usbphy.c
index 5c5e1bb5..30aebb5 100644
--- a/drivers/usb/phy/samsung-usbphy.c
+++ b/drivers/usb/phy/samsung-usbphy.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
@@ -60,20 +61,46 @@
#define MHZ (1000*1000)
#endif
+#define S3C64XX_USBPHY_ENABLE (0x1 << 16)
+#define EXYNOS_USBPHY_ENABLE (0x1 << 0)
+
enum samsung_cpu_type {
TYPE_S3C64XX,
TYPE_EXYNOS4210,
};
/*
+ * struct samsung_usbphy_drvdata - driver data for various SoC variants
+ * @cpu_type: machine identifier
+ * @devphy_en_mask: device phy enable mask for PHY CONTROL register
+ * @devphy_reg_offset: offset to DEVICE PHY CONTROL register from
+ *mapped address of system controller.
+ *
+ * Here we have a separate mask for device type phy.
+ * Having different masks for host and device type phy helps
+ * in setting independent masks in case of SoCs like S5PV210,
+ * in which PHY0 and PHY1 enable bits belong to same register
+ * placed at position 0 and 1 respectively.
+ * Although for newer SoCs like exynos these bits belong to
+ * different registers altogether placed at position 0.
+ */
+struct samsung_usbphy_drvdata {
+ int cpu_type;
+ int devphy_en_mask;
+ u32 devphy_reg_offset;
+};
+
+/*
* struct samsung_usbphy - transceiver driver state
* @phy: transceiver structure
* @plat: platform data
* @dev: The parent device supplied to the probe function
* @clk: usb phy clock
- * @regs: usb phy register memory base
+ * @regs: usb phy controller registers memory base
+ * @pmuregs: USB device PHY_CONTROL register memory base
* @ref_clk_freq: reference clock frequency selection
- * @cpu_type: machine identifier
+ * @drv_data: driver data available for different SoCs
+ * @lock: lock for phy operations
*/
struct samsung_usbphy {
struct usb_phy phy;
@@ -81,12 +108,66 @@ struct samsung_usbphy {
struct device *dev;
struct clk *clk;
void __iomem*regs;
+ void __iomem*pmuregs;
int ref_clk_freq;
- int cpu_type;
+ const struct samsung_usbphy_drvdata *drv_data;
+ spinlock_t lock;
};
#define phy_to_sphy(x) container_of((x), struct samsung_usbphy, phy)
+static int samsung_usbphy_parse_dt(struct samsung_usb
Re: [Bulk] [PATCH] timer: vt8500: Move timer code to drivers/clocksource
On Mon, Jan 14, 2013 at 8:12 PM, Tony Prisk wrote: > On Mon, 2013-01-14 at 12:07 -0800, Olof Johansson wrote: >> On Mon, Jan 14, 2013 at 06:47:35PM +1300, Tony Prisk wrote: >> > On Mon, 2013-01-14 at 18:13 +1300, Tony Prisk wrote: >> > > On Mon, 2013-01-14 at 18:09 +1300, Tony Prisk wrote: >> > > > This patch moves arch-vt8500/timer.c into drivers/clocksource and >> > > > updates the necessary Kconfig/Makefile options. >> > > > >> > > > Signed-off-by: Tony Prisk >> > > > --- >> > > > arch/arm/mach-vt8500/Kconfig |1 + >> > > > arch/arm/mach-vt8500/Makefile |2 +- >> > > > arch/arm/mach-vt8500/common.h |1 - >> > > > arch/arm/mach-vt8500/timer.c | 184 >> > > > >> > > > arch/arm/mach-vt8500/vt8500.c |1 + >> > > > drivers/clocksource/Kconfig|3 + >> > > > drivers/clocksource/Makefile |1 + >> > > > drivers/clocksource/vt8500_timer.c | 184 >> > > > >> > > > include/linux/vt8500_timer.h | 22 + >> > > > 9 files changed, 213 insertions(+), 186 deletions(-) >> > > > delete mode 100644 arch/arm/mach-vt8500/timer.c >> > > > create mode 100644 drivers/clocksource/vt8500_timer.c >> > > > create mode 100644 include/linux/vt8500_timer.h >> > > >> > > Darn.. forgot the -m again. I'll await your feedback regarding the >> > > basing of the patch first (and any other feedback), then I'll redo it >> > > with the correct stats. >> > > >> > > Regards >> > > Tony P >> > >> > Oh grr.. forget this completely. It doesn't take into account the >> > patches I already sent for WM8850. >> > >> > I guess it needs to be based on timer/cleanup + vt8500/wm8x50. >> > >> > Need a little advise on how to handle this one please :) >> >> The normal way to handle these kind of dependencies is to base them on merges >> of the needed branches. Based on the later email, you only seem to need >> timer/cleanup, but if you would have needed the other one, then you'd merge >> that on top of timer/cleanup, and then add your patches. >> >> Of course, ideally you would do the cleanup, then add the wm8x50 features, >> but in reality work doesn't always pan out that way, so you end up with >> cleanups that depend on including new features in the same (sweeping) >> cleanup since they have already been merged. That's when things sometimes >> get hairy, and we need to start a second cleanup branch that's "after" >> the feature branch in the sequence of topics. But it should be rare, >> and in your case it seems like it wasn't needed. >> >> >> -Olof >> > > Just to clarify what I did (and to make sure it was as you understood > it): > > #1) I wrote the patch on top of timer/cleanup. This is the branch the > patch was written for. > > #2) I then pulled timer/cleanup and merged vt8500/wm8x50 on top, then > reapplied the patch from #1 - it applied cleanly. > > What I have just realised is that you might?? get a conflict when you > merge vt8500/wm8x50 on top of wherever this patch ends up due to the few > lines at the top of arch-vt8500/Kconfig having changed (the addition of > SELECT VT8500_TIMER). This should be trivial to fix (I assume). Yeah, a couple of trivial conflicts are fine, but when they start to stack up we normally have to push back since some of these are exposed all the way up to Linus. We can also be a little more strategic in how we chose to pick bases for the topic branches to avoid some of this, which is what I intend to do this release cycle if it pans out. In this case, there are no manual conflict resolution to be done, everything panned out just fine as it was. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] timer: vt8500: Move timer code to drivers/clocksource
On Mon, Jan 14, 2013 at 8:53 PM, Tony Prisk wrote: > On Mon, 2013-01-14 at 09:34 -0700, Stephen Warren wrote: >> On 01/13/2013 10:09 PM, Tony Prisk wrote: >> > This patch moves arch-vt8500/timer.c into drivers/clocksource and >> > updates the necessary Kconfig/Makefile options. >> >> > diff --git a/include/linux/vt8500_timer.h b/include/linux/vt8500_timer.h >> >> > +#ifndef __VT8500_TIMER_H >> > +#define __VT8500_TIMER_H >> > + >> > +#include >> > + >> > +void vt8500_timer_init(void); >> > + >> > +#endif >> >> Is VT8500 DT-only? If so, it'd be nice not to add this header, but >> instead use CLOCKSOURCE_OF_DECLARE() inside the driver C file. > > Agreed - I didn't like the header when I added it but I didn't know of > another way and based in on the sunxi code. > > Unfortunately Olof already pulled it into arm-soc, so I will try get > another patch done to undo it :) Ack, I saw the comments but somehow blanked when it came to pulling it. Incremental patches on top are fine though. Sorry Stephen, I didn't mean to ignore your comments. :) -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] usbnet: dm9601: Fix incorrect command
commit 24b1042c4eb2 ("usbnet: dm9601: apply introduced usb command
APIs") removes the distiction between DM_WRITE_REG and DM_WRITE_REGS
command. The distiction is reintroduced to the driver so that the
functionality of the driver remains same.
CC: Ming Lei
Signed-off-by: Tushar Behera
---
drivers/net/usb/dm9601.c | 22 ++
1 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/net/usb/dm9601.c b/drivers/net/usb/dm9601.c
index 3f554c1..011410f 100644
--- a/drivers/net/usb/dm9601.c
+++ b/drivers/net/usb/dm9601.c
@@ -53,7 +53,6 @@
#define DM_RX_OVERHEAD 7 /* 3 byte header + 4 byte crc tail */
#define DM_TIMEOUT 1000
-
static int dm_read(struct usbnet *dev, u8 reg, u16 length, void *data)
{
int err;
@@ -84,32 +83,23 @@ static int dm_write(struct usbnet *dev, u8 reg, u16 length,
void *data)
static int dm_write_reg(struct usbnet *dev, u8 reg, u8 value)
{
- return usbnet_write_cmd(dev, DM_WRITE_REGS,
+ return usbnet_write_cmd(dev, DM_WRITE_REG,
USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
value, reg, NULL, 0);
}
-static void dm_write_async_helper(struct usbnet *dev, u8 reg, u8 value,
- u16 length, void *data)
+static void dm_write_async(struct usbnet *dev, u8 reg, u16 length, void *data)
{
usbnet_write_cmd_async(dev, DM_WRITE_REGS,
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- value, reg, data, length);
-}
-
-static void dm_write_async(struct usbnet *dev, u8 reg, u16 length, void *data)
-{
- netdev_dbg(dev->net, "dm_write_async() reg=0x%02x length=%d\n", reg,
length);
-
- dm_write_async_helper(dev, reg, 0, length, data);
+ 0, reg, data, length);
}
static void dm_write_reg_async(struct usbnet *dev, u8 reg, u8 value)
{
- netdev_dbg(dev->net, "dm_write_reg_async() reg=0x%02x value=0x%02x\n",
- reg, value);
-
- dm_write_async_helper(dev, reg, value, 0, NULL);
+ usbnet_write_cmd_async(dev, DM_WRITE_REG,
+ USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ value, reg, NULL, 0);
}
static int dm_read_shared_word(struct usbnet *dev, int phy, u8 reg, __le16
*value)
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] block: Optionally snapshot page contents to provide stable pages during write
This provides a band-aid to provide stable page writes on jbd without needing
to backport the fixed locking and page writeback bit handling schemes of jbd2.
The band-aid works by using bounce buffers to snapshot page contents instead of
waiting.
For those wondering about the ext3 bandage -- fixing the jbd locking (which was
done as part of ext4dev years ago) is a lot of surgery, and setting
PG_writeback on data pages when we actually hold the page lock dropped ext3
performance by nearly an order of magnitude. If we're going to migrate iscsi
and raid to use stable page writes, the complaints about high latency will
likely return. We might as well centralize their page snapshotting thing to
one place.
Tested-by: Andy Lutomirski
Signed-off-by: Darrick J. Wong
---
arch/tile/Kconfig |6 --
block/blk-core.c|8 +---
fs/ext3/super.c |1 +
include/uapi/linux/fs.h |1 +
mm/Kconfig | 13 +
mm/bounce.c | 47 +++
mm/page-writeback.c |4
7 files changed, 67 insertions(+), 13 deletions(-)
diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig
index 875d008..c671fda 100644
--- a/arch/tile/Kconfig
+++ b/arch/tile/Kconfig
@@ -410,12 +410,6 @@ config TILE_USB
Provides USB host adapter support for the built-in EHCI and OHCI
interfaces on TILE-Gx chips.
-# USB OHCI needs the bounce pool since tilegx will often have more
-# than 4GB of memory, but we don't currently use the IOTLB to present
-# a 32-bit address to OHCI. So we need to use a bounce pool instead.
-config NEED_BOUNCE_POOL
- def_bool USB_OHCI_HCD
-
source "drivers/pci/hotplug/Kconfig"
endmenu
diff --git a/block/blk-core.c b/block/blk-core.c
index c973249..277134c 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1474,6 +1474,11 @@ void blk_queue_bio(struct request_queue *q, struct bio
*bio)
*/
blk_queue_bounce(q, &bio);
+ if (bio_integrity_enabled(bio) && bio_integrity_prep(bio)) {
+ bio_endio(bio, -EIO);
+ return;
+ }
+
if (bio->bi_rw & (REQ_FLUSH | REQ_FUA)) {
spin_lock_irq(q->queue_lock);
where = ELEVATOR_INSERT_FLUSH;
@@ -1714,9 +1719,6 @@ generic_make_request_checks(struct bio *bio)
*/
blk_partition_remap(bio);
- if (bio_integrity_enabled(bio) && bio_integrity_prep(bio))
- goto end_io;
-
if (bio_check_eod(bio, nr_sectors))
goto end_io;
diff --git a/fs/ext3/super.c b/fs/ext3/super.c
index 6e50223..4ba2683 100644
--- a/fs/ext3/super.c
+++ b/fs/ext3/super.c
@@ -2065,6 +2065,7 @@ static int ext3_fill_super (struct super_block *sb, void
*data, int silent)
test_opt(sb,DATA_FLAGS) == EXT3_MOUNT_JOURNAL_DATA ? "journal":
test_opt(sb,DATA_FLAGS) == EXT3_MOUNT_ORDERED_DATA ? "ordered":
"writeback");
+ sb->s_flags |= MS_SNAP_STABLE;
return 0;
diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index 780d4c6..0144fbb 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -69,6 +69,7 @@ struct inodes_stat_t {
#define MS_REMOUNT 32 /* Alter flags of a mounted FS */
#define MS_MANDLOCK64 /* Allow mandatory locks on an FS */
#define MS_DIRSYNC 128 /* Directory modifications are synchronous */
+#define MS_SNAP_STABLE 256 /* Snapshot pages during writeback, if needed */
#define MS_NOATIME 1024/* Do not update access times. */
#define MS_NODIRATIME 2048/* Do not update directory access times */
#define MS_BIND4096
diff --git a/mm/Kconfig b/mm/Kconfig
index 278e3ab..7901d83 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -258,6 +258,19 @@ config BOUNCE
def_bool y
depends on BLOCK && MMU && (ZONE_DMA || HIGHMEM)
+# On the 'tile' arch, USB OHCI needs the bounce pool since tilegx will often
+# have more than 4GB of memory, but we don't currently use the IOTLB to present
+# a 32-bit address to OHCI. So we need to use a bounce pool instead.
+#
+# We also use the bounce pool to provide stable page writes for jbd. jbd
+# initiates buffer writeback without locking the page or setting PG_writeback,
+# and fixing that behavior (a second time; jbd2 doesn't have this problem) is
+# a major rework effort. Instead, use the bounce buffer to snapshot pages
+# (until jbd goes away). The only jbd user is ext3.
+config NEED_BOUNCE_POOL
+ bool
+ default y if (TILE && USB_OHCI_HCD) || (BLK_DEV_INTEGRITY && JBD)
+
config NR_QUICK
int
depends on QUICKLIST
diff --git a/mm/bounce.c b/mm/bounce.c
index 0420867..a5b30f9 100644
--- a/mm/bounce.c
+++ b/mm/bounce.c
@@ -178,8 +178,44 @@ static void bounce_end_io_read_isa(struct bio *bio, int
err)
__bounce_end_io_read(bio, isa_page_pool, err);
}
+#ifdef CONFIG_NEED_BOUNCE_POOL
+static int must_snapshot_
[PATCH 6/6] ubifs: Wait for page writeback to provide stable pages
When stable pages are required, we have to wait if the page is just going to disk and we want to modify it. Add proper callback to ubifs_vm_page_mkwrite(). CC: Artem Bityutskiy From: Jan Kara CC: Adrian Hunter CC: linux-...@lists.infradead.org Signed-off-by: Jan Kara --- fs/ubifs/file.c |1 + 1 file changed, 1 insertion(+) diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c index 5bc7781..4f6493c 100644 --- a/fs/ubifs/file.c +++ b/fs/ubifs/file.c @@ -1522,6 +1522,7 @@ static int ubifs_vm_page_mkwrite(struct vm_area_struct *vma, ubifs_release_dirty_inode_budget(c, ui); } + wait_for_stable_page(page); unlock_page(page); return 0; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] bdi: Allow block devices to say that they require stable page writes
This creates a per-backing-device flag that tracks whether or not pages must be
held immutable during writeout. Eventually it will be used to waive
wait_for_page_writeback() if nothing requires stable pages.
Reviewed-by: Jan Kara
Signed-off-by: Darrick J. Wong
---
Documentation/ABI/testing/sysfs-class-bdi |5 +
block/blk-integrity.c |4
include/linux/backing-dev.h |6 ++
mm/backing-dev.c | 11 +++
4 files changed, 26 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-class-bdi
b/Documentation/ABI/testing/sysfs-class-bdi
index 5f50097..d773d56 100644
--- a/Documentation/ABI/testing/sysfs-class-bdi
+++ b/Documentation/ABI/testing/sysfs-class-bdi
@@ -48,3 +48,8 @@ max_ratio (read-write)
most of the write-back cache. For example in case of an NFS
mount that is prone to get stuck, or a FUSE mount which cannot
be trusted to play fair.
+
+stable_pages_required (read-only)
+
+ If set, the backing device requires that all pages comprising a write
+ request must not be changed until writeout is complete.
diff --git a/block/blk-integrity.c b/block/blk-integrity.c
index da2a818..dabd221 100644
--- a/block/blk-integrity.c
+++ b/block/blk-integrity.c
@@ -420,6 +420,8 @@ int blk_integrity_register(struct gendisk *disk, struct
blk_integrity *template)
} else
bi->name = bi_unsupported_name;
+ disk->queue->backing_dev_info.capabilities |= BDI_CAP_STABLE_WRITES;
+
return 0;
}
EXPORT_SYMBOL(blk_integrity_register);
@@ -438,6 +440,8 @@ void blk_integrity_unregister(struct gendisk *disk)
if (!disk || !disk->integrity)
return;
+ disk->queue->backing_dev_info.capabilities &= ~BDI_CAP_STABLE_WRITES;
+
bi = disk->integrity;
kobject_uevent(&bi->kobj, KOBJ_REMOVE);
diff --git a/include/linux/backing-dev.h b/include/linux/backing-dev.h
index 12731a1..3504599 100644
--- a/include/linux/backing-dev.h
+++ b/include/linux/backing-dev.h
@@ -254,6 +254,7 @@ int bdi_set_max_ratio(struct backing_dev_info *bdi,
unsigned int max_ratio);
#define BDI_CAP_EXEC_MAP 0x0040
#define BDI_CAP_NO_ACCT_WB 0x0080
#define BDI_CAP_SWAP_BACKED0x0100
+#define BDI_CAP_STABLE_WRITES 0x0200
#define BDI_CAP_VMFLAGS \
(BDI_CAP_READ_MAP | BDI_CAP_WRITE_MAP | BDI_CAP_EXEC_MAP)
@@ -308,6 +309,11 @@ long wait_iff_congested(struct zone *zone, int sync, long
timeout);
int pdflush_proc_obsolete(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos);
+static inline bool bdi_cap_stable_pages_required(struct backing_dev_info *bdi)
+{
+ return bdi->capabilities & BDI_CAP_STABLE_WRITES;
+}
+
static inline bool bdi_cap_writeback_dirty(struct backing_dev_info *bdi)
{
return !(bdi->capabilities & BDI_CAP_NO_WRITEBACK);
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index d3ca2b3..41733c5 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -221,12 +221,23 @@ static ssize_t max_ratio_store(struct device *dev,
}
BDI_SHOW(max_ratio, bdi->max_ratio)
+static ssize_t stable_pages_required_show(struct device *dev,
+ struct device_attribute *attr,
+ char *page)
+{
+ struct backing_dev_info *bdi = dev_get_drvdata(dev);
+
+ return snprintf(page, PAGE_SIZE-1, "%d\n",
+ bdi_cap_stable_pages_required(bdi) ? 1 : 0);
+}
+
#define __ATTR_RW(attr) __ATTR(attr, 0644, attr##_show, attr##_store)
static struct device_attribute bdi_dev_attrs[] = {
__ATTR_RW(read_ahead_kb),
__ATTR_RW(min_ratio),
__ATTR_RW(max_ratio),
+ __ATTR_RO(stable_pages_required),
__ATTR_NULL,
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] 9pfs: Fix filesystem to wait for stable page writeback
Fix up the ->page_mkwrite handler to provide stable page writes if necessary. Signed-off-by: Darrick J. Wong --- fs/9p/vfs_file.c |1 + 1 file changed, 1 insertion(+) diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c index c2483e9..357260b 100644 --- a/fs/9p/vfs_file.c +++ b/fs/9p/vfs_file.c @@ -620,6 +620,7 @@ v9fs_vm_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf) lock_page(page); if (page->mapping != inode->i_mapping) goto out_unlock; + wait_for_stable_page(page); return VM_FAULT_LOCKED; out_unlock: -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 5/6] ocfs2: Wait for page writeback to provide stable pages
When stable pages are required, we have to wait if the page is just going to disk and we want to modify it. Add proper callback to ocfs2_grab_pages_for_write(). CC: ocfs2-de...@oss.oracle.com CC: Joel Becker CC: Mark Fasheh From: Jan Kara Signed-off-by: Jan Kara --- fs/ocfs2/aops.c |1 + 1 file changed, 1 insertion(+) diff --git a/fs/ocfs2/aops.c b/fs/ocfs2/aops.c index 6577432..9796330 100644 --- a/fs/ocfs2/aops.c +++ b/fs/ocfs2/aops.c @@ -1194,6 +1194,7 @@ static int ocfs2_grab_pages_for_write(struct address_space *mapping, goto out; } } + wait_for_stable_page(wc->w_pages[i]); if (index == target_index) wc->w_target_page = wc->w_pages[i]; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 0/3] mm/fs: Remove unnecessary waiting for stable pages
Hi all,
This patchset ("stable page writes, part 2") makes some key modifications to
the original 'stable page writes' patchset. First, it provides creators
(devices and filesystems) of a backing_dev_info a flag that declares whether or
not it is necessary to ensure that page contents cannot change during writeout.
It is no longer assumed that this is true of all devices (which was never true
anyway). Second, the flag is used to relaxed the wait_on_page_writeback calls
so that wait only occurs if the device needs it. Third, it fixes up the
remaining disk-backed filesystems to use this improved conditional-wait logic
to provide stable page writes on those filesystems.
It is hoped that (for people not using checksumming devices, anyway) this
patchset will give back unnecessary performance decreases since the original
stable page write patchset went into 3.0. Sorry about not fixing it sooner.
Complaints were registered by several people about the long write latencies
introduced by the original stable page write patchset. Generally speaking, the
kernel ought to allocate as little extra memory as possible to facilitate
writeout, but for people who simply cannot wait, a second page stability
strategy is (re)introduced: snapshotting page contents. The waiting behavior
is still the default strategy; to enable page snapshotting, a superblock flag
(MS_SNAP_STABLE) must be set. This flag is used to bandaid^Henable stable page
writeback on ext3[1], and is not used anywhere else.
Given that there are already a few storage devices and network FSes that have
rolled their own page stability wait/page snapshot code, it would be nice to
move towards consolidating all of these. It seems possible that iscsi and
raid5 may wish to use the new stable page write support to enable zero-copy
writeout.
Thank you to Jan Kara for helping fix a couple more filesystems.
This patchset has been tested on 3.8.0-rc3 on x64 with ext3, ext4, and xfs.
What does everyone think about queueing this for 3.9?
--D
[1] The alternative fixes to ext3 include fixing the locking order and page bit
handling like we did for ext4 (but then why not just use ext4?), or setting
PG_writeback so early that ext3 becomes extremely slow. I tried that, but the
number of write()s I could initiate dropped by nearly an order of magnitude.
That was a bit much even for the author of the stable page series! :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] mm: Only enforce stable page writes if the backing device requires it
Create a helper function to check if a backing device requires stable page
writes and, if so, performs the necessary wait. Then, make it so that all
points in the memory manager that handle making pages writable use the helper
function. This should provide stable page write support to most filesystems,
while eliminating unnecessary waiting for devices that don't require the
feature.
Signed-off-by: Darrick J. Wong
---
fs/buffer.c |2 +-
fs/ext4/inode.c |2 +-
fs/gfs2/file.c |2 +-
fs/nilfs2/file.c|2 +-
include/linux/pagemap.h |1 +
mm/filemap.c|3 ++-
mm/page-writeback.c | 20
7 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index c017a2d..2981449 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -2359,7 +2359,7 @@ int __block_page_mkwrite(struct vm_area_struct *vma,
struct vm_fault *vmf,
if (unlikely(ret < 0))
goto out_unlock;
set_page_dirty(page);
- wait_on_page_writeback(page);
+ wait_for_stable_page(page);
return 0;
out_unlock:
unlock_page(page);
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index cbfe13b..cd818d8b 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -4968,7 +4968,7 @@ int ext4_page_mkwrite(struct vm_area_struct *vma, struct
vm_fault *vmf)
0, len, NULL,
ext4_bh_unmapped)) {
/* Wait so that we don't change page under IO */
- wait_on_page_writeback(page);
+ wait_for_stable_page(page);
ret = VM_FAULT_LOCKED;
goto out;
}
diff --git a/fs/gfs2/file.c b/fs/gfs2/file.c
index 991ab2d..b9e0ca2 100644
--- a/fs/gfs2/file.c
+++ b/fs/gfs2/file.c
@@ -483,7 +483,7 @@ out:
gfs2_holder_uninit(&gh);
if (ret == 0) {
set_page_dirty(page);
- wait_on_page_writeback(page);
+ wait_for_stable_page(page);
}
sb_end_pagefault(inode->i_sb);
return block_page_mkwrite_return(ret);
diff --git a/fs/nilfs2/file.c b/fs/nilfs2/file.c
index 6194688..bec4af6 100644
--- a/fs/nilfs2/file.c
+++ b/fs/nilfs2/file.c
@@ -126,7 +126,7 @@ static int nilfs_page_mkwrite(struct vm_area_struct *vma,
struct vm_fault *vmf)
nilfs_transaction_commit(inode->i_sb);
mapped:
- wait_on_page_writeback(page);
+ wait_for_stable_page(page);
out:
sb_end_pagefault(inode->i_sb);
return block_page_mkwrite_return(ret);
diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
index 6da609d..0e38e13 100644
--- a/include/linux/pagemap.h
+++ b/include/linux/pagemap.h
@@ -414,6 +414,7 @@ static inline void wait_on_page_writeback(struct page *page)
}
extern void end_page_writeback(struct page *page);
+void wait_for_stable_page(struct page *page);
/*
* Add an arbitrary waiter to a page's wait queue
diff --git a/mm/filemap.c b/mm/filemap.c
index 83efee7..5577dc8 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1728,6 +1728,7 @@ int filemap_page_mkwrite(struct vm_area_struct *vma,
struct vm_fault *vmf)
* see the dirty page and writeprotect it again.
*/
set_page_dirty(page);
+ wait_for_stable_page(page);
out:
sb_end_pagefault(inode->i_sb);
return ret;
@@ -2274,7 +2275,7 @@ repeat:
return NULL;
}
found:
- wait_on_page_writeback(page);
+ wait_for_stable_page(page);
return page;
}
EXPORT_SYMBOL(grab_cache_page_write_begin);
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 0713bfb..9c5af4d 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -2289,3 +2289,23 @@ int mapping_tagged(struct address_space *mapping, int
tag)
return radix_tree_tagged(&mapping->page_tree, tag);
}
EXPORT_SYMBOL(mapping_tagged);
+
+/**
+ * wait_for_stable_page() - wait for writeback to finish, if necessary.
+ * @page: The page to wait on.
+ *
+ * This function determines if the given page is related to a backing device
+ * that requires page contents to be held stable during writeback. If so, then
+ * it will wait for any pending writeback to complete.
+ */
+void wait_for_stable_page(struct page *page)
+{
+ struct address_space *mapping = page_mapping(page);
+ struct backing_dev_info *bdi = mapping->backing_dev_info;
+
+ if (!bdi_cap_stable_pages_required(bdi))
+ return;
+
+ wait_on_page_writeback(page);
+}
+EXPORT_SYMBOL_GPL(wait_for_stable_page);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] usb: phy: samsung: Add support to set pmu isolation
Hi Doug,
On Tue, Jan 15, 2013 at 3:41 AM, Doug Anderson wrote:
> Vivek,
>
> Sorry for being so absent from these reviews. I'll try to look over a
> few patches today, but please don't hold up anything on account of my
> reviews. I'm definitely a bit of an interested bystander in USB land.
> ;)
>
> In general things look pretty good here. :) One last comment below...
>
> On Fri, Jan 11, 2013 at 12:08 AM, Vivek Gautam
> wrote:> +static int
> samsung_usbphy_parse_dt(struct samsung_usbphy *sphy)
>> +{
>> + struct device_node *usbphy_sys;
>> +
>> + /* Getting node for system controller interface for usb-phy */
>> + usbphy_sys = of_get_child_by_name(sphy->dev->of_node, "usbphy-sys");
>> + if (!usbphy_sys)
>> + dev_warn(sphy->dev, "No sys-controller interface for
>> usb-phy\n");
>
> Seems like you ought to return with an error here. Calling of_iomap()
> with a NULL value seems undesirable.
>
Yeah, true. This should have been returning error value alongwith dev_err().
>> +
>> + sphy->pmuregs = of_iomap(usbphy_sys, 0);
>> +
>> + of_node_put(usbphy_sys);
>> +
>> + if (sphy->pmuregs == NULL) {
>> + dev_err(sphy->dev, "Can't get usb-phy pmu control
>> register\n");
>> + return -ENODEV;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +/*
>> + * Set isolation here for phy.
>> + * Here 'on = true' would mean USB PHY block is isolated, hence
>> + * de-activated and vice-versa.
>> + */
>
> Thank you very much for this comment. :) This explains one of the
> confusions I had earlier...
>
Your welcome :-)
>
> Once you fix the one error condition above you can add my
> "Reviewed-by". Thanks!
>
Sure, thanks !!
--
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: cpuset: lockdep spew on proc_cpuset_show
On 2013/1/15 10:47, Sasha Levin wrote:
> Hi Tejun,
>
> I've stumbled on the following:
>
> [ 75.972016] ===
> [ 75.977317] [ INFO: suspicious RCU usage. ]
> [ 76.041031] 3.8.0-rc3-next-20130114-sasha-00016-ga107525-dirty #262
> Tainted: GW
> [ 76.057535] ---
> [ 76.063397] include/linux/cgroup.h:534 suspicious rcu_dereference_check()
> usage!
> [ 76.076333]
> [ 76.076333] other info that might help us debug this:
> [ 76.076333]
> [ 76.087091]
> [ 76.087091] rcu_scheduler_active = 1, debug_locks = 1
> [ 76.098682] 2 locks held by trinity/7514:
> [ 76.104154] #0: (&p->lock){+.+.+.}, at: []
> seq_read+0x3a/0x3e0
> [ 76.119533] #1: (cpuset_mutex){+.+...}, at: []
> proc_cpuset_show+0x84/0x190
> [ 76.151167]
> [ 76.151167] stack backtrace:
> [ 76.156853] Pid: 7514, comm: trinity Tainted: GW
> 3.8.0-rc3-next-20130114-sasha-00016-ga107525-dirty #262
> [ 76.180547] Call Trace:
> [ 76.183754] [] lockdep_rcu_suspicious+0x10b/0x120
> [ 76.191885] [] proc_cpuset_show+0x111/0x190
> [ 76.200572] [] seq_read+0x1b7/0x3e0
> [ 76.206843] [] ? seq_lseek+0x110/0x110
> [ 76.213562] [] do_loop_readv_writev+0x4b/0x90
> [ 76.220961] [] do_readv_writev+0xf6/0x1d0
> [ 76.227940] [] vfs_readv+0x3e/0x60
> [ 76.235971] [] sys_readv+0x50/0xd0
> [ 76.241945] [] tracesys+0xe1/0xe6
>
> This is the result of "cpuset: replace cgroup_mutex locking with cpuset
> internal locking"
> which remove the cgroup_lock() before calling task_subsys_state(), which now
> complains since
> one of the debug conditions in the rcu_dereference_check() there is
> cgroup_lock_is_held().
>
> I'm not sure if this is an actual issue, but I do see that
> task_subsys_state() gets called
> from other places as well, so I think that possibly lockdep is right here and
> we do need
> to fix up locking there, but again, I'm not sure...
>
I've prepared a fix.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [dgrp_register_proc] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
On Tue, Jan 15, 2013 at 12:10 AM, Fengguang Wu wrote:
> 7b6d45c211a401a9bdeebfa96f8a4c811bd3eeaf is the first bad commit
>
> commit 7b6d45c211a401a9bdeebfa96f8a4c811bd3eeaf
> Author: Bill Pemberton
> Date: Thu Sep 20 16:55:28 2012 -0400
>
> staging: dgrp: add dgrp to the build
>
> Kconfig and Makefile changes to add dgrp to the build system.
>
> Signed-off-by: Bill Pemberton
> Signed-off-by: Greg Kroah-Hartman
>
> [7.904899] i2c-core: driver [isl29018] registered
> [7.906424] i2c-core: driver [tsl2583] registered
> [7.908289] BUG: unable to handle kernel NULL pointer dereference at
> 0040
> [7.909055] IP: [] register_proc_table+0xe0/0x26f
> [7.909055] PGD 0
> [7.909055] Oops: [#1] SMP
> [7.909055] CPU 0
> [7.909055] Pid: 1, comm: swapper/0 Not tainted 3.8.0-rc3-00051-gc83dcb9
> #16
> [7.909055] RIP: 0010:[] []
> register_proc_table+0xe0/0x26f
> [7.909055] RSP: :88000d0c1e78 EFLAGS: 00010246
> [7.909055] RAX: 0003 RBX: RCX:
> 0003
> [7.909055] RDX: 0002 RSI: RDI:
> 81989648
> [7.909055] RBP: 88000d0c1eb8 R08: R09:
>
> [7.909055] R10: 88000f4fed68 R11: 88000f4fecb8 R12:
> 81a9f008
> [7.909055] R13: R14: 82b3a710 R15:
> 81989644
> [7.909055] FS: () GS:88000da0()
> knlGS:
> [7.909055] CS: 0010 DS: ES: CR0: 8005003b
> [7.909055] CR2: 0040 CR3: 019a4000 CR4:
> 06f0
> [7.909055] DR0: DR1: DR2:
>
> [7.927424] tsc: Refined TSC clocksource calibration: 2666.662 MHz
>
> Thanks,
> Fengguang
Hello Fengguang,
Will you try the patch below please...
diff --git a/drivers/staging/dgrp/dgrp_specproc.c
b/drivers/staging/dgrp/dgrp_specproc.c
index c214078..f5845a7 100644
--- a/drivers/staging/dgrp/dgrp_specproc.c
+++ b/drivers/staging/dgrp/dgrp_specproc.c
@@ -231,6 +231,8 @@ static void register_proc_table(struct
dgrp_proc_entry *table,
if (table == NULL)
return;
+ if (root == NULL)
+ return;
for (; table->id; table++) {
/* Can't do anything without a proc name. */
Applies on current linus's head at 406089d01562f1e2bf9f089fd7637009ebaad589.
I am thinking of the case where you dont have any proc entry.
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 0/3] x86: enable common clk and add support for Lynxpoint clocks
On Mon, Jan 14, 2013 at 04:46:25PM +0200, Mika Westerberg wrote: > Hi all, > > The discussion that lead to this patch series starts from the below thread: > > http://thread.gmane.org/gmane.linux.kernel/1417691 > > In summary, there is no point in adding a special case code to the drivers > in order to pass them a fixed clock rate, but instead x86 should just > enable common clk subsystem and take advantage of it. > > This has been proposed before by Mark Brown but for some reason it has not > merged into x86 tree. > > This series tries to do the same but in this time we have real users for > the clk API. > > [1/3] Enables the common clk framework on x86 > [2/3] Adds Intel Lynxpoint Low Power Subsystem specific clocks as platform > driver. > [3/3] Creates the platform device for the LPSS clocks driver if we find out > that the Lynxpoint LPSS devices are available. > > This series is based on Rafael's linux-pm/linux-next branch because there > is a dependency to the ACPI scan rework by Rafael. I meant that they apply on top of 3.8-rcX but in order to patch [2/3] to work it needs to have the ACPI scan rework patches. Otherwise it is not able to find the base addresses of the devices. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] gpio: vt8500: memory cleanup missing
On Tue, 2013-01-15 at 07:37 +1300, Tony Prisk wrote: > This driver is missing a .remove callback, and the fail path on > probe is incomplete. > > If an error occurs in vt8500_add_chips, gpio_base is not unmapped. > The driver is also ignoring the return value from this function so > if a chip fails to register it completes as successful. > > Replaced pr_err with dev_err in vt8500_add_chips since the device is > available. > > There is also no .remove callback defined. To allow removing the > registered chips, I have moved *vtchip to be a static global. > > Signed-off-by: Tony Prisk > --- > Hi Grant, > > Let me know what you think of these changes. > > v2: > Removed unnecessary whitespace change. > Removed test against pdev->dev.of_node (np). Replaced code with a > devm_request_and_ioremap so np is now unneccessary. This also removes the > need > for cleanup in the fail path. > Move struct vt8500_gpio_chip within vt8500_data and store the iobase and > num_banks in vt8500_data. > Grant, If there are no further changes for this patch, would you mind correcting the commit message when you merge it? -There is also no .remove callback defined. To allow removing the -Registered chips, I have moved *vtchip to be a static global. + There is also no .remove callback defined. Otherwise, I will fix it along with whatever other comments come in. Regards Tony P -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/4] serial: vt8500: ioremap'd resource is never freed
On Tue, 2013-01-15 at 17:58 +1300, Tony Prisk wrote: > Memory mapped via ioremap call is never released. Rather than add an > iounmap call, change allocation function to devm_request_and_ioremap. > > Also, change the error on failure for this call to -EBUSY rather than > -EADDRNOTAVAIL. Grr.. I thought I fixed this typo before I sent the patch. I'll send another version but I'll wait for feedback on the series first. Regards Tony P -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] serial: vt8500: UART uses gated clock rather than 24Mhz reference
UART modules on Wondermedia SoCs are connected via a gated clock
source, rather than directly to the 24Mhz reference clock. While
uboot enables UART0 for debugging, other UART ports are unavailable
until the clock is enabled.
This patch checks that a valid clock is actually passed from devicetree,
enables the clock in probe. This change removes the fallback when a
clock was not specified as it doesn't apply any longer (and would only
work if the UART clock was already enabled).
DTSI files are updated for VT8500, WM8505 and WM8650.
Signed-off-by: Tony Prisk
---
arch/arm/boot/dts/vt8500.dtsi | 40 +---
arch/arm/boot/dts/wm8505.dtsi | 60
arch/arm/boot/dts/wm8650.dtsi | 20 ++--
drivers/tty/serial/vt8500_serial.c | 34 +++-
4 files changed, 127 insertions(+), 27 deletions(-)
diff --git a/arch/arm/boot/dts/vt8500.dtsi b/arch/arm/boot/dts/vt8500.dtsi
index d8645e9..cf31ced 100644
--- a/arch/arm/boot/dts/vt8500.dtsi
+++ b/arch/arm/boot/dts/vt8500.dtsi
@@ -45,6 +45,38 @@
compatible = "fixed-clock";
clock-frequency = <2400>;
};
+
+ clkuart0: uart0 {
+ #clock-cells = <0>;
+ compatible = "via,vt8500-device-clock";
+ clocks = <&ref24>;
+ enable-reg = <0x250>;
+ enable-bit = <1>;
+ };
+
+ clkuart1: uart1 {
+ #clock-cells = <0>;
+ compatible = "via,vt8500-device-clock";
+ clocks = <&ref24>;
+ enable-reg = <0x250>;
+ enable-bit = <2>;
+ };
+
+ clkuart2: uart2 {
+ #clock-cells = <0>;
+ compatible = "via,vt8500-device-clock";
+ clocks = <&ref24>;
+ enable-reg = <0x250>;
+ enable-bit = <3>;
+ };
+
+ clkuart3: uart3 {
+ #clock-cells = <0>;
+ compatible = "via,vt8500-device-clock";
+ clocks = <&ref24>;
+ enable-reg = <0x250>;
+ enable-bit = <4>;
+ };
};
};
@@ -83,28 +115,28 @@
compatible = "via,vt8500-uart";
reg = <0xd820 0x1040>;
interrupts = <32>;
- clocks = <&ref24>;
+ clocks = <&clkuart0>;
};
uart@d82b {
compatible = "via,vt8500-uart";
reg = <0xd82b 0x1040>;
interrupts = <33>;
- clocks = <&ref24>;
+ clocks = <&clkuart1>;
};
uart@d821 {
compatible = "via,vt8500-uart";
reg = <0xd821 0x1040>;
interrupts = <47>;
- clocks = <&ref24>;
+ clocks = <&clkuart2>;
};
uart@d82c {
compatible = "via,vt8500-uart";
reg = <0xd82c 0x1040>;
interrupts = <50>;
- clocks = <&ref24>;
+ clocks = <&clkuart3>;
};
rtc@d810 {
diff --git a/arch/arm/boot/dts/wm8505.dtsi b/arch/arm/boot/dts/wm8505.dtsi
index 330f833..e74a1c0 100644
--- a/arch/arm/boot/dts/wm8505.dtsi
+++ b/arch/arm/boot/dts/wm8505.dtsi
@@ -59,6 +59,54 @@
compatible = "fixed-clock";
clock-frequency = <2400>;
};
+
+ clkuart0: uart0 {
+ #clock-cells = <0>;
+ compatible = "via,vt8500-device-clock";
+ clocks = <&ref24>;
+ enable-reg = <0x250>;
+ enable-bit = <1>;
+ };
+
+ clkuart1: uart1 {
+ #clock-cel
[PATCH 4/4] serial: tty: Cleanup code using devm_ function
Convert the last memory allocation (vt8500_port) to use devm_kzalloc
and remove the fail path cleanup code from vt8500_serial_probe.
Reorder iomem mapping above clk_enable to simplify fail code. The
clock is only enabled if all other resources are available.
Signed-off-by: Tony Prisk
---
drivers/tty/serial/vt8500_serial.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/vt8500_serial.c
b/drivers/tty/serial/vt8500_serial.c
index 7f9e578..1fc6f3d 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -589,7 +589,8 @@ static int vt8500_serial_probe(struct platform_device *pdev)
return -EBUSY;
}
- vt8500_port = kzalloc(sizeof(struct vt8500_port), GFP_KERNEL);
+ vt8500_port = devm_kzalloc(&pdev->dev, sizeof(struct vt8500_port),
+ GFP_KERNEL);
if (!vt8500_port)
return -ENOMEM;
@@ -600,14 +601,13 @@ static int vt8500_serial_probe(struct platform_device
*pdev)
vt8500_port->clk = of_clk_get(pdev->dev.of_node, 0);
if (IS_ERR(vt8500_port->clk)) {
dev_err(&pdev->dev, "failed to get clock\n");
- ret = -EINVAL;
- goto err;
+ return -EINVAL;
}
ret = clk_prepare_enable(vt8500_port->clk);
if (ret) {
dev_err(&pdev->dev, "failed to enable clock\n");
- goto err;
+ return ret;
}
vt8500_port->uart.type = PORT_VT8500;
@@ -631,10 +631,6 @@ static int vt8500_serial_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, vt8500_port);
return 0;
-
-err:
- kfree(vt8500_port);
- return ret;
}
static int vt8500_serial_remove(struct platform_device *pdev)
@@ -644,7 +640,6 @@ static int vt8500_serial_remove(struct platform_device
*pdev)
platform_set_drvdata(pdev, NULL);
clk_disable_unprepare(vt8500_port->clk);
uart_remove_one_port(&vt8500_uart_driver, &vt8500_port->uart);
- kfree(vt8500_port);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL v2] Fixes/cleanup for vt8500 serial driver
Hi Greg, This is a series of fixes/cleanup for the vt8500 serial/uart driver. I'm not sure how you want to handle these. Arguably #1, #2 and #3 are bug fixes which could go into 3.8. None of them cause immediate problems, but potentially could. #4 is definately a cleanup for 3.9. Let me know if you would rather I split them up and how. Regards Tony P v2 Changes: Restore the setting of vt8500_port->uart.uartclk which was dropped in v1. Corrected the return-on-fail of devm_request_and_ioremap to -EADDRNOTAVAIL. The following changes since commit 9931faca02c604c22335f5a935a501bb2ace6e20: Linux 3.8-rc3 (2013-01-09 18:59:55 -0800) are available in the git repository at: git://server.prisktech.co.nz/git/linuxwmt.git tags/vt8500-serial-fixes for you to fetch changes up to 08bab1720e19e4f980e9e93536add4a7e497b38e: serial: tty: Cleanup code using devm_ function (2013-01-15 17:36:50 +1300) Series of fixes/cleanups for vt8500 serial/UART driver Tony Prisk (4): serial: vt8500: Fix range-checking on vt8500_uart_ports serial: vt8500: ioremap'd resource is never freed serial: vt8500: UART uses gated clock rather than 24Mhz reference serial: tty: Cleanup code using devm_ function arch/arm/boot/dts/vt8500.dtsi | 40 +--- arch/arm/boot/dts/wm8505.dtsi | 60 arch/arm/boot/dts/wm8650.dtsi | 20 ++-- drivers/tty/serial/vt8500_serial.c | 45 +-- 4 files changed, 130 insertions(+), 35 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] serial: vt8500: Fix range-checking on vt8500_uart_ports
Fix two instances where the index to vt8500_uart_ports is tested against > VT8500_MAX_PORTS. Correct usage should be >= VT8500_MAX_PORTS. Signed-off-by: Tony Prisk --- drivers/tty/serial/vt8500_serial.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/vt8500_serial.c b/drivers/tty/serial/vt8500_serial.c index 8fd1814..4c4a58d 100644 --- a/drivers/tty/serial/vt8500_serial.c +++ b/drivers/tty/serial/vt8500_serial.c @@ -569,7 +569,7 @@ static int vt8500_serial_probe(struct platform_device *pdev) if (np) port = of_alias_get_id(np, "serial"); - if (port > VT8500_MAX_PORTS) + if (port >= VT8500_MAX_PORTS) port = -1; else port = -1; @@ -580,7 +580,7 @@ static int vt8500_serial_probe(struct platform_device *pdev) sizeof(vt8500_ports_in_use)); } - if (port > VT8500_MAX_PORTS) + if (port >= VT8500_MAX_PORTS) return -ENODEV; /* reserve the port id */ -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] serial: vt8500: ioremap'd resource is never freed
Memory mapped via ioremap call is never released. Rather than add an
iounmap call, change allocation function to devm_request_and_ioremap.
Also, change the error on failure for this call to -EBUSY rather than
-EADDRNOTAVAIL.
Signed-off-by: Tony Prisk
---
drivers/tty/serial/vt8500_serial.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/vt8500_serial.c
b/drivers/tty/serial/vt8500_serial.c
index 4c4a58d..3e76dff 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -615,9 +615,9 @@ static int vt8500_serial_probe(struct platform_device *pdev)
snprintf(vt8500_port->name, sizeof(vt8500_port->name),
"VT8500 UART%d", pdev->id);
- vt8500_port->uart.membase = ioremap(mmres->start, resource_size(mmres));
+ vt8500_port->uart.membase = devm_request_and_ioremap(&pdev->dev, mmres);
if (!vt8500_port->uart.membase) {
- ret = -ENOMEM;
+ ret = -EADDRNOTAVAIL;
goto err;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] net: ipv4: refine the logic for determining daddr in ip_queue_xmit.
On Tue, 2013-01-15 at 12:47 +0800, Harvey Yang wrote: > The destination address daddr is faddr if source route option is set, > otherwise it is inet_daddr. So use if-else to assign the value. > > Signed-off-by: Harvey Yang > --- > net/ipv4/ip_output.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c > index 3e98ed2..22b738c 100644 > --- a/net/ipv4/ip_output.c > +++ b/net/ipv4/ip_output.c > @@ -349,10 +349,10 @@ int ip_queue_xmit(struct sk_buff *skb, struct flowi *fl) > __be32 daddr; > > /* Use correct destination address if we have options. */ > - daddr = inet->inet_daddr; > if (inet_opt && inet_opt->opt.srr) > daddr = inet_opt->opt.faddr; > - > + else > + daddr = inet->inet_daddr; > /* If this fails, retransmit mechanism of transport layer will >* keep trying until route appears or the connection times >* itself out. Current code is faster, srr is not often used. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] timer: vt8500: Move timer code to drivers/clocksource
On Mon, 2013-01-14 at 09:34 -0700, Stephen Warren wrote: > On 01/13/2013 10:09 PM, Tony Prisk wrote: > > This patch moves arch-vt8500/timer.c into drivers/clocksource and > > updates the necessary Kconfig/Makefile options. > > > diff --git a/include/linux/vt8500_timer.h b/include/linux/vt8500_timer.h > > > +#ifndef __VT8500_TIMER_H > > +#define __VT8500_TIMER_H > > + > > +#include > > + > > +void vt8500_timer_init(void); > > + > > +#endif > > Is VT8500 DT-only? If so, it'd be nice not to add this header, but > instead use CLOCKSOURCE_OF_DECLARE() inside the driver C file. Agreed - I didn't like the header when I added it but I didn't know of another way and based in on the sunxi code. Unfortunately Olof already pulled it into arm-soc, so I will try get another patch done to undo it :) Regards Tony P -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 0/2] sched: simplify the select_task_rq_fair()
On Tue, 2013-01-15 at 11:10 +0800, Michael Wang wrote: > hanks for the testing, could you please tell me which benchmark > generate these results? aim7, using the compute workfile, and a datapoints file containing $Tasks. multitask -nl -f will prompt for the datapoints file. You'll have to bump /proc/sys/kernel/sem if it's left at default by your distro. If you want, I can send you a tarball offline. > I will try to re-base the patch into 3.8-rc3 with consideration of NUMA > domain, I suppose it could fix the below BUG and provide a better results. I don't _think_ you'll fix the sweet spot without setting knobs such that last_buddy can do its thing, but go for it ;-) -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] net: ipv4: refine the logic for determining daddr in ip_queue_xmit.
From: Harvey Yang Date: Tue, 15 Jan 2013 12:47:35 +0800 > The destination address daddr is faddr if source route option is set, > otherwise it is inet_daddr. So use if-else to assign the value. > > Signed-off-by: Harvey Yang You are changing nothing in how this code behaves. And stylistically I know it was coded this way on purpose, because I'm pretty sure I wrote it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] x86 e820: only void usable memory areas in memmap=exactmap case
On Mon, Jan 14, 2013 at 4:54 PM, Thomas Renninger wrote:
> On Monday, January 14, 2013 11:04:36 AM Yinghai Lu wrote:
>> On Mon, Jan 14, 2013 at 7:05 AM, Thomas Renninger wrote:
>> > What is this for?:
>> > @@ -871,6 +879,11 @@ static int __init parse_memmap_one(char
>> >
>> > userdef = 1;
>> > if (*p == '@') {
>> >
>> > start_at = memparse(p+1, &p);
>> >
>> > + if (exactusablemap_parsed) {
>> > + /* remove all range with other types */
>> > + e820_remove_range(start_at, mem_size,
>> > +E820_RAM, 0);
>> > + }
>> >
>> > e820_add_region(start_at, mem_size, E820_RAM);
>> >
>> > } else if (*p == '#') {
>> >
>> > start_at = memparse(p+1, &p);
>>
>> remove all old renges before add E820_RAM, otherwise new add E820
>> ranges could be ignored.
> But this is intended?
> kexec must never request reserved memory to be used as ordinary E820_RAM
> by the kdump kernel.
> This also reverts what exactusablemap is all about:
> Keep all reserved memory ranges of the original BIOS map.
>
> Above would again wrongly remove the mmconf and other reserved regions
> if kexec passes memmap=exactuseablemap,x@y
>
> From what I can see the patch looks fine, but above part should
> simply be left out.
then, I would like to rename it to resetusablemap instead.
like attached.
Thanks
Yinghai
e820_resetusablemap.patch
Description: Binary data
[PATCH 1/1] net: ipv4: refine the logic for determining daddr in ip_queue_xmit.
The destination address daddr is faddr if source route option is set, otherwise it is inet_daddr. So use if-else to assign the value. Signed-off-by: Harvey Yang --- net/ipv4/ip_output.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c index 3e98ed2..22b738c 100644 --- a/net/ipv4/ip_output.c +++ b/net/ipv4/ip_output.c @@ -349,10 +349,10 @@ int ip_queue_xmit(struct sk_buff *skb, struct flowi *fl) __be32 daddr; /* Use correct destination address if we have options. */ - daddr = inet->inet_daddr; if (inet_opt && inet_opt->opt.srr) daddr = inet_opt->opt.faddr; - + else + daddr = inet->inet_daddr; /* If this fails, retransmit mechanism of transport layer will * keep trying until route appears or the connection times * itself out. -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] regulator-core: free requested GPIOs and manage the enable list
The regulator_ena_gpio_request() allocates the enable GPIO and add the list.
Related resources should be released if they are not used any more.
To free requested GPIO and remove it from the enable GPIO list,
new function, 'regulator_ena_gpio_free()' is added.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/core.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index dc713c4..8631234 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1501,6 +1501,19 @@ static int regulator_ena_gpio_request(struct
regulator_dev *rdev,
return 0;
}
+static void regulator_ena_gpio_free(struct regulator_dev *rdev)
+{
+ struct regulator_enable_gpio *pin, *n;
+
+ list_for_each_entry_safe(pin, n, ®ulator_ena_gpio_list, list) {
+ if (pin->regulator == rdev && pin->gpio) {
+ gpio_free(pin->gpio);
+ list_del(&pin->list);
+ kfree(pin);
+ }
+ }
+}
+
/**
* Balance enable_count of each GPIO and actual GPIO pin control.
* GPIO is enabled in case of initial use. (enable_count is 0)
@@ -3590,8 +3603,7 @@ unset_supplies:
scrub:
if (rdev->supply)
_regulator_put(rdev->supply);
- if (rdev->ena_gpio)
- gpio_free(rdev->ena_gpio);
+ regulator_ena_gpio_free(rdev);
kfree(rdev->constraints);
wash:
device_unregister(&rdev->dev);
@@ -3626,8 +3638,7 @@ void regulator_unregister(struct regulator_dev *rdev)
unset_regulator_supplies(rdev);
list_del(&rdev->list);
kfree(rdev->constraints);
- if (rdev->ena_gpio)
- gpio_free(rdev->ena_gpio);
+ regulator_ena_gpio_free(rdev);
device_unregister(&rdev->dev);
mutex_unlock(®ulator_list_mutex);
}
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] regulator-core: support shared enable GPIO concept
A Regulator can be enabled by external GPIO pin.
This is configurable in the regulator_config.
At this moment, this enable GPIO is owned by only one regulator device.
In some devices, multiple regulators are enabled by shared one GPIO pin.
This patch extends this limitation, enabling shared enable GPIO of regulators.
New list for enable GPIO: 'regulator_ena_gpio_list'
This manages enable GPIO list.
New structure for supporting shared enable GPIO: 'regulator_enable_gpio'
The enable count is used for balancing GPIO control count.
The count is incremented when GPIO is enabled.
On the other hand, it's decremented when GPIO is disabled.
How it works
If the GPIO is already used, skip requesting new GPIO usage.
The GPIO is new one, request GPIO function and add it to the list of
enable GPIO.
This list is used for balancing enable GPIO count and pin control.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/core.c | 49 +++---
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index de47880..1273090 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -51,6 +51,7 @@
static DEFINE_MUTEX(regulator_list_mutex);
static LIST_HEAD(regulator_list);
static LIST_HEAD(regulator_map_list);
+static LIST_HEAD(regulator_ena_gpio_list);
static bool has_full_constraints;
static bool board_wants_dummy_regulator;
@@ -69,6 +70,18 @@ struct regulator_map {
};
/*
+ * struct regulator_enable_gpio
+ *
+ * Management for shared enable GPIO pin
+ */
+struct regulator_enable_gpio {
+ struct list_head list;
+ int gpio;
+ u32 enable_count;
+ struct regulator_dev *regulator;
+};
+
+/*
* struct regulator
*
* One for each consumer device.
@@ -1456,6 +1469,38 @@ void devm_regulator_put(struct regulator *regulator)
}
EXPORT_SYMBOL_GPL(devm_regulator_put);
+/* Manage enable GPIO list. Same GPIO pin can be shared among regulators */
+static int regulator_ena_gpio_request(struct regulator_dev *rdev,
+ const struct regulator_config *config)
+{
+ struct regulator_enable_gpio *pin;
+ int ret;
+
+ list_for_each_entry(pin, ®ulator_ena_gpio_list, list) {
+ if (pin->gpio == config->ena_gpio) {
+ rdev_info(rdev, "GPIO %d is already used\n",
+ config->ena_gpio);
+ return 0;
+ }
+ }
+
+ ret = gpio_request_one(config->ena_gpio,
+ GPIOF_DIR_OUT | config->ena_gpio_flags,
+ rdev_get_name(rdev));
+ if (ret)
+ return ret;
+
+ pin = kzalloc(sizeof(struct regulator_enable_gpio), GFP_KERNEL);
+ if (pin == NULL)
+ return -ENOMEM;
+
+ pin->gpio = config->ena_gpio;
+ pin->regulator = rdev;
+ list_add(&pin->list, ®ulator_ena_gpio_list);
+
+ return 0;
+}
+
static int _regulator_do_enable(struct regulator_dev *rdev)
{
int ret, delay;
@@ -3420,9 +3465,7 @@ regulator_register(const struct regulator_desc
*regulator_desc,
dev_set_drvdata(&rdev->dev, rdev);
if (config->ena_gpio && gpio_is_valid(config->ena_gpio)) {
- ret = gpio_request_one(config->ena_gpio,
- GPIOF_DIR_OUT | config->ena_gpio_flags,
- rdev_get_name(rdev));
+ ret = regulator_ena_gpio_request(rdev, config);
if (ret != 0) {
rdev_err(rdev, "Failed to request enable GPIO%d: %d\n",
config->ena_gpio, ret);
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] regulator-core: manage enable GPIO list
To support shared enable GPIO pin, replace GPIO code with new static functions
regulator_ena_gpio_ctrl()
Find a GPIO information in the enable GPIO list and control the pin.
_do_ena_gpio_ctrl()
Balance the reference count of each GPIO and actual pin control.
The count is incremented with enabling GPIO.
On the other hand, it is decremented on disabling GPIO.
Actual GPIO pin is enabled at the initial use.(enable_count = 0)
The pin is disabled if it is not used(shared) any more. (enable_count = 1)
This concept is derived from the 'use_count' of regulator.
Regardless of the enable count, update GPIO state of the regulator.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/core.c | 54 --
1 file changed, 47 insertions(+), 7 deletions(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 1273090..dc713c4 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1501,6 +1501,51 @@ static int regulator_ena_gpio_request(struct
regulator_dev *rdev,
return 0;
}
+/**
+ * Balance enable_count of each GPIO and actual GPIO pin control.
+ * GPIO is enabled in case of initial use. (enable_count is 0)
+ * GPIO is disabled when it is not shared any more. (enable_count is 1)
+ */
+static void _do_ena_gpio_ctrl(struct regulator_enable_gpio *pin,
+ struct regulator_dev *rdev, bool enable)
+{
+ if (enable) {
+ /* Enable GPIO at initial use */
+ if (pin->enable_count == 0)
+ gpio_set_value_cansleep(rdev->ena_gpio,
+ !rdev->ena_gpio_invert);
+
+ rdev->ena_gpio_state = 1;
+ pin->enable_count++;
+
+ } else {
+ rdev->ena_gpio_state = 0;
+ if (pin->enable_count > 1) {
+ pin->enable_count--;
+ return;
+ }
+
+ /* Disable GPIO if not used */
+ if (pin->enable_count == 1) {
+ gpio_set_value_cansleep(rdev->ena_gpio,
+ rdev->ena_gpio_invert);
+ pin->enable_count = 0;
+ }
+ }
+}
+
+static void regulator_ena_gpio_ctrl(struct regulator_dev *rdev, bool enable)
+{
+ struct regulator_enable_gpio *pin;
+
+ list_for_each_entry(pin, ®ulator_ena_gpio_list, list) {
+ if (pin->gpio == rdev->ena_gpio) {
+ _do_ena_gpio_ctrl(pin, rdev, enable);
+ return;
+ }
+ }
+}
+
static int _regulator_do_enable(struct regulator_dev *rdev)
{
int ret, delay;
@@ -1517,9 +1562,7 @@ static int _regulator_do_enable(struct regulator_dev
*rdev)
trace_regulator_enable(rdev_get_name(rdev));
if (rdev->ena_gpio) {
- gpio_set_value_cansleep(rdev->ena_gpio,
- !rdev->ena_gpio_invert);
- rdev->ena_gpio_state = 1;
+ regulator_ena_gpio_ctrl(rdev, true);
} else if (rdev->desc->ops->enable) {
ret = rdev->desc->ops->enable(rdev);
if (ret < 0)
@@ -1621,10 +1664,7 @@ static int _regulator_do_disable(struct regulator_dev
*rdev)
trace_regulator_disable(rdev_get_name(rdev));
if (rdev->ena_gpio) {
- gpio_set_value_cansleep(rdev->ena_gpio,
- rdev->ena_gpio_invert);
- rdev->ena_gpio_state = 0;
-
+ regulator_ena_gpio_ctrl(rdev, false);
} else if (rdev->desc->ops->disable) {
ret = rdev->desc->ops->disable(rdev);
if (ret != 0)
--
1.7.9.5
Best Regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 4/4] lp8788-ldo: use ena_pin of regulator-core for external control
Regulator core driver provides enable GPIO control for enabling/disabling a
regulator. Now, enable GPIO is shared among regulators.
Use this internal working, so unnecessary code are removed.
GPIO enable pin configurations are added in digital LDO and analog LDO drivers.
Signed-off-by: Milo(Woogyom) Kim
---
drivers/regulator/lp8788-ldo.c | 98 +++-
1 file changed, 17 insertions(+), 81 deletions(-)
diff --git a/drivers/regulator/lp8788-ldo.c b/drivers/regulator/lp8788-ldo.c
index cd5a14a..fcba90a 100644
--- a/drivers/regulator/lp8788-ldo.c
+++ b/drivers/regulator/lp8788-ldo.c
@@ -184,40 +184,6 @@ static enum lp8788_ldo_id lp8788_aldo_id[] = {
ALDO10,
};
-static int lp8788_ldo_enable(struct regulator_dev *rdev)
-{
- struct lp8788_ldo *ldo = rdev_get_drvdata(rdev);
-
- if (ldo->en_pin) {
- gpio_set_value(ldo->en_pin->gpio, ENABLE);
- return 0;
- } else {
- return regulator_enable_regmap(rdev);
- }
-}
-
-static int lp8788_ldo_disable(struct regulator_dev *rdev)
-{
- struct lp8788_ldo *ldo = rdev_get_drvdata(rdev);
-
- if (ldo->en_pin) {
- gpio_set_value(ldo->en_pin->gpio, DISABLE);
- return 0;
- } else {
- return regulator_disable_regmap(rdev);
- }
-}
-
-static int lp8788_ldo_is_enabled(struct regulator_dev *rdev)
-{
- struct lp8788_ldo *ldo = rdev_get_drvdata(rdev);
-
- if (ldo->en_pin)
- return gpio_get_value(ldo->en_pin->gpio) ? 1 : 0;
- else
- return regulator_is_enabled_regmap(rdev);
-}
-
static int lp8788_ldo_enable_time(struct regulator_dev *rdev)
{
struct lp8788_ldo *ldo = rdev_get_drvdata(rdev);
@@ -253,17 +219,17 @@ static struct regulator_ops lp8788_ldo_voltage_table_ops
= {
.list_voltage = regulator_list_voltage_table,
.set_voltage_sel = regulator_set_voltage_sel_regmap,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
- .enable = lp8788_ldo_enable,
- .disable = lp8788_ldo_disable,
- .is_enabled = lp8788_ldo_is_enabled,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
.enable_time = lp8788_ldo_enable_time,
};
static struct regulator_ops lp8788_ldo_voltage_fixed_ops = {
.get_voltage = lp8788_ldo_fixed_get_voltage,
- .enable = lp8788_ldo_enable,
- .disable = lp8788_ldo_disable,
- .is_enabled = lp8788_ldo_is_enabled,
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
.enable_time = lp8788_ldo_enable_time,
};
@@ -535,43 +501,10 @@ static struct regulator_desc lp8788_aldo_desc[] = {
},
};
-static int lp8788_gpio_request_ldo_en(struct platform_device *pdev,
- struct lp8788_ldo *ldo,
- enum lp8788_ext_ldo_en_id id)
-{
- struct device *dev = &pdev->dev;
- struct lp8788_ldo_enable_pin *pin = ldo->en_pin;
- int ret, gpio, pinstate;
- char *name[] = {
- [EN_ALDO1] = "LP8788_EN_ALDO1",
- [EN_ALDO234] = "LP8788_EN_ALDO234",
- [EN_ALDO5] = "LP8788_EN_ALDO5",
- [EN_ALDO7] = "LP8788_EN_ALDO7",
- [EN_DLDO7] = "LP8788_EN_DLDO7",
- [EN_DLDO911] = "LP8788_EN_DLDO911",
- };
-
- gpio = pin->gpio;
- if (!gpio_is_valid(gpio)) {
- dev_err(dev, "invalid gpio: %d\n", gpio);
- return -EINVAL;
- }
-
- pinstate = pin->init_state;
- ret = devm_gpio_request_one(dev, gpio, pinstate, name[id]);
- if (ret == -EBUSY) {
- dev_warn(dev, "gpio%d already used\n", gpio);
- return 0;
- }
-
- return ret;
-}
-
static int lp8788_config_ldo_enable_mode(struct platform_device *pdev,
struct lp8788_ldo *ldo,
enum lp8788_ldo_id id)
{
- int ret;
struct lp8788 *lp = ldo->lp;
struct lp8788_platform_data *pdata = lp->pdata;
enum lp8788_ext_ldo_en_id enable_id;
@@ -613,14 +546,7 @@ static int lp8788_config_ldo_enable_mode(struct
platform_device *pdev,
goto set_default_ldo_enable_mode;
ldo->en_pin = pdata->ldo_pin[enable_id];
-
- ret = lp8788_gpio_request_ldo_en(pdev, ldo, enable_id);
- if (ret) {
- ldo->en_pin = NULL;
- goto set_default_ldo_enable_mode;
- }
-
- return ret;
+ return 0;
set_default_ldo_enable_mode:
return lp8788_update_bits(lp, LP8788_EN_SEL, en_mask[enable_id], 0);
@@ -644,6 +570,11 @@ static int lp8788_dldo_probe(struct platform_device *pdev)
if (ret)
return ret;
+ if (ldo->en_pin) {
+
[PATCH] HID: add support for Sony RF receiver with USB product id 0x0374
Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
a RF receiver, multi-interface USB device 054c:0374, that is used to connect
a wireless keyboard and a wireless mouse.
The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not
seem to be generating any pointer events. The problem is that the mouse pointer
is wrongly declared as a constant non-data variable in the report descriptor
(see lsusb and usbhid-dump output below), with the consenquence that it is
ignored by the HID code.
Add this device to the have-special-driver list and fix up the report
descriptor in the Sony-specific driver which happens to already have a fixup
for a similar firmware bug.
# lsusb -vd 054C:0374
Bus 003 Device 002: ID 054c:0374 Sony Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x054c Sony Corp.
idProduct 0x0374
iSerial 0
[...]
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 2 RF Receiver
[...]
Report Descriptor: (length is 100)
Item(Global): Usage Page, data= [ 0x01 ] 1
Generic Desktop Controls
Item(Local ): Usage, data= [ 0x30 ] 48
Direction-X
Item(Local ): Usage, data= [ 0x31 ] 49
Direction-Y
Item(Global): Report Count, data= [ 0x02 ] 2
Item(Global): Report Size, data= [ 0x08 ] 8
Item(Global): Logical Minimum, data= [ 0x81 ] 129
Item(Global): Logical Maximum, data= [ 0x7f ] 127
Item(Main ): Input, data= [ 0x07 ] 7
Constant Variable Relative No_Wrap Linear
Preferred_State No_Null_Position Non_Volatile
Bitfield
# sudo usbhid-dump
003:002:001:DESCRIPTOR 1357910009.758544
05 01 09 02 A1 01 05 01 09 02 A1 02 85 01 09 01
A1 00 05 09 19 01 29 05 95 05 75 01 15 00 25 01
81 02 75 03 95 01 81 01 05 01 09 30 09 31 95 02
75 08 15 81 25 7F 81 07 A1 02 85 01 09 38 35 00
45 00 15 81 25 7F 95 01 75 08 81 06 C0 A1 02 85
01 05 0C 15 81 25 7F 95 01 75 08 0A 38 02 81 06
C0 C0 C0 C0
Cc: linux-in...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Fernando Luis Vazquez Cao
---
diff -urNp linux-3.8-rc3-orig/drivers/hid/hid-core.c
linux-3.8-rc3/drivers/hid/hid-core.c
--- linux-3.8-rc3-orig/drivers/hid/hid-core.c 2013-01-13 20:54:36.846952518
+0900
+++ linux-3.8-rc3/drivers/hid/hid-core.c2013-01-13 18:21:19.901347327
+0900
@@ -1697,6 +1697,7 @@ static const struct hid_device_id hid_ha
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY,
USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY,
USB_DEVICE_ID_SONY_PS3_CONTROLLER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE)
},
+ { HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGP_MOUSE)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_SUNPLUS, USB_DEVICE_ID_SUNPLUS_WDESKTOP)
},
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb300) },
{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb304) },
diff -urNp linux-3.8-rc3-orig/drivers/hid/hid-ids.h
linux-3.8-rc3/drivers/hid/hid-ids.h
--- linux-3.8-rc3-orig/drivers/hid/hid-ids.h2013-01-13 20:54:36.850952537
+0900
+++ linux-3.8-rc3/drivers/hid/hid-ids.h 2013-01-13 18:21:19.901347327 +0900
@@ -706,6 +706,7 @@
#define USB_VENDOR_ID_SONY 0x054c
#define USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE 0x024b
+#define USB_DEVICE_ID_SONY_VAIO_VGP_MOUSE 0x0374
#define USB_DEVICE_ID_SONY_PS3_BDREMOTE0x0306
#define USB_DEVICE_ID_SONY_PS3_CONTROLLER 0x0268
#define USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER 0x042f
diff -urNp linux-3.8-rc3-orig/drivers/hid/hid-sony.c
linux-3.8-rc3/drivers/hid/hid-sony.c
--- linux-3.8-rc3-orig/drivers/hid/hid-sony.c 2012-12-11 12:30:57.0
+0900
+++ linux-3.8-rc3/drivers/hid/hid-sony.c2013-01-13 18:21:19.901347327
+0900
@@ -44,19 +44,21 @@ static __u8 *sony_report_fixup(struct hi
struct sony_sc *sc = hid_get_drvdata(hdev);
if ((sc->quirks & VAIO_RDESC_CONSTANT) &&
- *rsize >= 56 && rdesc[54] == 0x81 && rdesc[55] == 0x07)
{
- hid_info(hdev, "Fixing up Sony Vaio VGX report descriptor\n");
+ *rsize >= 56 && rdesc[54] == 0x81 && rdesc[55] == 0x07) {
+ hid_info(hdev,
+
Re: [PATCH v12 0/9] LSM: Multiple concurrent LSMs
On 1/8/2013 9:47 AM, Stephen Smalley wrote: > On 01/07/2013 08:54 PM, Casey Schaufler wrote: >> Subject: [PATCH v12 0/9] LSM: Multiple concurrent LSMs >> >> Change the infrastructure for Linux Security Modules (LSM)s >> from a single vector of hook handlers to a list based method >> for handling multiple concurrent modules. >> >> A level of indirection has been introduced in the handling of >> security blobs. LSMs no longer access ->security fields directly, >> instead they use an abstraction provided by lsm_[gs]et field >> functions. >> >> The XFRM hooks are only used by SELinux and it is not clear >> that they can be shared. The First LSM that registers using >> those hooks gets to use them. Any subsequent LSM that uses >> those hooks is denied registration. >> >> Secids have not been made shareable. Only one LSM that uses >> secids (SELinux and Smack) can be used at a time. The first >> to register wins. >> >> The "security=" boot option takes a comma separated list of >> LSMs, registering them in the order presented. The LSM hooks >> will be executed in the order registered. Hooks that return >> errors are not short circuited. All hooks are called even >> if one of the LSM hooks fails. The result returned will be >> that of the last LSM hook that failed. >> >> Some hooks don't fit that model. setprocattr, getprocattr, >> and a few others are special cased. All behavior from >> security/capability.c has been moved into the hook handling. >> The security/commoncap functions used to get called from >> the LSM specific code. The handling of the capability >> functions has been moved out of the LSMs and into the >> hook handling. >> >> The /proc/*/attr interfaces are given to one LSM. This >> can be done by setting CONFIG_SECURITY_PRESENT. Additional >> interfaces have been created in /proc/*/attr so that >> each LSM has its own named interfaces. >> >> Signed-off-by: Casey Schaufler > > Have you run any benchmarks, particularly to compare performance > overhead in the simple case of a single LSM? > Yes. Finally. I ran a series of micro-benchmarks on the assumption that we're most concerned with system call performance. I used lmbench, not because it's the world's greatest benchmark but because it targets some of the things I care about. I am perfectly happy to accept suggestions of other benchmarks, but I make no guarantees that I'll be able to run them. I ran sets of three runs for each configuration and tossed any benchmark where I had too great a deviation. I ran one set on Fedora 17 and another on Ubuntu 12.04. I ran what I consider some interesting configurations, with both the old LSM infrastructure and the stacking infrastructure. I compared the performance for these configurations: CONFIG_SECURITY disabled CONFIG_SECURITY enabled, no LSM specified CONFIG_SECURITY enabled, SELinux enabled CONFIG_SECURITY enabled, SELinux and Yama enabled CONFIG_SECURITY enabled, Smack enabled CONFIG_SECURITY enabled, Smack and Yama enabled I also ran SELinux + AppArmor + Yama, Smack + AppArmor + Yama and Smack + AppArmor + TOMOYO + Yama under the stacking framework, but as I can't run them without it I can't do comparisons. I found that with security disabled I got 0.79% worse overall performance with Fedora but a 0.81% better overall performance with Ubuntu. The combined was 0.01% better, so I figure that the methodology looks OK. On Fedora I found that for all comparable configurations stacking added 1.23%. For Ubuntu, it was 0.61%. I am no statistician, and I do not aspire to becoming one. I know that my methods were nowhere near clean and were in fact very noisy. I had to disqualify a good number of my results because the deviation between runs was too large. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-c6x-dev] [PATCH 3/9] c6x: Provide dma_mmap_coherent() and dma_get_sgtable()
On Monday 14 January 2013 09:07 PM, Mark Salter wrote: > On Sun, 2013-01-13 at 11:44 +0100, Geert Uytterhoeven wrote: >> c6x/allmodconfig (assumed): >> >> drivers/media/v4l2-core/videobuf2-dma-contig.c: In function ‘vb2_dc_mmap’: >> drivers/media/v4l2-core/videobuf2-dma-contig.c:204: error: implicit >> declaration of function ‘dma_mmap_coherent’ >> drivers/media/v4l2-core/videobuf2-dma-contig.c: In function >> ‘vb2_dc_get_base_sgt’: >> drivers/media/v4l2-core/videobuf2-dma-contig.c:387: error: implicit >> declaration of function ‘dma_get_sgtable’ >> >> For architectures using dma_map_ops, dma_mmap_coherent() and >> dma_get_sgtable() are provided in . >> >> C6x does not use dma_map_ops, hence it should implement them as inline >> stubs using dma_common_mmap() and dma_common_get_sgtable(). >> > > So are dma_mmap_coherent() and dma_get_sgtable() part of the DMA API > now? I don't them in Documentation/DMA*.txt anywhere. > > Why does the default dma_common_mmap() for !CONFIG_MMU return an > error? > > Wouldn't it be better to provide default implementations that an arch > could override rather than having to patch all "no dma_map_ops" > architectures? > > --Mark > > Speaking for the still-reviewed ARC Port, I completely agree with Mark. -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: BUG at net/sunrpc/svc_xprt.c:921
On 13-01-14 03:37 PM, J. Bruce Fields wrote: > Thanks for the report. > > On Mon, Jan 14, 2013 at 11:17:09AM -0500, Mark Lord wrote: >> Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server > > It's acting as an NFS client, right? Client and server, with other Linux boxes all running 3.something kernels. > What did you upgrade from? 3.4.something, I believe. >> is getting these BUG complaints. The .config file is gzip'd/attached. > > Is this easy to reproduce? So far, it seems to pop up within a day or so of any reboot. I normally only reboot that system for a kernel upgrade, but can do so a bit more often if there's useful info to collect. Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Bulk] [PATCH] timer: vt8500: Move timer code to drivers/clocksource
On Mon, 2013-01-14 at 12:07 -0800, Olof Johansson wrote: > On Mon, Jan 14, 2013 at 06:47:35PM +1300, Tony Prisk wrote: > > On Mon, 2013-01-14 at 18:13 +1300, Tony Prisk wrote: > > > On Mon, 2013-01-14 at 18:09 +1300, Tony Prisk wrote: > > > > This patch moves arch-vt8500/timer.c into drivers/clocksource and > > > > updates the necessary Kconfig/Makefile options. > > > > > > > > Signed-off-by: Tony Prisk > > > > --- > > > > arch/arm/mach-vt8500/Kconfig |1 + > > > > arch/arm/mach-vt8500/Makefile |2 +- > > > > arch/arm/mach-vt8500/common.h |1 - > > > > arch/arm/mach-vt8500/timer.c | 184 > > > > > > > > arch/arm/mach-vt8500/vt8500.c |1 + > > > > drivers/clocksource/Kconfig|3 + > > > > drivers/clocksource/Makefile |1 + > > > > drivers/clocksource/vt8500_timer.c | 184 > > > > > > > > include/linux/vt8500_timer.h | 22 + > > > > 9 files changed, 213 insertions(+), 186 deletions(-) > > > > delete mode 100644 arch/arm/mach-vt8500/timer.c > > > > create mode 100644 drivers/clocksource/vt8500_timer.c > > > > create mode 100644 include/linux/vt8500_timer.h > > > > > > Darn.. forgot the -m again. I'll await your feedback regarding the > > > basing of the patch first (and any other feedback), then I'll redo it > > > with the correct stats. > > > > > > Regards > > > Tony P > > > > Oh grr.. forget this completely. It doesn't take into account the > > patches I already sent for WM8850. > > > > I guess it needs to be based on timer/cleanup + vt8500/wm8x50. > > > > Need a little advise on how to handle this one please :) > > The normal way to handle these kind of dependencies is to base them on merges > of the needed branches. Based on the later email, you only seem to need > timer/cleanup, but if you would have needed the other one, then you'd merge > that on top of timer/cleanup, and then add your patches. > > Of course, ideally you would do the cleanup, then add the wm8x50 features, > but in reality work doesn't always pan out that way, so you end up with > cleanups that depend on including new features in the same (sweeping) > cleanup since they have already been merged. That's when things sometimes > get hairy, and we need to start a second cleanup branch that's "after" > the feature branch in the sequence of topics. But it should be rare, > and in your case it seems like it wasn't needed. > > > -Olof > Just to clarify what I did (and to make sure it was as you understood it): #1) I wrote the patch on top of timer/cleanup. This is the branch the patch was written for. #2) I then pulled timer/cleanup and merged vt8500/wm8x50 on top, then reapplied the patch from #1 - it applied cleanly. What I have just realised is that you might?? get a conflict when you merge vt8500/wm8x50 on top of wherever this patch ends up due to the few lines at the top of arch-vt8500/Kconfig having changed (the addition of SELECT VT8500_TIMER). This should be trivial to fix (I assume). Regards Tony P -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 3/3] vfio-pci: Add support for legacy MMIO & I/O port towards VGA support
Create two new legacy regions, one for MMIO space below 1MB and
another for 64k of I/O port space. For devices of PCI class VGA
these ranges will be exposed and allow direct access to the device
at the PCI defined VGA addresses, 0xa, 0x3b0, 0x3c0. VFIO
makes use of the host VGA arbiter to manage host chipset config
to route each access to the correct device.
Signed-off-by: Alex Williamson
---
drivers/vfio/pci/Kconfig| 10
drivers/vfio/pci/vfio_pci.c | 49
drivers/vfio/pci/vfio_pci_private.h |9
drivers/vfio/pci/vfio_pci_rdwr.c| 85 +++
include/uapi/linux/vfio.h |8 +++
5 files changed, 160 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
index 5980758..559d807 100644
--- a/drivers/vfio/pci/Kconfig
+++ b/drivers/vfio/pci/Kconfig
@@ -6,3 +6,13 @@ config VFIO_PCI
use of PCI drivers using the VFIO framework.
If you don't know what to do here, say N.
+
+config VFIO_PCI_VGA
+ bool "VFIO PCI support for VGA devices"
+ depends on VFIO_PCI && X86 && VGA_ARB && EXPERIMENTAL
+ help
+ Support for VGA extensions to VFIO PCI. This exposes additional
+ regions on VGA devices for accessing legacy VGA addresses used
+ by BIOS and generic video drivers.
+
+ If you don't know what to do here, say N.
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index 781f900..61346bc 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -81,6 +81,11 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev)
if (ret)
goto out;
+#ifdef CONFIG_VFIO_PCI_VGA
+ if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA)
+ vdev->has_vga = true;
+#endif
+
return ret;
out:
@@ -193,6 +198,7 @@ static long vfio_pci_ioctl(void *device_data,
if (cmd == VFIO_DEVICE_GET_INFO) {
struct vfio_device_info info;
+ bool legacy_io = false, legacy_mem = false;
minsz = offsetofend(struct vfio_device_info, num_irqs);
@@ -207,9 +213,24 @@ static long vfio_pci_ioctl(void *device_data,
if (vdev->reset_works)
info.flags |= VFIO_DEVICE_FLAGS_RESET;
- info.num_regions = VFIO_PCI_NUM_REGIONS;
+ info.num_regions = VFIO_PCI_CONFIG_REGION_INDEX + 1;
info.num_irqs = VFIO_PCI_NUM_IRQS;
+ if (vdev->has_vga) {
+ info.flags |= VFIO_DEVICE_FLAGS_PCI_VGA;
+ legacy_io = legacy_mem = true;
+ }
+
+ if (legacy_io) {
+ info.flags |= VFIO_DEVICE_FLAGS_PCI_LEGACY_IOPORT;
+ info.num_regions++;
+ }
+
+ if (legacy_mem) {
+ info.flags |= VFIO_DEVICE_FLAGS_PCI_LEGACY_MMIO;
+ info.num_regions++;
+ }
+
return copy_to_user((void __user *)arg, &info, minsz);
} else if (cmd == VFIO_DEVICE_GET_REGION_INFO) {
@@ -269,6 +290,26 @@ static long vfio_pci_ioctl(void *device_data,
info.flags = VFIO_REGION_INFO_FLAG_READ;
break;
}
+ case VFIO_PCI_LEGACY_MMIO_REGION_INDEX:
+ if (!vdev->has_vga)
+ return -EINVAL;
+
+ info.offset = VFIO_PCI_INDEX_TO_OFFSET(info.index);
+ info.size = 1024 * 1024;
+ info.flags = VFIO_REGION_INFO_FLAG_READ |
+VFIO_REGION_INFO_FLAG_WRITE;
+
+ break;
+ case VFIO_PCI_LEGACY_IOPORT_REGION_INDEX:
+ if (!vdev->has_vga)
+ return -EINVAL;
+
+ info.offset = VFIO_PCI_INDEX_TO_OFFSET(info.index);
+ info.size = 64 * 1024;
+ info.flags = VFIO_REGION_INFO_FLAG_READ |
+VFIO_REGION_INFO_FLAG_WRITE;
+
+ break;
default:
return -EINVAL;
}
@@ -375,6 +416,12 @@ static ssize_t vfio_pci_rw(void *device_data, char __user
*buf,
case VFIO_PCI_BAR0_REGION_INDEX ... VFIO_PCI_BAR5_REGION_INDEX:
return vfio_pci_bar_rw(vdev, buf, count, ppos, iswrite);
+
+ case VFIO_PCI_LEGACY_MMIO_REGION_INDEX:
+ return vfio_pci_legacy_mem_rw(vdev, buf, count, ppos, iswrite);
+
+ case VFIO_PCI_LEGACY_IOPORT_REGION_INDEX:
+ return vfio_pci_legacy_io_rw(vdev, buf, count, ppos, iswrite);
}
return -EINVAL;
diff --git a/drivers/vfio/pci/vfio_pci_private.h
b/drivers/vfio/pci/vfio_pci_private.h
index 00d19b9..453ea69 100644
--- a/drivers/vfio/pci/v
