[git pull] drm fixes

Hi Linus, This is mostly amdgpu/radeon fixes, and imx related fixes. There are also one one TTM fix, one nouveau fix, and one hdlcd fix. The AMD ones are some fixes for power management after suspend/resume one some GPUs, and some vblank fixes. The IMX ones are for more stricter plane checks

[git pull] drm fixes

Hi Linus, This is mostly amdgpu/radeon fixes, and imx related fixes. There are also one one TTM fix, one nouveau fix, and one hdlcd fix. The AMD ones are some fixes for power management after suspend/resume one some GPUs, and some vblank fixes. The IMX ones are for more stricter plane checks

PXA310 U2DC Controller support

Hi, Robert I'm woking with a board which integrated PXA310 on it. While Debugging U2DC controller, found that once U2DC Controller have been started, It couldn't be stopped completely. The windows shows unknown device while Stopping U2DC and Usb line haven't been unplugged from PC Have

PXA310 U2DC Controller support

Hi, Robert I'm woking with a board which integrated PXA310 on it. While Debugging U2DC controller, found that once U2DC Controller have been started, It couldn't be stopped completely. The windows shows unknown device while Stopping U2DC and Usb line haven't been unplugged from PC Have

[PATCH 04/10] powerpc/hugetlb: Add ABI defines for MAP_HUGE_16MB and MAP_HUGE_16GB

This just adds user space exported ABI definitions for both 16MB and 16GB non default huge page sizes to be used with mmap() system call. Signed-off-by: Anshuman Khandual --- arch/powerpc/include/uapi/asm/mman.h | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH 04/10] powerpc/hugetlb: Add ABI defines for MAP_HUGE_16MB and MAP_HUGE_16GB

This just adds user space exported ABI definitions for both 16MB and 16GB non default huge page sizes to be used with mmap() system call. Signed-off-by: Anshuman Khandual --- arch/powerpc/include/uapi/asm/mman.h | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH 06/10] powerpc/hugetlb: Split the function 'huge_pte_offset'

Currently the function 'huge_pte_offset' has just got one version for all possible configurations and platforms. This change splits that function into two versions, first one for ARCH_WANT_GENERAL_HUGETLB implementation and the other one for everything else. This change is again one of the

[PATCH 10/10] selfttest/powerpc: Add memory page migration tests

This adds two tests for memory page migration. One for normal page migration which works for both 4K or 64K base page size kernel and the other one is for huge page migration which works only on 64K base page sized 16MB huge page implemention at the PMD level. Signed-off-by: Anshuman Khandual

[PATCH 02/10] mm/hugetlb: Add PGD based implementation awareness

Currently the config ARCH_WANT_GENERAL_HUGETLB enabled functions like 'huge_pte_alloc' and 'huge_pte_offset' dont take into account HugeTLB page implementation at the PGD level. This is also true for functions like 'follow_page_mask' which is called from move_pages() system call. This lack of PGD

[PATCH 06/10] powerpc/hugetlb: Split the function 'huge_pte_offset'

Currently the function 'huge_pte_offset' has just got one version for all possible configurations and platforms. This change splits that function into two versions, first one for ARCH_WANT_GENERAL_HUGETLB implementation and the other one for everything else. This change is again one of the

[PATCH 10/10] selfttest/powerpc: Add memory page migration tests

This adds two tests for memory page migration. One for normal page migration which works for both 4K or 64K base page size kernel and the other one is for huge page migration which works only on 64K base page sized 16MB huge page implemention at the PMD level. Signed-off-by: Anshuman Khandual

[PATCH 02/10] mm/hugetlb: Add PGD based implementation awareness

Currently the config ARCH_WANT_GENERAL_HUGETLB enabled functions like 'huge_pte_alloc' and 'huge_pte_offset' dont take into account HugeTLB page implementation at the PGD level. This is also true for functions like 'follow_page_mask' which is called from move_pages() system call. This lack of PGD

[PATCH 05/10] powerpc/hugetlb: Split the function 'huge_pte_alloc'

Currently the function 'huge_pte_alloc' has got two versions, one for the BOOK3S server and the other one for the BOOK3E embedded platforms. This change splits only the BOOK3S server version into two parts, one for the ARCH_WANT_GENERAL_HUGETLB config implementation and the other one for

[PATCH 05/10] powerpc/hugetlb: Split the function 'huge_pte_alloc'

Currently the function 'huge_pte_alloc' has got two versions, one for the BOOK3S server and the other one for the BOOK3E embedded platforms. This change splits only the BOOK3S server version into two parts, one for the ARCH_WANT_GENERAL_HUGETLB config implementation and the other one for

[PATCH 01/10] mm/mmap: Replace SHM_HUGE_MASK with MAP_HUGE_MASK inside mmap_pgoff

The commit 091d0d55b286 ("shm: fix null pointer deref when userspace specifies invalid hugepage size") had replaced MAP_HUGE_MASK with SHM_HUGE_MASK. Though both of them contain the same numeric value of 0x3f, MAP_HUGE_MASK flag sounds more appropriate than the other one in the context. Hence

[PATCH 03/10] mm/hugetlb: Protect follow_huge_(pud|pgd) functions from race

follow_huge_(pmd|pud|pgd) functions are used to walk the page table and fetch the page struct during 'follow_page_mask' call. There are possible race conditions faced by these functions which arise out of simultaneous calls of move_pages() and freeing of huge pages. This was fixed partly by the

[PATCH 08/10] powerpc/hugetlb: Selectively enable ARCH_WANT_GENERAL_HUGETLB

This enables ARCH_WANT_GENERAL_HUGETLB config option only for BOOK3S platforms with 64K page size implementation. Existing arch specific functions for ARCH_WANT_GENERAL_HUGETLB config like 'huge_pte_alloc' and 'huge_pte_offset' are no longer required and are removed with this change.

[PATCH 07/10] powerpc/hugetlb: Prepare arch functions for ARCH_WANT_GENERAL_HUGETLB

Arch override function 'follow_huge_addr' is called from 'follow_page_mask' looking out for the associated page struct. Right now, it does not support the FOLL_GET option. With ARCH_WANTS_GENERAL_HUGETLB, we will need function 'follow_page_mask' to use generic 'follow_huge_*' functions instead of

[PATCH 01/10] mm/mmap: Replace SHM_HUGE_MASK with MAP_HUGE_MASK inside mmap_pgoff

The commit 091d0d55b286 ("shm: fix null pointer deref when userspace specifies invalid hugepage size") had replaced MAP_HUGE_MASK with SHM_HUGE_MASK. Though both of them contain the same numeric value of 0x3f, MAP_HUGE_MASK flag sounds more appropriate than the other one in the context. Hence

[PATCH 03/10] mm/hugetlb: Protect follow_huge_(pud|pgd) functions from race

follow_huge_(pmd|pud|pgd) functions are used to walk the page table and fetch the page struct during 'follow_page_mask' call. There are possible race conditions faced by these functions which arise out of simultaneous calls of move_pages() and freeing of huge pages. This was fixed partly by the

[PATCH 08/10] powerpc/hugetlb: Selectively enable ARCH_WANT_GENERAL_HUGETLB

This enables ARCH_WANT_GENERAL_HUGETLB config option only for BOOK3S platforms with 64K page size implementation. Existing arch specific functions for ARCH_WANT_GENERAL_HUGETLB config like 'huge_pte_alloc' and 'huge_pte_offset' are no longer required and are removed with this change.

[PATCH 07/10] powerpc/hugetlb: Prepare arch functions for ARCH_WANT_GENERAL_HUGETLB

Arch override function 'follow_huge_addr' is called from 'follow_page_mask' looking out for the associated page struct. Right now, it does not support the FOLL_GET option. With ARCH_WANTS_GENERAL_HUGETLB, we will need function 'follow_page_mask' to use generic 'follow_huge_*' functions instead of

[PATCH 09/10] powerpc/hugetlb: Selectively enable ARCH_ENABLE_HUGEPAGE_MIGRATION

This change enables the config option ARCH_ENABLE_HUGEPAGE_MIGRATION depending on whether the platform has got ARCH_WANT_GENERAL_HUGETLB or not along with config option MIGRATION. In turn, it turns on the 'hugepage_migration_supported' function which is checked for feature presence during HugeTLB

[PATCH 00/10] Enable HugeTLB page migration on POWER

This patch series enables HugeTLB page migration on POWER platform. This series has some core VM changes (patch 1, 2, 3) and some powerpc specific changes (patch 4, 5, 6, 7, 8, 9, 10). Comments, suggestions and inputs are welcome. Anshuman Khandual (10): mm/mmap: Replace SHM_HUGE_MASK with

[PATCH 09/10] powerpc/hugetlb: Selectively enable ARCH_ENABLE_HUGEPAGE_MIGRATION

This change enables the config option ARCH_ENABLE_HUGEPAGE_MIGRATION depending on whether the platform has got ARCH_WANT_GENERAL_HUGETLB or not along with config option MIGRATION. In turn, it turns on the 'hugepage_migration_supported' function which is checked for feature presence during HugeTLB

[PATCH 00/10] Enable HugeTLB page migration on POWER

This patch series enables HugeTLB page migration on POWER platform. This series has some core VM changes (patch 1, 2, 3) and some powerpc specific changes (patch 4, 5, 6, 7, 8, 9, 10). Comments, suggestions and inputs are welcome. Anshuman Khandual (10): mm/mmap: Replace SHM_HUGE_MASK with

Re: [PATCH 1/9] iio: adc: exynos_adc: use regmap to retrieve struct device

Hello, On 2016-04-06 22:33, Alison Schofield wrote: On Wed, Apr 06, 2016 at 09:03:00AM +0200, Marek Szyprowski wrote: Hello, On 2016-04-06 07:15, Alison Schofield wrote: Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to

Re: [PATCH 1/9] iio: adc: exynos_adc: use regmap to retrieve struct device

Hello, On 2016-04-06 22:33, Alison Schofield wrote: On Wed, Apr 06, 2016 at 09:03:00AM +0200, Marek Szyprowski wrote: Hello, On 2016-04-06 07:15, Alison Schofield wrote: Driver includes struct regmap and struct device in its global data. Remove the struct device and use regmap API to

[PATCH v4 3/5] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine

This patch adds support for the AXI Direct Memory Access (AXI DMA) core in the existing vdma driver, AXI DMA Core is a soft Xilinx IP core that provides high-bandwidth direct memory access between memory and AXI4-Stream type target peripherals. Signed-off-by: Kedareswara rao Appana

[PATCH v4 4/5] Documentation: DT: vdma: update binding doc for AXI CDMA

This patch updates the device-tree binding doc for adding support for AXI CDMA. Signed-off-by: Kedareswara rao Appana --- Changes for v4: ---> None. Changes for v3: ---> Removed CDMA DT example from the patch as suggested by the Rob. Changes for v2: ---> Modified commit

[PATCH v4 2/5] Documentation: DT: vdma: update binding doc for AXI DMA

This patch updates the device-tree binding doc for adding support for AXI DMA. Also this patch differentiates required properties b/w DMA and VDMA. Signed-off-by: Kedareswara rao Appana --- Changes for v4: ---> None. Changes for v3: ---> Removed AXI DMA DT example from the

[PATCH v4 2/5] Documentation: DT: vdma: update binding doc for AXI DMA

This patch updates the device-tree binding doc for adding support for AXI DMA. Also this patch differentiates required properties b/w DMA and VDMA. Signed-off-by: Kedareswara rao Appana --- Changes for v4: ---> None. Changes for v3: ---> Removed AXI DMA DT example from the patch as suggested by

[PATCH v4 3/5] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine

This patch adds support for the AXI Direct Memory Access (AXI DMA) core in the existing vdma driver, AXI DMA Core is a soft Xilinx IP core that provides high-bandwidth direct memory access between memory and AXI4-Stream type target peripherals. Signed-off-by: Kedareswara rao Appana --- Changes

[PATCH v4 4/5] Documentation: DT: vdma: update binding doc for AXI CDMA

This patch updates the device-tree binding doc for adding support for AXI CDMA. Signed-off-by: Kedareswara rao Appana --- Changes for v4: ---> None. Changes for v3: ---> Removed CDMA DT example from the patch as suggested by the Rob. Changes for v2: ---> Modified commit message as suggested by

[PATCH v4 0/5] dmaengine: vdma: AXI DMA's enhancments

This patch series does some enhancments to the VDMA driver which includes --> Adding support for AXI DMA IP. --> Adding support for AXI CDMA IP. Kedareswara rao Appana (5): dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma Documentation: DT: vdma: update binding doc for AXI DMA

[PATCH v4 0/5] dmaengine: vdma: AXI DMA's enhancments

This patch series does some enhancments to the VDMA driver which includes --> Adding support for AXI DMA IP. --> Adding support for AXI CDMA IP. Kedareswara rao Appana (5): dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma Documentation: DT: vdma: update binding doc for AXI DMA

[PATCH v4 5/5] dmaengine: vdma: Add Support for Xilinx AXI Central Direct Memory Access Engine

This patch adds support for the AXI Central Direct Memory Access (AXI CDMA) core to the existing vdma driver, AXI CDMA is a soft Xilinx IP core that provides high-bandwidth Direct Memory Access(DMA) between a memory-mapped source address and a memory-mapped destination address. Signed-off-by:

[PATCH v4 5/5] dmaengine: vdma: Add Support for Xilinx AXI Central Direct Memory Access Engine

This patch adds support for the AXI Central Direct Memory Access (AXI CDMA) core to the existing vdma driver, AXI CDMA is a soft Xilinx IP core that provides high-bandwidth Direct Memory Access(DMA) between a memory-mapped source address and a memory-mapped destination address. Signed-off-by:

[PATCH v4 1/5] dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma

This patch renames the xilinx_vdma_ prefix to xilinx_dma for the API's and masks that will be shared b/w three DMA IP cores. Signed-off-by: Kedareswara rao Appana --- Changes for v4: > Removed renaming of vdma-mm2s/vdma-s2mm channel names. Changes for v3: ---> None.

[PATCH v4 1/5] dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma

This patch renames the xilinx_vdma_ prefix to xilinx_dma for the API's and masks that will be shared b/w three DMA IP cores. Signed-off-by: Kedareswara rao Appana --- Changes for v4: > Removed renaming of vdma-mm2s/vdma-s2mm channel names. Changes for v3: ---> None. Changes for v2: ---> New

linux-next: Tree for Apr 7

Hi all, Changes since 20160406: The akpm-current tree gained a build failure for which I applied a patch. Non-merge commits (relative to Linus' tree): 2722 2566 files changed, 106575 insertions(+), 66077 deletions

linux-next: Tree for Apr 7

Hi all, Changes since 20160406: The akpm-current tree gained a build failure for which I applied a patch. Non-merge commits (relative to Linus' tree): 2722 2566 files changed, 106575 insertions(+), 66077 deletions

bindat/connectat syscalls

Related thread (2012): https://marc.info/?l=linux-netdev=133897212713981=2 FreeBSD[1] chose signatures of: int bindat(int fd, int s, const struct sockaddr *addr, socklen_t addrlen); int connectat(int fd, int s, const struct sockaddr *name, socklen_t namelen); An alternate implementation

bindat/connectat syscalls

Related thread (2012): https://marc.info/?l=linux-netdev=133897212713981=2 FreeBSD[1] chose signatures of: int bindat(int fd, int s, const struct sockaddr *addr, socklen_t addrlen); int connectat(int fd, int s, const struct sockaddr *name, socklen_t namelen); An alternate implementation

linux-next: build warning after merge of the tip tree

Hi all, After merging the tip tree, today's linux-next build (powerpc ppc44x_defconfig) produced this warning: mm/gup.c: In function 'get_user_pages_fast': mm/gup.c:1510:20: warning: unused variable 'mm' [-Wunused-variable] struct mm_struct *mm = current->mm; ^ Introduced

linux-next: build warning after merge of the tip tree

Hi all, After merging the tip tree, today's linux-next build (powerpc ppc44x_defconfig) produced this warning: mm/gup.c: In function 'get_user_pages_fast': mm/gup.c:1510:20: warning: unused variable 'mm' [-Wunused-variable] struct mm_struct *mm = current->mm; ^ Introduced

Re: [PATCH v6 2/6] hwmon: (fam15h_power) Add compute unit accumulated power

On 04/06/2016 10:05 PM, Huang Rui wrote: On Wed, Apr 06, 2016 at 08:30:25AM -0700, Guenter Roeck wrote: On Wed, Apr 06, 2016 at 03:44:11PM +0800, Huang Rui wrote: +static void do_read_registers_on_cu(void *_data) +{ + struct fam15h_power_data *data = _data; + int cpu, cu; + +

Re: [PATCH v6 2/6] hwmon: (fam15h_power) Add compute unit accumulated power

On 04/06/2016 10:05 PM, Huang Rui wrote: On Wed, Apr 06, 2016 at 08:30:25AM -0700, Guenter Roeck wrote: On Wed, Apr 06, 2016 at 03:44:11PM +0800, Huang Rui wrote: +static void do_read_registers_on_cu(void *_data) +{ + struct fam15h_power_data *data = _data; + int cpu, cu; + +

Re: linux-next: build failure after merge of the akpm-current tree

On Thu, 7 Apr 2016, Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm-current tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > In file included from include/linux/linkage.h:4:0, > from include/linux/fs.h:4, > from

RE: [PATCH v2 0/3] Improvement, fix and new entry for dwc3 debugfs

HI "Du, Changbin" writes: >> before I review your patches, one comment >> >> changbin...@intel.com writes: >> > From: "Du, Changbin" >> > >> > The first patch removed unnecessary checking for debugfs api call; >> > The second patch fix a memory

Re: linux-next: build failure after merge of the akpm-current tree

On Thu, 7 Apr 2016, Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm-current tree, today's linux-next build (arm > multi_v7_defconfig) failed like this: > > In file included from include/linux/linkage.h:4:0, > from include/linux/fs.h:4, > from

RE: [PATCH v2 0/3] Improvement, fix and new entry for dwc3 debugfs

HI "Du, Changbin" writes: >> before I review your patches, one comment >> >> changbin...@intel.com writes: >> > From: "Du, Changbin" >> > >> > The first patch removed unnecessary checking for debugfs api call; >> > The second patch fix a memory leak issue; >> > The third patch add one new

RE: [PATCH v2 0/3] Improvement, fix and new entry for dwc3 debugfs

> before I review your patches, one comment > > changbin...@intel.com writes: > > From: "Du, Changbin" > > > > The first patch removed unnecessary checking for debugfs api call; > > The second patch fix a memory leak issue; > > The third patch add one new entry to debufs.

RE: [PATCH v2 0/3] Improvement, fix and new entry for dwc3 debugfs

> before I review your patches, one comment > > changbin...@intel.com writes: > > From: "Du, Changbin" > > > > The first patch removed unnecessary checking for debugfs api call; > > The second patch fix a memory leak issue; > > The third patch add one new entry to debufs. > > > > Du, Changbin

linux-next: build failure after merge of the akpm-current tree

Hi Andrew, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) failed like this: In file included from include/linux/linkage.h:4:0, from include/linux/fs.h:4, from mm/shmem.c:24: In function 'shmem_disband_hugeteam',

linux-next: build failure after merge of the akpm-current tree

Hi Andrew, After merging the akpm-current tree, today's linux-next build (arm multi_v7_defconfig) failed like this: In file included from include/linux/linkage.h:4:0, from include/linux/fs.h:4, from mm/shmem.c:24: In function 'shmem_disband_hugeteam',

Re: [PATCH v2 2/3] usb: dwc3: free dwc->regset on dwc3_debugfs_exit

changbin...@intel.com writes: > From: "Du, Changbin" > no commit log == no commit, sorry > Signed-off-by: Du, Changbin > --- > drivers/usb/dwc3/debugfs.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/usb/dwc3/debugfs.c

Re: [PATCH v2 2/3] usb: dwc3: free dwc->regset on dwc3_debugfs_exit

changbin...@intel.com writes: > From: "Du, Changbin" > no commit log == no commit, sorry > Signed-off-by: Du, Changbin > --- > drivers/usb/dwc3/debugfs.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c > index

Re: [PATCH v2 0/3] Improvement, fix and new entry for dwc3 debugfs

Hi, before I review your patches, one comment changbin...@intel.com writes: > From: "Du, Changbin" > > The first patch removed unnecessary checking for debugfs api call; > The second patch fix a memory leak issue; > The third patch add one new entry to debufs. > > Du,

Re: [PATCH v2 0/3] Improvement, fix and new entry for dwc3 debugfs

Hi, before I review your patches, one comment changbin...@intel.com writes: > From: "Du, Changbin" > > The first patch removed unnecessary checking for debugfs api call; > The second patch fix a memory leak issue; > The third patch add one new entry to debufs. > > Du, Changbin (3): > usb:

Re: [PATCH v6 2/6] hwmon: (fam15h_power) Add compute unit accumulated power

On Wed, Apr 06, 2016 at 08:30:25AM -0700, Guenter Roeck wrote: > On Wed, Apr 06, 2016 at 03:44:11PM +0800, Huang Rui wrote: > > > > +static void do_read_registers_on_cu(void *_data) > > +{ > > + struct fam15h_power_data *data = _data; > > + int cpu, cu; > > + > > + cpu =

Re: [PATCH v6 2/6] hwmon: (fam15h_power) Add compute unit accumulated power

On Wed, Apr 06, 2016 at 08:30:25AM -0700, Guenter Roeck wrote: > On Wed, Apr 06, 2016 at 03:44:11PM +0800, Huang Rui wrote: > > > > +static void do_read_registers_on_cu(void *_data) > > +{ > > + struct fam15h_power_data *data = _data; > > + int cpu, cu; > > + > > + cpu =

Re: [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

Hi, Greg Kroah-Hartman writes: > On Wed, Apr 06, 2016 at 01:19:04PM +0300, Felipe Balbi wrote: >> > What happened to getting internal help in designing this api? This >> > shouldn't be my job :) >> >> I looked at this Baolu but, at least to me, it's unclear what

Re: [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

Hi, Greg Kroah-Hartman writes: > On Wed, Apr 06, 2016 at 01:19:04PM +0300, Felipe Balbi wrote: >> > What happened to getting internal help in designing this api? This >> > shouldn't be my job :) >> >> I looked at this Baolu but, at least to me, it's unclear what you're >> hinting here. Sure,

Re: [PATCH v9 2/4] gadget: Support for the usb charger framework

Hi, Peter Chen writes: >> >> > In below change of usb_gadget_vbus_draw(), already can get charger >> >> > type via usb_charger_get_type(). >> >> > >> >> > static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget, >> >> > unsigned mA) { >> >> > + enum

[PATCH v2] gpio: pca953x: add PCAL9535 interrupt support for Galileo Gen2

Galileo Gen2 board uses the PCAL9535 as the GPIO expansion, it is different from PCA9535 and includes interrupt mask/status registers, The current driver does not support the interrupt registers configuration, it causes some gpio pins cannot trigger interrupt events, this patch fix this issue. The

Re: [PATCH v9 2/4] gadget: Support for the usb charger framework

Hi, Peter Chen writes: >> >> > In below change of usb_gadget_vbus_draw(), already can get charger >> >> > type via usb_charger_get_type(). >> >> > >> >> > static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget, >> >> > unsigned mA) { >> >> > + enum usb_charger_type type; >> >>

[PATCH v2] gpio: pca953x: add PCAL9535 interrupt support for Galileo Gen2

Galileo Gen2 board uses the PCAL9535 as the GPIO expansion, it is different from PCA9535 and includes interrupt mask/status registers, The current driver does not support the interrupt registers configuration, it causes some gpio pins cannot trigger interrupt events, this patch fix this issue. The

Re: [PATCH v9 1/4] gadget: Introduce the usb charger framework

Hi, Peter Chen writes: > On Wed, Apr 06, 2016 at 01:25:06PM +0300, Felipe Balbi wrote: >> >> Hi, >> >> Peter Chen writes: >> > On Wed, Apr 06, 2016 at 11:05:26AM +0300, Felipe Balbi wrote: >> >> Peter Chen writes: >> >> >

Re: [PATCH v9 1/4] gadget: Introduce the usb charger framework

Hi, Peter Chen writes: > On Wed, Apr 06, 2016 at 01:25:06PM +0300, Felipe Balbi wrote: >> >> Hi, >> >> Peter Chen writes: >> > On Wed, Apr 06, 2016 at 11:05:26AM +0300, Felipe Balbi wrote: >> >> Peter Chen writes: >> >> > On Wed, Apr 06, 2016 at 10:38:23AM +0300, Felipe Balbi wrote: >> >>

Re: [PATCH] x86/hpet: Reduce HPET counter read contention

On Wed, Apr 6, 2016 at 7:02 AM, Waiman Long wrote: > On a large system with many CPUs, using HPET as the clock source can > have a significant impact on the overall system performance because > of the following reasons: > 1) There is a single HPET counter shared by all the

Re: [PATCH] x86/hpet: Reduce HPET counter read contention

On Wed, Apr 6, 2016 at 7:02 AM, Waiman Long wrote: > On a large system with many CPUs, using HPET as the clock source can > have a significant impact on the overall system performance because > of the following reasons: > 1) There is a single HPET counter shared by all the CPUs. > 2) HPET

Re: [PATCH] of/platform: Allow secondary compatible match in of_dev_lookup

On Fri, Apr 1, 2016 at 4:40 PM, Tony Lindgren wrote: > * Tony Lindgren [160401 14:37]: >> We currently try to match of_dev_auxdata based on compatible, >> IO address, and device name. But in some cases we have multiple >> instances of drivers that can use the

Re: [PATCH] of/platform: Allow secondary compatible match in of_dev_lookup

On Fri, Apr 1, 2016 at 4:40 PM, Tony Lindgren wrote: > * Tony Lindgren [160401 14:37]: >> We currently try to match of_dev_auxdata based on compatible, >> IO address, and device name. But in some cases we have multiple >> instances of drivers that can use the same auxdata. >> >> Let's add an

Re: [rfc patch 2/2] rt/locking/hotplug: Fix rt_spin_lock_slowlock() migrate_disable() bug

On Wed, 2016-04-06 at 14:00 +0200, Mike Galbraith wrote: > It'll take a hotplug beating seemingly as well as any non-rt kernel, > but big box NAKed it due to jitter, which can mean 1.0 things.. duh. FWIW, the below turned big box NAK into ACK. Stressing hotplug over night, iteration completion

Re: [rfc patch 2/2] rt/locking/hotplug: Fix rt_spin_lock_slowlock() migrate_disable() bug

On Wed, 2016-04-06 at 14:00 +0200, Mike Galbraith wrote: > It'll take a hotplug beating seemingly as well as any non-rt kernel, > but big box NAKed it due to jitter, which can mean 1.0 things.. duh. FWIW, the below turned big box NAK into ACK. Stressing hotplug over night, iteration completion

Re: [PATCH 1/2] perf/powerpc: Fix kprobe and kretprobe handling with kallsyms

On Wed, Apr 06, 2016 at 06:02:57PM +0530, Naveen N. Rao wrote: > + if (!pev->uprobes && map->dso->symtab_type == DSO_BINARY_TYPE__KALLSYMS) > tev->point.offset += PPC64LE_LEP_OFFSET; uprobes check against kallsysms? Am I missing something here? Ananth

Re: [PATCH] cpufreq: Rearrange cpufreq_add_dev()

On 07-04-16, 03:31, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Reorganize the code in cpufreq_add_dev() to avoid using the ret > variable and reduce the indentation level in it. > > No functional changes. > > Signed-off-by: Rafael J. Wysocki

Re: [PATCH 1/2] perf/powerpc: Fix kprobe and kretprobe handling with kallsyms

On Wed, Apr 06, 2016 at 06:02:57PM +0530, Naveen N. Rao wrote: > + if (!pev->uprobes && map->dso->symtab_type == DSO_BINARY_TYPE__KALLSYMS) > tev->point.offset += PPC64LE_LEP_OFFSET; uprobes check against kallsysms? Am I missing something here? Ananth

Re: [PATCH] cpufreq: Rearrange cpufreq_add_dev()

On 07-04-16, 03:31, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Reorganize the code in cpufreq_add_dev() to avoid using the ret > variable and reduce the indentation level in it. > > No functional changes. > > Signed-off-by: Rafael J. Wysocki > --- > drivers/cpufreq/cpufreq.c |

Re: [PATCH] cpufreq: Simplify switch () in cpufreq_cpu_callback()

On 07-04-16, 03:30, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Merge two switch entries that do the same thing in > cpufreq_cpu_callback(). > > No functional changes. > > Signed-off-by: Rafael J. Wysocki > --- >

Re: [PATCH] cpufreq: Simplify switch () in cpufreq_cpu_callback()

On 07-04-16, 03:30, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Merge two switch entries that do the same thing in > cpufreq_cpu_callback(). > > No functional changes. > > Signed-off-by: Rafael J. Wysocki > --- > drivers/cpufreq/cpufreq.c |5 + > 1 file changed, 1

Re: [PATCH] cpufreq: Skip all governor-related actions for cpufreq_suspended set

On 07-04-16, 03:29, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Since governor operations are generally skipped if cpufreq_suspended > is set, do nothing at all in cpufreq_start_governor() and > cpufreq_exit_governor() in that case. > > In particular, this

Re: [PATCH] cpufreq: Skip all governor-related actions for cpufreq_suspended set

On 07-04-16, 03:29, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Since governor operations are generally skipped if cpufreq_suspended > is set, do nothing at all in cpufreq_start_governor() and > cpufreq_exit_governor() in that case. > > In particular, this prevents fast frequency

Haswell IOMMU bug that gets no response from maintainers

Hello. In August 2013, I have reported this bug: https://bugzilla.kernel.org/show_bug.cgi?id=60769 . It has been determined on October 2013 to be a bug with IOMMU. The bug manifests itself as either unreliable or completely non-working HDMI audio on Haswell systems. However, there have

Haswell IOMMU bug that gets no response from maintainers

Hello. In August 2013, I have reported this bug: https://bugzilla.kernel.org/show_bug.cgi?id=60769 . It has been determined on October 2013 to be a bug with IOMMU. The bug manifests itself as either unreliable or completely non-working HDMI audio on Haswell systems. However, there have

[PATCH] drm: bridge: analogix/dp: fix no drm hpd event when panel plug in

The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only send drm hp event when the irq_type and the enum value is true. if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...) drm_helper_hpd_irq_event(dp->drm_dev); So there would no drm hpd event when cable plug in, to fix that just

[PATCH] drm: bridge: analogix/dp: fix no drm hpd event when panel plug in

The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only send drm hp event when the irq_type and the enum value is true. if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...) drm_helper_hpd_irq_event(dp->drm_dev); So there would no drm hpd event when cable plug in, to fix that just

Re: [PATCH] drm: bridge: analogix/dp: fix no drm hpd event when panel plug in

Sorry for disturb, I make a mistaken about the receive list, please ignore this email. - Yakir On 04/07/2016 12:15 PM, Yakir Yang wrote: The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only send drm hp event when the irq_type and the enum value is true. if (irq_type &

Re: [PATCH] drm: bridge: analogix/dp: fix no drm hpd event when panel plug in

Sorry for disturb, I make a mistaken about the receive list, please ignore this email. - Yakir On 04/07/2016 12:15 PM, Yakir Yang wrote: The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only send drm hp event when the irq_type and the enum value is true. if (irq_type &

Re: [PATCH] gpio: pca953x: add PCAL9535 interrupt support for Galileo Gen2

Hi Yong, [auto build test WARNING on gpio/for-next] [also build test WARNING on v4.6-rc2 next-20160406] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Yong-Li/gpio-pca953x-add-PCAL9535

Re: [PATCH] gpio: pca953x: add PCAL9535 interrupt support for Galileo Gen2

Hi Yong, [auto build test WARNING on gpio/for-next] [also build test WARNING on v4.6-rc2 next-20160406] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Yong-Li/gpio-pca953x-add-PCAL9535

[PATCH] gpio: pca953x: fix boolreturn.cocci warnings

drivers/gpio/gpio-pca953x.c:522:10-11: WARNING: return of 0/1 in function 'pca953x_irq_pending' with return type bool Return statements in functions returning bool should use true/false instead of 1/0. Generated by: scripts/coccinelle/misc/boolreturn.cocci CC: Yong Li

[PATCH] gpio: pca953x: fix boolreturn.cocci warnings

drivers/gpio/gpio-pca953x.c:522:10-11: WARNING: return of 0/1 in function 'pca953x_irq_pending' with return type bool Return statements in functions returning bool should use true/false instead of 1/0. Generated by: scripts/coccinelle/misc/boolreturn.cocci CC: Yong Li Signed-off-by:

[PATCH] drm: bridge: analogix/dp: fix no drm hpd event when panel plug in

The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only send drm hp event when the irq_type and the enum value is true. if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...) drm_helper_hpd_irq_event(dp->drm_dev); So there would no drm hpd event when cable plug in, to fix that just

[PATCH] drm: bridge: analogix/dp: fix no drm hpd event when panel plug in

The enum value of DP_IRQ_TYPE_HP_CABLE_IN is zero, but driver only send drm hp event when the irq_type and the enum value is true. if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN || ...) drm_helper_hpd_irq_event(dp->drm_dev); So there would no drm hpd event when cable plug in, to fix that just

Re: [PATCH 09/27] target: use bio_is_full()

On Tue, Apr 5, 2016 at 9:02 PM, Christoph Hellwig wrote: > On Tue, Apr 05, 2016 at 07:56:54PM +0800, Ming Lei wrote: >> +++ b/drivers/target/target_core_pscsi.c >> @@ -951,7 +951,7 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist >> *sgl, u32 sgl_nents, >>

Re: [PATCH 09/27] target: use bio_is_full()

On Tue, Apr 5, 2016 at 9:02 PM, Christoph Hellwig wrote: > On Tue, Apr 05, 2016 at 07:56:54PM +0800, Ming Lei wrote: >> +++ b/drivers/target/target_core_pscsi.c >> @@ -951,7 +951,7 @@ pscsi_map_sg(struct se_cmd *cmd, struct scatterlist >> *sgl, u32 sgl_nents, >>

RE: [PATCH v3 1/5] Documentation: DT: vdma: Rename vdma-chan prefix to dma-chan

Hi Vinod, > -Original Message- > From: Koul, Vinod [mailto:vinod.k...@intel.com] > Sent: Thursday, April 07, 2016 5:53 AM > To: Soren Brinkmann > Cc: l...@metafoo.de; linux-kernel@vger.kernel.org; pawel.m...@arm.com; > Appana Durga Kedareswara Rao ;

RE: [PATCH v3 1/5] Documentation: DT: vdma: Rename vdma-chan prefix to dma-chan

Hi Vinod, > -Original Message- > From: Koul, Vinod [mailto:vinod.k...@intel.com] > Sent: Thursday, April 07, 2016 5:53 AM > To: Soren Brinkmann > Cc: l...@metafoo.de; linux-kernel@vger.kernel.org; pawel.m...@arm.com; > Appana Durga Kedareswara Rao ; > l...@debethencourt.com;

  1   2   3   4   5   6   7   8   9   10   >