[patch] mm, compaction: add vmstats for kcompactd work

A "compact_daemon_wake" vmstat exists that represents the number of times kcompactd has woken up. This doesn't represent how much work it actually did, though. It's useful to understand how much compaction work is being done by kcompactd versus other methods such as direct compaction and

[patch] mm, compaction: add vmstats for kcompactd work

A "compact_daemon_wake" vmstat exists that represents the number of times kcompactd has woken up. This doesn't represent how much work it actually did, though. It's useful to understand how much compaction work is being done by kcompactd versus other methods such as direct compaction and

Re: [PATCH] drm/mxsfb: fix pixel clock polarity

On 2016-12-07 16:59, Stefan Agner wrote: > On 2016-12-07 16:49, Marek Vasut wrote: >> On 12/08/2016 01:27 AM, Stefan Agner wrote: >>> The DRM subsystem specifies the pixel clock polarity from a >>> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means >>> the controller drives the data on

Re: [PATCH v2] inotify: Convert to using per-namespace limits

Nikolay Borisov writes: > Gentle ping, now that rc1 has shipped and Jan's sysctl concern hopefully > resolved. After getting slowed down by some fixes I am now taking a hard look at your patch in the hopes of merging it. Did you happen to see the kbuild test roboot boot

Re: [PATCH] drm/mxsfb: fix pixel clock polarity

On 2016-12-07 16:59, Stefan Agner wrote: > On 2016-12-07 16:49, Marek Vasut wrote: >> On 12/08/2016 01:27 AM, Stefan Agner wrote: >>> The DRM subsystem specifies the pixel clock polarity from a >>> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means >>> the controller drives the data on

Re: [PATCH v2] inotify: Convert to using per-namespace limits

Nikolay Borisov writes: > Gentle ping, now that rc1 has shipped and Jan's sysctl concern hopefully > resolved. After getting slowed down by some fixes I am now taking a hard look at your patch in the hopes of merging it. Did you happen to see the kbuild test roboot boot failures and did you

Re: [PATCH v2 3/3] USB: OHCI: nxp: remove useless extern declaration

On 12/08/2016 12:34 AM, csmanjuvi...@gmail.com wrote: > From: Manjunath Goudar > > Remove usb_disabled() extern declaration as it is already declared > as extern in include/linux/usb.h. > > Signed-off-by: Manjunath Goudar > Cc: Vladimir Zapolskiy

Re: [PATCH v2 3/3] USB: OHCI: nxp: remove useless extern declaration

On 12/08/2016 12:34 AM, csmanjuvi...@gmail.com wrote: > From: Manjunath Goudar > > Remove usb_disabled() extern declaration as it is already declared > as extern in include/linux/usb.h. > > Signed-off-by: Manjunath Goudar > Cc: Vladimir Zapolskiy > Cc: Sylvain Lemieux > Cc: Alan Stern > Cc:

Re: [PATCH] USB: OHCI: nxp: fix code warnings

On 12/08/2016 01:54 AM, csmanjuvi...@gmail.com wrote: > From: Manjunath Goudar > > This patch will fix the checkpatch.pl following warnings: > WARNING: Missing a blank line after declarations > WARNING: braces {} are not necessary for single statement blocks > >

Re: [PATCH] USB: OHCI: nxp: fix code warnings

On 12/08/2016 01:54 AM, csmanjuvi...@gmail.com wrote: > From: Manjunath Goudar > > This patch will fix the checkpatch.pl following warnings: > WARNING: Missing a blank line after declarations > WARNING: braces {} are not necessary for single statement blocks > > Signed-off-by: Manjunath Goudar

Re: [PATCH] platform: Introduce button support for the Surface 3

On Mon, Dec 05, 2016 at 04:10:33PM +0100, Benjamin Tissoires wrote: > The Surface 3 is not following the ACPI spec for PNP0C40, but nearly. > The device is connected to a I2C device that might have some magic > but we don't know about. > Just create the device after the enumeration and use the

Re: [PATCH] platform: Introduce button support for the Surface 3

On Mon, Dec 05, 2016 at 04:10:33PM +0100, Benjamin Tissoires wrote: > The Surface 3 is not following the ACPI spec for PNP0C40, but nearly. > The device is connected to a I2C device that might have some magic > but we don't know about. > Just create the device after the enumeration and use the

Re: [Intel-wired-lan] [PATCH 1/1] ixgbe: fcoe: return value of skb_linearize should be handled

Zhouyi Zhou wrote: diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c index fee1f29..4926d48 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c @@ -2173,8

Re: [Intel-wired-lan] [PATCH 1/1] ixgbe: fcoe: return value of skb_linearize should be handled

Zhouyi Zhou wrote: diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c index fee1f29..4926d48 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c @@ -2173,8 +2173,7 @@ static int

[RFC 02/10] lib/idr.c: delete useless condition

Whether or not we have a spare ida_bitmap hanging off ida->free_bitmap doesn't seem related to whether the embedded struct idr may have a spare struct idr_layer in its free list. So the only thing this condition does is increase the chance that we end up calling get_from_free_list in vain.

[RFC 02/10] lib/idr.c: delete useless condition

Whether or not we have a spare ida_bitmap hanging off ida->free_bitmap doesn't seem related to whether the embedded struct idr may have a spare struct idr_layer in its free list. So the only thing this condition does is increase the chance that we end up calling get_from_free_list in vain.

[RFC 00/10] implement alternative and much simpler id allocator

TL;DR: these patches save 250 KB of memory, with more low-hanging fruit ready to pick. While browsing through the lib/idr.c code, I noticed that the code at the end of ida_get_new_above() probably doesn't work as intended: Most users of ida use it via ida_simple_get(), and that starts by

[RFC 06/10] block: use tida as small id allocator

A struct ida ends up costing > 16 KB of runtime memory, which is quite a lot for something which on my laptop as of this writing has handed out 27 ids in its lifetime. So use the simpler and lighter-weight struct tida. Signed-off-by: Rasmus Villemoes ---

[RFC 00/10] implement alternative and much simpler id allocator

TL;DR: these patches save 250 KB of memory, with more low-hanging fruit ready to pick. While browsing through the lib/idr.c code, I noticed that the code at the end of ida_get_new_above() probably doesn't work as intended: Most users of ida use it via ida_simple_get(), and that starts by

[RFC 06/10] block: use tida as small id allocator

A struct ida ends up costing > 16 KB of runtime memory, which is quite a lot for something which on my laptop as of this writing has handed out 27 ids in its lifetime. So use the simpler and lighter-weight struct tida. Signed-off-by: Rasmus Villemoes --- block/blk-core.c | 6 +++---

[RFC 09/10] drm: use simpler id allocator

Using the recently introduced "tida" allocator for small integer ids saves about 100 KB of memory on my laptop - every struct ida from which a single id has been allocated uses at least 16 KB of memory due to the pre-allocation/caching of struct idr_layers (each worth a little over 2K).

[RFC 08/10] lib/tida.c: introduce tida_get_above

Some potential users want to impose a minimum on the returned id. Extend tida_get to accept a start parameter, renaming it to tida_get_above, and make tida_get a trivial wrapper. Signed-off-by: Rasmus Villemoes --- include/linux/tida.h | 8 +++- lib/tida.c

[RFC 10/10] fs/devpts: use tida for id allocation

Using the newly introduced tida for allocating pty indexes saves around 16KB of runtime memory. Since tida does it's own internal locking, we don't need to protect it with the _ptys_lock and do the whole "preallocate outside lock, loop if we're extremely unlucky", thus allowing us simplify

[RFC 10/10] fs/devpts: use tida for id allocation

Using the newly introduced tida for allocating pty indexes saves around 16KB of runtime memory. Since tida does it's own internal locking, we don't need to protect it with the _ptys_lock and do the whole "preallocate outside lock, loop if we're extremely unlucky", thus allowing us simplify

[RFC 09/10] drm: use simpler id allocator

Using the recently introduced "tida" allocator for small integer ids saves about 100 KB of memory on my laptop - every struct ida from which a single id has been allocated uses at least 16 KB of memory due to the pre-allocation/caching of struct idr_layers (each worth a little over 2K).

[RFC 08/10] lib/tida.c: introduce tida_get_above

Some potential users want to impose a minimum on the returned id. Extend tida_get to accept a start parameter, renaming it to tida_get_above, and make tida_get a trivial wrapper. Signed-off-by: Rasmus Villemoes --- include/linux/tida.h | 8 +++- lib/tida.c | 22

[RFC 07/10] drivers/base/platform.c: use simpler id allocator

Use the newly introduced tida allocator, which saves about 16 KB of memory. Signed-off-by: Rasmus Villemoes --- drivers/base/platform.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c

[RFC 01/10] lib/idr.c: reused free bitmaps are already clear

If we're recycling a previously used struct ida_bitmap, it ended up in ->free_bitmap precisely because it was all zeroes. Thus, by using kzalloc in ida_pre_get we can avoid doing the memset while holding whatever locks protects the ida (which, judging by the number of callers of ida_simple_get vs

[RFC 07/10] drivers/base/platform.c: use simpler id allocator

Use the newly introduced tida allocator, which saves about 16 KB of memory. Signed-off-by: Rasmus Villemoes --- drivers/base/platform.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index

[RFC 01/10] lib/idr.c: reused free bitmaps are already clear

If we're recycling a previously used struct ida_bitmap, it ended up in ->free_bitmap precisely because it was all zeroes. Thus, by using kzalloc in ida_pre_get we can avoid doing the memset while holding whatever locks protects the ida (which, judging by the number of callers of ida_simple_get vs

[RFC 05/10] kernel/workqueue.c: replace id allocator ida with tida

The implementation of the id allocator ida causes about 14 KB of unused memory to sit around in the embedded struct idr. Even if one could get rid of that, ida would still use at least one idr_layer worth 2 KB of memory as well as one idr_bitmap worth another 128 bytes, which is all a bit much if

[RFC 03/10] lib/idr.c: only fill ida->idr when needed

If I'm reading the code correctly, every call of ida_simple_get (and almost all users of ida use that) starts by calling ida_pre_get -> __idr_pre_get which fills up the free list of >idr with MAX_IDR_FREE (aka 8) struct idr_layers. After a successful id allocation, ida_get_new_above gets rid

[RFC 05/10] kernel/workqueue.c: replace id allocator ida with tida

The implementation of the id allocator ida causes about 14 KB of unused memory to sit around in the embedded struct idr. Even if one could get rid of that, ida would still use at least one idr_layer worth 2 KB of memory as well as one idr_bitmap worth another 128 bytes, which is all a bit much if

[RFC 03/10] lib/idr.c: only fill ida->idr when needed

If I'm reading the code correctly, every call of ida_simple_get (and almost all users of ida use that) starts by calling ida_pre_get -> __idr_pre_get which fills up the free list of >idr with MAX_IDR_FREE (aka 8) struct idr_layers. After a successful id allocation, ida_get_new_above gets rid

[PATCH] sched/fair: use user weight to calculate util_avg in post_init_entity_util_avg()

To calculate util_avg, se's weight should have the same resolution as cfs->avg.load_avg. So use user weight instead. Signed-off-by: T.Zhou --- kernel/sched/fair.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c

[PATCH] sched/fair: use user weight to calculate util_avg in post_init_entity_util_avg()

To calculate util_avg, se's weight should have the same resolution as cfs->avg.load_avg. So use user weight instead. Signed-off-by: T.Zhou --- kernel/sched/fair.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index

[RELEASE EOL] LTTng-modules 2.7 branch end of life

Hi, With the release of lttng-modules 2.9.0, the stable-2.7 branch is reaching its end of life with lttng-modules 2.7.7. It will therefore not be maintained anymore. lttng-modules 2.7.7 is the last release of that stable branch. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc.

[RFC 04/10] lib/tida.c: a very simple integer id allocator

The idr-based id allocator ida has a rather large memory footprint (despite claims to the contrary). For example, on my laptop, each of the six idas associated to the workqueues uses more than 16 KB of memory (most of which sits unused in the embedded idr structure), even though _combined_ they

[RELEASE EOL] LTTng-modules 2.7 branch end of life

Hi, With the release of lttng-modules 2.9.0, the stable-2.7 branch is reaching its end of life with lttng-modules 2.7.7. It will therefore not be maintained anymore. lttng-modules 2.7.7 is the last release of that stable branch. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc.

[RFC 04/10] lib/tida.c: a very simple integer id allocator

The idr-based id allocator ida has a rather large memory footprint (despite claims to the contrary). For example, on my laptop, each of the six idas associated to the workqueues uses more than 16 KB of memory (most of which sits unused in the embedded idr structure), even though _combined_ they

Re: [PATCH] Input: synaptics-rmi4 - fix debug for sensor clip

On Mon, Dec 05, 2016 at 01:04:41AM +, Nick Dyer wrote: > The debug would only ever output zero for the clip information. > > Signed-off-by: Nick Dyer Applied, thank you. > --- > > drivers/input/rmi4/rmi_f12.c | 7 ++- > 1 file changed, 2 insertions(+), 5

Re: [PATCH] Input: synaptics-rmi4 - fix debug for sensor clip

On Mon, Dec 05, 2016 at 01:04:41AM +, Nick Dyer wrote: > The debug would only ever output zero for the clip information. > > Signed-off-by: Nick Dyer Applied, thank you. > --- > > drivers/input/rmi4/rmi_f12.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git

Re: [PATCH 1/1] ixgbe: fcoe: return value of skb_linearize should be handled

Thanks Jeff for your advice, Sorry for the my innocence as a Linux kernel rookie. Zhouyi On Thu, Dec 8, 2016 at 1:30 AM, Jeff Kirsher wrote: > On Wed, 2016-12-07 at 15:43 +0800, Zhouyi Zhou wrote: >> Signed-off-by: Zhouyi Zhou >> Reviewed-by:

Re: [PATCH 1/1] ixgbe: fcoe: return value of skb_linearize should be handled

Thanks Jeff for your advice, Sorry for the my innocence as a Linux kernel rookie. Zhouyi On Thu, Dec 8, 2016 at 1:30 AM, Jeff Kirsher wrote: > On Wed, 2016-12-07 at 15:43 +0800, Zhouyi Zhou wrote: >> Signed-off-by: Zhouyi Zhou >> Reviewed-by: Cong Wang >> Reviewed-by: Yuval Shaia >>

Re: [PATCH 08/11] ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Tue, Nov 29, 2016 at 11:21 PM, Lv Zheng wrote: > ACPICA commit cac6790954d4d752a083e610b8a22febcd07 > > This patch back ports Linux acpi_get_table_with_size() and > early_acpi_os_unmap_memory() into ACPICA upstream to reduce divergences. > > The 2 APIs are used by Linux

Re: [PATCH 08/11] ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

On Tue, Nov 29, 2016 at 11:21 PM, Lv Zheng wrote: > ACPICA commit cac6790954d4d752a083e610b8a22febcd07 > > This patch back ports Linux acpi_get_table_with_size() and > early_acpi_os_unmap_memory() into ACPICA upstream to reduce divergences. > > The 2 APIs are used by Linux as table management

Re: Note on 4.10 merge window timing (was Re: Linux 4.9-rc8)

On Wed, Dec 7, 2016 at 4:04 PM, Al Viro wrote: > > Could you run this just before cutting 4.10-rc1? Sure. I hope you'll remind me just in case, though. Especially since xmas eve in the Torvalds household tends to involve glögg and snaps. Linus

Re: Note on 4.10 merge window timing (was Re: Linux 4.9-rc8)

On Wed, Dec 7, 2016 at 4:04 PM, Al Viro wrote: > > Could you run this just before cutting 4.10-rc1? Sure. I hope you'll remind me just in case, though. Especially since xmas eve in the Torvalds household tends to involve glögg and snaps. Linus

Re: [PATCH] drm/mxsfb: fix pixel clock polarity

On 2016-12-07 16:49, Marek Vasut wrote: > On 12/08/2016 01:27 AM, Stefan Agner wrote: >> The DRM subsystem specifies the pixel clock polarity from a >> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means >> the controller drives the data on pixel clocks falling edge. >> That is the

Re: [PATCH] drm/mxsfb: fix pixel clock polarity

On 2016-12-07 16:49, Marek Vasut wrote: > On 12/08/2016 01:27 AM, Stefan Agner wrote: >> The DRM subsystem specifies the pixel clock polarity from a >> controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means >> the controller drives the data on pixel clocks falling edge. >> That is the

[PATCH 08/12] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture

Add pinctrl groups for both GPT input capture channels. Signed-off-by: Steve Longerbeam --- arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi

[PATCH 08/12] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture

Add pinctrl groups for both GPT input capture channels. Signed-off-by: Steve Longerbeam --- arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi index

[PATCH 10/12] gpu: ipu-v3: Add ipu_unit_type enumeration

Adds an enumeration of the major IPUv3 subunits. Provide that info in struct ipu_client_platformdata to more easily determine the IPU client type. Signed-off-by: Steve Longerbeam --- include/video/imx-ipu-v3.h | 18 ++ 1 file changed, 18

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote: > Hi, > > Since the fbdev framework is in maintenance mode and all new display drivers > should be made with the DRM framework, remove the fbdev drivers from staging. > > Note: the patches are created with git format-patch -D, so they

[PATCH 04/12] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor. Both hang off the same i2c2 bus, so they require different (and non- default) i2c slave addresses. The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux. The OV5640 connects to the input port on the MIPI

[PATCH 10/12] gpu: ipu-v3: Add ipu_unit_type enumeration

Adds an enumeration of the major IPUv3 subunits. Provide that info in struct ipu_client_platformdata to more easily determine the IPU client type. Signed-off-by: Steve Longerbeam --- include/video/imx-ipu-v3.h | 18 ++ 1 file changed, 18 insertions(+) diff --git

Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Wed, 2016-11-23 at 10:03 +0200, Tomi Valkeinen wrote: > Hi, > > Since the fbdev framework is in maintenance mode and all new display drivers > should be made with the DRM framework, remove the fbdev drivers from staging. > > Note: the patches are created with git format-patch -D, so they

[PATCH 04/12] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor. Both hang off the same i2c2 bus, so they require different (and non- default) i2c slave addresses. The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux. The OV5640 connects to the input port on the MIPI

[PATCH 05/12] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors

Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor. The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux. The OV5640 connects to the input port on the MIPI CSI-2 receiver on mipi_csi. It is set to transmit over MIPI virtual channel 1. Until the OV5652

[PATCH 09/12] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder

Enables the ADV7180 decoder sensor. The ADV7180 connects to the parallel-bus mux input on ipu1_csi0_mux. On the sabreauto, two analog video inputs are routed to the ADV7180, composite on Ain1, and composite on Ain3. Those inputs are defined via inputs and input-names under the ADV7180 node. The

[PATCH 05/12] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors

Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor. The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux. The OV5640 connects to the input port on the MIPI CSI-2 receiver on mipi_csi. It is set to transmit over MIPI virtual channel 1. Until the OV5652

[PATCH 09/12] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder

Enables the ADV7180 decoder sensor. The ADV7180 connects to the parallel-bus mux input on ipu1_csi0_mux. On the sabreauto, two analog video inputs are routed to the ADV7180, composite on Ain1, and composite on Ain3. Those inputs are defined via inputs and input-names under the ADV7180 node. The

[PATCH 12/12] gpu: ipu-v3: Add smfc and ic client devices

Adds IPU client devices for the SMFC and IC task units. Signed-off-by: Steve Longerbeam --- drivers/gpu/ipu-v3/ipu-common.c | 87 +++-- include/video/imx-ipu-v3.h | 3 ++ 2 files changed, 87 insertions(+), 3 deletions(-)

[PATCH 03/12] ARM: dts: imx6qdl: add video capture devices and connections

From: Philipp Zabel This patch adds the IPU subunit devices involved in video capture and image conversion, and defines all the possible hardware connections between them via OF graphs. External to the IPU: Video input multiplexers are defined that multiplex inputs from

[PATCH 11/12] gpu: ipu-v3: lookup ipu client nodes by name

To allow for IPU clients containing multiple ports, they are no longer a single port node name, but have a name of the format "ipu_". So we can no longer use of_graph_get_port_by_id() to lookup the client node. Create the function of_get_ipu_client_node() that looks up the client node by node

[PATCH 12/12] gpu: ipu-v3: Add smfc and ic client devices

Adds IPU client devices for the SMFC and IC task units. Signed-off-by: Steve Longerbeam --- drivers/gpu/ipu-v3/ipu-common.c | 87 +++-- include/video/imx-ipu-v3.h | 3 ++ 2 files changed, 87 insertions(+), 3 deletions(-) diff --git

[PATCH 03/12] ARM: dts: imx6qdl: add video capture devices and connections

From: Philipp Zabel This patch adds the IPU subunit devices involved in video capture and image conversion, and defines all the possible hardware connections between them via OF graphs. External to the IPU: Video input multiplexers are defined that multiplex inputs from camera sensors and the

[PATCH 11/12] gpu: ipu-v3: lookup ipu client nodes by name

To allow for IPU clients containing multiple ports, they are no longer a single port node name, but have a name of the format "ipu_". So we can no longer use of_graph_get_port_by_id() to lookup the client node. Create the function of_get_ipu_client_node() that looks up the client node by node

[PATCH 06/12] ARM: dts: imx6-sabreauto: create i2cmux for i2c3

The sabreauto uses a steering pin to select between the SDA signal on i2c3 bus, and a data-in pin for an SPI NOR chip. Use i2cmux to control this steering pin. Idle state of the i2cmux selects SPI NOR. This is not a classic way to use i2cmux, since one side of the mux selects something other than

[PATCH 07/12] ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b

The reset pin to the port expander chip (MAX7310) is controlled by a gpio, so define a reset-gpios property to control it. There are three MAX7310's on the SabreAuto CPU card (max7310_[abc]), but all use the same pin for their reset. Since all can't acquire the same pin, assign it to max7310_b,

[PATCH 06/12] ARM: dts: imx6-sabreauto: create i2cmux for i2c3

The sabreauto uses a steering pin to select between the SDA signal on i2c3 bus, and a data-in pin for an SPI NOR chip. Use i2cmux to control this steering pin. Idle state of the i2cmux selects SPI NOR. This is not a classic way to use i2cmux, since one side of the mux selects something other than

[PATCH 07/12] ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b

The reset pin to the port expander chip (MAX7310) is controlled by a gpio, so define a reset-gpios property to control it. There are three MAX7310's on the SabreAuto CPU card (max7310_[abc]), but all use the same pin for their reset. Since all can't acquire the same pin, assign it to max7310_b,

[PATCH 02/12] ARM: dts: imx6qdl: rename ipu client nodes

To allow for IPU client devices that are composed of more than one port for input and output (SMFC and IC), change the nodes from being a single port node to nodes that can contain multiple ports. Rename the nodes to use the following format: "ipu_". The IPUv3 driver will then need to lookup the

[PATCH 00/12] i.MX media devices and connections

Hi Philipp, Sascha, Shawn, et al, I've been working for the past few months on a media driver for i.MX. In addition to the media entities for the IPU-external units involved with video capture (video mux and MIPI CSI-2 receiver), I've created media entities for the IPU CSI, SMFC, and IC subunits.

[PATCH 02/12] ARM: dts: imx6qdl: rename ipu client nodes

To allow for IPU client devices that are composed of more than one port for input and output (SMFC and IC), change the nodes from being a single port node to nodes that can contain multiple ports. Rename the nodes to use the following format: "ipu_". The IPUv3 driver will then need to lookup the

[PATCH 00/12] i.MX media devices and connections

Hi Philipp, Sascha, Shawn, et al, I've been working for the past few months on a media driver for i.MX. In addition to the media entities for the IPU-external units involved with video capture (video mux and MIPI CSI-2 receiver), I've created media entities for the IPU CSI, SMFC, and IC subunits.

[PATCH 01/12] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node

Add to the MIPI CSI2 receiver node: compatible string, interrupt sources, clocks. Signed-off-by: Steve Longerbeam --- arch/arm/boot/dts/imx6qdl.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/imx6qdl.dtsi

[PATCH 01/12] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node

Add to the MIPI CSI2 receiver node: compatible string, interrupt sources, clocks. Signed-off-by: Steve Longerbeam --- arch/arm/boot/dts/imx6qdl.dtsi | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi index b13b0b2..e01e5d5

Re: [PATCH] ARM: dts: imx7d: fix LCDIF clock assignment

On Wed, Dec 07, 2016 at 12:53:14PM -0800, Olof Johansson wrote: > Applied, with the fixes line. In the future, please email a...@kernel.org too, > it's easier to make sure we don't miss it that way. Noted. Thanks, Olof. Shawn

Re: [PATCH] ARM: dts: imx7d: fix LCDIF clock assignment

On Wed, Dec 07, 2016 at 12:53:14PM -0800, Olof Johansson wrote: > Applied, with the fixes line. In the future, please email a...@kernel.org too, > it's easier to make sure we don't miss it that way. Noted. Thanks, Olof. Shawn

Re: [PATCH] dm: Avoid sleeping while holding the dm_bufio lock

Hi, On Wed, Nov 23, 2016 at 12:57 PM, Mikulas Patocka wrote: > Hi > > The GFP_NOIO allocation frees clean cached pages. The GFP_NOWAIT > allocation doesn't. Your patch would incorrectly reuse buffers in a > situation when the memory is filled with clean cached pages. > >

Re: [PATCH] dm: Avoid sleeping while holding the dm_bufio lock

Hi, On Wed, Nov 23, 2016 at 12:57 PM, Mikulas Patocka wrote: > Hi > > The GFP_NOIO allocation frees clean cached pages. The GFP_NOWAIT > allocation doesn't. Your patch would incorrectly reuse buffers in a > situation when the memory is filled with clean cached pages. > > Here I'm proposing an

Re: [PATCH] drm/mxsfb: fix pixel clock polarity

On 12/08/2016 01:27 AM, Stefan Agner wrote: > The DRM subsystem specifies the pixel clock polarity from a > controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means > the controller drives the data on pixel clocks falling edge. > That is the controllers DOTCLK_POL=0 (Default is data launched >

Re: [PATCH] drm/mxsfb: fix pixel clock polarity

On 12/08/2016 01:27 AM, Stefan Agner wrote: > The DRM subsystem specifies the pixel clock polarity from a > controllers perspective: DRM_BUS_FLAG_PIXDATA_NEGEDGE means > the controller drives the data on pixel clocks falling edge. > That is the controllers DOTCLK_POL=0 (Default is data launched >

Re: [PATCH 1/8] staging/lustre/llite: move root_squash from sysfs to debugfs

> root_squash control got accidentally moved to sysfs instead of > debugfs, and the write side of it was also broken expecting a > userspace buffer. > It contains both uid and gid values in a single file, so debugfs > is a clear place for it. I see why this was missed. The uid/gid pair I needed

Re: [PATCH 1/8] staging/lustre/llite: move root_squash from sysfs to debugfs

> root_squash control got accidentally moved to sysfs instead of > debugfs, and the write side of it was also broken expecting a > userspace buffer. > It contains both uid and gid values in a single file, so debugfs > is a clear place for it. I see why this was missed. The uid/gid pair I needed

Re: [PATCH v2 0/5] perf report: Show inline stack

Got it, thanks so much! I will use the new version rather than just using the "RESEND" prefix in the future. For this time, since the "RESEND PATCH v2" has been sent out, I will not resend the v3 to avoid sending duplicate content to the mailing list. I will take care next time. Jin Yao

Re: [PATCH v2 0/5] perf report: Show inline stack

Got it, thanks so much! I will use the new version rather than just using the "RESEND" prefix in the future. For this time, since the "RESEND PATCH v2" has been sent out, I will not resend the v3 to avoid sending duplicate content to the mailing list. I will take care next time. Jin Yao

[PATCH 1/1] orinoco: fix improper return value

Function orinoco_ioctl_commit() returns 0 (indicates success) when the call to orinoco_lock() fails. Thus, the return value is inconsistent with the execution status. It may be better to return "-EBUSY" when the call to orinoco_lock() fails. Bugzilla:

[PATCH 1/1] orinoco: fix improper return value

Function orinoco_ioctl_commit() returns 0 (indicates success) when the call to orinoco_lock() fails. Thus, the return value is inconsistent with the execution status. It may be better to return "-EBUSY" when the call to orinoco_lock() fails. Bugzilla:

Re: [PATCH-tip] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

在 2016/12/7 03:14, Waiman Long 写道: A number of cmpxchg calls in qspinlock_paravirt.h were replaced by more relaxed versions to improve performance on architectures that use LL/SC. Signed-off-by: Waiman Long --- thanks! I apply it on my tree. and the tests is okay. ke

Re: [PATCH-tip] locking/pvqspinlock: Relax cmpxchg's to improve performance on some archs

在 2016/12/7 03:14, Waiman Long 写道: A number of cmpxchg calls in qspinlock_paravirt.h were replaced by more relaxed versions to improve performance on architectures that use LL/SC. Signed-off-by: Waiman Long --- thanks! I apply it on my tree. and the tests is okay. ke

Re: Misalignment, MIPS, and ip_hdr(skb)->version

From: "Jason A. Donenfeld" Date: Thu, 8 Dec 2016 01:29:42 +0100 > On Wed, Dec 7, 2016 at 8:52 PM, David Miller wrote: >> The only truly difficult case to handle is GRE encapsulation. Is >> that the situation you are running into? >> >> If not, please

Re: Misalignment, MIPS, and ip_hdr(skb)->version

From: "Jason A. Donenfeld" Date: Thu, 8 Dec 2016 01:29:42 +0100 > On Wed, Dec 7, 2016 at 8:52 PM, David Miller wrote: >> The only truly difficult case to handle is GRE encapsulation. Is >> that the situation you are running into? >> >> If not, please figure out what the header configuration

Re: Misalignment, MIPS, and ip_hdr(skb)->version

On Wed, Dec 7, 2016 at 8:52 PM, David Miller wrote: > The only truly difficult case to handle is GRE encapsulation. Is > that the situation you are running into? > > If not, please figure out what the header configuration looks like > in the case that hits for you, and what

Re: Misalignment, MIPS, and ip_hdr(skb)->version

On Wed, Dec 7, 2016 at 8:52 PM, David Miller wrote: > The only truly difficult case to handle is GRE encapsulation. Is > that the situation you are running into? > > If not, please figure out what the header configuration looks like > in the case that hits for you, and what the originating

Re: [PATCH v2 0/6] Provides bug fixes for rtc-mcp795.c

On 08/12/2016 at 00:27:36 +0100, Emil Bartczak wrote : > This patchset provides 4 bug fixes (patch 1, 2, 3, 4), one > improvement (patch 5) and whitespace, indention errors fixes > (patch 6) in the file driver/rtc/rtc-mcp795.c. > Please review the changes and consider to apply them to the >

Re: [PATCH v2 0/6] Provides bug fixes for rtc-mcp795.c

On 08/12/2016 at 00:27:36 +0100, Emil Bartczak wrote : > This patchset provides 4 bug fixes (patch 1, 2, 3, 4), one > improvement (patch 5) and whitespace, indention errors fixes > (patch 6) in the file driver/rtc/rtc-mcp795.c. > Please review the changes and consider to apply them to the >

Re: [PATCH 8/8] staging/lustre/ptlrpc: Move nrs_conf_fifo extern to a header

> This avoids having an extern definition in a C file which is bad, > and also silences sparse complaint as well. > > Signed-off-by: Oleg Drokin Reviewed-by: James Simmons > --- > drivers/staging/lustre/lustre/ptlrpc/nrs.c | 3 --- >

Re: [PATCH 8/8] staging/lustre/ptlrpc: Move nrs_conf_fifo extern to a header

> This avoids having an extern definition in a C file which is bad, > and also silences sparse complaint as well. > > Signed-off-by: Oleg Drokin Reviewed-by: James Simmons > --- > drivers/staging/lustre/lustre/ptlrpc/nrs.c | 3 --- >

<    1   2   3   4   5   6   7   8   9   10   >