ut these pages are normal system RAM,
typically HugePages (but not always).
>
>Cc: Greg Kroah-Hartman
>Cc: Vandana BN
>Cc: "Simon Sandström"
>Cc: Dan Carpenter
>Cc: Nishka Dasgupta
>Cc: Madhumitha Prabakaran
>Cc: Fabio Estevam
>Cc: Matt Sickler
>Cc:
>-Original Message-
>From: devel On Behalf Of
>Chandra Annamaneni
>Sent: Wednesday, October 09, 2019 10:09 PM
>To: gre...@linuxfoundation.org
>Cc: de...@driverdev.osuosl.org; gneuk...@gmail.com; chandra...@gmail.com;
>fabian.krue...@fau.de; linux-
>ker...@vger.kernel.org; si...@nikanor.n
>-Original Message-
>From: devel On Behalf Of Greg
>KH
>Sent: Thursday, August 01, 2019 11:35 AM
>To: Harsh Jain
>Cc: de...@driverdev.osuosl.org; linux-ker...@vger.kernel.org
>Subject: Re: [PATCH] staging:kpc2000:Fix dubious x | !y sparse warning
>
>On Thu, Aug 01, 2019 at 12:06:06AM +05
>From: Bharath Vedartham
>Changes since v2
>- Added back PageResevered check as suggested by John Hubbard.
>
>The PageReserved check needs a closer look and is not worth messing
>around with for now.
>
>Matt, Could you give any suggestions for testing this patch?
Myself or someone else fr
It looks like Outlook is going to absolutely trash this email. Hopefully it
comes through okay.
>> There have been issues with get_user_pages and filesystem writeback.
>> The issues are better described in [1].
>>
>> The solution being proposed wants to keep track of gup_pinned pages
>which will
>-Original Message-
>From: Jeremy Sowden
>I've had a go at getting the DMA AIO working. It compiles, but I don't
>have access to the hardware, so I have done no more testing than that.
Honestly, it'd probably be better to just remove the AIO support entirely. The
one use case we had tha
mplete
>call-back of the kiocb object.
>
>Cc: Matt Sickler
>Signed-off-by: Jeremy Sowden
>---
> drivers/staging/kpc2000/kpc_dma/fileops.c | 40 +++
> 1 file changed, 26 insertions(+), 14 deletions(-)
>
>diff --git a/drivers/staging/kpc2000/kpc_dma/file
>-Original Message-
>From: devel On Behalf Of
>Geordan Neukum
>
>This inb() call looks like a bug. We perform a 64-bit operation when
>talking to this hardware register everywhere else in this driver. Anyone
>have more insight into the hardware with which this driver interacts
>such that t
>-Original Message-
>From: Fabio Estevam
>Hi Greg,
>
>Please discard this. It fixes arm32 build warning, but introduces
>warnings with arm64.
>
>I will think about a better fix.
The hardware/driver will only ever be used on amd64. If it can be totally
disabled for any other architectur
>This was reported by sparse:
>drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.c:39:7: warning: symbol
>'kpc_dma_add_device
>' was not declared. Should it be static?
>
>Signed-off-by: Valerio Genovese
>---
> drivers/staging/kpc2000/kpc_dma/kpc_dma_driver.h | 1 +
> 1 file changed, 1 insertion(+)
>
>
>From: devel On Behalf Of
>Greg KH
>On Fri, May 24, 2019 at 01:07:59PM +0200, Simon Sandström wrote:
>> --- a/drivers/staging/kpc2000/kpc2000/core.c
>> +++ b/drivers/staging/kpc2000/kpc2000/core.c
>> @@ -276,18 +276,18 @@ static ssize_t kp2000_cdev_read(struct file *filp,
>
>This whole function ju
>-Original Message-
>From: devel On Behalf Of Greg
>KH
>On Fri, May 24, 2019 at 01:19:26PM +0100, Jeremy Sowden wrote:
>> kp2000_check_uio_irq contained a pair of nested ifs which each evaluated
>> a bitwise operation. If both operations yielded true, the function
>> returned 1; otherwis
>-Original Message-
>From: devel On Behalf Of
>Define separate simple show functions for each attribute instead of having a
>one big one containing a chain of conditionals.
>
>+static ssize_t s2c_dma_ch_show(struct device *dev,
>+ struct device_attribute *attr,
>-Original Message-
>From: devel On Behalf Of
>Previously the next card number was assigned from a static int local variable,
>which was read and later incremented. This was not thread- safe, so now we
>use an atomic_t and atomic_fetch_add instead.
Switching to atomic_fetch_add is defini
>-Original Message-
>From: Dan Carpenter
>
>Add Staging: to the subject.
Added to my notes so I don't forget it next time.
>[PATCH v2] Staging: kpc_i2c: Remove unused file fileops.c
>
>On Thu, May 09, 2019 at 01:38:27PM +, Matt Sickler wrote:
>> The
>-Original Message-
>From: Dan Carpenter >
>On Thu, May 09, 2019 at 02:47:50PM +, Matt Sickler wrote:
>
>A few people/subsystems (DRM) put the change log in the commit message
>but that's pretty weird and I don't know if they do it on purpose or
>t
The whole file was wrapped in an #if 0. I'm guessing it was a leftover file
from when we were first developing the driver and we just forgot about it.
V2: Forgot the signed-off-by line on the first patch.
Signed-off-by: Matt Sickler
---
drivers/staging/kpc2000/kpc_i2c/Makefile
The whole file was wrapped in an #if 0. I'm guessing it was a leftover file
from when we were first developing the driver and we just forgot about it.
---
drivers/staging/kpc2000/kpc_i2c/Makefile | 2 +-
drivers/staging/kpc2000/kpc_i2c/fileops.c | 181 --
2 files ch
>-Original Message-
>From: 'gre...@linuxfoundation.org'
>On Sun, May 05, 2019 at 10:14:17PM +, Matt Sickler wrote:
>> The I2C and SPI drivers don't depend on anything other than the I2C
>> and SPI subsystems. Actually, they might be depending on
>-Original Message-
>From: 'gre...@linuxfoundation.org'
>On Fri, May 03, 2019 at 10:24:00PM +, Matt Sickler wrote:
>> Hello,
>>
>> Recently Greg KH posted the first set of drivers for our PCIe device
>(kpc2000) and shortly after that
y registers for
the DMA engines. The second one is dedicated to our IP cores.
[2] Using the new naming, and taking the p3k future into account:
DAK_DMA depends on nothing
DAK_I2C depends on I2C
DAK_SPI depends on SPI
DAK_P2K depends on PCI && DAK_DMA && DAK_I2C && DAK_SPI
DAK_P3K depends on PCI && DAK_DMA && DAK_I2C && DAK_SPI
Thanks,
Matt Sickler
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
l Message-
>From: Nicholas Mc Guire
>Sent: Saturday, April 27, 2019 4:15 AM
>To: Greg Kroah-Hartman
>Cc: Matt Sickler ; de...@driverdev.osuosl.org;
>linux-ker...@vger.kernel.org; Nicholas Mc Guire
>Subject: [PATCH RFC V2] staging: kpc2000: use int for
>wait_for_completio
Add Daktronics DMA driver. I've added the SPDX license identifiers, Kconfig
entry, and cleaned up as many of the warnings as I could.
The AIO support code will be removed in a future patch.
Signed-off-by: Matt Sickler
---
drivers/staging/kpc2000/Kconfig | 11 +
dr
>From 6e70cb81c75ebb0ac7897d07c0f12d80505bb22b Mon Sep 17 00:00:00 2001
From: Matt Sickler
Date: Mon, 22 Apr 2019 09:24:03 -0500
Subject: [PATCH] staging: kpc2000: Add DMA driver
Add Daktronics DMA driver. I've added the SPDX license identifiers, Kconfig
entry, and cleaned up as man
24 matches
Mail list logo
