On Tue, 31 May 2016, Dave Hansen wrote:
> On 05/31/2016 01:41 PM, Jacob Pan wrote:
> > --- a/drivers/powercap/intel_rapl.c
> > +++ b/drivers/powercap/intel_rapl.c
> > @@ -1137,6 +1137,7 @@ static const struct x86_cpu_id rapl_ids[] __initconst
> > = {
> > RAPL_CPU(0x57, rapl_defaults_hsw_server
On Tue, 31 May 2016, Hans Ulli Kroll wrote:
> @@ -152,6 +153,9 @@ static int __init cs5535_mfgpt_init(void)
> }
> cs5535_event_clock = timer;
>
> + clockevents_config_and_register(&cs5535_clockevent, MFGPT_HZ,
> + 0xF, 0xFFFE);
> +
> /* Se
On Wed, Jun 01, 2016 at 10:45:51AM +0800, Chen-Yu Tsai wrote:
> On Wed, Jun 1, 2016 at 3:01 AM, Maxime Ripard
> wrote:
> > Hi,
> >
> > On Wed, Jun 01, 2016 at 12:23:23AM +0800, Chen-Yu Tsai wrote:
> >> These 3 regulators are provided in sunxi-common-regulators.dtsi.
> >> 3.0V/3.3V and 5.0V are com
On Wed 01-06-16 00:29:33, Oleg Nesterov wrote:
> On 05/31, Michal Hocko wrote:
> >
> > On Mon 30-05-16 19:35:05, Oleg Nesterov wrote:
> > >
> > > Well, let me suggest this again. I think it should do
> > >
> > >
> > > if (SIGNAL_GROUP_COREDUMP)
> > > return false;
> > >
> > > if (SIGN
On Tue, 31 May 2016, Neil Armstrong wrote:
> +static int oxnas_rps_timer_shutdown(struct clock_event_device *evt)
> +{
> + struct oxnas_rps_timer *rps =
> + container_of(evt, struct oxnas_rps_timer, clkevent);
> +
> + if (!clockevent_state_periodic(evt))
> + return 0
On Tue 31-05-16 23:43:38, Oleg Nesterov wrote:
> On 05/31, Michal Hocko wrote:
> >
> > On Mon 30-05-16 21:28:57, Oleg Nesterov wrote:
> > >
> > > I don't think we can trust vfork_done != NULL.
> > >
> > > copy_process() doesn't disallow CLONE_VFORK without CLONE_VM, so with
> > > this patch
> > >
On Wed, Jun 01, 2016 at 07:52:31AM +0200, Daniel Wagner wrote:
> Hi,
>
> I got the error message below while compiling a kernel
> on that system. I can't really say if I did something
> which made the file system unhappy before the crash.
>
>
> [Jun 1 07:41] XFS (sde1): Internal error xfs_trans
The dt binding document for Marvell bt-sd8897 specify the
'marvell,wakeup-pin' and 'marvell,gpio-gap-ms' attributes to be a 32-bit
value, but the driver parse it as 16-bit instead. Fix this to meet the
dt-binding document, and to be consistent with the 'marvell,wakeup-pin'
property in the mwifiex d
Device-tree binding documentation for Xilinx zynqmp dma engine
used in Zynq UltraScale+ MPSoC.
Acked-by: Rob Herring
Signed-off-by: Punnaiah Choudary Kalluri
Signed-off-by: Kedareswara rao Appana
---
Changes in v10:
- Added Rob Acked-by in the commit message.
Changs in v9:
- Removed include sg
Added the driver for zynqmp dma engine used in Zynq
UltraScale+ MPSoC. This dma controller supports memory to memory
and memory to I/O buffer transfers.
Signed-off-by: Punnaiah Choudary Kalluri
Signed-off-by: Kedareswara rao Appana
---
Changes for v10:
- Use 64bit write for 64-bit platforms as s
Please ignore this patch. I think we should make the driver parse 32
bit value instead (to be consistent with mwifiex driver).
On Wed, Jun 1, 2016 at 11:09 AM, Wei-Ning Huang wrote:
> The property marvell,wakeup-pin and marvell,wakeup-gap-ms are read as
> u16 in the driver. Fix documentation and
The dt binding document for Marvell bt-sd8897 specify the
'marvell,wakeup-pin' and 'marvell,wakeup-gap-ms' attributes to be a 32-bit
value, but the driver parse it as 16-bit instead. Fix this to meet the
dt-binding document, and to be consistent with the 'marvell,wakeup-pin'
property in the mwifiex
Driver supports two paths of device instantiation: as platform and i2c
device. In the platform path it lacks of storing the driver specific
structure as drvdata.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. New patch.
---
drivers/usb/misc/usb3503.c | 1 +
1 file changed, 1 inser
The driver should clean up after itself by unpreparing the clock when it
is unbound.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
Changes since v1:
1. Add Javier's tag.
2. Follow Javier's suggestion - the 'hub' cannot be null now.
---
drivers/usb/misc/usb3503.c
Hi Linus,
here are three pin control fixes for v4.7. Not much, and just driver
fixes.
Please pull them in!
Yours,
Linus Walleij
The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
are available in the git repository at:
g
Hi all
In v7 thread Lorenzo has summarized a roadmap to
get ACPI support for PCI controllers upstream.
The second point of the roadmap was
<< 2) In a real world (1) is not enough. Some ARM64 platforms, not entirely
ECAM compliant, already shipped with the corresponding firmware that
w
On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
> @@ -530,6 +683,8 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
> }
> mutex_unlock(&udc_lock);
>
> + mutex_unlock(&udc_lock);
> +
Here, you have one more mutex_unlock.
Peter
> kobject_uevent(&udc->dev.
Implementations might use different IRQs for
host, gadget and OTG so use named interrupt resources
to allow Device tree to specify the 3 interrupts.
Following are the interrupt names
Peripheral Interrupt - peripheral
HOST Interrupt - host
OTG Interrupt - otg
We still maintain backward compatibil
On (06/01/16 15:47), Minchan Kim wrote:
[..]
> > so both BUILTIN and BUILT-AS-A-MODULE cases are handled at compile
> > time now and we can avoid crypto_has_comp() checks for most of the
> > comp_algorithm calls, except for the case when someone requests an
> > out-of-tree module.
>
> Hmm, isn't i
On Wednesday, June 1, 2016 3:30:03 PM CEST Masahiro Yamada wrote:
> Hi Arnd.
>
> 2016-05-31 18:21 GMT+09:00 Arnd Bergmann :
> > On Tuesday, May 31, 2016 5:17:08 PM CEST Masahiro Yamada wrote:
> >> Commit 307d40c56b0c ("ARM: uniphier: rework SMP code to support new
> >> System Bus binding") added a
Hi,
[cut]
> > We could have a parameter (say "send_lid_open_on_resume" or
> > "use_bios_lid_value") in acpi/button.c which would allow people to
> > choose if they want the "new" behavior or the old one. And we could
> > also add some DMI matching for the messed up laptops/tablets where
> we
> > f
On Wed, Jun 01, 2016 at 07:36:42AM +0200, Krzysztof Kozlowski wrote:
> > No really for this patch, but I would much prefer to document them next
> > to the code in the long run. Also I really think these BIT() macros
> > are a distraction compared to the (1 << N) notation.
>
> Not much difference
If bootloader has set a wrong DPLL then we must trash those values
and re-program it anyways. This fixes USB3 devices not being enumerated
on Beagleboard-x15 if usb was started in u-boot. (e.g. v2016.05)
We don't re-program SATA DPLL if it is locked as it was causing
SATA failures if device was ho
This patch adds the necessary members to user_struct. The idea behind
the solution is really simple - user the userns pointers as keys into
a hash table which holds the inotify instances/watches counts. This
allows to account the limits per userns rather than per real user,
which makes certain scen
Signed-off-by: Nikolay Borisov
---
fs/notify/fdinfo.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c
index fd98e5100cab..62068f89d144 100644
--- a/fs/notify/fdinfo.c
+++ b/fs/notify/fdinfo.c
@@ -13,7 +13,10 @@
#include
#include
+#ifdef CONFIG_
This change is required since the inotify-per-namespace code added
hashtable.h to the include list of sched.h. This in turn causes
compiler warnings since HASH_SIZE is being defined in multiple
locations
Signed-off-by: Nikolay Borisov
---
fs/logfs/dir.c | 6 +++---
net
Currently the inotify instances/watches are being accounted in the
user_struct structure. This means that in setups where multiple
users in unprivileged containers map to the same underlying
real user (e.g. user_struct) the inotify limits are going to be
shared as well which can lead to unplesa
Looks fine,
Reviewed-by: Christoph Hellwig
Signed-off-by: Nikolay Borisov
---
fs/notify/inotify/inotify_fsnotify.c | 14 +-
fs/notify/inotify/inotify_user.c | 23 +++
include/linux/sched.h| 2 --
3 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/fs/notify/inotify/inotify_
On Tue, May 31, 2016 at 02:05:09PM +0200, Johannes Thumshirn wrote:
> Add helpers to request and release a device's memory or I/O regions.
>
> With these helpers in place, one does not need to select a device's memory or
> I/O regions with pci_select_bars() prior to requesting or releasing them.
>
Looks fine,
Reviewed-by: Christoph Hellwig
On Wed, Jun 01, 2016 at 07:07:13AM +0200, Mike Galbraith wrote:
> On Tue, 2016-05-31 at 09:31 +0800, Yuyang Du wrote:
> > On Tue, May 31, 2016 at 11:21:46AM +0200, Peter Zijlstra wrote:
> > > On Tue, May 31, 2016 at 09:11:37AM +0800, Yuyang Du wrote:
> > > > The SD_BALANCE_WAKE is irrelevant in the
On Tue, May 31, 2016 at 02:05:11PM +0200, Johannes Thumshirn wrote:
> Now that we do have pci_request_mem_regions() and pci_release_mem_regions() at
> hand, use it in the lpfc driver.
This should read lpfc instead of scsi in the subject line.
Also the request side of the patch seems to be missing
On 06/01/2016 09:03 AM, Thomas Gleixner wrote:
> On Tue, 31 May 2016, Neil Armstrong wrote:
>> +static int oxnas_rps_timer_shutdown(struct clock_event_device *evt)
>> +{
>> +struct oxnas_rps_timer *rps =
>> +container_of(evt, struct oxnas_rps_timer, clkevent);
>> +
>> +if (!cloc
On Tue, May 31, 2016 at 02:05:13PM +0200, Johannes Thumshirn wrote:
> Now that we do have pci_request_mem_regions() and pci_release_mem_regions() at
> hand, use it in the ethernet drivers.
This should probably be one patch per driver.
On Tue, May 31, 2016 at 12:35 PM, Paolo Bonzini wrote:
>
>
> On 08/01/2016 19:42, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers GPF in kvm_lapic_latched_init if run in
>> a parallel loop:
>> https://gist.githubusercontent.com/dvyukov/524b398f379440b21115/raw/9627095f57a72501f
On 31/05/2016 at 22:29:56 +0200, Arnd Bergmann wrote :
> The mwave driver has its own macros for the BOOLEAN type and the
> TRUE/FALSE values. This is redundant because the kernel already
> has bool/true/false, and it clashes with the ACPI headers that
> also define these types. The linux/acpi.h he
Parse usb-pwrseq property from Device Tree to get the phandle to pwrseq
device. The pwrseq device will be used by USB hub to cycle the power
before activating ports.
Signed-off-by: Krzysztof Kozlowski
---
drivers/usb/core/hub.h | 3 +++
drivers/usb/core/port.c | 15 +++
2 files ch
Hi,
My third approach for a USB power sequence which fixes usb3503+lan
on Odroid U3 board if it was initialized by bootloader
(e.g. for TFTP boot).
Changes since v2
1. Add Javier's reviewed-by tags. Address some comments.
2. Re-use existing properties for GPIOs etc by pwrseq-si
The power sequence hooks (mmc_pwrseq_pre_power_on(),
mmc_pwrseq_post_power_on() and mmc_pwrseq_power_off()) can be made more
generic to allow re-use in other subsystems. They do not need to take
pointer to struct mmc_host but instead the struct pwrseq should be
sufficient.
Remove the "mmc" prefix
FYI, we noticed the following commit:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit df1e2f56632ddf17186f7036a3bd809d3aed8fd8 ("oom_reaper: close race with
exiting task")
on test machine: vm-lkp-wsx03-openwrt-i386: 1 threads qemu-system-i386
-enable-kvm wit
On Wed, Jun 01, 2016 at 12:59:29AM -0700, Christoph Hellwig wrote:
> On Tue, May 31, 2016 at 02:05:11PM +0200, Johannes Thumshirn wrote:
> > Now that we do have pci_request_mem_regions() and pci_release_mem_regions()
> > at
> > hand, use it in the lpfc driver.
>
> This should read lpfc instead of
Hi Nicolai,
Yes, I think this is too ugly:
#!/usr/bin/gawk {exit system("/bin/sh -c 'exec \"$(dirname
\"$0\")\"/subdir/catself \"$0\"' " FILENAME);}
Imagine you have that feature in your kernel would you rather use:
#!{dirname}/subdir/catself
You second advice involves changing root fs which
Add support for deferred probing to the usb hub. Currently EPROBE_DEFER
does not exist in usb hub path but future patches will add it on the
port level.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
drivers/usb/core/hub.c | 6 --
1 file changed, 4 insertions(
Some USB devices on embedded boards have external power supply which has
to be reset in certain conditions. Add pwrseq interface for this.
Signed-off-by: Krzysztof Kozlowski
---
drivers/power/pwrseq/pwrseq.c | 47 ++-
include/linux/pwrseq.h| 11 +++
On Odroid U3 (Exynos4412-based) board if USB was initialized by
bootloader (in U-Boot "usb start" before tftpboot), the HUB (usb3503)
and LAN (smsc95xx) after after successful probing were not visible in the
system ("lsusb").
In such case the devices had to be fully reset before configuring.
Reset
The MMC power sequence drivers are useful also outside of MMC world: for
USB devices needed a hard-reset before probing. Before extending and
re-using pwrseq drivers, move them to a new place.
The commit does not introduce significant changes in the pwrseq drivers
code so still all the functions a
On Wed, Jun 1, 2016 at 9:51 AM, Zheng, Lv wrote:
> Hi,
>
> [cut]
>> > We could have a parameter (say "send_lid_open_on_resume" or
>> > "use_bios_lid_value") in acpi/button.c which would allow people to
>> > choose if they want the "new" behavior or the old one. And we could
>> > also add some DMI
Switch the control of buck8 to GPIO mode. It is faster than I2C/register
mode and it is the easiest way to disable it (regulator state is a
logical OR state of GPIO and register value).
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos4412-odr
Hi,
Roger Quadros writes:
> Implementations might use different IRQs for
> host, gadget and OTG so use named interrupt resources
> to allow Device tree to specify the 3 interrupts.
>
> Following are the interrupt names
>
> Peripheral Interrupt - peripheral
> HOST Interrupt - host
> OTG Interrupt
Some devices need real hard-reset by cutting the power. During power
sequence turn off and on the regulator, if it is provided.
Additionally add support for instantiating the pwrseq-simple device on a
generic property 'power-sequence'. The device will attach itself to the
node containing the pro
The "mmc" prefix is no longer needed after moving the pwrseq core code
from mmc/ to power/.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
drivers/power/pwrseq/pwrseq.c| 18 +-
drivers/power/pwrseq/pwrseq_emmc.c | 8
drivers/powe
The autodetection of attached USB device might not work on certain
boards where the power is delivered externally. These devices also might
require a hard reset. Use pwrseq for that in USB hub.
Signed-off-by: Krzysztof Kozlowski
---
drivers/usb/core/hub.c | 10 ++
1 file changed, 10 in
Allow build testing for power sequence drivers.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
drivers/power/pwrseq/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/power/pwrseq/Kconfig b/drivers/power/pwrseq/Kconfig
index 7ec
Hi Heiko,
On 05/31/2016 05:02 PM, Heiko Stübner wrote:
Hi Frank,
Am Dienstag, 31. Mai 2016, 14:40:10 schrieb Frank Wang:
Signed-off-by: Frank Wang
---
.../bindings/phy/phy-rockchip-inno-usb2.txt| 48
1 file changed, 48 insertions(+)
create mode 100644
Documen
On Wednesday, June 1, 2016 10:00:33 AM CEST Alexandre Belloni wrote:
> On 31/05/2016 at 22:29:56 +0200, Arnd Bergmann wrote :
> > The mwave driver has its own macros for the BOOLEAN type and the
> > TRUE/FALSE values. This is redundant because the kernel already
> > has bool/true/false, and it clas
Before moving pwrseq drivers from drivers/mmc/core/ to drivers/power/,
they were maintained by Ulf Hansson.
Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Javier Martinez Canillas
---
MAINTAINERS | 9 +
1 file changed, 9 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4f2a7
On Wed, Jun 01, 2016 at 02:52:57PM +0800, Kefeng Wang wrote:
> After patch "of/platform: Add common method to populate default bus",
> it is possible for arch code to remove unnecessary callers of
> of_platform_populate with default match table.
>
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: Ar
On Tue, May 31, 2016 at 10:20:34AM -0700, Guenter Roeck wrote:
> On Tue, May 31, 2016 at 03:43:56PM +0300, Heikki Krogerus wrote:
> > On Tue, May 31, 2016 at 03:09:01PM +0300, Heikki Krogerus wrote:
> > > On Tue, May 31, 2016 at 10:48:29AM +0200, Oliver Neukum wrote:
> > > > On Tue, 2016-05-31 at 1
On Friday, May 27, 2016 6:31:28 PM CEST Wenrui Li wrote:
> Hi,
>
> On 2016/5/27 15:13, Bharat Kumar Gogada wrote:
> >>>
> +
> +static int rockchip_pcie_rd_other_conf(struct rockchip_pcie_port *pp,
> + struct pci_bus *bus, u32 devfn,
> +
")
$ git fetch next
$ git describe next/master
next-20160601
$ git show df1e2f56632ddf17186f7036a3bd809d3aed8fd8:mm/oom_kill.c
fatal: Path 'mm/oom_kill.c' exists on disk, but not in
'df1e2f56632ddf17186f7036a3bd809d3aed8fd8'
So I am not sure which exact commit have you te
On 05/31/2016 04:42 AM, Michael Ellerman wrote:
> Hi Laurent,
>
> Sorry no. My next branch closed for 4.7 about 3 weeks ago.
>
> This series has been blocked for a long time on the gdb support, but that is
> now working. However it still doesn't pass its own selftests, and I had some
This series
Hi Greg,
Am 02.05.2016 um 20:36 schrieb Srinivas Kandagatla:
> Hi Greg,
>
> This is v3 patchset for the leftover 2 patches for nvmem regmap
> removal series [1]. These patches are based on char-misc tree.
>
> nvmem uses regmap_raw_read/write apis to read/write data from providers,
> With recent p
Currently we do not allow patch module to unload since there is no
method to determine if a task is still running in the patched code.
The consistency model gives us the way because when the unpatching
finishes we know that all tasks were marked as safe to call an original
function. Thus every new
On 1 June 2016 at 02:01, Yuyang Du wrote:
> On Wed, Jun 01, 2016 at 07:07:13AM +0200, Mike Galbraith wrote:
>> On Tue, 2016-05-31 at 09:31 +0800, Yuyang Du wrote:
>> > On Tue, May 31, 2016 at 11:21:46AM +0200, Peter Zijlstra wrote:
>> > > On Tue, May 31, 2016 at 09:11:37AM +0800, Yuyang Du wrote:
On 01/06/16 03:56, Wenrui Li wrote:
> Hi:
>
> On 2016/5/27 20:25, Marc Zyngier Wrote:
>> [+Lorenzo]
>>
>> On 20/05/16 11:29, Shawn Lin wrote:
>>> RK3399 has a PCIe controller which can be used as Root Complex.
>>> This driver supports a PCIe controller as Root Complex mode.
>>>
>
> []
>
>>>
On Wed, 2016-06-01 at 11:23 +0300, Heikki Krogerus wrote:
> On Tue, May 31, 2016 at 10:20:34AM -0700, Guenter Roeck wrote:
> > On Tue, May 31, 2016 at 03:43:56PM +0300, Heikki Krogerus wrote:
> > > On Tue, May 31, 2016 at 03:09:01PM +0300, Heikki Krogerus wrote:
> > > > On Tue, May 31, 2016 at 10:4
The macro CLOCKSOURCE_OF_DECLARE is widely used in the timer drivers.
Basically, this macro is defined to insert in a table a tuple name,function.
This function is an init function called when the name matches the DT node and
its signature is:
typedef void (*of_init_fn_1)(struct device_no
The init functions do not return any error. They behave as the following:
- panic, thus leading to a kernel crash while another timer may work and
make the system boot up correctly
or
- print an error and let the caller unaware if the state of the system
Change that by converting the init
The panel is not used by any legacy board files so the legacy (pdata) boot
support can be dropped.
Signed-off-by: Peter Ujfalusi
---
.../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 52 +++---
include/video/omap-panel-data.h| 27 ---
2 files change
The driver does not support legacy (pdata) based probing.
Signed-off-by: Peter Ujfalusi
---
drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tpd12s015.c
b/drivers/video/fbdev/omap2/
The panel is not used by any legacy board files so the legacy (pdata) boot
support can be dropped.
Signed-off-by: Peter Ujfalusi
---
.../fbdev/omap2/omapfb/displays/connector-hdmi.c | 42 --
include/video/omap-panel-data.h| 10 --
2 files changed, 6
The panel is not used by any legacy board files so the legacy (pdata) boot
support can be dropped.
Signed-off-by: Peter Ujfalusi
---
.../fbdev/omap2/omapfb/displays/encoder-tfp410.c | 44 +++---
include/video/omap-panel-data.h| 14 ---
2 files changed, 6
The default_device is no longer used, it is a leftower from legacy. The
else if (pdata->default_device) is always going to be false.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/dss/core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/core.c
b/dri
The omap_vout is only supported with omapfb. Switch the driver to use the
correct header file.
Signed-off-by: Peter Ujfalusi
---
drivers/media/platform/omap/omap_vout.c| 2 +-
drivers/media/platform/omap/omap_voutdef.h | 2 +-
drivers/media/platform/omap/omap_voutlib.c | 2 +-
3 files change
In legacy mode (non DT mode) support only composite connector type. The
only user for this is rx51, using composite type.
Dropping the connector_type selection via pdata will allow cleanups in
omapdss (drm vs fbdev).
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-an
The omap_display_init() is implemented in the mach-omap2/display.c so the
declaration should have been there as well.
Change the board files to include display.h to avoid build breakage at the
same time.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-ldp.c| 1 +
arch/arm/mac
Move the contents of the video/omapdss.h header file to omapdrm/dss local
header file and remove the original global header. The omapfb stach is
using video/omapfb_dss.h so this change will complete the separation of the
two driver implementation.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/dr
clampval() returns the clamped value instead of updating the variable
itself. And the driver is using it in a wrong way. Fix it.
Signed-off-by: Viresh Kumar
---
drivers/video/fbdev/pxafb.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/pxafb.
Hi Michal,
On Wed, 1 Jun 2016 10:24:58 +0200 Michal Hocko wrote:
>
> $ git describe next/master
> next-20160601
> $ git show df1e2f56632ddf17186f7036a3bd809d3aed8fd8:mm/oom_kill.c
> fatal: Path 'mm/oom_kill.c' exists on disk, but not in
> 'df1e2f56632ddf17186f70
From: xingzhen
3debb0a9ddb adding a "__used" to the variable in the
__trace_printk_fmt section. Sometimes it will cause
*iter to be NULL, then strcmp in lookup_format and
strcpy in hold_module_trace_bprintk_format will panic.
Signed-off-by: xingzhen
---
kernel/trace/trace_printk.c | 3 +++
1 f
On Tue, May 31, 2016 at 11:19:02AM +, He Kuang wrote:
> For determine the libunwind methods to use, we should get the
> 32bit/64bit information from maps of a thread. When a thread is newly
> created, the information is not prepared. This patch moves
> unwind__prepare_access() into thread__inse
On Tue, May 31, 2016 at 11:19:04AM +, He Kuang wrote:
SNIP
> ifndef NO_LIBUNWIND
> + have_libunwind :=
>ifneq ($(feature-libunwind), 1)
> msg := $(warning No libunwind found. Please install libunwind-dev[el] >=
> 1.1 and/or set LIBUNWIND_DIR);
> +NO_LOCAL_LIBUNWIND := 1
> + e
On Tue, May 31, 2016 at 11:19:01AM +, He Kuang wrote:
> Currently, libunwind operations are fixed, and they are chosen
> according to the host architecture. This will lead a problem that if a
> thread is run as x86_32 on x86_64 machine, perf will use libunwind
> methods for x86_64 to parse the
On Tue, May 31, 2016 at 11:19:01AM +, He Kuang wrote:
> Currently, libunwind operations are fixed, and they are chosen
> according to the host architecture. This will lead a problem that if a
> thread is run as x86_32 on x86_64 machine, perf will use libunwind
> methods for x86_64 to parse the
On Tue, May 31, 2016 at 11:19:08AM +, He Kuang wrote:
SNIP
> -int unwind__prepare_access(struct thread *thread)
> +int unwind__prepare_access(struct thread *thread, struct map *map)
> {
> - unwind__register_ops(thread, local_unwind_libunwind_ops);
> + const char *arch;
> + enum d
On Tue, May 31, 2016 at 11:19:11AM +, He Kuang wrote:
SNIP
> diff --git a/tools/perf/util/unwind-libunwind.c
> b/tools/perf/util/unwind-libunwind.c
> index e183390..5774317 100644
> --- a/tools/perf/util/unwind-libunwind.c
> +++ b/tools/perf/util/unwind-libunwind.c
> @@ -5,6 +5,7 @@
> #incl
On Tue, May 31, 2016 at 11:19:11AM +, He Kuang wrote:
SNIP
> +
> + ifeq ($(feature-libunwind-x86), 1)
> +$(call detected,CONFIG_LIBUNWIND_X86)
> +CFLAGS += -DHAVE_LIBUNWIND_X86_SUPPORT
> +LDFLAGS += -lunwind-x86
> +have_libunwind = 1
> + endif
> +
>ifneq ($(feature-libun
On Tue, May 31, 2016 at 11:19:11AM +, He Kuang wrote:
SNIP
> diff --git a/tools/perf/util/libunwind/x86_32.c
> b/tools/perf/util/libunwind/x86_32.c
> new file mode 100644
> index 000..46b4111
> --- /dev/null
> +++ b/tools/perf/util/libunwind/x86_32.c
> @@ -0,0 +1,18 @@
> +#define REMOTE_
On Tue, May 31, 2016 at 11:19:08AM +, He Kuang wrote:
SNIP
> -int unwind__prepare_access(struct thread *thread)
> +int unwind__prepare_access(struct thread *thread, struct map *map)
> {
> - unwind__register_ops(thread, local_unwind_libunwind_ops);
> + const char *arch;
> + enum d
On Tue, May 31, 2016 at 11:19:12AM +, He Kuang wrote:
SNIP
> diff --git a/tools/perf/util/Build b/tools/perf/util/Build
> index 7746e09..fced833 100644
> --- a/tools/perf/util/Build
> +++ b/tools/perf/util/Build
> @@ -102,6 +102,7 @@ libperf-$(CONFIG_LIBDW_DWARF_UNWIND) += unwind-libdw.o
> l
On Wed, Jun 01, 2016 at 01:00:10PM +0800, Huang, Ying wrote:
> Hi, Peter,
>
> Peter Zijlstra writes:
>
> > On Tue, May 31, 2016 at 04:34:36PM +0800, Huang, Ying wrote:
> >> Hi, Ingo,
> >>
> >> Part of the regression has been recovered in v4.7-rc1 from -32.9% to
> >> -9.8%. But there is still s
From: Thomas Gleixner
Add some more comments and reformat existing ones to kernel doc style.
Reviewed-by: Darren Hart
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
kernel/futex.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git
All drivers to include the omapdrm/dss/omapdss.h header file. This header
includes the
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 3 ++-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c| 4 ++--
drivers/gpu/drm/omapdrm/displays/co
Copy the content of video/omapdss.h to a new (video/omapfb_dss.h) header
file and convert the omapfb drivers to use this new file.
The new header file is needed to complete the separation of omapdrm and
omapfb implementation of DSS.
Signed-off-by: Peter Ujfalusi
---
.../omap2/omapfb/displays/co
The default_device is no longer used, it is a leftower from legacy. The
else if (pdata->default_device) is always going to be false.
Signed-off-by: Peter Ujfalusi
---
drivers/video/fbdev/omap2/omapfb/dss/core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb
Clean up the header files regarding to hdmi audio so the omap-hdmi-audio.h
file will only need to include the platform_data/omapdss.h file.
Signed-off-by: Peter Ujfalusi
CC: Mark Brown
CC: Jyri Sarha
CC: Liam Girdwood
---
drivers/gpu/drm/omapdrm/dss/hdmi.h | 1 +
drivers/video/fbdev/
The num_devices, **devices and *default_device is leftover from the past.
They can be removed as they are no used.
Signed-off-by: Peter Ujfalusi
---
include/video/omapdss.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 0c7ae93ebd76.
Instead of the full omapdss internal header, include only the platform_data
header.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-ldp.c| 2 +-
arch/arm/mach-omap2/board-rx51-video.c | 2 +-
arch/arm/mach-omap2/display.c | 2 +-
arch/arm/mach-omap2/dss-common.c
On Wed, Jun 01, 2016 at 02:10:45PM +0800, Boqun Feng wrote:
> On Wed, Jun 01, 2016 at 11:11:38AM +0800, Boqun Feng wrote:
> > Looks like I missed this one in v1, it should be
> >
> > return res;
Indeed.
> > because the primitives will return the values before modified by the
> > operati
1 - 100 of 1085 matches
Mail list logo
