On Wed, 2013-12-04 at 09:28 +, Ian Campbell wrote:
> This could probably even be semi automated by producing a script to feed
> to gdb which run through all of the options and diffing the result.
>
> If I could have the moon on a stick I would have a tool such as this
> running against the can
From: Magnus Damm
Set the ->irq_enable() and ->irq_disable() methods to NULL
to enable lazy disable of interrupts. This by itself provides
some level of optimization, but is mainly enabled as ground
work for future Suspend-to-RAM wake up support.
Signed-off-by: Magnus Damm
---
drivers/irqchip
irqchip: renesas-irqc: Lazy disable and mask-on-suspend
[PATCH 01/02] irqchip: renesas-irqc: Use lazy disable
[PATCH 02/02] irqchip: renesas-irqc: Enable mask on suspend
Update the IRQC driver to use lazy disable and mask on suspend. This fixes
the Suspend-to-RAM behavior to make sure wakeup sour
From: Magnus Damm
Now when lazy interrupt disable has been enabled in the driver
then extend the code to set IRQCHIP_MASK_ON_SUSPEND which tells
the core that only IRQs marked as wakeups need to stay enabled
during Suspend-to-RAM.
Signed-off-by: Magnus Damm
---
drivers/irqchip/irq-renesas-irq
On 12/03/2013 10:40 PM, Corey Minyard wrote:
> On 12/03/2013 12:18 AM, srinivas_g_go...@dell.com wrote:
>> Dell - Internal Use - Confidential
>>
>> Hi Corey,
>>> Unfortunately, that would start the timer unnecessarily. You don't want to
>>> start timers unnecessarily in the kernel or the power
Am Dienstag, den 03.12.2013, 23:18 +0100 schrieb Stefan Agner:
> Set the parent of the regulators LDO2 to LDO9 according to the
> schematic. Set the base voltage to 3.3V, there is only 3.3V on the
> module itself.
>
> Set the Core and CPU voltage to the specified voltages of 1.2V and
> 1.0V respec
> > > As I pointed out in the comment above, the struct tps6586x is in the C
> > > file, so I would need to move that too. That's why I did not made that
> > > change in the end. What do you think, should I still move (and move the
> > > struct too?)
>
> > Why would the struct have to be moved if
On 12/04/2013 02:08 PM, Glauber Costa wrote:
>>> Could you do something clever with just one flag? Probably yes. But I
>>> doubt it would
>>> be that much cleaner, this is just the way that patching sites work.
>> Thank you for spending your time to listen to me.
>>
> Don't worry! I thank you for c
On Tue, Dec 03, 2013 at 04:41:16PM +, Alan Tull wrote:
> From: Jamie Iles
>
> The Synopsys DesignWare block is used in some ARM devices (picoxcell)
> and can be configured to provide multiple banks of GPIO pins.
>
> Signed-off-by: Alan Tull
> Reviewed-by: Sebastian Hesselbarth
>
> v8:
Hi,
I queued up a number of tests including IO stress tests a few weeks ago
and had noticed that some of the btrfs tests failed to complete but only
looked today. Specfically, stress tests with reaims alltests configuration
on btrfs failed up until 3.12 with a console log that looked like
[ 2882
On 12/03/2013 04:21 PM, Andrew Morton wrote:
> On Mon, 2 Dec 2013 10:19:37 -0500 Prarit Bhargava wrote:
> A slight simplification:
>
>> +static inline char *dump_hadware_arch_desc(void)
>> +{
>> +return NULL;
>> +}
>
> return "unavailable";
>
>> +void warn_slowpath_fmt_dev(const ch
On Wed, Dec 04, 2013 at 10:07:28AM +, Lee Jones wrote:
> On Wed, 04 Dec 2013, Stefan Agner wrote:
> > As I pointed out in the comment above, the struct tps6586x is in the C
> > file, so I would need to move that too. That's why I did not made that
> > change in the end. What do you think, shou
On Wed, 04 Dec 2013, Stefan Agner wrote:
> Am 2013-12-04 11:07, schrieb Lee Jones:
> > On Wed, 04 Dec 2013, Stefan Agner wrote:
> >
> >> Am 2013-12-04 09:10, schrieb Lee Jones:
> >> >> +int tps6586x_get_version(struct device *dev)
> >> >> +{
> >> >> + struct tps6586x *tps6586x = dev_get_drv
On 12/04/2013 12:42 AM, Russell King - ARM Linux wrote:
This will make it correct when using interrupts but it will make the
loop wait one jiffie longer than it should when polling.
Alternatively, code it like this instead.
drivers/net/ethernet/marvell/mvmdio.c | 32 +++
Commit 0b2aa8be introduced a regression that causes failure
in setting LED GPO direction to OUT.
This causes USB host probe failures for Beagleboard C4.
[2.075469] platform usb_phy_gen_xceiv.2: Driver usb_phy_gen_xceiv requests
probe deferral
[2.090454] hsusb2_vcc: Failed to request enab
Hi,
Commit 0b2aa8be that went into 3.13-rc2 introduced a regression
that causes failure in setting LED GPO direction to OUT.
This causes USB Host to fail probe on Beagleboard.
The following patch fixes this issue.
I've tried to higlight the issue in the original patch here
http://www.spinics.ne
On Wed, 4 Dec 2013, Stefano Stabellini wrote:
> On Tue, 3 Dec 2013, Konrad Rzeszutek Wilk wrote:
> > > > If Konrad and Boris agree that breaking the kernel's ABI in this way is
> > > > acceptable in this specific case, I'll defer to them.
> > >
> > > My opinion as Xen on ARM hypervisor maintainer
On 12/04/2013 02:08 AM, Joel Fernandes wrote:
On 12/04/2013 07:09 AM, Nishanth Menon wrote:
Due to the cross dependencies between hwmod for automanaged device
information for OMAP and dts node definitions, we can run into scenarios
where the dts node is defined, however it's hwmod entry is yet t
Am 2013-12-04 11:07, schrieb Lee Jones:
> On Wed, 04 Dec 2013, Stefan Agner wrote:
>
>> Am 2013-12-04 09:10, schrieb Lee Jones:
>> >> +int tps6586x_get_version(struct device *dev)
>> >> +{
>> >> + struct tps6586x *tps6586x = dev_get_drvdata(dev);
>> >> +
>> >> + return tps6586x->version;
>> >> +}
On 12/03, H. Peter Anvin wrote:
>
> On 12/03/2013 02:01 PM, Linus Torvalds wrote:
> > On Tue, Dec 3, 2013 at 12:54 PM, Oleg Nesterov wrote:
> >>
> >> So do you think the patch I sent is wrong? Why?
> >
> > I think the TLB shootdown should guarantee that it's ok on other
> > CPU's, since that's bas
> We obsevered 150% performance gain with vm-scalability/300s-mmap-pread-seq
> testcase with this patch applied. Here is a list of changes we got so far:
>
> testbox : brickland
got some explain of brickland on wiki:
High-end server platform based on the Ivy Bridge-EX processor
> testcase: vm-sc
On 12/04/2013 07:17 PM, Haojian Zhuang wrote:
Dan indicated that you could pack these two patches into one. Whatever
it's also OK to use two patches.
Misunderstood it... Thanks for correcting.
--
Best Regards
Qiao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
On Wed, 2013-12-04 at 11:18 +, Stefano Stabellini wrote:
> On Wed, 4 Dec 2013, Ian Campbell wrote:
> > On Wed, 2013-12-04 at 11:05 +, Stefano Stabellini wrote:
> > > On Wed, 4 Dec 2013, Ian Campbell wrote:
> > > > On Wed, 2013-12-04 at 10:51 +, Stefano Stabellini wrote:
> > > > > On Wed
> Add document describing device tree bindings for MAX14577 MFD driver.
>
> Signed-off-by: Krzysztof Kozlowski
> Signed-off-by: Kyungmin Park
> ---
> Documentation/devicetree/bindings/mfd/max14577.txt | 48
>
> 1 file changed, 48 insertions(+)
> create mode 100644 Docum
On Wed, Dec 04, 2013 at 03:57:07AM +, Alex Elder wrote:
> Replace the "fake" clocks defined in the "bcm11351.dtsi" device tree
> file with real definitions backed by the new BCM281xx clock driver..
>
> Signed-off-by: Alex Elder
> Reviewed-by: Matt Porter
> Reviewed-by: Tim Kryger
> ---
> a
On Wed, 4 Dec 2013, Ian Campbell wrote:
> On Wed, 2013-12-04 at 11:05 +, Stefano Stabellini wrote:
> > On Wed, 4 Dec 2013, Ian Campbell wrote:
> > > On Wed, 2013-12-04 at 10:51 +, Stefano Stabellini wrote:
> > > > On Wed, 4 Dec 2013, Ian Campbell wrote:
> > > > > > +bool xen_has_pv_devices(
On Wed, Dec 4, 2013 at 4:21 PM, Qiao Zhou wrote:
> V1 -> V0:
> No need for help text for MMP_SRAM in Kconfig and move it into MMP_TDMA
> text in Kconfig.
>
> Qiao Zhou (2):
> arm: mmp: build sram driver alone
> dma: mmp-tdma: select sram driver
>
> arch/arm/mach-mmp/Kconfig |3 +++
> arc
On Wed, Dec 04, 2013 at 03:57:03AM +, Alex Elder wrote:
> Add code for device tree support of clocks in the BCM281xx family of
> SoCs. Machines in this family use peripheral clocks implemented by
> "Kona" clock control units (CCUs). (Other Broadcom SoC families use
> Kona style CCUs as well,
On Tue 03-12-13 15:50:41, David Rientjes wrote:
> On Tue, 3 Dec 2013, Michal Hocko wrote:
>
> > OK, as it seems that the notification part is too controversial, how
> > would you like the following? It reverts the notification part and still
> > solves the fault on exit path. I will prepare the fu
On Wed, Dec 4, 2013 at 6:26 PM, Daniel Mack wrote:
> On 12/04/2013 11:22 AM, Thierry Reding wrote:
>> The conf and of_id variables are assigned but never used, so they may as
>> well just be removed.
>>
>> Signed-off-by: Thierry Reding
>
> Acked-by: Daniel Mack
>
>> ---
>> arch/arm/mach-pxa/irq
On 12/03, Linus Torvalds wrote:
>
> On Tue, Dec 3, 2013 at 12:54 PM, Oleg Nesterov wrote:
> >
> > So do you think the patch I sent is wrong? Why?
>
> I think the TLB shootdown should guarantee that it's ok on other
> CPU's, since that's basically what we do on mmap.
OK, thanks. I'll resend this p
On 12/04/2013 08:03 PM, Krzysztof Kozlowski wrote:
> On Wed, 2013-12-04 at 20:01 +0900, Chanwoo Choi wrote:
>> On 12/04/2013 07:56 PM, Krzysztof Kozlowski wrote:
>>> On Wed, 2013-12-04 at 19:50 +0900, Chanwoo Choi wrote:
> (...)
I prefer to add dt data about max14577-muic on following:
>>
On Wed, 2013-12-04 at 11:05 +, Stefano Stabellini wrote:
> On Wed, 4 Dec 2013, Ian Campbell wrote:
> > On Wed, 2013-12-04 at 10:51 +, Stefano Stabellini wrote:
> > > On Wed, 4 Dec 2013, Ian Campbell wrote:
> > > > > +bool xen_has_pv_devices(void)
> > > > > +{
> > > > > + if (!xen_domain
On Wed, 4 Dec 2013, Ian Campbell wrote:
> On Wed, 2013-12-04 at 10:51 +, Stefano Stabellini wrote:
> > On Wed, 4 Dec 2013, Ian Campbell wrote:
> > > > +bool xen_has_pv_devices(void)
> > > > +{
> > > > + if (!xen_domain())
> > > > + return false;
> > > > +
> > > > + if
At Mon, 2 Dec 2013 11:13:11 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.12.3 release.
> There are 212 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
On Tue, 3 Dec 2013, Konrad Rzeszutek Wilk wrote:
> > > If Konrad and Boris agree that breaking the kernel's ABI in this way is
> > > acceptable in this specific case, I'll defer to them.
> >
> > My opinion as Xen on ARM hypervisor maintainer is that this is the right
> > thing to do in this case.
On Wed, 2013-12-04 at 20:01 +0900, Chanwoo Choi wrote:
> On 12/04/2013 07:56 PM, Krzysztof Kozlowski wrote:
> > On Wed, 2013-12-04 at 19:50 +0900, Chanwoo Choi wrote:
(...)
> >>
> >> I prefer to add dt data about max14577-muic on following:
> >> If extcon consumer driver need to use muic device, dt
On Tue, Dec 03, 2013 at 11:16:01AM -0500, Steven Rostedt wrote:
> On Tue, 3 Dec 2013 14:09:36 +0100
> Jiri Olsa wrote:
>
> > Removing malloc_or_die calls from event-plugin.c,
> > replacing them with standard malloc and error path.
> >
> > Suggested-by: Namhyung Kim
> > Signed-off-by: Jiri Olsa
On 12/04/2013 07:56 PM, Krzysztof Kozlowski wrote:
> On Wed, 2013-12-04 at 19:50 +0900, Chanwoo Choi wrote:
>> Hi Krzysztof,
>>
>> On 12/04/2013 07:40 PM, Krzysztof Kozlowski wrote:
>>> Add document describing device tree bindings for MAX14577 MFD driver.
>>>
>>> Signed-off-by: Krzysztof Kozlowski
On 4 December 2013 00:41, Rafael J. Wysocki wrote:
> On Wednesday, December 04, 2013 12:15:13 AM Rafael J. Wysocki wrote:
>> On Wednesday, November 27, 2013 04:34:56 PM Ulf Hansson wrote:
>> > To put devices into low power state during sleep, it sometimes makes
>> > sense at subsystem-level to re-
On Wed, 2013-12-04 at 10:51 +, Stefano Stabellini wrote:
> On Wed, 4 Dec 2013, Ian Campbell wrote:
> > > +bool xen_has_pv_devices(void)
> > > +{
> > > + if (!xen_domain())
> > > + return false;
> > > +
> > > + if (xen_hvm_domain()) {
> > > + /* User requested no unplug, so no PV
On Wed, 2013-12-04 at 19:50 +0900, Chanwoo Choi wrote:
> Hi Krzysztof,
>
> On 12/04/2013 07:40 PM, Krzysztof Kozlowski wrote:
> > Add document describing device tree bindings for MAX14577 MFD driver.
> >
> > Signed-off-by: Krzysztof Kozlowski
> > Signed-off-by: Kyungmin Park
> > ---
> > Docume
On Wed, 4 Dec 2013, Ian Campbell wrote:
> > +bool xen_has_pv_devices(void)
> > +{
> > + if (!xen_domain())
> > + return false;
> > +
> > + if (xen_hvm_domain()) {
> > + /* User requested no unplug, so no PV drivers. */
> > + if (xen_emul_unplug & XEN_UNPLUG_NEVER)
> > LP3943 is an integrated device capable of driving 16 output channels.
> > It can be used for GPIO expander and PWM generators.
> > LP3493 registers are controlled via the I2C interface.
> >
> > This patch-set consists of four parts - MFD, GPIO, PWM and documents.
> >
> > Update from v3 to v4:
On Tue, Dec 03, 2013 at 06:02:18PM +0200, Mathias Nyman wrote:
> On 12/03/2013 05:00 PM, Linus Walleij wrote:
> >This uses the new API for tagging GPIO lines as in use by
> >IRQs. This enforces a few semantic checks on how the underlying
> >GPIO line is used.
> >
> >Cc: Andy Shevchenko
> >Cc: Mika
Hi Krzysztof,
On 12/04/2013 07:40 PM, Krzysztof Kozlowski wrote:
> Add document describing device tree bindings for MAX14577 MFD driver.
>
> Signed-off-by: Krzysztof Kozlowski
> Signed-off-by: Kyungmin Park
> ---
> Documentation/devicetree/bindings/mfd/max14577.txt | 48
> ++
On Tue, 3 Dec 2013, Konrad Rzeszutek Wilk wrote:
> diff --git a/arch/x86/xen/platform-pci-unplug.c
> b/arch/x86/xen/platform-pci-unplug.c
> index 0a78524..087dfeb 100644
> --- a/arch/x86/xen/platform-pci-unplug.c
> +++ b/arch/x86/xen/platform-pci-unplug.c
> @@ -69,6 +69,24 @@ static int check_plat
MAX14577 chip is a multi-function device which includes MUIC,
charger and voltage regulator. The driver is located in drivers/mfd.
This patch adds regulator driver for MAX14577 chip. There are two
regulators in this chip:
1. Safeout LDO with constant voltage output of 4.9V. It can be only
enabl
Add document describing device tree bindings for MAX14577 MFD driver.
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Kyungmin Park
---
Documentation/devicetree/bindings/mfd/max14577.txt | 48
1 file changed, 48 insertions(+)
create mode 100644 Documentation/devicetree
Hi,
This is sixth version of patchset adding drivers for MAXIM 14577 chip.
Some parts (MFD, extcon) were already merged by maintainers so I removed them
from the patchset.
This version of patchset depends on the max14577 MFD core driver:
- mfd: max14577: Add max14577 MFD driver core
Merged in
MAX14577 chip is a multi-function device which includes MUIC, charger
and voltage regulator. The driver is located in drivers/mfd.
This patch supports battery charging control of MAX14577 chip and
provides power supply class information to userspace.
Signed-off-by: Krzysztof Kozlowski
Signed-off
Adding perf record support for new branch stack filter criteria
PERF_SAMPLE_BRANCH_COND.
Signed-off-by: Anshuman Khandual
Reviewed-by: Stephane Eranian
---
tools/perf/builtin-record.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
i
This patch adds conditional branch filtering support,
enabling it for PERF_SAMPLE_BRANCH_COND in perf branch
stack sampling framework by utilizing an available
software filter X86_BR_JCC.
Signed-off-by: Anshuman Khandual
Reviewed-by: Stephane Eranian
---
arch/x86/kernel/cpu/perf_event_intel_lbr
Enables conditional branch filter support for POWER8
utilizing MMCRA register based filter and also invalidates
any BHRB branch filter combination.
Signed-off-by: Anshuman Khandual
---
arch/powerpc/perf/power8-pmu.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/per
Generic powerpc branch instruction analysis support added in the code
patching library which will help the subsequent patch on SW based
filtering of branch records in perf. This patch also converts and
exports some of the existing local static functions through the header
file to be used else where
This patch simply changes the name of the variable from "bhrb_filter" to
"bhrb_hw_filter" in order to add one more variable which will track SW
filters in generic powerpc book3s code which will be implemented in the
subsequent patch.
Signed-off-by: Anshuman Khandual
---
arch/powerpc/perf/core-bo
Powerpc kernel now supports SW based branch filters for book3s systems with some
specifc requirements while dealing with HW supported branch filters in order to
achieve overall OR semantics prevailing in perf branch stack sampling framework.
This patch adapts the BHRB branch filter configuration to
On Wed, Sep 25, 2013 at 01:22:55PM +0900, Milo Kim wrote:
> LP3943 is an integrated device capable of driving 16 output channels.
> It can be used for GPIO expander and PWM generators.
> LP3493 registers are controlled via the I2C interface.
>
> This patch-set consists of four parts - MFD, GPIO, P
This patch adds enumeration for all available SW branch filters
in powerpc book3s code and also streamlines the look for the
SW branch filter entries while trying to figure out which all
branch filters can be supported in SW.
Signed-off-by: Anshuman Khandual
---
arch/powerpc/perf/core-book3s.c |
This patchset is the re-spin of the original branch stack
sampling
patchset which introduced new PERF_SAMPLE_BRANCH_COND branch filter. This
patchset
also enables SW based branch filtering support for book3s powerpc platforms
which
have PMU HW backed branch stack sampling support
This patch enables SW based post processing of BHRB captured branches
to be able to meet more user defined branch filtration criteria in perf
branch stack sampling framework. These changes increase the number of
branch filters and their valid combinations on any powerpc64 server
platform with BHRB
POWER8 PMU based BHRB supports filtering for conditional branches.
This patch introduces new branch filter PERF_SAMPLE_BRANCH_COND which
will extend the existing perf ABI. Other architectures can provide
this functionality with either HW filtering support (if present) or
with SW filtering of instru
Adding documentation support for conditional branch filter.
Signed-off-by: Anshuman Khandual
Reviewed-by: Stephane Eranian
---
tools/perf/Documentation/perf-record.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Do
On Wed, Sep 25, 2013 at 01:25:09PM +0900, Milo Kim wrote:
> Bindings for LP3943 MFD, GPIO and PWM controller are added.
>
> Cc: devicet...@vger.kernel.org
> Cc: Lee Jones
> Cc: Linus Walleij
> Cc: Samuel Ortiz
> Cc: Thierry Reding
> Signed-off-by: Milo Kim
> ---
> .../devicetree/bindings/gpi
On Mon, 25 Nov 2013, dt.ta...@gmail.com wrote:
> diff --git a/drivers/irqchip/irq-zevio.c b/drivers/irqchip/irq-zevio.c
> +static void zevio_irq_ack(struct irq_data *irqd)
> +{
> + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(irqd);
> + struct irq_chip_regs *regs =
> +
On Wed, Sep 25, 2013 at 01:24:38PM +0900, Milo Kim wrote:
> This is the other of the LP3943 MFD driver.
> LP3943 can be used as a PWM generator, up to 2 channels.
>
> * Two PWM generators supported
>
> * Supported PWM operations
> request, free, config, enable and disable
>
> * Pin assignment
On 11/29/2013 06:38 AM, Sekhar Nori wrote:
On Wednesday 27 November 2013 08:01 PM, Ivan Khoronzhuk wrote:
The problem that the set timings code contains the call of Davinci
platform function davinci_aemif_setup_timing() which is not
accessible if kernel is built for another platform like Keyston
On 12/04/2013 11:22 AM, Thierry Reding wrote:
> The conf and of_id variables are assigned but never used, so they may as
> well just be removed.
>
> Signed-off-by: Thierry Reding
Acked-by: Daniel Mack
> ---
> arch/arm/mach-pxa/irq.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a
Clean up the aio ring file in the fail path of aio_setup_ring
and ioctx_alloc. And maybe it can fix the GPF issue reported by
Dave Jones:
https://lkml.org/lkml/2013/11/25/898
Signed-off-by: Gu Zheng
---
fs/aio.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/
At Mon, 2 Dec 2013 11:09:43 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.10.22 release.
> There are 173 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
At Mon, 2 Dec 2013 11:05:41 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.4.72 release.
> There are 60 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
The conf and of_id variables are assigned but never used, so they may as
well just be removed.
Signed-off-by: Thierry Reding
---
arch/arm/mach-pxa/irq.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
index b6cc1816463e..0eecd83c624e 10064
On Wed, Dec 04, 2013 at 12:36:51AM +0800, Hanjun Guo wrote:
> Add Kconfigs to build ACPI on ARM64, and make ACPI runable on ARM64.
>
> acpi_idle driver is x86/IA64 dependent now, so make CONFIG_ACPI_PROCESSOR
> depends on X86 || IA64, and implement it on ARM in the furture.
>
> In order to make a
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Thereby, removing old phy-samsung-usb3 driver and related code
used untill now which was based on usb/phy framework
Add device tree nodes for DWC3 controller present on
Exynos 5420 SoC, to enable support for USB 3.0.
Signed-off-by: Vivek Gautam
---
arch/arm/boot/dts/exynos5420.dtsi | 38 +++-
1 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ex
Arnaldo Carvalho de Melo wrote:
> static inline percent_color_snprintf(...)
> {
> return value_color_snprintf(...);
> }
The issue with this suggestion is that the prototype of
percent_color_snprintf() is:
int percent_color_snprintf(char *bf, size_t size, const char *fmt, ...)
So, I can
Update device tree bindings for DWC3 controller and
USB 3.0 phy present on Exynos 5250 SoC, to start using
the phy driver based on generic phy framework.
Signed-off-by: Vivek Gautam
---
arch/arm/boot/dts/exynos5250.dtsi | 16 ++--
1 files changed, 6 insertions(+), 10 deletions(-)
This patch adds an accessor function for IRQ_PER_CPU flag.
The accessor function is useful to determine whether an IRQ is percpu or not.
This patch is based on an older patch posted by Chris Smith here [1].
There is a minor change w.r.t. Chris's original patch: The accessor function
is renamed as
* Arnaldo Carvalho de Melo wrote:
> Em Mon, Dec 02, 2013 at 12:58:35PM -0700, David Ahern escreveu:
> > On 12/2/13, 12:38 PM, Arnaldo Carvalho de Melo wrote:
> > >Can you suggest a better name for the option being discussed?
>
> > >Perhaps one of:
>
> > >--show-event-time
> > >--event-time
>
Adding a phy driver for USB 3.0 PHY controller present on Exynos5
series of SoCs alongwith DWC3 controller for USB 3.0 operations.
Few functions used in this driver to translate ref clock rate are
common to Kamil's usb2.0 phy driver [1]. So we can figure out how
to re-use them across these drivers
Add device tree nodes for USB 3.0 PHY present alongwith
USB 3.0 controller Exynos 5420 SoC. This phy driver is
based on generic phy framework.
Signed-off-by: Vivek Gautam
---
arch/arm/boot/dts/exynos5420.dtsi | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --
This patch series adds support to handle interrupt registration/deregistration
in arm64 pmu driver when pmu interrupt type is percpu.
Changelog:
V7:
* In arm64 pmu driver: Instead of passing 'struct arm_pmu' pointer, pass the
irq number directly to armpmu_[enable/disable]_percpu_irq().
Clean-u
Add support for irq registration when pmu interrupt is percpu.
Signed-off-by: Vinayak Kale
Signed-off-by: Tuan Phan
---
arch/arm64/kernel/perf_event.c | 108 +---
1 file changed, 78 insertions(+), 30 deletions(-)
diff --git a/arch/arm64/kernel/perf_event.c
>>
>> Could you do something clever with just one flag? Probably yes. But I
>> doubt it would
>> be that much cleaner, this is just the way that patching sites work.
>
> Thank you for spending your time to listen to me.
>
Don't worry! I thank you for carrying this forward.
> Let me try to explain
On Wed, 04 Dec 2013, Stefan Agner wrote:
> Am 2013-12-04 09:10, schrieb Lee Jones:
> >> +int tps6586x_get_version(struct device *dev)
> >> +{
> >> + struct tps6586x *tps6586x = dev_get_drvdata(dev);
> >> +
> >> + return tps6586x->version;
> >> +}
> >> +EXPORT_SYMBOL_GPL(tps6586x_get_version);
>
On Wed, Dec 04, 2013 at 10:59:46AM +0800, Bo Shen wrote:
> Hi Thierry,
>
> On 12/03/2013 05:43 PM, Thierry Reding wrote:
> >On Tue, Dec 03, 2013 at 11:09:12AM +0800, Bo Shen wrote:
> >>On 12/02/2013 06:59 PM, Thierry Reding wrote:
> >>>On Mon, Nov 18, 2013 at 05:13:21PM +0800, Bo Shen wrote:
> >[.
Hi,
Am Dienstag, den 03.12.2013, 15:28 +0100 schrieb Frank Haverkamp:
> + */
> +struct genwqe_mem {
> + unsigned long addr;
> + unsigned long size;
> + int direction;
> +};
> +
> +#define GENWQE_PIN_MEM _IOWR(GENWQE_IOC_CODE, 40, struct
> genwqe_mem *)
> +#define GENWQE_UNP
* Arnaldo Carvalho de Melo wrote:
> Em Mon, Dec 02, 2013 at 05:36:20PM +0100, Ingo Molnar escreveu:
> > * Namhyung Kim wrote:
> > > 2013-12-02 (월), 13:57 +0100, Ingo Molnar:
> > > > So basically, in the end I think it should be possible to have the
> > > > following behavior:
>
> > > >per
On Wed, Dec 04, 2013 at 10:02:44AM +0800, Chris Ruehl wrote:
> usb: phy-tegra-usb.c: wrong pointer check for remap UTMI
>
> A wrong pointer was used to test the result of devm_ioremap()
>
> Signed-off-by: Chris Ruehl
> Acked-by: Venu Byravarasu
> ---
> drivers/usb/phy/phy-tegra-usb.c |2 +-
Hi Hiroshi,
On Wed, Dec 04, 2013 at 07:40:27AM +, Hiroshi Doyu wrote:
> On Mon, 25 Nov 2013 14:49:37 +0100
> Hiroshi Doyu wrote:
>
> > Hi Joerg,
> >
> > Do you have some time to review this patch along with the following ones?
> >
> > [PATCHv6 02/13] iommu/of: introduce a global iommu de
On 2013-12-03 16:25, Roger Quadros wrote:
> Hi,
>
> This is a follow up solution to the original series in [1]
>
> The first patch fixes the OMAP4 Panda USB detection problems on 3.13-rc1
> with u-boot v2013.10.
>
> The remaining 2 patches are required if SOFTRESET needs to be done for the
> USB
Hi Arnd,
thanks for helping to review the code.
Am Dienstag, den 03.12.2013, 16:05 +0100 schrieb Arnd Bergmann:
> On Tuesday 03 December 2013, Frank Haverkamp wrote:
> > Ohh, sorry __u64 of course:
> >
> > /* common struct for chip image exchange */
> > struct genwqe_bitstream {
> > __u6
Check for cpu_map__dummy_new() or cpu_map__new() to be called in
perf_evlist__create_maps() is more complicated. This patch moves
the checking work into target.h, combining two conditions and making
perf_evlist__create_maps() more readable.
Signed-off-by: Dongsheng Yang
---
tools/perf/util/evlis
* David Ahern wrote:
> On 12/2/13, 10:44 PM, Namhyung Kim wrote:
> >>Right now 'perf stat -i' i used for '--no-inherit', perhaps we can just
> >>have --no-inherit have no short option and grab -i to have the same
> >>meaning as in 'report', 'script', etc.
> >
> >Agreed. Maybe we could change it
In machine__get_kernel_start_addr, the code, which is
using machine->root_dir to build filename, works for both
host and guests initialized from guestmount. So this patch
remove the branch for machine__is_host.
Signed-off-by: Dongsheng Yang
---
tools/perf/util/machine.c | 14 +-
1 fi
As we have changed the default behavior of perf kvm to --guest enabled,
the document about perf kvm record is outdated. This patch update it to
show the correct output with --host/--guest/neither/both of them.
Signed-off-by: Dongsheng Yang
---
tools/perf/Documentation/perf-kvm.txt | 15 +
As the buildid is read from /sys/kernel/notes, then if we use perf kvm
buildid-list
with a perf data file captured by perf kvm record with --guestkallsyms and
--guestmodules,
there is no result in output. This patch add a explanation about it and add a
limit
of using perf kvm buildid-list.
Sign
As option --host and --guest request no input for it, there should
not be a '=' after them in Document. And --output request a filename
as the input, so there should be a '=' after it. This patch remove
the wrong '=' after --guest and --host, and add a '=' after --output
in perf-kvm.txt.
Signed-of
Hi all,
When I read the code and document of perf tool as a newbie,
I feel confused in some places. Then I made some patches here to make
them more clear.
Please help to review them.
Note: The last 3 commits are all about perf-kvm.txt. I splite them
to make the logic more clear. I
Hi Chris,
On Wed, Dec 04, 2013 at 03:16:21PM +0800, Chris Ruehl wrote:
> On Tuesday, December 03, 2013 04:15 PM, Heikki Krogerus wrote:
> >On Mon, Dec 02, 2013 at 03:05:19PM +0800, Chris Ruehl wrote:
> >>@@ -154,6 +164,27 @@ int usb_phy_gen_create_phy(struct device *dev, struct
> >>usb_phy_gen_xc
601 - 700 of 770 matches
Mail list logo
