Hi Jonathan,
On Saturday 21 September 2013 14:42:37 Jonathan Cameron wrote:
> The device tree list has moved, so I've changed the cc.
>
> Few comments inline. Basically I'd go for longer more
> descriptive names when the abreviation isn't a really
> well known common one.
>
> Note I'm not all tha
Hi Marek,
On Monday 23 September 2013 01:55:04 Marek Vasut wrote:
> > The following series replaces the current busy loop touchscreen
> > implementation for i.MX28/i.MX23 SoCs by a fully interrupt driven
> > implementation.
> >
> > Since i.MX23 and i.MX28 silicon differs, the existing implementati
On (09/23/13 13:24), Minchan Kim wrote:
> > On (09/16/13 09:02), Minchan Kim wrote:
> > > Hello Sergey,
> > >
> > > Sorry for really slow response. I was really busy by internal works
> > > and Thanks for pointing the BUG, Dan, Jerome and Sergey.
> > > I read your threads roughly so I may miss som
Hi,
Jürgen Beisert writes:
> Hi Marek,
>
> Seems the very first touch detection does not work. A colleague just told me,
> we have an i.MX28 based hardware here and maybe a touchscreen from a
> different
> platform which maybe can be used with the i.MX28 platform. Stay tuned...
>
> > btw. the
On Thu, Sep 19, 2013 at 04:11:57PM +0200, Dominik Paulus wrote:
> +int usbip_init_crypto(struct usbip_device *ud, unsigned char *sendkey,
> unsigned
> + char *recvkey)
> +{
> + int ret;
> +
> + ud->use_crypto = 1;
> +
> + ud->tfm_recv = crypto_alloc_aead("gcm(aes)", 0, 0);
Hi Marek,
On Monday 23 September 2013 09:55:58 Jürgen Beisert wrote:
> On Monday 23 September 2013 01:55:04 Marek Vasut wrote:
> > > The following series replaces the current busy loop touchscreen
> > > implementation for i.MX28/i.MX23 SoCs by a fully interrupt driven
> > > implementation.
> > >
>
On Thu, Sep 19, 2013 at 04:11:57PM +0200, Dominik Paulus wrote:
> +int usbip_init_crypto(struct usbip_device *ud, unsigned char *sendkey,
> unsigned
> + char *recvkey)
> +{
> + int ret;
> +
> + ud->use_crypto = 1;
> +
> + ud->tfm_recv = crypto_alloc_aead("gcm(aes)", 0, 0);
Dear Jürgen Beisert,
> Hi Marek,
>
> On Monday 23 September 2013 09:55:58 Jürgen Beisert wrote:
> > On Monday 23 September 2013 01:55:04 Marek Vasut wrote:
> > > > The following series replaces the current busy loop touchscreen
> > > > implementation for i.MX28/i.MX23 SoCs by a fully interrupt dr
On Thu, Sep 19, 2013 at 10:48:01PM +0100, Russell King wrote:
> The DMA API requires drivers to call the appropriate dma_set_mask()
> functions before doing any DMA mapping. Add this required call to
> the AMBA PL08x driver.
>
> Signed-off-by: Russell King
Acked-by: Vinod Koul
~Vinod
> ---
>
On Thu, Sep 19, 2013 at 04:11:57PM +0200, Dominik Paulus wrote:
> +/*
> + * Perform encryption/decryption on one chunk of data.
> + * Uses global crypto state stored in usbip_device.
> + * Parameters:
> + * encrypt: 1 to perform encryption, 0 to perform decryption operation
Make this a define:
#de
On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> register_platform_device_full() can setup the DMA mask provided the
> appropriate member is set in struct platform_device_info. So lets
> make that be the case. This avoids a direct reference to the DMA
> masks by this driver.
>
> S
On Sat, Sep 21, 2013 at 09:00:00PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 20, 2013 at 07:26:27PM +0200, Heiko Stübner wrote:
> > Am Donnerstag, 19. September 2013, 23:49:01 schrieb Russell King:
> > > The DMA API requires drivers to call the appropriate dma_set_mask()
> > > functions
On Mon, Sep 23, 2013 at 03:55:33PM +0530, Vinod Koul wrote:
> On Fri, Sep 20, 2013 at 12:15:39AM +0100, Russell King wrote:
> > register_platform_device_full() can setup the DMA mask provided the
> > appropriate member is set in struct platform_device_info. So lets
> > make that be the case. This
Hi Marek,
On Monday 23 September 2013 12:36:27 Marek Vasut wrote:
> > [...]
> > I also found an MX28EVK with a touchscreen here and: yes it does not work
> > with the modified driver. But now I'm confused, because of Lothar's
> > statement about the TX28 platform.
> >
> > @Lothar: What kernel revi
On Sun, Sep 22, 2013 at 12:27:34AM +0200, Peter Senna Tschudin wrote:
> diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
> index cb82233..fa37369 100644
> --- a/drivers/hv/hv_util.c
> +++ b/drivers/hv/hv_util.c
> @@ -82,7 +82,7 @@ static void shutdown_onchannelcallback(void *context)
>
Hi,
Jürgen Beisert writes:
> Hi Marek,
>
> On Monday 23 September 2013 09:55:58 Jürgen Beisert wrote:
> > On Monday 23 September 2013 01:55:04 Marek Vasut wrote:
> > > > The following series replaces the current busy loop touchscreen
> > > > implementation for i.MX28/i.MX23 SoCs by a fully interr
On 20/09/2013 00:01, Russell King :
The correct way for a driver to specify the coherent DMA mask is
not to directly access the field in the struct device, but to use
dma_set_coherent_mask(). Only arch and bus code should access this
member directly.
Convert all direct write accesses to using t
On 20/09/2013 00:02, Russell King :
Signed-off-by: Russell King
---
drivers/usb/chipidea/ci_hdrc_imx.c |4 +---
drivers/usb/dwc3/dwc3-exynos.c |4 +---
drivers/usb/host/ehci-atmel.c |4 +---
For Atmel driver:
Acked-by: Nicolas Ferre
[..]
diff --git a/drivers/usb/ho
> -Original Message-
> From: Gleb Natapov [mailto:g...@redhat.com]
> Sent: Tuesday, September 17, 2013 10:44 PM
> To: KY Srinivasan
> Cc: H. Peter Anvin; x...@kernel.org; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@cano
Hi Lothar,
On Monday 23 September 2013 14:12:02 Lothar Waßmann wrote:
> [...]
> > @Lothar: What kernel revision did you use? I had to go back to 3.9 to get
> > a
>
> Current linux-next (3.12-rc1).
Okay.
> > working kernel on the MX28EVK. More recent vanilla kernels stop working
> > (MMC and netw
On Monday 23 September 2013 15:24:37 Jürgen Beisert wrote:
> Hi Lothar,
>
> On Monday 23 September 2013 14:12:02 Lothar Waßmann wrote:
> > [...]
> >
> > > @Lothar: What kernel revision did you use? I had to go back to 3.9 to
> > > get a
> >
> > Current linux-next (3.12-rc1).
>
> Okay.
>
> > > work
Hi,
Jürgen Beisert writes:
> The i.MX28 manual says the LRADC delay unit is driven by a 2 kHz clock, but
> does not say what kind of clock it is (or is derived from). I guess now, this
> clock isn't enabled and thus the delay unit can't work. At least on the
> MX28EVK. On your TX28 platform the
From: Wei Yongjun
usb_free_urb(NULL) is safe and this check is not required.
Signed-off-by: Wei Yongjun
---
drivers/staging/rtl8188eu/os_dep/recv_linux.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/rtl8188eu/os_dep/recv_linux.c
b/drivers/staging/rtl81
Hi Lothar,
On Monday 23 September 2013 15:40:18 Lothar Waßmann wrote:
> Jürgen Beisert writes:
> > The i.MX28 manual says the LRADC delay unit is driven by a 2 kHz clock,
> > but does not say what kind of clock it is (or is derived from). I guess
> > now, this clock isn't enabled and thus the dela
In order to support i.MX23 and i.MX28 within one driver we need to separate the
register definitions which differ in both SoC variants.
Signed-off-by: Juergen Beisert
CC: linux-arm-ker...@lists.infradead.org
CC: linux-in...@vger.kernel.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut
CC: Fabio
The LRADC units in i.MX23 and i.MX28 differ and we need to distinguish both
SoC variants in order to make the touchscreen work on i.MX23
Signed-off-by: Juergen Beisert
CC: linux-arm-ker...@lists.infradead.org
CC: linux-in...@vger.kernel.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut
CC: Fabi
Some things have still to be done to the LRADC driver.
Signed-off-by: Juergen Beisert
CC: linux-arm-ker...@lists.infradead.org
CC: linux-in...@vger.kernel.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut
CC: Fabio Estevam
CC: Jonathan Cameron
---
drivers/staging/iio/TODO | 11 +++
1
The following series replaces the current busy loop touchscreen implementation
for i.MX28/i.MX23 SoCs by a fully interrupt driven implementation.
Since i.MX23 and i.MX28 silicon differs, the existing implementation can
be used for the i.MX28 SoC only.
The first patch adds proper clock handling. V
Signed-off-by: Juergen Beisert
CC: linux-arm-ker...@lists.infradead.org
CC: linux-in...@vger.kernel.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut
CC: Fabio Estevam
CC: Jonathan Cameron
---
drivers/staging/iio/adc/mxs-lradc.c | 163
1 file changed, 163
For battery driven systems it is a very bad idea to collect the touchscreen
data within a kernel busy loop.
This change uses the features of the hardware to delay and accumulate samples in
hardware to avoid a high interrupt and CPU load.
Note: this is only tested on an i.MX23 SoC yet.
Signed-off
Distinguish i.MX23 and i.MX28 at runtime and do the same for both SoC at least
for the 4 wire touchscreen.
Note: support for the remaining LRADC channels is not tested on an
i.MX23 yet.
Signed-off-by: Juergen Beisert
CC: linux-arm-ker...@lists.infradead.org
CC: linux-in...@vger.kernel.org
CC: de
This is an RFC for the new touchscreen properties.
Signed-off-by: Juergen Beisert
CC: linux-arm-ker...@lists.infradead.org
CC: linux-in...@vger.kernel.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut
CC: Fabio Estevam
CC: Jonathan Cameron
CC: devicet...@vger.kernel.org
---
.../bindings/stag
The delay units inside the LRADC depend on the presence of a 2 kHz clock.
This change enables the clock to be able to use the delay unit for the
touchscreen part of the driver.
Signed-off-by: Juergen Beisert
---
arch/arm/boot/dts/imx23.dtsi| 1 +
arch/arm/boot/dts/imx28.dtsi| 1 +
Replace the individual register access by a few shared access function to make
the
code easier to read and in order to add the i.MX23 SoC in the next step.
Signed-off-by: Juergen Beisert
CC: linux-arm-ker...@lists.infradead.org
CC: linux-in...@vger.kernel.org
CC: de...@driverdev.osuosl.org
CC: M
On 09/23/2013 11:36 AM, Juergen Beisert wrote:
+ lradc->clk = devm_clk_get(&pdev->dev, NULL);
+ clk_prepare_enable(lradc->clk);
clk_prepare_enable() may fail, so better check its return value.
___
devel mailing list
de...@linuxdriverproj
On Sat, Sep 21, 2013 at 08:55:31PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 20, 2013 at 04:42:08PM +0100, Ben Hutchings wrote:
> > On Thu, 2013-09-19 at 22:43 +0100, Russell King wrote:
> > > + if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)) ||
> > > + dma_set_mask_and_c
Dear Juergen Beisert,
> The following series replaces the current busy loop touchscreen
> implementation for i.MX28/i.MX23 SoCs by a fully interrupt driven
> implementation.
>
> Since i.MX23 and i.MX28 silicon differs, the existing implementation can
> be used for the i.MX28 SoC only.
>
> The fi
On 09/23/2013 06:02 AM, KY Srinivasan wrote:
>
> Peter,
> Please let me know if there are other issues I need to address here. Now that
> Dmitry has queued up the
> Hyper-V keyboard driver, with this patch we can fully support Linux on our
> uefi firmware.
>
I just got back from Plumber's -- t
On 2013-09-21 00:33, H Hartley Sweeten wrote:
Tidy up this driver a bit.
Unfortunately not a great reduction in the lines of code but it did
uncover a couple bugs in the 8112 board and async command support.
The async command support still needs to be looked over.
1) The analog input sample
The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:
Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/
tags/staging-3.12-rc2
for you to fetch changes up to 61740810136
On Thu, 19 Sep 2013, Russell King wrote:
> The correct way for a driver to specify the coherent DMA mask is
> not to directly access the field in the struct device, but to use
> dma_set_coherent_mask(). Only arch and bus code should access this
> member directly.
>
> Convert all direct write acc
On Mon, Sep 23, 2013 at 02:27:39PM -0400, Alan Stern wrote:
> On Thu, 19 Sep 2013, Russell King wrote:
>
> > The correct way for a driver to specify the coherent DMA mask is
> > not to directly access the field in the struct device, but to use
> > dma_set_coherent_mask(). Only arch and bus code s
On Monday, September 23, 2013 9:23 AM, Ian Abbott wrote:
> On 2013-09-21 00:33, H Hartley Sweeten wrote:
>> Tidy up this driver a bit.
>>
>> Unfortunately not a great reduction in the lines of code but it did
>> uncover a couple bugs in the 8112 board and async command support.
>>
>> The async comm
Hi,
Juergen Beisert writes:
> diff --git a/drivers/staging/iio/adc/mxs-lradc.c
> b/drivers/staging/iio/adc/mxs-lradc.c
> index a08c173..00b61ac 100644
> --- a/drivers/staging/iio/adc/mxs-lradc.c
> +++ b/drivers/staging/iio/adc/mxs-lradc.c
> @@ -35,6 +35,7 @@
> #include
> #include
> #include
> -Original Message-
> From: H. Peter Anvin [mailto:h...@zytor.com]
> Sent: Monday, September 23, 2013 8:50 AM
> To: KY Srinivasan
> Cc: Gleb Natapov; x...@kernel.org; gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de;
> a...@canonic
This patch adds the staging/dgnc [DIGI NEO AND CLASSIC
PCI PRODUCTS] and staging/dgap [DIGI EPCA PCI PRODUCTS]
drivers to the MAINTAINERS file. I am listed as the
maintainer and the driverdev-devel list is the mailing
list for these drivers.
Signed-off-by: Lidza Louina
---
MAINTAINERS | 12 +
On Mon, Sep 23, 2013 at 04:13:15PM -0400, Lidza Louina wrote:
> This patch adds the staging/dgnc [DIGI NEO AND CLASSIC
> PCI PRODUCTS] and staging/dgap [DIGI EPCA PCI PRODUCTS]
> drivers to the MAINTAINERS file. I am listed as the
> maintainer and the driverdev-devel list is the mailing
> list for
On Mon, Sep 23, 2013 at 4:16 PM, Greg KH wrote:
> On Mon, Sep 23, 2013 at 04:13:15PM -0400, Lidza Louina wrote:
>> This patch adds the staging/dgnc [DIGI NEO AND CLASSIC
>> PCI PRODUCTS] and staging/dgap [DIGI EPCA PCI PRODUCTS]
>> drivers to the MAINTAINERS file. I am listed as the
>> maintainer
On Mon, Sep 23, 2013 at 04:22:10PM -0400, Lidza Louina wrote:
> On Mon, Sep 23, 2013 at 4:16 PM, Greg KH wrote:
> > On Mon, Sep 23, 2013 at 04:13:15PM -0400, Lidza Louina wrote:
> >> This patch adds the staging/dgnc [DIGI NEO AND CLASSIC
> >> PCI PRODUCTS] and staging/dgap [DIGI EPCA PCI PRODUCTS]
On Monday, September 23, 2013 11:08:12 PM Olaf Hering wrote:
> On Wed, Sep 18, Dmitry Torokhov wrote:
> > This looks much better. Could you tell me if the patch below (on top of
> > yours) still works?
>
> The help text is slightly incorrect, its a dash not underscore:
> drivers/input/serio/hyperv
On Wed, Sep 18, Dmitry Torokhov wrote:
> This looks much better. Could you tell me if the patch below (on top of
> yours) still works?
The help text is slightly incorrect, its a dash not underscore:
drivers/input/serio/hyperv-keyboard.ko
Olaf
___
devel
On Mon, Sep 23, 2013 at 04:22:10PM -0400, Lidza Louina wrote:
> Awesome, thanks.
>
> Btw, are will still in the merge window? Do you need me to send out
> fixes for warnings (sparse or smatch) or can I send things like TODO
> updates or checkpatch fixes?
The merge window ends when -rc1 is release
This patch removes these smatch warnings:
redundant null check on dgap_TmpWriteBuf calling kfree()
redundant null check on brd->SerialDriver->ttys calling kfree()
redundant null check on brd->PrintDriver->ttys calling kfree()
The code checked to see if these variables are null
before freeing. This
This patch removes this smatch warning:
warn: missing break? reassigning 'ch->pscan_state'
Signed-off-by: Lidza Louina
---
drivers/staging/dgap/dgap_fep5.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/dgap/dgap_fep5.c b/drivers/staging/dgap/dgap_fe
This patch removes these smatch warnings from dgap_driver.c:
redundant null check on dgap_config_buf calling kfree()
redundant null check on brd->flipbuf calling kfree()
redundant null check on brd->flipflagbuf calling kfree()
Signed-off-by: Lidza Louina
---
drivers/staging/dgap/dgap_driver.c |
This patch removes this smatch warning:
info: ignoring unreachable code.
There were instances where there was extra code after
the default action in switch statements. These default
actions ended with a break so the code wasn't being run
at anytime. This patch removes that extra code.
Signed-off-
This patch removes this smatch warning:
unsigned '--un->un_open_count' is never less than zero
The code decremented the un_open_count variable
and tested to see if it was less than zero. Because
un_open_count is unsigned and can't be below zero,
this test doesn't work. This patch tests
un_open_cou
This patch removes these warnings:
potential null dereference 'brd->SerialDriver'. (alloc_tty_driver returns null)
potential null dereference 'brd->PrintDriver'. (alloc_tty_driver returns null)
This warning popped up because there wasn't a check
to make sure that the serial and print drivers were
On Mon, Sep 23, 2013 at 6:16 PM, Dan Carpenter wrote:
> On Mon, Sep 23, 2013 at 04:22:10PM -0400, Lidza Louina wrote:
>> Awesome, thanks.
>>
>> Btw, are will still in the merge window? Do you need me to send out
>> fixes for warnings (sparse or smatch) or can I send things like TODO
>> updates or
On Mon, Sep 23, 2013 at 06:47:17PM -0400, Lidza Louina wrote:
> This patch removes this smatch warning:
> unsigned '--un->un_open_count' is never less than zero
>
> The code decremented the un_open_count variable
> and tested to see if it was less than zero. Because
> un_open_count is unsigned and
On Mon, Sep 23, 2013 at 06:47:13PM -0400, Lidza Louina wrote:
> This patch removes this smatch warning:
> warn: missing break? reassigning 'ch->pscan_state'
I would just leave this one as is.
With Smatch, I don't put a lot of effort into cutting down false
positives. Eventually I do plan to pars
On Tue, Sep 24, 2013 at 03:06:06AM +0300, Dan Carpenter wrote:
> On Mon, Sep 23, 2013 at 06:47:13PM -0400, Lidza Louina wrote:
> > This patch removes this smatch warning:
> > warn: missing break? reassigning 'ch->pscan_state'
>
> I would just leave this one as is.
>
Yes. Actually, the fix isn't
On Mon, Sep 23, 2013 at 06:47:16PM -0400, Lidza Louina wrote:
> This patch removes these warnings:
> potential null dereference 'brd->SerialDriver'. (alloc_tty_driver returns
> null)
> potential null dereference 'brd->PrintDriver'. (alloc_tty_driver returns null)
>
> This warning popped up becaus
63 matches
Mail list logo
