Re: [PATCH] i2c: qup: fix building without CONFIG_ACPI

On 5/30/2018 3:31 PM, Arnd Bergmann wrote: The added Centriq support broke compilation with CONFIG_ACPI disabled: drivers/i2c/busses/i2c-qup.c: In function 'qup_i2c_probe': drivers/i2c/busses/i2c-qup.c:1707:25: error: 'qup_i2c_acpi_match' undeclared (first use in this function); did you

Re: [PATCH] i2c: qup: fix building without CONFIG_ACPI

On 5/30/2018 3:31 PM, Arnd Bergmann wrote: The added Centriq support broke compilation with CONFIG_ACPI disabled: drivers/i2c/busses/i2c-qup.c: In function 'qup_i2c_probe': drivers/i2c/busses/i2c-qup.c:1707:25: error: 'qup_i2c_acpi_match' undeclared (first use in this function); did you

Re: [PATCH v2 00/13] Major code reorganization to make all i2c transfers working

Sorry for the miscommunication. I reviewed the patches and tested them on the Centriq 2400 platform. Perhaps the following is the most appropriate. Acked-by: Austin Christ <austi...@codeaurora.org> On 3/13/2018 3:17 PM, Wolfram Sang wrote: On Tue, Mar 13, 2018 at 03:09:00PM -0600,

Re: [PATCH v2 00/13] Major code reorganization to make all i2c transfers working

Sorry for the miscommunication. I reviewed the patches and tested them on the Centriq 2400 platform. Perhaps the following is the most appropriate. Acked-by: Austin Christ On 3/13/2018 3:17 PM, Wolfram Sang wrote: On Tue, Mar 13, 2018 at 03:09:00PM -0600, Christ, Austin wrote: I've tested

Re: [PATCH v2 00/13] Major code reorganization to make all i2c transfers working

I've tested this v2 series on Centriq 2400. Looks good to me. Reviewed-by: Austin Christ On 3/12/2018 7:14 AM, Abhishek Sahu wrote: * v2: 1. Address review comments in v1 2. Changed the license to SPDX 3. Changed commit messages for some of the patch having more

Re: [PATCH v2 00/13] Major code reorganization to make all i2c transfers working

I've tested this v2 series on Centriq 2400. Looks good to me. Reviewed-by: Austin Christ On 3/12/2018 7:14 AM, Abhishek Sahu wrote: * v2: 1. Address review comments in v1 2. Changed the license to SPDX 3. Changed commit messages for some of the patch having more detail 4. Removed event-based

Re: [PATCH 12/12] i2c: qup: reorganization of driver code to remove polling for qup v2

On 2/3/2018 12:58 AM, Abhishek Sahu wrote: Following are the major issues in current driver code 1. The current driver simply assumes the transfer completion whenever its gets any non-error interrupts and then simply do the polling of available/free bytes in FIFO. 2. The block mode is

Re: [PATCH 12/12] i2c: qup: reorganization of driver code to remove polling for qup v2

On 2/3/2018 12:58 AM, Abhishek Sahu wrote: Following are the major issues in current driver code 1. The current driver simply assumes the transfer completion whenever its gets any non-error interrupts and then simply do the polling of available/free bytes in FIFO. 2. The block mode is

Re: [PATCH 10/12] i2c: qup: send NACK for last read sub transfers

Tested on Centriq 2400 Reviewed-by: Austin Christ On 2/3/2018 12:58 AM, Abhishek Sahu wrote: According to I2c specification, “If a master-receiver sends a repeated START condition, it sends a not-acknowledge (A) just before the repeated START condition”. QUP v2

Re: [PATCH 10/12] i2c: qup: send NACK for last read sub transfers

Tested on Centriq 2400 Reviewed-by: Austin Christ On 2/3/2018 12:58 AM, Abhishek Sahu wrote: According to I2c specification, “If a master-receiver sends a repeated START condition, it sends a not-acknowledge (A) just before the repeated START condition”. QUP v2 supports sending of NACK

Re: [PATCH 09/12] i2c: qup: fix buffer overflow for multiple msg of maximum xfer len

Hey Abhishek, On 2/3/2018 12:58 AM, Abhishek Sahu wrote: The BAM mode requires buffer for start tag data and tx, rx SG list. Currently, this is being taken for maximum transfer length (65K). But an I2C transfer can have multiple messages and each message can be of this maximum length so the

Re: [PATCH 09/12] i2c: qup: fix buffer overflow for multiple msg of maximum xfer len

Hey Abhishek, On 2/3/2018 12:58 AM, Abhishek Sahu wrote: The BAM mode requires buffer for start tag data and tx, rx SG list. Currently, this is being taken for maximum transfer length (65K). But an I2C transfer can have multiple messages and each message can be of this maximum length so the

Re: [PATCH 07/12] i2c: qup: use the complete transfer length to choose DMA mode

Tested on Centriq 2400 Reviewed-by: Austin Christ On 2/3/2018 12:58 AM, Abhishek Sahu wrote: Currently each message length in complete transfer is being checked for determining DMA mode and if any of the message length is less than FIFO length then non DMA mode is

Re: [PATCH 07/12] i2c: qup: use the complete transfer length to choose DMA mode

Tested on Centriq 2400 Reviewed-by: Austin Christ On 2/3/2018 12:58 AM, Abhishek Sahu wrote: Currently each message length in complete transfer is being checked for determining DMA mode and if any of the message length is less than FIFO length then non DMA mode is being used which will

Re: [PATCH 06/12] i2c: qup: proper error handling for i2c error in BAM mode

Tested on Centriq 2400 Reviewed-by: Austin Christ On 2/3/2018 12:58 AM, Abhishek Sahu wrote: Currently the i2c error handling in BAM mode is not working properly in stress condition. 1. After an error, the FIFO are being written with FLUSH and EOT tags which

Re: [PATCH 06/12] i2c: qup: proper error handling for i2c error in BAM mode

Tested on Centriq 2400 Reviewed-by: Austin Christ On 2/3/2018 12:58 AM, Abhishek Sahu wrote: Currently the i2c error handling in BAM mode is not working properly in stress condition. 1. After an error, the FIFO are being written with FLUSH and EOT tags which should not be required since

Re: [PATCH 03/12] i2c: qup: remove redundant variables for BAM SG count

I agree with Sricharan's comments about naming, otherwise looks good. Tested on Centriq 2400 Reviewed-by: Austin Christ On 2/3/2018 12:58 AM, Abhishek Sahu wrote: The rx_nents and tx_nents are redundant. rx_buf and tx_buf can be used for total number of SG entries.

Re: [PATCH 03/12] i2c: qup: remove redundant variables for BAM SG count

I agree with Sricharan's comments about naming, otherwise looks good. Tested on Centriq 2400 Reviewed-by: Austin Christ On 2/3/2018 12:58 AM, Abhishek Sahu wrote: The rx_nents and tx_nents are redundant. rx_buf and tx_buf can be used for total number of SG entries. Signed-off-by: Abhishek

Re: [PATCH 02/12] i2c: qup: minor code reorganization for use_dma

Tested on Centriq 2400 Reviewed-by: Austin Christ On 2/3/2018 12:58 AM, Abhishek Sahu wrote: 1. Assigns use_dma in qup_dev structure itself which will help in subsequent patches to determine the mode in IRQ handler. 2. Does minor code reorganization for loops to

Re: [PATCH 02/12] i2c: qup: minor code reorganization for use_dma

Tested on Centriq 2400 Reviewed-by: Austin Christ On 2/3/2018 12:58 AM, Abhishek Sahu wrote: 1. Assigns use_dma in qup_dev structure itself which will help in subsequent patches to determine the mode in IRQ handler. 2. Does minor code reorganization for loops to reduce the unnecessary

Re: [PATCH 01/12] i2c: qup: fixed releasing dma without flush operation completion

Tested on Centriq 2400 Reviewed-by: Austin Christ On 2/3/2018 12:58 AM, Abhishek Sahu wrote: The QUP BSLP BAM generates the following error sometimes if the current I2C DMA transfer fails and the flush operation has been scheduled “bam-dma-engine 7884000.dma:

Re: [PATCH 01/12] i2c: qup: fixed releasing dma without flush operation completion

Tested on Centriq 2400 Reviewed-by: Austin Christ On 2/3/2018 12:58 AM, Abhishek Sahu wrote: The QUP BSLP BAM generates the following error sometimes if the current I2C DMA transfer fails and the flush operation has been scheduled “bam-dma-engine 7884000.dma: Cannot free busy channel”

Re: [PATCH v3 1/7] ACPI/PPTT: Add Processor Properties Topology Table parsing

Hey Jeremy, Quick comment below. On 10/12/2017 1:48 PM, Jeremy Linton wrote: +static int topology_setup_acpi_cpu(struct acpi_table_header *table, + unsigned int cpu, int level) +{ + struct acpi_pptt_processor *cpu_node; + u32 acpi_cpu_id =

Re: [PATCH v3 1/7] ACPI/PPTT: Add Processor Properties Topology Table parsing

Hey Jeremy, Quick comment below. On 10/12/2017 1:48 PM, Jeremy Linton wrote: +static int topology_setup_acpi_cpu(struct acpi_table_header *table, + unsigned int cpu, int level) +{ + struct acpi_pptt_processor *cpu_node; + u32 acpi_cpu_id =

Re: [PATCH V3 0/2] load_balance() fixes for affinity

Hey Peter, On 5/22/2017 9:52 AM, Peter Zijlstra wrote: On Thu, May 18, 2017 at 01:36:01PM -0600, Jeffrey Hugo wrote: The group_imbalance path correctly sets the flag to indicate the group can not be properly balanced due to affinity, but the redo condition right after this branch incorrectly

Re: [PATCH V3 0/2] load_balance() fixes for affinity

Hey Peter, On 5/22/2017 9:52 AM, Peter Zijlstra wrote: On Thu, May 18, 2017 at 01:36:01PM -0600, Jeffrey Hugo wrote: The group_imbalance path correctly sets the flag to indicate the group can not be properly balanced due to affinity, but the redo condition right after this branch incorrectly

Re: [PATCH V3 1/2] sched/fair: Fix load_balance() affinity redo path

Hey Dietmar, On 5/22/2017 3:48 AM, Dietmar Eggemann wrote: On 19/05/17 14:31, Dietmar Eggemann wrote: On 18/05/17 20:36, Jeffrey Hugo wrote: [...] diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index d711093..a5d41b1 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@

Re: [PATCH V3 1/2] sched/fair: Fix load_balance() affinity redo path

Hey Dietmar, On 5/22/2017 3:48 AM, Dietmar Eggemann wrote: On 19/05/17 14:31, Dietmar Eggemann wrote: On 18/05/17 20:36, Jeffrey Hugo wrote: [...] diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index d711093..a5d41b1 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@

Re: [PATCH] efi: capsule: allocate whole capsule into virtual memory

Hello, On 7/28/2016 12:07 AM, joeyli wrote: Hi Austin, On Fri, Jul 15, 2016 at 10:41:31AM -0600, Austin Christ wrote: According to UEFI 2.6 section 7.5.3, the capsule should be in contiguous virtual memory and firmware may consume the capsule immediately. To correctly implement this

Re: [PATCH] efi: capsule: allocate whole capsule into virtual memory

Hello, On 7/28/2016 12:07 AM, joeyli wrote: Hi Austin, On Fri, Jul 15, 2016 at 10:41:31AM -0600, Austin Christ wrote: According to UEFI 2.6 section 7.5.3, the capsule should be in contiguous virtual memory and firmware may consume the capsule immediately. To correctly implement this

Re: [PATCH] efi: capsule: allocate whole capsule into virtual memory

Hey Matt, On 7/21/2016 7:12 AM, Matt Fleming wrote: On Fri, 15 Jul, at 10:41:31AM, Christ, Austin wrote: According to UEFI 2.6 section 7.5.3, the capsule should be in contiguous virtual memory and firmware may consume the capsule immediately. To correctly implement this functionality

Re: [PATCH] efi: capsule: allocate whole capsule into virtual memory

Hey Matt, On 7/21/2016 7:12 AM, Matt Fleming wrote: On Fri, 15 Jul, at 10:41:31AM, Christ, Austin wrote: According to UEFI 2.6 section 7.5.3, the capsule should be in contiguous virtual memory and firmware may consume the capsule immediately. To correctly implement this functionality

Re: [PATCH 1/2][v3] i2c: qup: add ACPI support

On 6/5/2016 12:57 PM, Andy Gross wrote: On Thu, May 26, 2016 at 01:37:56PM -0600, Austin Christ wrote: @@ -1354,14 +1359,13 @@ static void qup_i2c_disable_clocks(struct qup_i2c_dev *qup) static int qup_i2c_probe(struct platform_device *pdev) { static const int blk_sizes[] = {4,

Re: [PATCH 1/2][v3] i2c: qup: add ACPI support

On 6/5/2016 12:57 PM, Andy Gross wrote: On Thu, May 26, 2016 at 01:37:56PM -0600, Austin Christ wrote: @@ -1354,14 +1359,13 @@ static void qup_i2c_disable_clocks(struct qup_i2c_dev *qup) static int qup_i2c_probe(struct platform_device *pdev) { static const int blk_sizes[] = {4,

Re: [PATCH v3 2/2] i2c: qup: support SMBus block read

Hello, On 5/25/2016 3:31 AM, rajeev kumar wrote: On Fri, May 20, 2016 at 3:14 AM, Austin Christ wrote: From: Naveen Kaje I2C QUP driver relies on SMBus emulation support from the framework. To handle SMBus block reads, the driver should check

Re: [PATCH v3 2/2] i2c: qup: support SMBus block read

Hello, On 5/25/2016 3:31 AM, rajeev kumar wrote: On Fri, May 20, 2016 at 3:14 AM, Austin Christ wrote: From: Naveen Kaje I2C QUP driver relies on SMBus emulation support from the framework. To handle SMBus block reads, the driver should check I2C_M_RECV_LEN flag and should read the first

Re: [PATCH v2 2/2] i2c: qup: support SMBus block read

On 5/20/2016 2:31 AM, Sricharan wrote: Hi, @@ -1128,6 +1173,22 @@ static int qup_i2c_read_one_v2(struct qup_i2c_dev *qup, struct i2c_msg *msg) goto err; qup->blk.pos++; + + /* Handle SMBus block read length */ + if

Re: [PATCH v2 2/2] i2c: qup: support SMBus block read

On 5/20/2016 2:31 AM, Sricharan wrote: Hi, @@ -1128,6 +1173,22 @@ static int qup_i2c_read_one_v2(struct qup_i2c_dev *qup, struct i2c_msg *msg) goto err; qup->blk.pos++; + + /* Handle SMBus block read length */ + if