Re: linux-next: build failure after merge of the sound-asoc tree

On Tue, Nov 08, 2016 at 11:18:29AM +0800, Chen-Yu Tsai wrote: > sound-asoc is missing patch > ASoC: sun4i-codec: Add support for optional reset control to quirks > http://www.spinics.net/lists/alsa-devel/msg56289.html > which commit 8d9e4c9e993f ("ASoC: sun4i-codec: Add support for A31

Re: linux-next: build failure after merge of the sound-asoc tree

On Tue, Nov 08, 2016 at 11:18:29AM +0800, Chen-Yu Tsai wrote: > sound-asoc is missing patch > ASoC: sun4i-codec: Add support for optional reset control to quirks > http://www.spinics.net/lists/alsa-devel/msg56289.html > which commit 8d9e4c9e993f ("ASoC: sun4i-codec: Add support for A31

Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic

On 09/11/16 14:19, Lorenzo Pieralisi wrote: > The of_iommu_{set/get}_ops() API is used to associate a device > tree node with a specific set of IOMMU operations. The same > kernel interface is required on systems booting with ACPI, where > devices are not associated with a device tree node,

Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic

On 09/11/16 14:19, Lorenzo Pieralisi wrote: > The of_iommu_{set/get}_ops() API is used to associate a device > tree node with a specific set of IOMMU operations. The same > kernel interface is required on systems booting with ACPI, where > devices are not associated with a device tree node,

Re: [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c

Em Wed, Nov 09, 2016 at 04:01:12PM +0200, Adrian Hunter escreveu: > On 09/11/16 15:59, Arnaldo Carvalho de Melo wrote: > > Em Wed, Nov 09, 2016 at 10:14:26AM -0300, Arnaldo Carvalho de Melo escreveu: > >> Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu: > >>> From: Andi Kleen

Re: [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c

Em Wed, Nov 09, 2016 at 04:01:12PM +0200, Adrian Hunter escreveu: > On 09/11/16 15:59, Arnaldo Carvalho de Melo wrote: > > Em Wed, Nov 09, 2016 at 10:14:26AM -0300, Arnaldo Carvalho de Melo escreveu: > >> Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu: > >>> From: Andi Kleen > >>>

Re: [PATCH 12/13] ARM64: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"

Am Donnerstag, 3. November 2016, 15:21:34 CET schrieb Jaehoon Chung: > In drivers/mmc/core/host.c, there is "max-freqeuncy" property. > It should be same behavior, So Use the "max-frequency" instead of > "clock-freq-min-max". > > Signed-off-by: Jaehoon Chung applied to

Re: [PATCH 12/13] ARM64: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"

Am Donnerstag, 3. November 2016, 15:21:34 CET schrieb Jaehoon Chung: > In drivers/mmc/core/host.c, there is "max-freqeuncy" property. > It should be same behavior, So Use the "max-frequency" instead of > "clock-freq-min-max". > > Signed-off-by: Jaehoon Chung applied to my dts64 branch for 4.10

Re: [PATCH v9 0/4] Enabling Ring 3 MONITOR/MWAIT feature for Knights Landing

On Wed, 9 Nov 2016, Grzegorz Andrejczuk wrote: > These patches enable Intel Xeon Phi x200 feature to use MONITOR/MWAIT > instruction in ring 3 (userspace) Patches set MSR 0x140 for all logical CPUs. > Then expose it as CPU feature and introduces elf HWCAP capability for x86. > Reference: >

Re: [PATCH 1/6] dt-bindings: mdio-mux: Add documentation for mdio mux for NSP SoC

On Wed, Nov 09, 2016 at 04:33:09AM -0500, Yendapally Reddy Dhananjaya Reddy wrote: > Add documentation for mdio mux available in Broadcom NSP SoC > > Signed-off-by: Yendapally Reddy Dhananjaya Reddy > > --- > .../devicetree/bindings/net/brcm,mdio-mux-nsp.txt |

Re: [PATCH v9 0/4] Enabling Ring 3 MONITOR/MWAIT feature for Knights Landing

On Wed, 9 Nov 2016, Grzegorz Andrejczuk wrote: > These patches enable Intel Xeon Phi x200 feature to use MONITOR/MWAIT > instruction in ring 3 (userspace) Patches set MSR 0x140 for all logical CPUs. > Then expose it as CPU feature and introduces elf HWCAP capability for x86. > Reference: >

Re: [PATCH 1/6] dt-bindings: mdio-mux: Add documentation for mdio mux for NSP SoC

On Wed, Nov 09, 2016 at 04:33:09AM -0500, Yendapally Reddy Dhananjaya Reddy wrote: > Add documentation for mdio mux available in Broadcom NSP SoC > > Signed-off-by: Yendapally Reddy Dhananjaya Reddy > > --- > .../devicetree/bindings/net/brcm,mdio-mux-nsp.txt | 57 > ++ >

Re: [PATCH 2/4] perf hist browser: Show folded sign properly on --hierarchy

Em Wed, Nov 09, 2016 at 11:28:11AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Tue, Nov 08, 2016 at 10:08:31PM +0900, Namhyung Kim escreveu: > > When horizontall scrolling is used in hierarchy mode, the folded signed > > disappears at the right most column. > > Humm, this indeed shows the '+'

Re: [PATCH 2/4] perf hist browser: Show folded sign properly on --hierarchy

Em Wed, Nov 09, 2016 at 11:28:11AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Tue, Nov 08, 2016 at 10:08:31PM +0900, Namhyung Kim escreveu: > > When horizontall scrolling is used in hierarchy mode, the folded signed > > disappears at the right most column. > > Humm, this indeed shows the '+'

Re: [PATCH 2/4] perf hist browser: Show folded sign properly on --hierarchy

Em Tue, Nov 08, 2016 at 10:08:31PM +0900, Namhyung Kim escreveu: > When horizontall scrolling is used in hierarchy mode, the folded signed > disappears at the right most column. Humm, this indeed shows the '+' folded signal after pressing ->, but it moves from the first to the third column :-\ -

Re: [PATCH 2/4] perf hist browser: Show folded sign properly on --hierarchy

Em Tue, Nov 08, 2016 at 10:08:31PM +0900, Namhyung Kim escreveu: > When horizontall scrolling is used in hierarchy mode, the folded signed > disappears at the right most column. Humm, this indeed shows the '+' folded signal after pressing ->, but it moves from the first to the third column :-\ -

Re: [PATCH] perf/x86: Fix overlap counter scheduling bug

On 08.11.16 19:27:39, Peter Zijlstra wrote: > The comment with EVENT_CONSTRAINT_OVERLAP states: "This is the case if > the counter mask of such an event is not a subset of any other counter > mask of a constraint with an equal or higher weight". > > Esp. that latter part is of interest here I

[GIT PULL] kvm/page_track changes for i915 KVMGT

Daniel, The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e: kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02 21:31:53 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-kvmgt for you to fetch

Re: [PATCH] perf/x86: Fix overlap counter scheduling bug

On 08.11.16 19:27:39, Peter Zijlstra wrote: > The comment with EVENT_CONSTRAINT_OVERLAP states: "This is the case if > the counter mask of such an event is not a subset of any other counter > mask of a constraint with an equal or higher weight". > > Esp. that latter part is of interest here I

[GIT PULL] kvm/page_track changes for i915 KVMGT

Daniel, The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e: kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02 21:31:53 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-kvmgt for you to fetch

[PATCH] pinctrl: single: check for any error when getting rows

pinctrl_count_index_with_args returns -ENOENT not -EINVAL. The return check would pass, and we would try to kzalloc with a negative error size throwing a warning. Instead of checking for -EINVAL specifically, lets check for any error and avoid negative size allocations. Signed-off-by: Axel

[PATCH] pinctrl: single: check for any error when getting rows

pinctrl_count_index_with_args returns -ENOENT not -EINVAL. The return check would pass, and we would try to kzalloc with a negative error size throwing a warning. Instead of checking for -EINVAL specifically, lets check for any error and avoid negative size allocations. Signed-off-by: Axel

[PATCH v7 00/16] ACPI IORT ARM SMMU support

This patch series is v7 of a previous posting: https://lkml.org/lkml/2016/10/18/506 v6 -> v7 - Rebased against v4.9-rc4 - Fixed IORT probing on ACPI systems with missing IORT table - Fixed SMMUv1/v2 global interrupt detection - Updated iommu_ops firmware look-up

[PATCH v7 03/16] drivers: acpi: iort: add support for IOMMU fwnode registration

The ACPI IORT table provide entries for IOMMU (aka SMMU in ARM world) components that allow creating the kernel data structures required to probe and initialize the IOMMU devices. This patch provides support in the IORT kernel code to register IOMMU components and their respective fwnode.

[PATCH v7 02/16] drivers: acpi: iort: introduce linker section for IORT entries probing

Since commit e647b532275b ("ACPI: Add early device probing infrastructure") the kernel has gained the infrastructure that allows adding linker script section entries to execute ACPI driver callbacks (ie probe routines) for all subsystems that register a table entry in the respective kernel section

[PATCH v7 03/16] drivers: acpi: iort: add support for IOMMU fwnode registration

The ACPI IORT table provide entries for IOMMU (aka SMMU in ARM world) components that allow creating the kernel data structures required to probe and initialize the IOMMU devices. This patch provides support in the IORT kernel code to register IOMMU components and their respective fwnode.

[PATCH v7 02/16] drivers: acpi: iort: introduce linker section for IORT entries probing

Since commit e647b532275b ("ACPI: Add early device probing infrastructure") the kernel has gained the infrastructure that allows adding linker script section entries to execute ACPI driver callbacks (ie probe routines) for all subsystems that register a table entry in the respective kernel section

[PATCH v7 00/16] ACPI IORT ARM SMMU support

This patch series is v7 of a previous posting: https://lkml.org/lkml/2016/10/18/506 v6 -> v7 - Rebased against v4.9-rc4 - Fixed IORT probing on ACPI systems with missing IORT table - Fixed SMMUv1/v2 global interrupt detection - Updated iommu_ops firmware look-up

[PATCH v7 05/16] drivers: iommu: arm-smmu: convert struct device of_node to fwnode usage

Current ARM SMMU driver rely on the struct device.of_node pointer for device look-up and iommu_ops retrieval. In preparation for ACPI probing enablement, convert the driver to use the struct device.fwnode member for device and iommu_ops look-up so that the driver infrastructure can be used also

[PATCH v7 05/16] drivers: iommu: arm-smmu: convert struct device of_node to fwnode usage

Current ARM SMMU driver rely on the struct device.of_node pointer for device look-up and iommu_ops retrieval. In preparation for ACPI probing enablement, convert the driver to use the struct device.fwnode member for device and iommu_ops look-up so that the driver infrastructure can be used also

[PATCH v7 15/16] drivers: acpi: iort: add single mapping function

The current IORT id mapping API requires components to provide an input requester ID (a Bus-Device-Function (BDF) identifier for PCI devices) to translate an input identifier to an output identifier through an IORT range mapping. Named components do not have an identifiable source ID therefore

[PATCH v7 06/16] drivers: iommu: arm-smmu-v3: convert struct device of_node to fwnode usage

Current ARM SMMU v3 driver rely on the struct device.of_node pointer for device look-up and iommu_ops retrieval. In preparation for ACPI probing enablement, convert the driver to use the struct device.fwnode member for device and iommu_ops look-up so that the driver infrastructure can be used

[PATCH v7 12/16] drivers: iommu: arm-smmu: split probe functions into DT/generic portions

Current ARM SMMU probe functions intermingle HW and DT probing in the initialization functions to detect and programme the ARM SMMU driver features. In order to allow probing the ARM SMMU with other firmwares than DT, this patch splits the ARM SMMU init functions into DT and HW specific portions

[PATCH v7 16/16] drivers: acpi: iort: introduce iort_iommu_configure

DT based systems have a generic kernel API to configure IOMMUs for devices (ie of_iommu_configure()). On ARM based ACPI systems, the of_iommu_configure() equivalent can be implemented atop ACPI IORT kernel API, with the corresponding functions to map device identifiers to IOMMUs and retrieve the

[PATCH v7 15/16] drivers: acpi: iort: add single mapping function

The current IORT id mapping API requires components to provide an input requester ID (a Bus-Device-Function (BDF) identifier for PCI devices) to translate an input identifier to an output identifier through an IORT range mapping. Named components do not have an identifiable source ID therefore

[PATCH v7 06/16] drivers: iommu: arm-smmu-v3: convert struct device of_node to fwnode usage

Current ARM SMMU v3 driver rely on the struct device.of_node pointer for device look-up and iommu_ops retrieval. In preparation for ACPI probing enablement, convert the driver to use the struct device.fwnode member for device and iommu_ops look-up so that the driver infrastructure can be used

[PATCH v7 12/16] drivers: iommu: arm-smmu: split probe functions into DT/generic portions

Current ARM SMMU probe functions intermingle HW and DT probing in the initialization functions to detect and programme the ARM SMMU driver features. In order to allow probing the ARM SMMU with other firmwares than DT, this patch splits the ARM SMMU init functions into DT and HW specific portions

[PATCH v7 16/16] drivers: acpi: iort: introduce iort_iommu_configure

DT based systems have a generic kernel API to configure IOMMUs for devices (ie of_iommu_configure()). On ARM based ACPI systems, the of_iommu_configure() equivalent can be implemented atop ACPI IORT kernel API, with the corresponding functions to map device identifiers to IOMMUs and retrieve the

[PATCH v7 14/16] drivers: acpi: iort: replace rid map type with type mask

IORT tables provide data that allow the kernel to carry out device ID mappings between endpoints and system components (eg interrupt controllers, IOMMUs). When the mapping for a given device ID is carried out, the translation mechanism is done on a per-subsystem basis rather than a component

[PATCH v7 09/16] drivers: acpi: iort: add support for ARM SMMU platform devices creation

In ARM ACPI systems, IOMMU components are specified through static IORT table entries. In order to create platform devices for the corresponding ARM SMMU components, IORT kernel code should be made able to parse IORT table entries and create platform devices dynamically. This patch adds the

Re: [PATCH 22/25] x86/mcheck: Do the init in one place

On 2016-11-08 10:23:02 [+0100], Borislav Petkov wrote: > On Mon, Nov 07, 2016 at 09:12:24PM +0100, Borislav Petkov wrote: > > On Mon, Nov 07, 2016 at 10:55:24AM -0800, Luck, Tony wrote: > > > I don't think that helps as much as you'd like it to help (at > > > least on Intel). A broadcast machine

Re: [PATCH v3 4/4] KVM: x86: emulate FXSAVE and FXRSTOR

2016-11-09 13:12+0100, Radim Krčmář: > 2016-11-09 00:25+0100, Paolo Bonzini: >> On 08/11/2016 20:54, Radim Krčmář wrote: >>> +static int em_fxsave(struct x86_emulate_ctxt *ctxt) >>> +{ >>> + struct fxregs_state fx_state; >>> + size_t size = 288; /* up to XMM7 */ >> >> Sorry for noticing this

Re: [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP

On 10/28/2016 05:29 PM, Randy Li wrote: On 10/28/2016 05:11 PM, Shawn Lin wrote: On 2016/10/23 3:18, Randy Li wrote: I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at RK3288, once trying to enable the pclk clock, the kernel would dead. This patch would try to enable them

[PATCH v7 13/16] drivers: iommu: arm-smmu: add IORT configuration

In ACPI bases systems, in order to be able to create platform devices and initialize them for ARM SMMU components, the IORT kernel implementation requires a set of static functions to be used by the IORT kernel layer to configure platform devices for ARM SMMU components. Add static configuration

Re: [PATCH v3 4/4] KVM: x86: emulate FXSAVE and FXRSTOR

2016-11-09 13:12+0100, Radim Krčmář: > 2016-11-09 00:25+0100, Paolo Bonzini: >> On 08/11/2016 20:54, Radim Krčmář wrote: >>> +static int em_fxsave(struct x86_emulate_ctxt *ctxt) >>> +{ >>> + struct fxregs_state fx_state; >>> + size_t size = 288; /* up to XMM7 */ >> >> Sorry for noticing this

Re: [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP

On 10/28/2016 05:29 PM, Randy Li wrote: On 10/28/2016 05:11 PM, Shawn Lin wrote: On 2016/10/23 3:18, Randy Li wrote: I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at RK3288, once trying to enable the pclk clock, the kernel would dead. This patch would try to enable them

[PATCH v7 13/16] drivers: iommu: arm-smmu: add IORT configuration

In ACPI bases systems, in order to be able to create platform devices and initialize them for ARM SMMU components, the IORT kernel implementation requires a set of static functions to be used by the IORT kernel layer to configure platform devices for ARM SMMU components. Add static configuration

[PATCH v7 14/16] drivers: acpi: iort: replace rid map type with type mask

IORT tables provide data that allow the kernel to carry out device ID mappings between endpoints and system components (eg interrupt controllers, IOMMUs). When the mapping for a given device ID is carried out, the translation mechanism is done on a per-subsystem basis rather than a component

[PATCH v7 09/16] drivers: acpi: iort: add support for ARM SMMU platform devices creation

In ARM ACPI systems, IOMMU components are specified through static IORT table entries. In order to create platform devices for the corresponding ARM SMMU components, IORT kernel code should be made able to parse IORT table entries and create platform devices dynamically. This patch adds the

Re: [PATCH 22/25] x86/mcheck: Do the init in one place

On 2016-11-08 10:23:02 [+0100], Borislav Petkov wrote: > On Mon, Nov 07, 2016 at 09:12:24PM +0100, Borislav Petkov wrote: > > On Mon, Nov 07, 2016 at 10:55:24AM -0800, Luck, Tony wrote: > > > I don't think that helps as much as you'd like it to help (at > > > least on Intel). A broadcast machine

[PATCH v7 10/16] drivers: iommu: arm-smmu-v3: split probe functions into DT/generic portions

Current ARM SMMUv3 probe functions intermingle HW and DT probing in the initialization functions to detect and programme the ARM SMMU v3 driver features. In order to allow probing the ARM SMMUv3 with other firmwares than DT, this patch splits the ARM SMMUv3 init functions into DT and HW specific

[PATCH v7 07/16] drivers: acpi: implement acpi_dma_configure

On DT based systems, the of_dma_configure() API implements DMA configuration for a given device. On ACPI systems an API equivalent to of_dma_configure() is missing which implies that it is currently not possible to set-up DMA operations for devices through the ACPI generic kernel layer. This

[PATCH v7 10/16] drivers: iommu: arm-smmu-v3: split probe functions into DT/generic portions

Current ARM SMMUv3 probe functions intermingle HW and DT probing in the initialization functions to detect and programme the ARM SMMU v3 driver features. In order to allow probing the ARM SMMUv3 with other firmwares than DT, this patch splits the ARM SMMUv3 init functions into DT and HW specific

[PATCH v7 07/16] drivers: acpi: implement acpi_dma_configure

On DT based systems, the of_dma_configure() API implements DMA configuration for a given device. On ACPI systems an API equivalent to of_dma_configure() is missing which implies that it is currently not possible to set-up DMA operations for devices through the ACPI generic kernel layer. This

Re: [PATCH v4 0/4] MIPS: Remote processor driver

On Wed, 9 Nov 2016, Matt Redfearn wrote: > On 09/11/16 10:15, Thomas Gleixner wrote: > > On Wed, 2 Nov 2016, Matt Redfearn wrote: > > > The MIPS remote processor driver allows non-Linux firmware to take > > > control of and execute on one of the systems VPEs. The CPU must be > > > offlined from

Re: [PATCH v4 0/4] MIPS: Remote processor driver

On Wed, 9 Nov 2016, Matt Redfearn wrote: > On 09/11/16 10:15, Thomas Gleixner wrote: > > On Wed, 2 Nov 2016, Matt Redfearn wrote: > > > The MIPS remote processor driver allows non-Linux firmware to take > > > control of and execute on one of the systems VPEs. The CPU must be > > > offlined from

[PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic

The of_iommu_{set/get}_ops() API is used to associate a device tree node with a specific set of IOMMU operations. The same kernel interface is required on systems booting with ACPI, where devices are not associated with a device tree node, therefore the interface requires generalization. The

[PATCH v7 08/16] drivers: acpi: iort: add node match function

Device drivers (eg ARM SMMU) need to know if a specific component is part of the IORT table, so that kernel data structures are not initialized at initcalls time if the respective component is not part of the IORT table. To this end, this patch adds a trivial function that allows detecting if a

[PATCH v7 11/16] drivers: iommu: arm-smmu-v3: add IORT configuration

In ACPI bases systems, in order to be able to create platform devices and initialize them for ARM SMMU v3 components, the IORT kernel implementation requires a set of static functions to be used by the IORT kernel layer to configure platform devices for ARM SMMU v3 components. Add static

[PATCH v7 01/16] drivers: acpi: add FWNODE_ACPI_STATIC fwnode type

On systems booting with a device tree, every struct device is associated with a struct device_node, that provides its DT firmware representation. The device node can be used in generic kernel contexts (eg IRQ translation, IOMMU streamid mapping), to retrieve the properties associated with the

[PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic

The of_iommu_{set/get}_ops() API is used to associate a device tree node with a specific set of IOMMU operations. The same kernel interface is required on systems booting with ACPI, where devices are not associated with a device tree node, therefore the interface requires generalization. The

[PATCH v7 08/16] drivers: acpi: iort: add node match function

Device drivers (eg ARM SMMU) need to know if a specific component is part of the IORT table, so that kernel data structures are not initialized at initcalls time if the respective component is not part of the IORT table. To this end, this patch adds a trivial function that allows detecting if a

[PATCH v7 11/16] drivers: iommu: arm-smmu-v3: add IORT configuration

In ACPI bases systems, in order to be able to create platform devices and initialize them for ARM SMMU v3 components, the IORT kernel implementation requires a set of static functions to be used by the IORT kernel layer to configure platform devices for ARM SMMU v3 components. Add static

[PATCH v7 01/16] drivers: acpi: add FWNODE_ACPI_STATIC fwnode type

On systems booting with a device tree, every struct device is associated with a struct device_node, that provides its DT firmware representation. The device node can be used in generic kernel contexts (eg IRQ translation, IOMMU streamid mapping), to retrieve the properties associated with the

Re: [PATCH v4 1/3] spi-nor: Add support for Intel SPI serial flash controller

On Wed, Nov 09, 2016 at 02:51:20PM +0100, Cyrille Pitchen wrote: > > +/* Reads max 64 bytes from the device fifo */ > > +static int intel_spi_read_block(struct intel_spi *ispi, void *buf, size_t > > size) > > +{ > > + size_t bytes; > > + int i = 0; > > + > > + if (size > 64) > > This is

Re: [PATCH v4 1/3] spi-nor: Add support for Intel SPI serial flash controller

On Wed, Nov 09, 2016 at 02:51:20PM +0100, Cyrille Pitchen wrote: > > +/* Reads max 64 bytes from the device fifo */ > > +static int intel_spi_read_block(struct intel_spi *ispi, void *buf, size_t > > size) > > +{ > > + size_t bytes; > > + int i = 0; > > + > > + if (size > 64) > > This is

Re: [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP

On 10/28/2016 05:29 PM, Randy Li wrote: On 10/28/2016 05:11 PM, Shawn Lin wrote: On 2016/10/23 3:18, Randy Li wrote: I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at RK3288, once trying to enable the pclk clock, the kernel would dead. This patch would try to enable them

Re: [PATCH] drm/rockchip: analogix_dp: add supports for regulators in edp IP

On 10/28/2016 05:29 PM, Randy Li wrote: On 10/28/2016 05:11 PM, Shawn Lin wrote: On 2016/10/23 3:18, Randy Li wrote: I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at RK3288, once trying to enable the pclk clock, the kernel would dead. This patch would try to enable them

Re: [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c

On 09/11/16 15:59, Arnaldo Carvalho de Melo wrote: > Em Wed, Nov 09, 2016 at 10:14:26AM -0300, Arnaldo Carvalho de Melo escreveu: >> Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu: >>> From: Andi Kleen >>> >>> Since the unprivileged sched switch event was

Re: [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c

On 09/11/16 15:59, Arnaldo Carvalho de Melo wrote: > Em Wed, Nov 09, 2016 at 10:14:26AM -0300, Arnaldo Carvalho de Melo escreveu: >> Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu: >>> From: Andi Kleen >>> >>> Since the unprivileged sched switch event was added in perf, >>> PT

Re: [PATCH 11/13] ARM: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"

Am Donnerstag, 3. November 2016, 15:21:33 CET schrieb Jaehoon Chung: > In drivers/mmc/core/host.c, there is "max-frequency" property. > It should be same behavior. So use the "max-frequency" instead of > "clock-freq-min-max". > > Signed-off-by: Jaehoon Chung looks good,

Re: [PATCH 11/13] ARM: dts: rockchip: replace to "max-frequency" instead of "clock-freq-min-max"

Am Donnerstag, 3. November 2016, 15:21:33 CET schrieb Jaehoon Chung: > In drivers/mmc/core/host.c, there is "max-frequency" property. > It should be same behavior. So use the "max-frequency" instead of > "clock-freq-min-max". > > Signed-off-by: Jaehoon Chung looks good, my veyron-pinky and

Re: [PATCH 2/2] regulator: rn5t618: add RC5T619 PMIC support

On Sat, Nov 05, 2016 at 05:19:25PM +0100, Pierre-Hugues Husson wrote: > Extend the driver to support Ricoh RC5T619. > Support the additional regulators and slightly different voltage ranges. Acked-by: Mark Brown signature.asc Description: PGP signature

Re: [PATCH 2/2] regulator: rn5t618: add RC5T619 PMIC support

On Sat, Nov 05, 2016 at 05:19:25PM +0100, Pierre-Hugues Husson wrote: > Extend the driver to support Ricoh RC5T619. > Support the additional regulators and slightly different voltage ranges. Acked-by: Mark Brown signature.asc Description: PGP signature

Re: [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c

Em Wed, Nov 09, 2016 at 10:14:26AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu: > > From: Andi Kleen > > > > Since the unprivileged sched switch event was added in perf, > > PT doesn't need need

Re: [PATCH] perf tools pt: Remove obsolete paragraph in intel-pt.c

Em Wed, Nov 09, 2016 at 10:14:26AM -0300, Arnaldo Carvalho de Melo escreveu: > Em Tue, Nov 08, 2016 at 04:11:00PM -0800, Andi Kleen escreveu: > > From: Andi Kleen > > > > Since the unprivileged sched switch event was added in perf, > > PT doesn't need need perf_event_paranoid=-1 anymore for > >

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

> I think it is a relatively safe assumption that there is only one > ISA bridge. A lot of old drivers hardcode PIO or memory addresses It's not a safe assumption for x86 at least. There are a few systems with multiple ISA busses particularly older laptops with a docking station. > when talking

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

> I think it is a relatively safe assumption that there is only one > ISA bridge. A lot of old drivers hardcode PIO or memory addresses It's not a safe assumption for x86 at least. There are a few systems with multiple ISA busses particularly older laptops with a docking station. > when talking

Re: [PATCH v4 1/3] spi-nor: Add support for Intel SPI serial flash controller

Hi Mika, Le 17/10/2016 à 16:58, Mika Westerberg a écrit : > Add support for the SPI serial flash host controller found on many Intel > CPUs including Baytrail and Braswell. The SPI serial flash controller is > used to access BIOS and other platform specific information. By default the > driver

Re: [PATCH v4 1/3] spi-nor: Add support for Intel SPI serial flash controller

Hi Mika, Le 17/10/2016 à 16:58, Mika Westerberg a écrit : > Add support for the SPI serial flash host controller found on many Intel > CPUs including Baytrail and Braswell. The SPI serial flash controller is > used to access BIOS and other platform specific information. By default the > driver

[PATCH v9 4/4] x86/cpufeatures: handle RING3MWAIT on Xeon Phi models

Unfortunately presence of this feature cannot be detected automatically (by reading some other MSR) therefore it is required to do explicit check for the family and model of the cpu. If processor is Intel Xeon Phi x200 RING 3 MONITOR/MWAIT feature is enabled by setting cpu cap

[PATCH v9 4/4] x86/cpufeatures: handle RING3MWAIT on Xeon Phi models

Unfortunately presence of this feature cannot be detected automatically (by reading some other MSR) therefore it is required to do explicit check for the family and model of the cpu. If processor is Intel Xeon Phi x200 RING 3 MONITOR/MWAIT feature is enabled by setting cpu cap

[PATCH v9 1/4] x86/msr: add MSR_MISC_FEATURE_ENABLES and RING3MWAIT bit

Intel Xeon Phi x200 (codenamed Knights Landing) allows to enable MONITOR and MWAIT instructions outside of ring 0. The feature is controlled by MSR MISC_FEATURE_ENABLES (0x140). Setting bit 1 of this register enables it, so MONITOR and MWAIT instructions do not cause invalid-opcode exceptions

[PATCH v9 1/4] x86/msr: add MSR_MISC_FEATURE_ENABLES and RING3MWAIT bit

Intel Xeon Phi x200 (codenamed Knights Landing) allows to enable MONITOR and MWAIT instructions outside of ring 0. The feature is controlled by MSR MISC_FEATURE_ENABLES (0x140). Setting bit 1 of this register enables it, so MONITOR and MWAIT instructions do not cause invalid-opcode exceptions

[PATCH v9 3/4] x86/cpufeature: add RING3MWAIT to CPU features

Add Intel Xeon Phi x200 (KnightsLanding) CPU feature - ring 3 MONITOR/MWAIT. Signed-off-by: Grzegorz Andrejczuk --- arch/x86/include/asm/cpufeatures.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/cpufeatures.h

[PATCH v9 3/4] x86/cpufeature: add RING3MWAIT to CPU features

Add Intel Xeon Phi x200 (KnightsLanding) CPU feature - ring 3 MONITOR/MWAIT. Signed-off-by: Grzegorz Andrejczuk --- arch/x86/include/asm/cpufeatures.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h

[PATCH v9 2/4] x86/elf: use HWCAP2 to expose ring 3 MWAIT

Add HWCAP2 for x86 and reserve its bit 0 to expose ring 3 mwait. Signed-off-by: Grzegorz Andrejczuk --- arch/x86/include/asm/elf.h | 9 + arch/x86/include/uapi/asm/hwcap2.h | 7 +++ arch/x86/kernel/cpu/common.c | 3 +++ 3 files changed,

[PATCH v9 0/4] Enabling Ring 3 MONITOR/MWAIT feature for Knights Landing

These patches enable Intel Xeon Phi x200 feature to use MONITOR/MWAIT instruction in ring 3 (userspace) Patches set MSR 0x140 for all logical CPUs. Then expose it as CPU feature and introduces elf HWCAP capability for x86. Reference:

[PATCH v9 2/4] x86/elf: use HWCAP2 to expose ring 3 MWAIT

Add HWCAP2 for x86 and reserve its bit 0 to expose ring 3 mwait. Signed-off-by: Grzegorz Andrejczuk --- arch/x86/include/asm/elf.h | 9 + arch/x86/include/uapi/asm/hwcap2.h | 7 +++ arch/x86/kernel/cpu/common.c | 3 +++ 3 files changed, 19 insertions(+) create mode

[PATCH v9 0/4] Enabling Ring 3 MONITOR/MWAIT feature for Knights Landing

These patches enable Intel Xeon Phi x200 feature to use MONITOR/MWAIT instruction in ring 3 (userspace) Patches set MSR 0x140 for all logical CPUs. Then expose it as CPU feature and introduces elf HWCAP capability for x86. Reference:

[PATCH net-next v5]] cadence: Add LSO support.

New Cadence GEM hardware support Large Segment Offload (LSO): TCP segmentation offload (TSO) as well as UDP fragmentation offload (UFO). Support for those features was added to the driver. Signed-off-by: Rafal Ozieblo --- Changed in v2: macb_lso_check_compatibility() changed

[PATCH net-next v5]] cadence: Add LSO support.

New Cadence GEM hardware support Large Segment Offload (LSO): TCP segmentation offload (TSO) as well as UDP fragmentation offload (UFO). Support for those features was added to the driver. Signed-off-by: Rafal Ozieblo --- Changed in v2: macb_lso_check_compatibility() changed to

Re: [PATCH 2/2] ASoC: axentia: tse850: add ASoC driver for the Axentia TSE-850

On Tue, Nov 08, 2016 at 05:20:57PM +0100, Peter Rosin wrote: > +++ b/sound/soc/axentia/Kconfig > @@ -0,0 +1,10 @@ > +config SND_SOC_AXENTIA_TSE850_PCM5142 > + tristate "ASoC driver for the Axentia TSE-850" > + depends on ARCH_AT91 && OF > + select ATMEL_SSC > + select

Re: [PATCH 2/2] ASoC: axentia: tse850: add ASoC driver for the Axentia TSE-850

On Tue, Nov 08, 2016 at 05:20:57PM +0100, Peter Rosin wrote: > +++ b/sound/soc/axentia/Kconfig > @@ -0,0 +1,10 @@ > +config SND_SOC_AXENTIA_TSE850_PCM5142 > + tristate "ASoC driver for the Axentia TSE-850" > + depends on ARCH_AT91 && OF > + select ATMEL_SSC > + select

Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID

On Wed, 9 Nov 2016, Borislav Petkov wrote: > On Tue, Nov 08, 2016 at 09:06:31PM +0100, Thomas Gleixner wrote: > > The upcoming ring3 mwait stuff can add its magic to tweak that MSR into > > this function. > > > > Stick the call at the end of init_scattered_cpuid_features() for now. I > > still

Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID

On Wed, 9 Nov 2016, Borislav Petkov wrote: > On Tue, Nov 08, 2016 at 09:06:31PM +0100, Thomas Gleixner wrote: > > The upcoming ring3 mwait stuff can add its magic to tweak that MSR into > > this function. > > > > Stick the call at the end of init_scattered_cpuid_features() for now. I > > still

Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus

Hi Arnd, On Mon, Nov 7, 2016 at 10:35 AM, Geert Uytterhoeven wrote: > On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven > wrote: >> Some Renesas SoCs may exist in different revisions, providing slightly >> different functionalities (e.g. R-Car

Re: [PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus

Hi Arnd, On Mon, Nov 7, 2016 at 10:35 AM, Geert Uytterhoeven wrote: > On Mon, Oct 31, 2016 at 12:30 PM, Geert Uytterhoeven > wrote: >> Some Renesas SoCs may exist in different revisions, providing slightly >> different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior >> (errate and

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/08/2016 08:50 PM, Peter Zijlstra wrote: >> The problem is that using RT_RUNTIME_SHARE a CPU will almost always >> > borrow enough runtime to make a CPU intensive rt task to run forever... >> > well not forever, but until the system crash because a kworker starved >> > in this CPU. Kworkers

Re: [PATCH] sched/rt: RT_RUNTIME_GREED sched feature

On 11/08/2016 08:50 PM, Peter Zijlstra wrote: >> The problem is that using RT_RUNTIME_SHARE a CPU will almost always >> > borrow enough runtime to make a CPU intensive rt task to run forever... >> > well not forever, but until the system crash because a kworker starved >> > in this CPU. Kworkers

<    7   8   9   10   11   12   13   14   15   16   >