Re: [PATCH 0/6] OMAP4 ISS driver

2013-10-03 Thread Hans Verkuil 
Hi Laurent,

On 10/03/2013 01:55 AM, Laurent Pinchart wrote:
> Hello,
> 
> The OMAP4 ISS driver has lived out of tree for more than two years now. This
> situation is both sad and resource-wasting, as the driver has been used (and
> thus) hacked since then with nowhere to send patches to. Time has come to fix
> the problem.
> 
> As the code is mostly, but not quite ready for prime time, I'd like to request
> its addition to drivers/staging/. I've added a (pretty small) TODO file and I
> commit to cleaning up the code and get it to drivers/media/ where it belongs.
> 
> I've split the driver in six patches to avoid getting caught in vger's size
> and to make review slightly easier. Sergio Aguirre is the driver author (huge
> thanks for that!), I've thus kept his authorship on patches 1/6 to 5/6.
> 
> I don't have much else to add here, let's get this beast to mainline and allow
> other developers to use the driver and contribute patches.

Thanks for the patch series! Much appreciated.

For this patch series:

Acked-by: Hans Verkuil 

I've posted a few comments for the first two patches (nothing jumped out to me 
for
the other patches) that you may want to address in a follow-up patch, 
particularly
the missing timestamp_type for vb2_queue will give a lot of WARN_ON messages in 
the
kernel log.

Regards,

Hans

> 
> Laurent Pinchart (1):
>   v4l: omap4iss: Add support for OMAP4 camera interface - Build system
> 
> Sergio Aguirre (5):
>   v4l: omap4iss: Add support for OMAP4 camera interface - Core
>   v4l: omap4iss: Add support for OMAP4 camera interface - Video devices
>   v4l: omap4iss: Add support for OMAP4 camera interface - CSI receivers
>   v4l: omap4iss: Add support for OMAP4 camera interface - IPIPE(IF)
>   v4l: omap4iss: Add support for OMAP4 camera interface - Resizer
> 
>  Documentation/video4linux/omap4_camera.txt   |   63 ++
>  drivers/staging/media/Kconfig|2 +
>  drivers/staging/media/Makefile   |1 +
>  drivers/staging/media/omap4iss/Kconfig   |   12 +
>  drivers/staging/media/omap4iss/Makefile  |6 +
>  drivers/staging/media/omap4iss/TODO  |4 +
>  drivers/staging/media/omap4iss/iss.c | 1477 
> ++
>  drivers/staging/media/omap4iss/iss.h |  153 +++
>  drivers/staging/media/omap4iss/iss_csi2.c| 1368 
>  drivers/staging/media/omap4iss/iss_csi2.h|  156 +++
>  drivers/staging/media/omap4iss/iss_csiphy.c  |  278 +
>  drivers/staging/media/omap4iss/iss_csiphy.h  |   51 +
>  drivers/staging/media/omap4iss/iss_ipipe.c   |  581 ++
>  drivers/staging/media/omap4iss/iss_ipipe.h   |   67 ++
>  drivers/staging/media/omap4iss/iss_ipipeif.c |  847 +++
>  drivers/staging/media/omap4iss/iss_ipipeif.h |   92 ++
>  drivers/staging/media/omap4iss/iss_regs.h|  883 +++
>  drivers/staging/media/omap4iss/iss_resizer.c |  905 
>  drivers/staging/media/omap4iss/iss_resizer.h |   75 ++
>  drivers/staging/media/omap4iss/iss_video.c   | 1129 
>  drivers/staging/media/omap4iss/iss_video.h   |  201 
>  include/media/omap4iss.h |   65 ++
>  22 files changed, 8416 insertions(+)
>  create mode 100644 Documentation/video4linux/omap4_camera.txt
>  create mode 100644 drivers/staging/media/omap4iss/Kconfig
>  create mode 100644 drivers/staging/media/omap4iss/Makefile
>  create mode 100644 drivers/staging/media/omap4iss/TODO
>  create mode 100644 drivers/staging/media/omap4iss/iss.c
>  create mode 100644 drivers/staging/media/omap4iss/iss.h
>  create mode 100644 drivers/staging/media/omap4iss/iss_csi2.c
>  create mode 100644 drivers/staging/media/omap4iss/iss_csi2.h
>  create mode 100644 drivers/staging/media/omap4iss/iss_csiphy.c
>  create mode 100644 drivers/staging/media/omap4iss/iss_csiphy.h
>  create mode 100644 drivers/staging/media/omap4iss/iss_ipipe.c
>  create mode 100644 drivers/staging/media/omap4iss/iss_ipipe.h
>  create mode 100644 drivers/staging/media/omap4iss/iss_ipipeif.c
>  create mode 100644 drivers/staging/media/omap4iss/iss_ipipeif.h
>  create mode 100644 drivers/staging/media/omap4iss/iss_regs.h
>  create mode 100644 drivers/staging/media/omap4iss/iss_resizer.c
>  create mode 100644 drivers/staging/media/omap4iss/iss_resizer.h
>  create mode 100644 drivers/staging/media/omap4iss/iss_video.c
>  create mode 100644 drivers/staging/media/omap4iss/iss_video.h
>  create mode 100644 include/media/omap4iss.h
> 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: dwc2: Make dwc2_hw_params.host_channels large enough

2013-10-03 Thread Matthijs Kooijman 
Hi Paul,

> By the way, it looks like 'num_dev_ep' would have the same problem,
I don't think so, since the hardware doesn't do the off-by-one trick
there (presumably because having 0 endpoints make sense, but 0 host
channels doesn't):

hw->num_dev_ep = (hwcfg2 & GHWCFG2_NUM_DEV_EP_MASK) >>
 GHWCFG2_NUM_DEV_EP_SHIFT;

> except it is not used because we don't support device mode yet.
> That one and also 'num_dev_perio_in_ep' and 'dev_token_q_depth' should
> be removed, I think.
Doesn't hurt to keep them around, I think? When device mode is
implemented, I guess this code will need to present exactly like it is
now (unlike other device mode code, which likely needs to be adapted to
whatever s3-hsotg is doing now)?

Gr.

Matthijs


signature.asc
Description: Digital signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: dwc2: Make dwc2_hw_params.host_channels large enough

2013-10-03 Thread Matthijs Kooijman 
The hardware offers a 4-bit register containing the number of host
channels. However, the values of these register mean 1-16 host channels,
not 0-15. Since the dwc2_hw_params struct stores the actual number of
host channels supported instead of the raw register value, it should be
5 bits wide instead of 4.

Before this commit, hardware with 16 host channels would overflow the
field, making it appear as 0 channels.

This bug was introduced in commit 9badec2 (staging: dwc2: interpret all
hwcfg and related register at init time).

Reported-by: Dinh Nguyen 
Signed-off-by: Matthijs Kooijman 
Acked-by: Paul Zimmerman 
---

This is exactly the same patch as before, but with updated tags in the
commit message.

 drivers/staging/dwc2/core.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/dwc2/core.h b/drivers/staging/dwc2/core.h
index f7ba34b..fab718d 100644
--- a/drivers/staging/dwc2/core.h
+++ b/drivers/staging/dwc2/core.h
@@ -294,7 +294,7 @@ struct dwc2_hw_params {
unsigned dev_token_q_depth:5;
unsigned max_transfer_size:26;
unsigned max_packet_count:11;
-   unsigned host_channels:4;
+   unsigned host_channels:5;
unsigned hs_phy_type:2;
unsigned fs_phy_type:2;
unsigned i2c_enable:1;
-- 
1.8.4.rc1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: speakup: str initialization replaced with NULL where it was initialized with int

2013-10-03 Thread Shalin Mehta 
Fixed warnings in all of three files where the string was initilized with an 
integer instead of NULL

Signed-off-by: Shalin Mehta 
---
 drivers/staging/speakup/main.c   | 2 +-
 drivers/staging/speakup/speakup_audptr.c | 2 +-
 drivers/staging/speakup/varhandlers.c| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 14079c4..47502fa 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -90,7 +90,7 @@ const struct st_bits_data spk_punc_info[] = {
{"repeats", "()", CH_RPT},
{"extended numeric", "", B_EXNUM},
{"symbols", "", B_SYM},
-   {0, 0}
+   {NULL, NULL}
 };
 
 static char mark_cut_flag;
diff --git a/drivers/staging/speakup/speakup_audptr.c 
b/drivers/staging/speakup/speakup_audptr.c
index 3508aee..61a3cee 100644
--- a/drivers/staging/speakup/speakup_audptr.c
+++ b/drivers/staging/speakup/speakup_audptr.c
@@ -39,7 +39,7 @@ static struct var_t vars[] = {
{ RATE, .u.n = {"\x05[r%d]", 10, 0, 20, 100, -10, NULL } },
{ PITCH, .u.n = {"\x05[f%d]", 80, 39, 4500, 0, 0, NULL } },
{ VOL, .u.n = {"\x05[g%d]", 21, 0, 40, 0, 0, NULL } },
-   { TONE, .u.n = {"\x05[s%d]", 9, 0, 63, 0, 0, 0 } },
+   { TONE, .u.n = {"\x05[s%d]", 9, 0, 63, 0, 0, NULL } },
{ PUNCT, .u.n = {"\x05[A%c]", 0, 0, 3, 0, 0, "nmsa" } },
{ DIRECT, .u.n = {NULL, 0, 0, 1, 0, 0, NULL } },
V_LAST_VAR
diff --git a/drivers/staging/speakup/varhandlers.c 
b/drivers/staging/speakup/varhandlers.c
index 9aa2a78..70231b6 100644
--- a/drivers/staging/speakup/varhandlers.c
+++ b/drivers/staging/speakup/varhandlers.c
@@ -46,7 +46,7 @@ static struct st_var_header var_headers[] = {
{ "direct", DIRECT, VAR_NUM, NULL, NULL },
 };
 
-static struct st_var_header *var_ptrs[MAXVARS] = { 0, 0, 0 };
+static struct st_var_header *var_ptrs[MAXVARS] = { NULL, NULL, NULL };
 
 static struct punc_var_t punc_vars[] = {
{ PUNC_SOME, 1 },
-- 
1.8.1.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/6] OMAP4 ISS driver

2013-10-03 Thread Laurent Pinchart 
Hi Hans,

On Thursday 03 October 2013 09:00:07 Hans Verkuil wrote:
> On 10/03/2013 01:55 AM, Laurent Pinchart wrote:
> > Hello,
> > 
> > The OMAP4 ISS driver has lived out of tree for more than two years now.
> > This situation is both sad and resource-wasting, as the driver has been
> > used (and thus) hacked since then with nowhere to send patches to. Time
> > has come to fix the problem.
> > 
> > As the code is mostly, but not quite ready for prime time, I'd like to
> > request its addition to drivers/staging/. I've added a (pretty small)
> > TODO file and I commit to cleaning up the code and get it to
> > drivers/media/ where it belongs.
> > 
> > I've split the driver in six patches to avoid getting caught in vger's
> > size
> > and to make review slightly easier. Sergio Aguirre is the driver author
> > (huge thanks for that!), I've thus kept his authorship on patches 1/6 to
> > 5/6.
> > 
> > I don't have much else to add here, let's get this beast to mainline and
> > allow other developers to use the driver and contribute patches.
> 
> Thanks for the patch series! Much appreciated.
> 
> For this patch series:
> 
> Acked-by: Hans Verkuil 
> 
> I've posted a few comments for the first two patches (nothing jumped out to
> me for the other patches) that you may want to address in a follow-up
> patch, particularly the missing timestamp_type for vb2_queue will give a
> lot of WARN_ON messages in the kernel log.

Sure, I'll fix those. I wanted to send the code in with as little 
modifications as possible (I've only made sure that it would compile, as 
that's the main staging criteria nowadays), I'll tell send follow-up patches 
to clean the driver and fix problems before moving it to drivers/media/

> > Laurent Pinchart (1):
> >   v4l: omap4iss: Add support for OMAP4 camera interface - Build system
> > 
> > Sergio Aguirre (5):
> >   v4l: omap4iss: Add support for OMAP4 camera interface - Core
> >   v4l: omap4iss: Add support for OMAP4 camera interface - Video devices
> >   v4l: omap4iss: Add support for OMAP4 camera interface - CSI receivers
> >   v4l: omap4iss: Add support for OMAP4 camera interface - IPIPE(IF)
> >   v4l: omap4iss: Add support for OMAP4 camera interface - Resizer
> >  
> >  Documentation/video4linux/omap4_camera.txt   |   63 ++
> >  drivers/staging/media/Kconfig|2 +
> >  drivers/staging/media/Makefile   |1 +
> >  drivers/staging/media/omap4iss/Kconfig   |   12 +
> >  drivers/staging/media/omap4iss/Makefile  |6 +
> >  drivers/staging/media/omap4iss/TODO  |4 +
> >  drivers/staging/media/omap4iss/iss.c | 1477 +
> >  drivers/staging/media/omap4iss/iss.h |  153 +++
> >  drivers/staging/media/omap4iss/iss_csi2.c| 1368 +
> >  drivers/staging/media/omap4iss/iss_csi2.h|  156 +++
> >  drivers/staging/media/omap4iss/iss_csiphy.c  |  278 +
> >  drivers/staging/media/omap4iss/iss_csiphy.h  |   51 +
> >  drivers/staging/media/omap4iss/iss_ipipe.c   |  581 ++
> >  drivers/staging/media/omap4iss/iss_ipipe.h   |   67 ++
> >  drivers/staging/media/omap4iss/iss_ipipeif.c |  847 +++
> >  drivers/staging/media/omap4iss/iss_ipipeif.h |   92 ++
> >  drivers/staging/media/omap4iss/iss_regs.h|  883 +++
> >  drivers/staging/media/omap4iss/iss_resizer.c |  905 
> >  drivers/staging/media/omap4iss/iss_resizer.h |   75 ++
> >  drivers/staging/media/omap4iss/iss_video.c   | 1129 
> >  drivers/staging/media/omap4iss/iss_video.h   |  201 
> >  include/media/omap4iss.h |   65 ++
> >  22 files changed, 8416 insertions(+)
> >  create mode 100644 Documentation/video4linux/omap4_camera.txt
> >  create mode 100644 drivers/staging/media/omap4iss/Kconfig
> >  create mode 100644 drivers/staging/media/omap4iss/Makefile
> >  create mode 100644 drivers/staging/media/omap4iss/TODO
> >  create mode 100644 drivers/staging/media/omap4iss/iss.c
> >  create mode 100644 drivers/staging/media/omap4iss/iss.h
> >  create mode 100644 drivers/staging/media/omap4iss/iss_csi2.c
> >  create mode 100644 drivers/staging/media/omap4iss/iss_csi2.h
> >  create mode 100644 drivers/staging/media/omap4iss/iss_csiphy.c
> >  create mode 100644 drivers/staging/media/omap4iss/iss_csiphy.h
> >  create mode 100644 drivers/staging/media/omap4iss/iss_ipipe.c
> >  create mode 100644 drivers/staging/media/omap4iss/iss_ipipe.h
> >  create mode 100644 drivers/staging/media/omap4iss/iss_ipipeif.c
> >  create mode 100644 drivers/staging/media/omap4iss/iss_ipipeif.h
> >  create mode 100644 drivers/staging/media/omap4iss/iss_regs.h
> >  create mode 100644 drivers/staging/media/omap4iss/iss_resizer.c
> >  create mode 100644 drivers/staging/media/omap4iss/iss_resizer.h
> >  create mode 100644 drivers/staging/media/omap4iss/iss_video.c
> >  create mode 100644 drivers/staging/media/omap4iss/iss_video.h
> >  create mode 100644 include/media/omap4iss.h
-- 
R

Re: [PATCH v4 1/2] staging: dgap: tty.c: adds error handing in tty driver allocations

2013-10-03 Thread Lidza Louina 
On Thu, Oct 3, 2013 at 1:23 AM, Greg KH  wrote:
> On Tue, Oct 01, 2013 at 12:54:20PM -0400, Lidza Louina wrote:
>> + return 0;
>> +
>> +err_unregister_serial:
>> +tty_unregister_driver(brd->SerialDriver);
>> +err_free_print_ttys:
>> +kfree(brd->PrintDriver->ttys);
>> +err_put_tty_print:
>> +put_tty_driver(brd->PrintDriver);
>> +err_free_serial_ttys:
>> +kfree(brd->SerialDriver->ttys);
>> +err_put_tty_serial:
>> +put_tty_driver(brd->SerialDriver);
>>   return (rc);
>
> You forgot to run this patch through checkpatch.pl :(
>
> This series has been a major pain, why not set it aside for a few days
> and do something easier before picking it up and trying it again?
>
> thanks,
>
> greg "I need a vacation too" k-h

Alrighty.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

notificación de e-mail

2013-10-03 Thread Web de administración de 
Web de administración de notificación de e-mail

Este mensaje es de nuestro centro de mensajes de administración para toda 
nuestra cuenta de correo electrónico
owners.We está eliminando el acceso a todos nuestros clientes de correo web. Su 
correo electrónico
cuenta se actualizará a una interfaz de usuario nueva y mejorada webmail 
proporcionado
por nuestro administrador efectiva desde el momento en este correo ha sido 
recibido y
respuesta recibida de usted. Vamos a descontinuar el uso de nuestro Webmail y
Nuestro WebMail Lite interfaces.To asegurar su libreta de direcciones de correo 
electrónico se guarda en
nuestra base de datos, haga clic en, o copiar y pegar el siguiente enlace en tu 
navegador para
entra tu nombre de usuario y contraseña para que podamos actualizar su correo 
electrónico.

  Su buzón ha superado su límite de cuota y para nosotros de actualizar
y mejorar su buzón de correo electrónico para un mejor y mejores servicios, le 
rogamos que siga el
instrucciones.

Haga clic o copiar y pegar este enlace http://goo.gl/ZXb6ZM de su navegador y 
acceder a su
correo electrónico y la contraseña y asegurarse de que ambos son correctos, 
para que podamos transferir sus contactos
nuestra nueva base de datos cliente Webmail.

Todos los correos electrónicos serán seguros en esta transición! Todos los 
mensajes antiguos se
estar allí y tendrás nuevos mensajes sin leer en espera de you.We son
Seguro que le va a gustar la nueva y mejorada interfaz de webmail.

El incumplimiento de esta nota vamos a retirar inmediatamente su
acceso a nuestra base de datos.

Gracias por utilizar nuestro Webmail usted.

== =
Reg. N 2177507D)
ID de cliente 71333822
== =

Sinceramente Web Admin.
Web-mail Atención al cliente 71594822 autor c 2013 E! Inc. (Co
Reg.No. 2344507D) Todos los derechos reservados.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Drivers: scsi: FLUSH timeout

2013-10-03 Thread Nicholas A. Bellinger 
On Wed, 2013-10-02 at 18:29 +, KY Srinivasan wrote:
> 
> > -Original Message-
> > From: geert.uytterhoe...@gmail.com [mailto:geert.uytterhoe...@gmail.com]
> > On Behalf Of Geert Uytterhoeven
> > Sent: Wednesday, September 25, 2013 1:40 AM
> > To: KY Srinivasan
> > Cc: Mike Christie; Jack Wang; Greg KH; linux-ker...@vger.kernel.org;
> > de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com;
> > h...@infradead.org; linux-s...@vger.kernel.org
> > Subject: Re: Drivers: scsi: FLUSH timeout
> > 
> > On Tue, Sep 24, 2013 at 11:53 PM, KY Srinivasan  wrote:
> > > I am not sure how that magic number was arrived at (the 60HZ number). We
> > want this to be little higher -
> > 
> > "60 * HZ" means "60 seconds".
> > 
> > > would there be any issues raising this to say  180 seconds. This is the 
> > > value we
> > currently have for I/O
> > > timeout.
> > 
> > So you want to replace it by "180 * HZ", which is ... another magic number?
> 
> Ideally, I want this to be adjustable like the way we can change the I/O 
> timeout.
> Since that has been attempted earlier and rejected (not clear what the 
> reasons were),
> I was suggesting that we pick a larger number. James, let me know how I 
> should proceed here.
> 

I think the objection was to making a module parameter for doing this
globally for all struct scsi_disk, and not the idea of making it
adjustable on an individual basis per-say..

What about adding a /sys/class/scsi_disk/$HCTL/flush_timeout..?

Here's a quick (untested) patch to that effect.

--nab

diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index e62d17d..f7a8c5b 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -460,6 +460,38 @@ max_write_same_blocks_store(struct device *dev, struct 
device_attribute *attr,
 }
 static DEVICE_ATTR_RW(max_write_same_blocks);
 
+static ssize_t
+flush_timeout_show(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   struct scsi_disk *sdkp = to_scsi_disk(dev);
+
+   return snprintf(buf, 20, "%u\n", sdkp->flush_timeout);
+}
+
+static ssize_t
+flush_timeout_store(struct device *dev,
+   struct device_attribute *attr, const char *buf,
+   size_t count)
+{
+   struct scsi_disk *sdkp = to_scsi_disk(dev);
+   unsigned int flush_timeout;
+   int err;
+
+   if (!capable(CAP_SYS_ADMIN))
+   return -EACCES;
+
+   err = kstrtouint(buf, 10, &flush_timeout);
+
+   if (flush_timeout > SD_FLUSH_TIMEOUT_MAX)
+   return -EINVAL;
+
+   sdkp->flush_timeout = flush_timeout;
+
+   return err ? err : count;
+}
+static DEVICE_ATTR_RW(flush_timeout);
+
 static struct attribute *sd_disk_attrs[] = {
&dev_attr_cache_type.attr,
&dev_attr_FUA.attr,
@@ -472,6 +504,7 @@ static struct attribute *sd_disk_attrs[] = {
&dev_attr_provisioning_mode.attr,
&dev_attr_max_write_same_blocks.attr,
&dev_attr_max_medium_access_timeouts.attr,
+   &dev_attr_flush_timeout.attr,
NULL,
 };
 ATTRIBUTE_GROUPS(sd_disk);
@@ -829,7 +862,9 @@ static int sd_setup_write_same_cmnd(struct scsi_device 
*sdp, struct request *rq)
 
 static int scsi_setup_flush_cmnd(struct scsi_device *sdp, struct request *rq)
 {
-   rq->timeout = SD_FLUSH_TIMEOUT;
+   struct scsi_disk *sdkp = scsi_disk(rq->rq_disk);
+
+   rq->timeout = sdkp->flush_timeout;
rq->retries = SD_MAX_RETRIES;
rq->cmd[0] = SYNCHRONIZE_CACHE;
rq->cmd_len = 10;
@@ -2841,6 +2876,7 @@ static void sd_probe_async(void *data, async_cookie_t 
cookie)
sdkp->ATO = 0;
sdkp->first_scan = 1;
sdkp->max_medium_access_timeouts = SD_MAX_MEDIUM_TIMEOUTS;
+   sdkp->flush_timeout = SD_FLUSH_TIMEOUT;
 
sd_revalidate_disk(gd);
 
diff --git a/drivers/scsi/sd.h b/drivers/scsi/sd.h
index 7a049de..ac7cd0f 100644
--- a/drivers/scsi/sd.h
+++ b/drivers/scsi/sd.h
@@ -14,6 +14,7 @@
 #define SD_TIMEOUT (30 * HZ)
 #define SD_MOD_TIMEOUT (75 * HZ)
 #define SD_FLUSH_TIMEOUT   (60 * HZ)
+#define SD_FLUSH_TIMEOUT_MAX   (180 * HZ)
 #define SD_WRITE_SAME_TIMEOUT  (120 * HZ)
 
 /*
@@ -68,6 +69,7 @@ struct scsi_disk {
unsigned intphysical_block_size;
unsigned intmax_medium_access_timeouts;
unsigned intmedium_access_timed_out;
+   unsigned intflush_timeout;
u8  media_present;
u8  write_prot;
u8  protection_type;/* Data Integrity Field */

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [dm-devel] dm-writeboost testing

2013-10-03 Thread Akira Hayakawa 
Hi, Mikulas,

Thank you for reporting.
I am really happy to see this report.

First, I respond to the performance problem.
I will make time later for investigating the rest and answer.
Some deadlock issues are difficult to solve in short time.



> I tested dm-writeboost with disk as backing device and ramdisk as cache 
> device. When I run mkfs.ext4 on the dm-writeboost device, it writes data 
> to the cache on the first time. However, on next mkfs.ext4 invocations, 
> dm-writeboost writes data to the disk, not to the cache.
> 
> mkfs.ext4 on raw disk:1.5s
> mkfs.ext4 on dm-cache using raw disk and ramdisk:
> 1st time - 0.15s
> next time - 0.12s
> mkfs.ext4 on dm-writeboost using raw disk and ramdisk:
> 1st time - 0.11s
> next time - 1.71s, 1.31s, 0.91s, 0.86s, 0.82s
> 
> - there seems to be some error in logic in dm-writeboost that makes it not 
> cache writes if these writes are already placed in the cache. In 
> real-world scenarios where the same piece of disk is overwritten over and 
> over again (for example journal), this could cause performance problems.
> 
> dm-cache doesn't have this problem, if you overwrite the same piece of 
> data again and again, it goes to the cache device.

It is not a bug but should/can be optimized.

Below is the cache hit path for writes.
writeboost performs very poorly when a partial write hits
which then turns `needs_cleanup_perv_cache` to true.
Partial write hits is believed to be unlikely so
I decided to give up this path to make other likely-paths optimized.
I think this is just a tradeoff issue of what to be optimized the most.

if (found) {

if (unlikely(on_buffer)) {
mutex_unlock(&cache->io_lock);

update_mb_idx = mb->idx;
goto write_on_buffer;
} else {
u8 dirty_bits = atomic_read_mb_dirtiness(seg, mb);

/*
 * First clean up the previous cache
 * and migrate the cache if needed.
 */
bool needs_cleanup_prev_cache =
!bio_fullsize || !(dirty_bits == 255);

if (unlikely(needs_cleanup_prev_cache)) {
wait_for_completion(&seg->flush_done);
migrate_mb(cache, seg, mb, dirty_bits, true);
}

I checked that the mkfs.ext4 writes only in 4KB size
so it is not gonna turn the boolean value true for going into the slowpath.

Problem:
Problem is that
it chooses the slowpath even though the bio is full-sized overwrite
in the test.

The reason is that the dirty bits is sometimes seen as 0
and the suspect is the migration daemon.

I guess you created the writeboost device with the default configuration.
In that case migration daemon always works and
some metadata is cleaned up in background.

If you turns both enable_migration_modulator and allow_migrate to 0
before beginning the test
to stop migration at all
it never goes into the slowpath with the test.

Solution:
Changing the code to
avoid going into the slowpath when the dirty bits is zero
will solve this problem.

And done. Please pull the latest one from the repo.
--- a/Driver/dm-writeboost-target.c
+++ b/Driver/dm-writeboost-target.c
@@ -688,6 +688,14 @@ static int writeboost_map(struct dm_target *ti, struct bio 
*bio
bool needs_cleanup_prev_cache =
!bio_fullsize || !(dirty_bits == 255);

+   /*
+* Migration works in background
+* and may have cleaned up the metablock.
+* If the metablock is clean we need not to migrate.
+*/
+   if (!dirty_bits)
+   needs_cleanup_prev_cache = false;
+
if (unlikely(needs_cleanup_prev_cache)) {
wait_for_completion(&seg->flush_done);
migrate_mb(cache, seg, mb, dirty_bits, true);

Thanks,
Akira
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Drivers: scsi: FLUSH timeout

2013-10-03 Thread James Bottomley 
On Wed, 2013-10-02 at 18:29 +, KY Srinivasan wrote:
> 
> > -Original Message-
> > From: geert.uytterhoe...@gmail.com [mailto:geert.uytterhoe...@gmail.com]
> > On Behalf Of Geert Uytterhoeven
> > Sent: Wednesday, September 25, 2013 1:40 AM
> > To: KY Srinivasan
> > Cc: Mike Christie; Jack Wang; Greg KH; linux-ker...@vger.kernel.org;
> > de...@linuxdriverproject.org; oher...@suse.com; jbottom...@parallels.com;
> > h...@infradead.org; linux-s...@vger.kernel.org
> > Subject: Re: Drivers: scsi: FLUSH timeout
> > 
> > On Tue, Sep 24, 2013 at 11:53 PM, KY Srinivasan  wrote:
> > > I am not sure how that magic number was arrived at (the 60HZ number). We
> > want this to be little higher -
> > 
> > "60 * HZ" means "60 seconds".
> > 
> > > would there be any issues raising this to say  180 seconds. This is the 
> > > value we
> > currently have for I/O
> > > timeout.
> > 
> > So you want to replace it by "180 * HZ", which is ... another magic number?
> 
> Ideally, I want this to be adjustable like the way we can change the I/O 
> timeout.
> Since that has been attempted earlier and rejected (not clear what the 
> reasons were),
> I was suggesting that we pick a larger number. James, let me know how I 
> should proceed here.

It's only one problem device with its own driver, right?  how about a
per target value you set in target_configure?  That way there's no
damage to the rest of the system even in a mixed device environment.  I
don't see a particular need to expose this via sysfs unless someone else
has a use case.

James

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: Drivers: scsi: FLUSH timeout

2013-10-03 Thread KY Srinivasan 


> -Original Message-
> From: Nicholas A. Bellinger [mailto:n...@linux-iscsi.org]
> Sent: Thursday, October 03, 2013 5:09 AM
> To: KY Srinivasan
> Cc: Geert Uytterhoeven; Mike Christie; Jack Wang; Greg KH; linux-
> ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com;
> jbottom...@parallels.com; h...@infradead.org; linux-s...@vger.kernel.org
> Subject: Re: Drivers: scsi: FLUSH timeout
> 
> On Wed, 2013-10-02 at 18:29 +, KY Srinivasan wrote:
> >
> > > -Original Message-
> > > From: geert.uytterhoe...@gmail.com
> [mailto:geert.uytterhoe...@gmail.com]
> > > On Behalf Of Geert Uytterhoeven
> > > Sent: Wednesday, September 25, 2013 1:40 AM
> > > To: KY Srinivasan
> > > Cc: Mike Christie; Jack Wang; Greg KH; linux-ker...@vger.kernel.org;
> > > de...@linuxdriverproject.org; oher...@suse.com;
> jbottom...@parallels.com;
> > > h...@infradead.org; linux-s...@vger.kernel.org
> > > Subject: Re: Drivers: scsi: FLUSH timeout
> > >
> > > On Tue, Sep 24, 2013 at 11:53 PM, KY Srinivasan  
> > > wrote:
> > > > I am not sure how that magic number was arrived at (the 60HZ number). We
> > > want this to be little higher -
> > >
> > > "60 * HZ" means "60 seconds".
> > >
> > > > would there be any issues raising this to say  180 seconds. This is the 
> > > > value
> we
> > > currently have for I/O
> > > > timeout.
> > >
> > > So you want to replace it by "180 * HZ", which is ... another magic 
> > > number?
> >
> > Ideally, I want this to be adjustable like the way we can change the I/O 
> > timeout.
> > Since that has been attempted earlier and rejected (not clear what the 
> > reasons
> were),
> > I was suggesting that we pick a larger number. James, let me know how I 
> > should
> proceed here.
> >
> 
> I think the objection was to making a module parameter for doing this
> globally for all struct scsi_disk, and not the idea of making it
> adjustable on an individual basis per-say..
> 
> What about adding a /sys/class/scsi_disk/$HCTL/flush_timeout..?
> 
> Here's a quick (untested) patch to that effect.

Thanks Nicholas. This is precisely what I was hoping we could agree on. 
James, if this is acceptable, we will go ahead and test this patch.


Regards,

K. Y
> 
> --nab
> 
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index e62d17d..f7a8c5b 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -460,6 +460,38 @@ max_write_same_blocks_store(struct device *dev,
> struct device_attribute *attr,
>  }
>  static DEVICE_ATTR_RW(max_write_same_blocks);
> 
> +static ssize_t
> +flush_timeout_show(struct device *dev,
> +struct device_attribute *attr, char *buf)
> +{
> + struct scsi_disk *sdkp = to_scsi_disk(dev);
> +
> + return snprintf(buf, 20, "%u\n", sdkp->flush_timeout);
> +}
> +
> +static ssize_t
> +flush_timeout_store(struct device *dev,
> + struct device_attribute *attr, const char *buf,
> + size_t count)
> +{
> + struct scsi_disk *sdkp = to_scsi_disk(dev);
> + unsigned int flush_timeout;
> + int err;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EACCES;
> +
> + err = kstrtouint(buf, 10, &flush_timeout);
> +
> + if (flush_timeout > SD_FLUSH_TIMEOUT_MAX)
> + return -EINVAL;
> +
> + sdkp->flush_timeout = flush_timeout;
> +
> + return err ? err : count;
> +}
> +static DEVICE_ATTR_RW(flush_timeout);
> +
>  static struct attribute *sd_disk_attrs[] = {
>   &dev_attr_cache_type.attr,
>   &dev_attr_FUA.attr,
> @@ -472,6 +504,7 @@ static struct attribute *sd_disk_attrs[] = {
>   &dev_attr_provisioning_mode.attr,
>   &dev_attr_max_write_same_blocks.attr,
>   &dev_attr_max_medium_access_timeouts.attr,
> + &dev_attr_flush_timeout.attr,
>   NULL,
>  };
>  ATTRIBUTE_GROUPS(sd_disk);
> @@ -829,7 +862,9 @@ static int sd_setup_write_same_cmnd(struct scsi_device
> *sdp, struct request *rq)
> 
>  static int scsi_setup_flush_cmnd(struct scsi_device *sdp, struct request *rq)
>  {
> - rq->timeout = SD_FLUSH_TIMEOUT;
> + struct scsi_disk *sdkp = scsi_disk(rq->rq_disk);
> +
> + rq->timeout = sdkp->flush_timeout;
>   rq->retries = SD_MAX_RETRIES;
>   rq->cmd[0] = SYNCHRONIZE_CACHE;
>   rq->cmd_len = 10;
> @@ -2841,6 +2876,7 @@ static void sd_probe_async(void *data, async_cookie_t
> cookie)
>   sdkp->ATO = 0;
>   sdkp->first_scan = 1;
>   sdkp->max_medium_access_timeouts = SD_MAX_MEDIUM_TIMEOUTS;
> + sdkp->flush_timeout = SD_FLUSH_TIMEOUT;
> 
>   sd_revalidate_disk(gd);
> 
> diff --git a/drivers/scsi/sd.h b/drivers/scsi/sd.h
> index 7a049de..ac7cd0f 100644
> --- a/drivers/scsi/sd.h
> +++ b/drivers/scsi/sd.h
> @@ -14,6 +14,7 @@
>  #define SD_TIMEOUT   (30 * HZ)
>  #define SD_MOD_TIMEOUT   (75 * HZ)
>  #define SD_FLUSH_TIMEOUT (60 * HZ)
> +#define SD_FLUSH_TIMEOUT_MAX (180 * HZ)
>  #define SD_WRITE_SAME_TIMEOUT(120 * HZ)
> 
>  /*
> @@ -68,6 +69,7 @@ struct scsi_disk {
>   unsigned in

Re: [PATCH 1/3] imx-drm: Add mx6 hdmi transmitter support

2013-10-03 Thread Robert Nelson 
On Wed, Oct 2, 2013 at 5:45 PM, Fabio Estevam
 wrote:
> This is based on the initial work done by Sascha Hauer and Tony Prisk.
>
> Tested on a mx6q wandboard and on a mx6qsabresd.
>
> Signed-off-by: Fabio Estevam 
> ---
> This was tested against linux-next 20130927.
>
>  drivers/staging/imx-drm/Kconfig |6 +
>  drivers/staging/imx-drm/Makefile|1 +
>  drivers/staging/imx-drm/imx-hdmi.c  | 1969 
> +++
>  drivers/staging/imx-drm/imx-hdmi.h  | 1032 ++
>  include/linux/mfd/syscon/imx6q-iomuxc-gpr.h |1 +
>  5 files changed, 3009 insertions(+)
>  create mode 100644 drivers/staging/imx-drm/imx-hdmi.c
>  create mode 100644 drivers/staging/imx-drm/imx-hdmi.h
>
> diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
> index 394254f..56d2a41 100644
> --- a/drivers/staging/imx-drm/Kconfig
> +++ b/drivers/staging/imx-drm/Kconfig
> @@ -52,3 +52,9 @@ config DRM_IMX_IPUV3
> depends on DRM_IMX_IPUV3_CORE
> help
>   Choose this if you have a i.MX5 or i.MX6 processor.
> +
> +config DRM_IMX_HDMI
> +   tristate "Freescale i.MX DRM HDMI "
> +   depends on DRM_IMX
> +   help
> + Choose this if you want to use HDMI on i.MX6.
> diff --git a/drivers/staging/imx-drm/Makefile 
> b/drivers/staging/imx-drm/Makefile
> index bfaf693..79a5588 100644
> --- a/drivers/staging/imx-drm/Makefile
> +++ b/drivers/staging/imx-drm/Makefile
> @@ -9,3 +9,4 @@ obj-$(CONFIG_DRM_IMX_LDB) += imx-ldb.o
>  obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
>  obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += ipu-v3/
>  obj-$(CONFIG_DRM_IMX_IPUV3)+= ipuv3-crtc.o
> +obj-$(CONFIG_DRM_IMX_HDMI) += imx-hdmi.o
> diff --git a/drivers/staging/imx-drm/imx-hdmi.c 
> b/drivers/staging/imx-drm/imx-hdmi.c
> new file mode 100644
> index 000..4b486eb
> --- /dev/null
> +++ b/drivers/staging/imx-drm/imx-hdmi.c
> @@ -0,0 +1,1969 @@
> +/*
> + * Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * SH-Mobile High-Definition Multimedia Interface (HDMI) driver
> + * for SLISHDMI13T and SLIPHDMIT IP cores
> + *
> + * Copyright (C) 2010, Guennadi Liakhovetski 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

Just started testing with v3.12-rc3 +
e6e7fb1ffc875adf2dd36d4a135b8d7addda0aea (top of torvalds tree.)

This needs to be:
#include "ipu-v3/imx-ipu-v3.h"

Otherwise.

drivers/staging/imx-drm/imx-hdmi.c:27:28: fatal error:
drm/imx-ipu-v3.h: No such file or directory
 #include 
^
compilation terminated.
make[3]: *** [drivers/staging/imx-drm/imx-hdmi.o] Error 1
make[2]: *** [drivers/staging/imx-drm] Error 2
make[2]: *** Waiting for unfinished jobs

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/3] imx-drm: Add mx6 hdmi transmitter support

2013-10-03 Thread Fabio Estevam 
On Thu, Oct 3, 2013 at 1:24 PM, Robert Nelson  wrote:

> Just started testing with v3.12-rc3 +
> e6e7fb1ffc875adf2dd36d4a135b8d7addda0aea (top of torvalds tree.)
>
> This needs to be:
> #include "ipu-v3/imx-ipu-v3.h"

Thanks for testing, Robert.

I used linux-next 20130927 to test these patches, and I can rebase it
against 3.12-rc3 if needed.

Will wait for some comments/feedbacks first though.

Regards,

Fabio Estevam
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

lustre: why does cfs_get_random_bytes() exist?

2013-10-03 Thread Theodore Ts'o 
I've been auditing uses of get_random_bytes() since there are places
where get_random_bytes() is getting used where something weaker, such
as prandom_u32() is quite sufficient.  Basically, if kernel code just
needs a random number which does not have any cryptographic
requirements (such as in ext[234]. which gets the new block group used
for inode allocations using get_random_bytes), then prandom_u32()
should be used instead of get_random_bytes() to save CPU overhead and
to reduce the drain on the /dev/urandom's entropy pool.

Typically, the reason for this is either for historical reasons, since
prandom_u32() hadn't existed when the code was written, or because
historical code was cut and pasted into newer code.

When I came across staging/lustre/lustre/libcfs/prng.c, I saw
something which is **really** weird.  It defines a cfs_rand() which is
functionally identical to prandom_u32().  More puzzlingly, it also
defines cfs_get_random_bytes() which calls get_random_bytes() and then
xor's the result with cfs_rand().  That last step has no cryptographic
effect, so I'm really wondering who thought this as a good idea and/or
necessary.

What I think should happen is that staging/lustre/lustre/libcfs/prng.c
should be removed, and calls to cfs_rand() should get replaced
prandom_u32(), and cfs_get_random_bytes() should get replaced with
get_random_bytes().

Does this sound reasonable?

Cheers,

- Ted
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: lustre: why does cfs_get_random_bytes() exist?

2013-10-03 Thread Greg KH 
On Thu, Oct 03, 2013 at 12:39:08PM -0400, Theodore Ts'o wrote:
> I've been auditing uses of get_random_bytes() since there are places
> where get_random_bytes() is getting used where something weaker, such
> as prandom_u32() is quite sufficient.  Basically, if kernel code just
> needs a random number which does not have any cryptographic
> requirements (such as in ext[234]. which gets the new block group used
> for inode allocations using get_random_bytes), then prandom_u32()
> should be used instead of get_random_bytes() to save CPU overhead and
> to reduce the drain on the /dev/urandom's entropy pool.
> 
> Typically, the reason for this is either for historical reasons, since
> prandom_u32() hadn't existed when the code was written, or because
> historical code was cut and pasted into newer code.
> 
> When I came across staging/lustre/lustre/libcfs/prng.c, I saw
> something which is **really** weird.  It defines a cfs_rand() which is
> functionally identical to prandom_u32().  More puzzlingly, it also
> defines cfs_get_random_bytes() which calls get_random_bytes() and then
> xor's the result with cfs_rand().  That last step has no cryptographic
> effect, so I'm really wondering who thought this as a good idea and/or
> necessary.
> 
> What I think should happen is that staging/lustre/lustre/libcfs/prng.c
> should be removed, and calls to cfs_rand() should get replaced
> prandom_u32(), and cfs_get_random_bytes() should get replaced with
> get_random_bytes().
> 
> Does this sound reasonable?

Sounds reasonable to me, care to send a patch to do so?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

RE: [PATCH] staging: dwc2: Make dwc2_hw_params.host_channels large enough

2013-10-03 Thread Paul Zimmerman 
> From: Matthijs Kooijman [mailto:matth...@stdin.nl]
> Sent: Thursday, October 03, 2013 12:35 AM
> 
> > By the way, it looks like 'num_dev_ep' would have the same problem,
> 
> I don't think so, since the hardware doesn't do the off-by-one trick
> there (presumably because having 0 endpoints make sense, but 0 host
> channels doesn't):
> 
> hw->num_dev_ep = (hwcfg2 & GHWCFG2_NUM_DEV_EP_MASK) >>
>  GHWCFG2_NUM_DEV_EP_SHIFT;

Yep, you're right, I got it confused with GHWCFG4_NUM_IN_EPS, which we
don't use.

> > That one and also 'num_dev_perio_in_ep' and 'dev_token_q_depth' should
> > be removed, I think.
> 
> Doesn't hurt to keep them around, I think? When device mode is
> implemented, I guess this code will need to present exactly like it is
> now (unlike other device mode code, which likely needs to be adapted to
> whatever s3-hsotg is doing now)?

When we go to move the driver out of staging, I'm pretty sure these
do-nothing parameters will have to be removed.

-- 
Paul

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 3/3] ARM: dts: imx6qdl-sabresd: Add HDMI support

2013-10-03 Thread Fabio Estevam 
Signed-off-by: Fabio Estevam 
---
Changes since v1:
- Put the dt entries in alphabetical order

 arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 39eafc2..4df4432 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -111,6 +111,11 @@
status = "okay";
 };
 
+&hdmi {
+   ddc = <&i2c2>;
+   status = "okay";
+};
+
 &i2c1 {
clock-frequency = <10>;
pinctrl-names = "default";
@@ -140,6 +145,13 @@
};
 };
 
+&i2c2 {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2c2_2>;
+   status = "okay";
+};
+
 &i2c3 {
clock-frequency = <10>;
pinctrl-names = "default";
-- 
1.8.1.2


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 2/3] ARM: dts: imx6qdl-wandboard: Add HDMI support

2013-10-03 Thread Fabio Estevam 
Signed-off-by: Fabio Estevam 
---
Changes since v1:
- None

 arch/arm/boot/dts/imx6dl.dtsi|  4 
 arch/arm/boot/dts/imx6q.dtsi |  4 
 arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 13 +
 arch/arm/boot/dts/imx6qdl.dtsi   | 10 ++
 4 files changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 9e8ae11..65e54b4 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -88,3 +88,7 @@
crtcs = <&ipu1 0>, <&ipu1 1>;
};
 };
+
+&hdmi {
+   crtcs = <&ipu1 0>, <&ipu1 1>;
+}
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index f024ef2..d2467f5 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -159,3 +159,7 @@
crtcs = <&ipu1 0>, <&ipu1 1>, <&ipu2 0>, <&ipu2 1>;
};
 };
+
+&hdmi {
+   crtcs = <&ipu1 0>, <&ipu1 1>, <&ipu2 0>, <&ipu2 1>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi 
b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
index a55113e..758c17f 100644
--- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi
@@ -51,6 +51,19 @@
status = "okay";
 };
 
+
+&hdmi {
+   ddc = <&i2c1>;
+   status = "okay";
+};
+
+&i2c1 {
+   clock-frequency = <10>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2c1_1>;
+   status = "okay";
+};
+
 &i2c2 {
clock-frequency = <10>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index ccd55c2..b148cb3 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1301,6 +1301,16 @@
};
};
 
+   hdmi: hdmi@012 {
+   compatible = "fsl,imx6q-hdmi";
+   reg = <0x0012 0x9000>;
+   interrupts = <0 115 0x04>;
+   gpr = <&gpr>;
+   clocks = <&clks 123>, <&clks 124>;
+   clock-names = "iahb", "isfr";
+   status = "disabled";
+   };
+
dcic1: dcic@020e4000 {
reg = <0x020e4000 0x4000>;
interrupts = <0 124 0x04>;
-- 
1.8.1.2


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: lustre: why does cfs_get_random_bytes() exist?

2013-10-03 Thread Theodore Ts'o 
On Thu, Oct 03, 2013 at 10:26:21AM -0700, Greg KH wrote:
> > Does this sound reasonable?
> 
> Sounds reasonable to me, care to send a patch to do so?
> 

I can do that, but I was waiting for Andras, Peng or Nikita to let me
now if there was something I was missing or not.  I'm pretty sure it's
something bogus, perhaps left over from a OS abstraction layer to
support Solaris or some such, but I am curious what was the historical
reason for the current code.

Cheers,

- Ted
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/3] imx-drm: Add mx6 hdmi transmitter support

2013-10-03 Thread Dan Carpenter 
On Thu, Oct 03, 2013 at 01:40:44PM -0300, Fabio Estevam wrote:
> On Thu, Oct 3, 2013 at 1:24 PM, Robert Nelson  wrote:
> 
> > Just started testing with v3.12-rc3 +
> > e6e7fb1ffc875adf2dd36d4a135b8d7addda0aea (top of torvalds tree.)
> >
> > This needs to be:
> > #include "ipu-v3/imx-ipu-v3.h"
> 
> Thanks for testing, Robert.
> 
> I used linux-next 20130927 to test these patches, and I can rebase it
> against 3.12-rc3 if needed.
> 

You had it correct the first time.  Use linux-next for this.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

looking for loan

2013-10-03 Thread Aijaz Lending 
Do you have a firm or company that need loan to start up a business or 
need,personal loan, Debt consolidation? For more information,Contact us now for 
a guarantee loan with low interest rate. We will provide you with loan to meet 
your needs. For more information contact us with the following information's.
Full name:
country:
Address:
Phone Number:
Amount needed:
Duration of loan:

sg.loan...@outlook.com
Kind regards
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

looking for loan

2013-10-03 Thread Aijaz Lending 
Do you have a firm or company that need loan to start up a business or 
need,personal loan, Debt consolidation? For more information,Contact us now for 
a guarantee loan with low interest rate. We will provide you with loan to meet 
your needs. For more information contact us with the following information's.
Full name:
country:
Address:
Phone Number:
Amount needed:
Duration of loan:

sg.loan...@outlook.com
Kind regards
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/3] imx-drm: Add mx6 hdmi transmitter support

2013-10-03 Thread Dan Carpenter 
On Thu, Oct 03, 2013 at 03:51:25PM -0300, Fabio Estevam wrote:
> This is based on the initial work done by Sascha Hauer and Tony Prisk.
> 
> Tested on imx6q-wandboard and imx6q-sabresd boards.
> 
> Signed-off-by: Fabio Estevam 
> ---
> Changes since v1:
> - Rebased against 3.12-rc3 and fixed header file location
> 

It should be done against linux-next as previously mentioned but the
header still needs to be fixed in linux-next I think?

Also it has the following Smatch warnings which are all basically
correct.

drivers/staging/imx-drm/imx-hdmi.c:511 imx_hdmi_update_csc_coeffs() error: 
buffer overflow '(*csc_coeff)[0]' 4 <= 4
drivers/staging/imx-drm/imx-hdmi.c:520 imx_hdmi_update_csc_coeffs() error: 
buffer overflow '(*csc_coeff)[1]' 4 <= 4
drivers/staging/imx-drm/imx-hdmi.c:529 imx_hdmi_update_csc_coeffs() error: 
buffer overflow '(*csc_coeff)[2]' 4 <= 4
drivers/staging/imx-drm/imx-hdmi.c:785 hdmi_phy_i2c_write() info: ignoring 
unreachable code.
drivers/staging/imx-drm/imx-hdmi.c:873 hdmi_phy_configure() warn: unsigned 
'hdmi->hdmi_data.video_mode.mpixelclock' is never less than zero.
drivers/staging/imx-drm/imx-hdmi.c:1537 imx_hdmi_fb_registered() warn: 
inconsistent returns spin_lock:&hdmi->irq_lock: locked (1514 
[s32min-(-1),1-s32max]) unlocked (1508 [0], 1537 [0])
drivers/staging/imx-drm/imx-hdmi.c:1537 imx_hdmi_fb_registered() warn: 
inconsistent returns irqsave:flags: locked (1514 [s32min-(-1),1-s32max]) 
unlocked (1508 [0], 1537 [0])
drivers/staging/imx-drm/imx-hdmi.c:1837 imx_hdmi_platform_probe() info: why not 
propagate 'irq' from platform_get_irq() instead of (-22)?

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] staging: octeon-ethernet: don't assume that CPU 0 is special

2013-10-03 Thread Greg Kroah-Hartman 
On Sat, Sep 28, 2013 at 10:50:33PM +0300, Aaro Koskinen wrote:
> Currently the driver assumes that CPU 0 is handling all the hard IRQs.
> This is wrong in Linux SMP systems where user is allowed to assign to
> hardware IRQs to any CPU. The driver will stop working if user sets
> smp_affinity so that interrupts end up being handled by other than CPU
> 0. The patch fixes that.
> 
> Signed-off-by: Aaro Koskinen 
> ---
>  drivers/staging/octeon/ethernet-rx.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

Given the objections for this series, I've now dropped it from my queue.
If you want to resubmit it, please do so.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v2 1/3] imx-drm: Add mx6 hdmi transmitter support

2013-10-03 Thread Greg KH 
On Thu, Oct 03, 2013 at 03:51:25PM -0300, Fabio Estevam wrote:
> This is based on the initial work done by Sascha Hauer and Tony Prisk.
> 
> Tested on imx6q-wandboard and imx6q-sabresd boards.

Why is _any_ new work going on here instead of working to get this code
out of staging?

I really don't want to accept this at all, as I'm not seeing any effort
to get this out of staging and into the proper place in the drm tree,
sorry.

And I shouldn't have to be saying this at all, you all know better than
to try to add new hardware support for staging drivers...

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Drivers: scsi: FLUSH timeout

2013-10-03 Thread Eric Seppanen 
On Thu, Oct 3, 2013 at 5:09 AM, Nicholas A. Bellinger
 wrote:
>
> On Wed, 2013-10-02 at 18:29 +, KY Srinivasan wrote:
> > Ideally, I want this to be adjustable like the way we can change the I/O 
> > timeout.
> > Since that has been attempted earlier and rejected (not clear what the 
> > reasons were),
> > I was suggesting that we pick a larger number. James, let me know how I 
> > should proceed here.
> >
>
> I think the objection was to making a module parameter for doing this
> globally for all struct scsi_disk, and not the idea of making it
> adjustable on an individual basis per-say..
>
> What about adding a /sys/class/scsi_disk/$HCTL/flush_timeout..?

Do I/O timeouts and flush timeouts need to be independently adjusted?
If you're having trouble with slow operations, it seems likely to be
across the board.

Flush timeout could be defined as 2x the read/write timeout.  Any
other command-specific timeouts could be scaled the same way.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: lustre: why does cfs_get_random_bytes() exist?

2013-10-03 Thread Dilger, Andreas 
On 2013/10/03 1:34 PM, "Theodore Ts'o"  wrote:
>On Thu, Oct 03, 2013 at 10:26:21AM -0700, Greg KH wrote:
>> > Does this sound reasonable?
>> 
>> Sounds reasonable to me, care to send a patch to do so?
>> 
>
>I can do that, but I was waiting for Andras, Peng or Nikita to let me
>now if there was something I was missing or not.  I'm pretty sure it's
>something bogus, perhaps left over from a OS abstraction layer to
>support Solaris or some such, but I am curious what was the historical
>reason for the current code.

The root of the problem with the existing get_random_bytes() is that when
the
Cray supercomputers with around 20k nodes reboot all at the same instant,
we
had problems with the Lustre client UUID (originally from
generate_random_uuid())
being identical between multiple nodes since they have virtually no
entropy at
boot time, and they and did not have hardware RNG.

The Lustre cfs_get_random_bytes() incorporates (via cfs_rand()) a seed
which
also hashes in the addresses from any network interfaces that are
configured.
Conversely, cfs_rand() also is seeded at startup from get_random_bytes() in
case a hardware RNG is available.  This ensures even with identical initial
conditions cfs_get_random_bytes() gets a different random stream on each
node.

It is also true that cfs_get_random_bytes() and cfs_rand() predate the
newer
APIs such as prandom_u32() (which, to be honest, I didn't even know existed
today).  This is work that was done for maybe 2.4.29? (RH 9?) kernels.

The number of users of cfs_get_random_bytes() is relatively small, mostly
just
for the client UUID and other unique identifiers at startup time.  The only
place it is used on an ongoing basis is for the capabilities that are
passed
from the metadata server to clients so the clients can validate they have
access
to the objects on the data server.  The rest of the code uses cfs_rand()
for
values that only need to be statistically uniform over time, so they don't
deplete the entropy pool.

I'm not against cleaning this up, if there is some mechanism for the
startup
code to add in the node interface addresses into the entropy pool, and this
is also used to perturb the prandom_u32() sequence after that point.
Besides
that initialization, it would be a simple search & replace for the users.

Cheers, Andreas
-- 
Andreas Dilger

Lustre Software Architect
Intel High Performance Data Division


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: lustre: why does cfs_get_random_bytes() exist?

2013-10-03 Thread Theodore Ts'o 
On Thu, Oct 03, 2013 at 11:06:58PM +, Dilger, Andreas wrote:
> 
> The Lustre cfs_get_random_bytes() incorporates (via cfs_rand()) a seed
> which
> also hashes in the addresses from any network interfaces that are
> configured.
> Conversely, cfs_rand() also is seeded at startup from get_random_bytes() in
> case a hardware RNG is available.  This ensures even with identical initial
> conditions cfs_get_random_bytes() gets a different random stream on each
> node.

With modern kernels, the /dev/random driver has the
add_device_randomness() interface which is used to mix in
personalization information, which includes the network MAC address.
So that particular concern should be covered without the hack of
mixing in cfs_rand().

> I'm not against cleaning this up, if there is some mechanism for the
> startup code to add in the node interface addresses into the entropy
> pool, and this is also used to perturb the prandom_u32() sequence
> after that point.

That's handled too, via the late initcall prandom_reseed().

Cheers,

- Ted
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] omapdce : fix transaction corruption due to wrong request id

2013-10-03 Thread Varun B Patil 
ioctl_codec_process was calling get_paddr() with a wrong pointer as
argument which resulted in wrong req_id being used to get the transaction
inside get_paddr().

Signed-off-by: Varun B Patil 
---
 drivers/staging/omapdce/dce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/omapdce/dce.c b/drivers/staging/omapdce/dce.c
index 87a45fa..2a7cbef 100644
--- a/drivers/staging/omapdce/dce.c
+++ b/drivers/staging/omapdce/dce.c
@@ -1296,7 +1296,7 @@ static int ioctl_codec_process(struct drm_device *dev, 
void *data,
 
codec_get_quirks(priv, arg->codec_handle, &quirks);
 
-   ret = PTR_RET(get_paddr(priv, hdr(&req), &req->out_args, 
arg->out_args_bo));
+   ret = PTR_RET(get_paddr(priv, hdr(req), &req->out_args, 
arg->out_args_bo));
if (ret)
return rpabort(hdr(req), ret);
 
-- 
1.8.1.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [dm-devel] Reworking dm-writeboost [was: Re: staging: Add dm-writeboost]

2013-10-03 Thread Dave Chinner 
On Wed, Oct 02, 2013 at 08:01:45PM -0400, Mikulas Patocka wrote:
> 
> 
> On Tue, 1 Oct 2013, Joe Thornber wrote:
> 
> > > Alternatively, delaying them will stall the filesystem because it's
> > > waiting for said REQ_FUA IO to complete. For example, journal writes
> > > in XFS are extremely IO latency sensitive in workloads that have a
> > > signifincant number of ordering constraints (e.g. O_SYNC writes,
> > > fsync, etc) and delaying even one REQ_FUA/REQ_FLUSH can stall the
> > > filesystem for the majority of that barrier_deadline_ms.
> > 
> > Yes, this is a valid concern, but I assume Akira has benchmarked.
> > With dm-thin, I delay the REQ_FUA/REQ_FLUSH for a tiny amount, just to
> > see if there are any other FUA requests on my queue that can be
> > aggregated into a single flush.  I agree with you that the target
> > should never delay waiting for new io; that's asking for trouble.
> > 
> > - Joe
> 
> You could send the first REQ_FUA/REQ_FLUSH request directly to the disk 
> and aggregate all the requests that were received while you processed the 
> initial request. This way, you can do request batching without introducing 
> artifical delays.

Yes, that's what XFS does with it's log when lots of fsync requests
come in. i.e. the first is dispatched immmediately, and the others
are gathered into the next log buffer until it is either full or the
original REQ_FUA log write completes.

That's where arbitrary delays in the storage stack below XFS cause
problems - if the first FUA log write is delayed, the next log
buffer will get filled, issued and delayed, and when we run out of
log buffers (there are 8 maximum) the entire log subsystem will
stall, stopping *all* log commit operations until log buffer
IOs complete and become free again. i.e. it can stall modifications
across the entire filesystem while we wait for batch timeouts to
expire and issue and complete FUA requests.

IMNSHO, REQ_FUA/REQ_FLUSH optimisations should be done at the
point where they are issued - any attempt to further optimise them
by adding delays down in the stack to aggregate FUA operations will
only increase latency of the operations that the issuer want to have
complete as fast as possible

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] omapdce : fix bug in ioctl_codec_process

2013-10-03 Thread Varun B Patil 
Do not send already free'd pointer to rpabort when rpsend fails.

Signed-off-by: Varun B Patil 
---
 drivers/staging/omapdce/dce.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/omapdce/dce.c b/drivers/staging/omapdce/dce.c
index 2a7cbef..1d9b75c 100644
--- a/drivers/staging/omapdce/dce.c
+++ b/drivers/staging/omapdce/dce.c
@@ -1318,15 +1318,17 @@ static int ioctl_codec_process(struct drm_device *dev, 
void *data,
 
ret = rpsend(priv, &arg->token, hdr(req), ptr - (void *)req);
 rpsend_out:
-   kfree(req);
if (ret) {
/* if input buffer is already locked, unlock it now so 
we
 * don't have a leak:
 */
if (input_id)
codec_unlockbuf(priv, arg->codec_handle, 
input_id);
-   return rpabort(hdr(req), ret);
+   ret = rpabort(hdr(req), ret);
+   kfree(req);
+   return ret;
}
+   kfree(req);
}
 
/* then wait for reply, which is interruptible */
-- 
1.8.1.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] omapdce : clear transaction if engine_open rpsend fails

2013-10-03 Thread Varun B Patil 
The next time the same transaction structure is used, when the req_id's
wrap around, it should be completely cleared (memset) to avoid corruption.

Signed-off-by: Varun B Patil 
---
 drivers/staging/omapdce/dce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/omapdce/dce.c b/drivers/staging/omapdce/dce.c
index 1d9b75c..2dbb24e9 100644
--- a/drivers/staging/omapdce/dce.c
+++ b/drivers/staging/omapdce/dce.c
@@ -754,7 +754,7 @@ static int ioctl_engine_open(struct drm_device *dev, void 
*data,
strncpy(req.name, arg->name, sizeof(req.name));
ret = rpsend(priv, &arg->token, hdr(&req), sizeof(req));
if (ret)
-   return ret;
+   return rpabort(hdr(&req), ret);
}
 
/* then wait for reply, which is interruptible */
-- 
1.8.1.2

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [dm-devel] dm-writeboost testing

2013-10-03 Thread Akira Hayakawa 
Hi, Mikulas,

I am sorry to say that
I don't have such machines to reproduce the problem.

But agree with that I am dealing with workqueue subsystem
in a little bit weird way.
I should clean them up.

For example,
free_cache() routine below is
a deconstructor of the cache metadata
including all the workqueues.

void free_cache(struct wb_cache *cache)
{
cache->on_terminate = true;

/* Kill in-kernel daemons */
cancel_work_sync(&cache->sync_work);
cancel_work_sync(&cache->recorder_work);
cancel_work_sync(&cache->modulator_work);

cancel_work_sync(&cache->flush_work);
destroy_workqueue(cache->flush_wq);

cancel_work_sync(&cache->barrier_deadline_work);

cancel_work_sync(&cache->migrate_work);
destroy_workqueue(cache->migrate_wq);
free_migration_buffer(cache);

/* Destroy in-core structures */
free_ht(cache);
free_segment_header_array(cache);

free_rambuf_pool(cache);
}

cancel_work_sync() before destroy_workqueue()
can probably be removed because destroy_workqueue() first
flush all the works.

Although I prepares independent workqueue
for each flush_work and migrate_work
other four works are queued into the system_wq
through schedule_work() routine.
This asymmetricity is not welcome for
architecture-portable code.
Dependencies to the subsystem should be minimized.
In detail, workqueue subsystem is really changing
about its concurrency support so
trusting only the single threaded workqueue
will be a good idea for stability.

To begin with,
these works are never out of queue
until the deconstructor is called
but they are repeating running and sleeping.
Queuing these kind of works to system_wq
may be unsupported.

So,
my strategy is to clean them up in a way that
1. all daemons are having their own workqueue
2. never use cancel_work_sync() but only calls destroy_workqueue()
   in the deconstructor free_cache() and error handling in resume_cache().

Could you please run the same test again
after I fixed these points
to see whether it is still reproducible?


> On 3.11.3 on PA-RISC without preemption, the device unloads (although it 
> takes many seconds and vmstat shows that the machine is idle during this 
> time)
This behavior is benign but probably should be improved.
In said free_cache() it first turns `on_terminate` flag to true
to notify all the daemons that we are shutting down.
Since the `update_interval` and `sync_interval` are 60 seconds by default
we must wait for them to finish for a while.

Akira
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel