Re: [PATCH 08/22] crypto: chcr: Make use of the new sg_map helper function

[Harsh Jain]

On Fri, Apr 14, 2017 at 3:35 AM, Logan Gunthorpe  wrote:
> The get_page in this area looks *highly* suspect due to there being no
> corresponding put_page. However, I've left that as is to avoid breaking
> things.
chcr driver will post the request to LLD driver cxgb4 and put_page is
implemented there. it will no harm. Any how
we have removed the below code from driver.

http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg24561.html

After this merge we can ignore your patch. Thanks

>
> I've also removed the KMAP_ATOMIC_ARGS check as it appears to be dead
> code that dates back to when it was first committed...


>
> Signed-off-by: Logan Gunthorpe 
> ---
>  drivers/crypto/chelsio/chcr_algo.c | 28 +++-
>  1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/crypto/chelsio/chcr_algo.c 
> b/drivers/crypto/chelsio/chcr_algo.c
> index 41bc7f4..a993d1d 100644
> --- a/drivers/crypto/chelsio/chcr_algo.c
> +++ b/drivers/crypto/chelsio/chcr_algo.c
> @@ -1489,22 +1489,21 @@ static struct sk_buff *create_authenc_wr(struct 
> aead_request *req,
> return ERR_PTR(-EINVAL);
>  }
>
> -static void aes_gcm_empty_pld_pad(struct scatterlist *sg,
> - unsigned short offset)
> +static int aes_gcm_empty_pld_pad(struct scatterlist *sg,
> +unsigned short offset)
>  {
> -   struct page *spage;
> unsigned char *addr;
>
> -   spage = sg_page(sg);
> -   get_page(spage); /* so that it is not freed by NIC */
> -#ifdef KMAP_ATOMIC_ARGS
> -   addr = kmap_atomic(spage, KM_SOFTIRQ0);
> -#else
> -   addr = kmap_atomic(spage);
> -#endif
> -   memset(addr + sg->offset, 0, offset + 1);
> +   get_page(sg_page(sg)); /* so that it is not freed by NIC */
> +
> +   addr = sg_map(sg, SG_KMAP_ATOMIC);
> +   if (IS_ERR(addr))
> +   return PTR_ERR(addr);
> +
> +   memset(addr, 0, offset + 1);
> +   sg_unmap(sg, addr, SG_KMAP_ATOMIC);
>
> -   kunmap_atomic(addr);
> +   return 0;
>  }
>
>  static int set_msg_len(u8 *block, unsigned int msglen, int csize)
> @@ -1940,7 +1939,10 @@ static struct sk_buff *create_gcm_wr(struct 
> aead_request *req,
> if (req->cryptlen) {
> write_sg_to_skb(skb, , src, req->cryptlen);
> } else {
> -   aes_gcm_empty_pld_pad(req->dst, authsize - 1);
> +   err = aes_gcm_empty_pld_pad(req->dst, authsize - 1);
> +   if (err)
> +   goto dstmap_fail;
> +
> write_sg_to_skb(skb, , reqctx->dst, crypt_len);
>
> }
> --
> 2.1.4
>

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Sat Apr 15 05:00:16 CEST 2017
media-tree git hash:f2fe89061d79706eca5c47e4efdc09bbc171e74a
media_build git hash:   8a44f033b9899e3193da85b1d3369a9dbfcc9eab
v4l-utils git hash: e748123b973e899cd6f0c08272a165661bd8386f
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: ERRORS
linux-git-arm-davinci: OK
linux-git-arm-multi: ERRORS
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: ERRORS
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: ERRORS
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: OK
linux-2.6.37.6-i686: OK
linux-2.6.38.8-i686: OK
linux-2.6.39.4-i686: OK
linux-3.0.60-i686: OK
linux-3.1.10-i686: OK
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: OK
linux-3.7.4-i686: OK
linux-3.8-i686: OK
linux-3.9.2-i686: OK
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: ERRORS
linux-3.12.67-i686: ERRORS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: ERRORS
linux-3.16.7-i686: ERRORS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-4.10.1-i686: OK
linux-4.11-rc1-i686: OK
linux-2.6.36.4-x86_64: OK
linux-2.6.37.6-x86_64: OK
linux-2.6.38.8-x86_64: OK
linux-2.6.39.4-x86_64: OK
linux-3.0.60-x86_64: OK
linux-3.1.10-x86_64: OK
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: OK
linux-3.7.4-x86_64: OK
linux-3.8-x86_64: OK
linux-3.9.2-x86_64: OK
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: ERRORS
linux-3.12.67-x86_64: ERRORS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: WARNINGS
linux-4.9-x86_64: WARNINGS
linux-4.10.1-x86_64: WARNINGS
linux-4.11-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
ABI WARNING: change for arm-davinci
ABI WARNING: change for arm-pxa
ABI WARNING: change for i686
ABI WARNING: change for m32r
ABI WARNING: change for powerpc64
ABI WARNING: change for sh
ABI WARNING: change for x86_64
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

Re: [PATCH v3 1/2] v4l: Add camera voice coil lens control class, current control

[Mauro Carvalho Chehab]

Hi Sakari,

Em Tue, 14 Feb 2017 14:20:22 +0200
Sakari Ailus  escreveu:

> Add a V4L2 control class for voice coil lens driver devices. These are
> simple devices that are used to move a camera lens from its resting
> position.

>From some past threads with this patch, you mentioned that:

"The FOCUS_ABSOLUTE control really is not a best control ID to
 control a voice coil driver's current."

However, I'm not seeing any explanation there at the thread, at
the patch description or at the documentation explaining why, and,
more important, when someone should use the focus control or the
camera voice coil control.

Worse than that, patch 2/2 gives the false sensation that both
controls are equal.

Ok, I understand that they need to be identical on the existing
driver, in order to keep backward compatibility, but I'm afraid
that, without a clear distinction between them at the documentation,
people may just clone the existing code on other drivers.

So, please add more details to patch 1/2.

Regards,
Mauro

> 
> Signed-off-by: Sakari Ailus 
> ---
>  Documentation/media/uapi/v4l/extended-controls.rst | 28 
> ++
>  include/uapi/linux/v4l2-controls.h |  8 +++
>  2 files changed, 36 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
> b/Documentation/media/uapi/v4l/extended-controls.rst
> index abb1057..a75451a 100644
> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> @@ -3022,6 +3022,34 @@ Image Process Control IDs
>  driver specific and are documented in :ref:`v4l-drivers`.
>  
>  
> +.. _voice-coil-lens-controls:
> +
> +Voice Coil Lens Control Reference
> +=
> +
> +The Voice Coil class controls are used to control voice coil lens
> +devices. These are very simple devices that consist of a voice coil, a
> +spring and a lens. The current applied on the voice coil is used to
> +move the lens away from the resting position which typically is (close
> +to) infinity. The higher the current applied, the closer the lens is
> +typically focused.
> +
> +.. _voice-coil-lens-control-is:
> +
> +Voice Coil Lens Control IDs
> +---
> +
> +``V4L2_CID_VOICE_COIL_CLASS (class)``
> +The VOICE_COIL class descriptor.
> +
> +``V4L2_CID_VOICE_COIL_CURRENT (integer)``
> +Current applied on a voice coil. The more current is applied, the
> +more is the position of the lens moved from its resting position.
> +Do note that there may be a ringing effect; the lens will
> +oscillate after changing the current applied unless the device
> +implements ringing compensation.
> +
> +
>  .. _dv-controls:
>  
>  Digital Video Control Reference
> diff --git a/include/uapi/linux/v4l2-controls.h 
> b/include/uapi/linux/v4l2-controls.h
> index 0d2e1e0..9ef152b 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -62,6 +62,7 @@
>  #define V4L2_CTRL_CLASS_FM_RX0x00a1  /* FM Receiver 
> controls */
>  #define V4L2_CTRL_CLASS_RF_TUNER 0x00a2  /* RF tuner controls */
>  #define V4L2_CTRL_CLASS_DETECT   0x00a3  /* Detection 
> controls */
> +#define V4L2_CTRL_CLASS_VOICE_COIL   0x00a4  /* Voice coil lens 
> driver controls */
>  
>  /* User-class control IDs */
>  
> @@ -894,6 +895,13 @@ enum v4l2_jpeg_chroma_subsampling {
>  #define V4L2_CID_TEST_PATTERN
> (V4L2_CID_IMAGE_PROC_CLASS_BASE + 3)
>  #define V4L2_CID_DEINTERLACING_MODE  (V4L2_CID_IMAGE_PROC_CLASS_BASE 
> + 4)
>  
> +/* Voice coil lens driver controls */
> +
> +#define V4L2_CID_VOICE_COIL_CLASS_BASE   
> (V4L2_CTRL_CLASS_VOICE_COIL | 0x900)
> +#define V4L2_CID_VOICE_COIL_CLASS(V4L2_CTRL_CLASS_VOICE_COIL | 1)
> +
> +#define V4L2_CID_VOICE_COIL_CURRENT  (V4L2_CID_VOICE_COIL_CLASS_BASE 
> + 1)
> +
>  
>  /*  DV-class control IDs defined by V4L2 */
>  #define V4L2_CID_DV_CLASS_BASE   (V4L2_CTRL_CLASS_DV | 
> 0x900)



Thanks,
Mauro

Re: [PATCH] staging/media: make atomisp vlv2_plat_clock explicitly non-modular

[Alan Cox]

> I'm pretty sure we want this code to be built as a module, so maybe a
> Kconfig change would resolve the issue instead?
> 
> Alan, any thoughts?

It's a tiny chunk of platform helper code. It probably ultimately
belongs in arch/x86 somewhere or folded into the driver. At the moment
it won't build modular.

I'm fine with the change, it strips out more pointless code so helps
see what tiny bits of code in there are actually used for anything
real.

Alan

Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver

[Pavel Machek]

Hi!

> > The MUX framework is already in linux-next. Could you use that instead of
> > adding new driver + bindings that are not compliant with the MUX framework?
> > I don't think it'd be much of a change in terms of code, using the MUX
> > framework appears quite simple.
> 
> It is not quite clear to me how to design the DT bindings for this. Just
> splitting the video-multiplexer driver from the mux-mmio / mux-gpio
> would make it necessary to keep the video-multiplexer node to describe
> the of-graph bindings. But then we have two different nodes in the DT
> that describe the same hardware:
> 
>   mux: mux {
>   compatible = "mux-gpio";
>   mux-gpios = < 0>, < 1>;
>   #mux-control-cells = <0>;
>   }
> 
>   video-multiplexer {
>   compatible = "video-multiplexer"
>   mux-controls = <>;
> 
>   ports {
>   /* ... */
>   }
>   }
> 
> It would feel more natural to have the ports in the mux node, but then
> how would the video-multiplexer driver be instanciated, and how would it
> get to the of-graph nodes?

Device tree representation and code used to implement the muxing
driver should be pretty independend, no? Yes, one piece of hardware
should have one entry in the device tree, so it should be something
like:


video-multiplexer {
compatible = "video-multiplexer-gpio"   
mux-gpios = < 0>, < 1>;
#mux-control-cells = <0>;

mux-controls = <>;
 
ports {
/* ... */
}
}

You should be able to use code in drivers/mux as a library...

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 10/22] staging: unisys: visorbus: Make use of the new sg_map helper function

[Logan Gunthorpe]

Great, thanks!

Logan

On 14/04/17 10:07 AM, Kershner, David A wrote:
> Can you add Acked-by for this patch? 
> 
> Acked-by: David Kershner 
> 
> Tested on s-Par and no problems. 
> 
> Thanks,
> David Kershner
> 
>> ---
>>  drivers/staging/unisys/visorhba/visorhba_main.c | 12 +++-
>>  1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c
>> b/drivers/staging/unisys/visorhba/visorhba_main.c
>> index 0ce92c8..2d8c8bc 100644
>> --- a/drivers/staging/unisys/visorhba/visorhba_main.c
>> +++ b/drivers/staging/unisys/visorhba/visorhba_main.c
>> @@ -842,7 +842,6 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct
>> scsi_cmnd *scsicmd)
>>  struct scatterlist *sg;
>>  unsigned int i;
>>  char *this_page;
>> -char *this_page_orig;
>>  int bufind = 0;
>>  struct visordisk_info *vdisk;
>>  struct visorhba_devdata *devdata;
>> @@ -869,11 +868,14 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp,
>> struct scsi_cmnd *scsicmd)
>>
>>  sg = scsi_sglist(scsicmd);
>>  for (i = 0; i < scsi_sg_count(scsicmd); i++) {
>> -this_page_orig = kmap_atomic(sg_page(sg + i));
>> -this_page = (void *)((unsigned long)this_page_orig |
>> - sg[i].offset);
>> +this_page = sg_map(sg + i, SG_KMAP_ATOMIC);
>> +if (IS_ERR(this_page)) {
>> +scsicmd->result = DID_ERROR << 16;
>> +return;
>> +}
>> +
>>  memcpy(this_page, buf + bufind, sg[i].length);
>> -kunmap_atomic(this_page_orig);
>> +sg_unmap(sg + i, this_page, SG_KMAP_ATOMIC);
>>  }
>>  } else {
>>  devdata = (struct visorhba_devdata *)scsidev->host-
>>> hostdata;
>> --
>> 2.1.4
> 

Re: [PATCH 04/22] target: Make use of the new sg_map function at 16 call sites (fwd)

[Logan Gunthorpe]

Thanks Julia. I missed that and I'll fix it in my series.

Logan

On 14/04/17 09:19 AM, Julia Lawall wrote:
> It looks like >cmdr_lock should be released at line 512 if it has
> not been released otherwise.  The lock was taken at line 438.
> 
> julia
> 
> -- Forwarded message --
> Date: Fri, 14 Apr 2017 22:21:44 +0800
> From: kbuild test robot <fengguang...@intel.com>
> To: kbu...@01.org
> Cc: Julia Lawall <julia.law...@lip6.fr>
> Subject: Re: [PATCH 04/22] target: Make use of the new sg_map function at 16
> call sites
> 
> Hi Logan,
> 
> [auto build test WARNING on scsi/for-next]
> [also build test WARNING on v4.11-rc6]
> [cannot apply to next-20170413]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Logan-Gunthorpe/Introduce-common-scatterlist-map-function/20170414-142518
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
> :: branch date: 8 hours ago
> :: commit date: 8 hours ago
> 
>>> drivers/target/target_core_user.c:512:2-8: preceding lock on line 438
>drivers/target/target_core_user.c:512:2-8: preceding lock on line 471
> 
> git remote add linux-review https://github.com/0day-ci/linux
> git remote update linux-review
> git checkout 78082134e7afdc59d744eb8d2def5c588e89c378
> vim +512 drivers/target/target_core_user.c
> 
> 7c9e7a6f Andy Grover  2014-10-01  432 
> sizeof(struct tcmu_cmd_entry));
> 7c9e7a6f Andy Grover  2014-10-01  433 command_size = base_command_size
> 7c9e7a6f Andy Grover  2014-10-01  434 + 
> round_up(scsi_command_size(se_cmd->t_task_cdb), TCMU_OP_ALIGN_SIZE);
> 7c9e7a6f Andy Grover  2014-10-01  435
> 7c9e7a6f Andy Grover  2014-10-01  436 WARN_ON(command_size & 
> (TCMU_OP_ALIGN_SIZE-1));
> 7c9e7a6f Andy Grover  2014-10-01  437
> 7c9e7a6f Andy Grover  2014-10-01 @438 spin_lock_irq(>cmdr_lock);
> 7c9e7a6f Andy Grover  2014-10-01  439
> 7c9e7a6f Andy Grover  2014-10-01  440 mb = udev->mb_addr;
> 7c9e7a6f Andy Grover  2014-10-01  441 cmd_head = mb->cmd_head % 
> udev->cmdr_size; /* UAM */
> 26418649 Sheng Yang   2016-02-26  442 data_length = 
> se_cmd->data_length;
> 26418649 Sheng Yang   2016-02-26  443 if (se_cmd->se_cmd_flags & 
> SCF_BIDI) {
> 26418649 Sheng Yang   2016-02-26  444 
> BUG_ON(!(se_cmd->t_bidi_data_sg && se_cmd->t_bidi_data_nents));
> 26418649 Sheng Yang   2016-02-26  445 data_length += 
> se_cmd->t_bidi_data_sg->length;
> 26418649 Sheng Yang   2016-02-26  446 }
> 554617b2 Andy Grover  2016-08-25  447 if ((command_size > 
> (udev->cmdr_size / 2)) ||
> 554617b2 Andy Grover  2016-08-25  448 data_length > 
> udev->data_size) {
> 554617b2 Andy Grover  2016-08-25  449 pr_warn("TCMU: Request 
> of size %zu/%zu is too big for %u/%zu "
> 3d9b9555 Andy Grover  2016-08-25  450 "cmd ring/data 
> area\n", command_size, data_length,
> 7c9e7a6f Andy Grover  2014-10-01  451 
> udev->cmdr_size, udev->data_size);
> 554617b2 Andy Grover  2016-08-25  452 
> spin_unlock_irq(>cmdr_lock);
> 554617b2 Andy Grover  2016-08-25  453 return 
> TCM_INVALID_CDB_FIELD;
> 554617b2 Andy Grover  2016-08-25  454 }
> 7c9e7a6f Andy Grover  2014-10-01  455
> 26418649 Sheng Yang   2016-02-26  456 while 
> (!is_ring_space_avail(udev, command_size, data_length)) {
> 7c9e7a6f Andy Grover  2014-10-01  457 int ret;
> 7c9e7a6f Andy Grover  2014-10-01  458 DEFINE_WAIT(__wait);
> 7c9e7a6f Andy Grover  2014-10-01  459
> 7c9e7a6f Andy Grover  2014-10-01  460 
> prepare_to_wait(>wait_cmdr, &__wait, TASK_INTERRUPTIBLE);
> 7c9e7a6f Andy Grover  2014-10-01  461
> 7c9e7a6f Andy Grover  2014-10-01  462 pr_debug("sleeping for 
> ring space\n");
> 7c9e7a6f Andy Grover  2014-10-01  463 
> spin_unlock_irq(>cmdr_lock);
> 7c9e7a6f Andy Grover  2014-10-01  464 ret = 
> schedule_timeout(msecs_to_jiffies(TCMU_TIME_OUT));
> 7c9e7a6f Andy Grover  2014-10-01  465 
> finish_wait(>wait_cmdr, &__wait);
> 7c9e7a6f Andy Grover  2014-10-01  466 if (!ret) {
> 7c9e7a6f Andy Grover  2014-10-01  467 pr_warn("tcmu: 
> command timed out\n");
> 02eb924f Andy Grover  2016-10-06  468 

RE: [PATCH 10/22] staging: unisys: visorbus: Make use of the new sg_map helper function

[Kershner, David A]

> -Original Message-
> From: Logan Gunthorpe [mailto:log...@deltatee.com]
...
> Subject: [PATCH 10/22] staging: unisys: visorbus: Make use of the new
> sg_map helper function
> 
> Straightforward conversion to the new function.
> 
> Signed-off-by: Logan Gunthorpe 

Can you add Acked-by for this patch? 

Acked-by: David Kershner 

Tested on s-Par and no problems. 

Thanks,
David Kershner

> ---
>  drivers/staging/unisys/visorhba/visorhba_main.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c
> b/drivers/staging/unisys/visorhba/visorhba_main.c
> index 0ce92c8..2d8c8bc 100644
> --- a/drivers/staging/unisys/visorhba/visorhba_main.c
> +++ b/drivers/staging/unisys/visorhba/visorhba_main.c
> @@ -842,7 +842,6 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp, struct
> scsi_cmnd *scsicmd)
>   struct scatterlist *sg;
>   unsigned int i;
>   char *this_page;
> - char *this_page_orig;
>   int bufind = 0;
>   struct visordisk_info *vdisk;
>   struct visorhba_devdata *devdata;
> @@ -869,11 +868,14 @@ do_scsi_nolinuxstat(struct uiscmdrsp *cmdrsp,
> struct scsi_cmnd *scsicmd)
> 
>   sg = scsi_sglist(scsicmd);
>   for (i = 0; i < scsi_sg_count(scsicmd); i++) {
> - this_page_orig = kmap_atomic(sg_page(sg + i));
> - this_page = (void *)((unsigned long)this_page_orig |
> -  sg[i].offset);
> + this_page = sg_map(sg + i, SG_KMAP_ATOMIC);
> + if (IS_ERR(this_page)) {
> + scsicmd->result = DID_ERROR << 16;
> + return;
> + }
> +
>   memcpy(this_page, buf + bufind, sg[i].length);
> - kunmap_atomic(this_page_orig);
> + sg_unmap(sg + i, this_page, SG_KMAP_ATOMIC);
>   }
>   } else {
>   devdata = (struct visorhba_devdata *)scsidev->host-
> >hostdata;
> --
> 2.1.4

Re: [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

[Logan Gunthorpe]

On 14/04/17 02:39 AM, Christoph Hellwig wrote:
> On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote:
>> Very straightforward conversion to the new function in all four spots.
> 
> I think the right fix here is to switch dm-crypt to the ahash API
> that takes a scatterlist.

Hmm, well I'm not sure I understand the code enough to make that
conversion. But I was looking at it. One tricky bit seems to be that
crypt_iv_lmk_one adds a seed, skips the first 16 bytes in the page and
then hashes another 16 bytes from other data. What would you do
construct a new sgl for it and pass it to the ahash api?

The other thing is crypt_iv_lmk_post also seems to modify the page after
the hash with a  crypto_xor so you'd still need at least one kmap in there.

Logan

Camera resolution question

[Ryan]

Hi,

I have a display of 720P and a 8MP camera.

Do i need to capture 8MP image or an image 720P from the camera as the
i need to display it on the LCD.

Where does the scaling take place? Should i scale the image down
before i display or should i capture a smaller resolution image from
the
camera to be able to display on the LCD.

thanks for your help.

Thanks,
ryan

Re: [PATCH] staging/media: make atomisp vlv2_plat_clock explicitly non-modular

[Paul Gortmaker]

[Re: [PATCH] staging/media: make atomisp vlv2_plat_clock explicitly 
non-modular] On 14/04/2017 (Fri 10:12) Greg Kroah-Hartman wrote:

> On Wed, Apr 12, 2017 at 09:57:55PM -0400, Paul Gortmaker wrote:
> > The Makefile / Kconfig currently controlling compilation of this code is:
> > 
> > clock/Makefile:obj-$(CONFIG_INTEL_ATOMISP) += vlv2_plat_clock.o
> > 
> > atomisp/Kconfig:menuconfig INTEL_ATOMISP
> > atomisp/Kconfig:bool "Enable support to Intel MIPI camera drivers"
> > 
> > ...meaning that it currently is not being built as a module by anyone.

[...]

> I'm pretty sure we want this code to be built as a module, so maybe a
> Kconfig change would resolve the issue instead?

As always, I'm good with things being moved to tristate if there is a use case
for it.  I will note that in this case however, that the above Kconfig option
is not specific to this file/driver.  It is controlling the inclusion of
several dirs/files, and so a more fine grained Kconfig may be required if some
are to be built-in and some are to be tristate...

P.

~/git/linux-head/drivers/staging/media/atomisp$ git grep 'obj.*INTEL_ATOMISP'
Makefile:obj-$(CONFIG_INTEL_ATOMISP) += pci/
Makefile:obj-$(CONFIG_INTEL_ATOMISP) += i2c/
Makefile:obj-$(CONFIG_INTEL_ATOMISP) += platform/
platform/Makefile:obj-$(CONFIG_INTEL_ATOMISP) += clock/
platform/Makefile:obj-$(CONFIG_INTEL_ATOMISP) += intel-mid/
platform/clock/Makefile:obj-$(CONFIG_INTEL_ATOMISP) += vlv2_plat_clock.o
platform/clock/Makefile:obj-$(CONFIG_INTEL_ATOMISP) += 
platform_vlv2_plat_clk.o
platform/intel-mid/Makefile:obj-$(CONFIG_INTEL_ATOMISP) += 
intel_mid_pcihelpers.o
platform/intel-mid/Makefile:obj-$(CONFIG_INTEL_ATOMISP) += 
atomisp_gmin_platform.o

> 
> Alan, any thoughts?
> 
> thanks,
> 
> greg k-h

Re: [PATCH 03/22] libiscsi: Make use of new the sg_map helper function

[Logan Gunthorpe]

On 14/04/17 02:36 AM, Christoph Hellwig wrote:
> On Thu, Apr 13, 2017 at 04:05:16PM -0600, Logan Gunthorpe wrote:
>> Convert the kmap and kmap_atomic uses to the sg_map function. We now
>> store the flags for the kmap instead of a boolean to indicate
>> atomicitiy. We also propogate a possible kmap error down and create
>> a new ISCSI_TCP_INTERNAL_ERR error type for this.
> 
> Can you split out the new error handling into a separate prep patch
> which should go to the iscsi maintainers ASAP?
> 

Yes, I can do that. I'd just have thought they'd want to see the use
case for the new error before accepting a patch like that...

Logan

Re: [PATCH 01/22] scatterlist: Introduce sg_map helper functions

[Logan Gunthorpe]

On 14/04/17 02:35 AM, Christoph Hellwig wrote:
>> +
>>  static inline int is_dma_buf_file(struct file *);
>>  
>>  struct dma_buf_list {
> 
> I think the right fix here is to rename the operation to unmap_atomic
> and send out a little patch for that ASAP.

Ok, I can do that next week.

> I'd rather have separate functions for kmap vs kmap_atomic instead of
> the flags parameter.  And while you're at it just always pass the 0
> offset parameter instead of adding a wrapper..
> 
> Otherwise this looks good to me.

I settled on the flags because I thought the interface could be expanded
to do more things like automatically copy iomem to a bounce buffer (with
a flag). It'd also be possible to add things like vmap and
physical_address to the interface which would cover even more sg_page
users. All the implementations would then share the common offset
calculations, and switching between them becomes a matter of changing a
couple flags.

If you're still not convinced by the above arguments  then I'll change
it but I did have reasons for choosing to do it this way.

I am fine with removing the offset versions. I will make that change.

Thanks,

Logan

Re: [PATCH 04/22] target: Make use of the new sg_map function at 16 call sites (fwd)

[Julia Lawall]

It looks like >cmdr_lock should be released at line 512 if it has
not been released otherwise.  The lock was taken at line 438.

julia

-- Forwarded message --
Date: Fri, 14 Apr 2017 22:21:44 +0800
From: kbuild test robot <fengguang...@intel.com>
To: kbu...@01.org
Cc: Julia Lawall <julia.law...@lip6.fr>
Subject: Re: [PATCH 04/22] target: Make use of the new sg_map function at 16
call sites

Hi Logan,

[auto build test WARNING on scsi/for-next]
[also build test WARNING on v4.11-rc6]
[cannot apply to next-20170413]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Logan-Gunthorpe/Introduce-common-scatterlist-map-function/20170414-142518
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
:: branch date: 8 hours ago
:: commit date: 8 hours ago

>> drivers/target/target_core_user.c:512:2-8: preceding lock on line 438
   drivers/target/target_core_user.c:512:2-8: preceding lock on line 471

git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout 78082134e7afdc59d744eb8d2def5c588e89c378
vim +512 drivers/target/target_core_user.c

7c9e7a6f Andy Grover  2014-10-01  432   
sizeof(struct tcmu_cmd_entry));
7c9e7a6f Andy Grover  2014-10-01  433   command_size = base_command_size
7c9e7a6f Andy Grover  2014-10-01  434   + 
round_up(scsi_command_size(se_cmd->t_task_cdb), TCMU_OP_ALIGN_SIZE);
7c9e7a6f Andy Grover  2014-10-01  435
7c9e7a6f Andy Grover  2014-10-01  436   WARN_ON(command_size & 
(TCMU_OP_ALIGN_SIZE-1));
7c9e7a6f Andy Grover  2014-10-01  437
7c9e7a6f Andy Grover  2014-10-01 @438   spin_lock_irq(>cmdr_lock);
7c9e7a6f Andy Grover  2014-10-01  439
7c9e7a6f Andy Grover  2014-10-01  440   mb = udev->mb_addr;
7c9e7a6f Andy Grover  2014-10-01  441   cmd_head = mb->cmd_head % 
udev->cmdr_size; /* UAM */
26418649 Sheng Yang   2016-02-26  442   data_length = 
se_cmd->data_length;
26418649 Sheng Yang   2016-02-26  443   if (se_cmd->se_cmd_flags & 
SCF_BIDI) {
26418649 Sheng Yang   2016-02-26  444   
BUG_ON(!(se_cmd->t_bidi_data_sg && se_cmd->t_bidi_data_nents));
26418649 Sheng Yang   2016-02-26  445   data_length += 
se_cmd->t_bidi_data_sg->length;
26418649 Sheng Yang   2016-02-26  446   }
554617b2 Andy Grover  2016-08-25  447   if ((command_size > 
(udev->cmdr_size / 2)) ||
554617b2 Andy Grover  2016-08-25  448   data_length > 
udev->data_size) {
554617b2 Andy Grover  2016-08-25  449   pr_warn("TCMU: Request 
of size %zu/%zu is too big for %u/%zu "
3d9b9555 Andy Grover  2016-08-25  450   "cmd ring/data 
area\n", command_size, data_length,
7c9e7a6f Andy Grover  2014-10-01  451   
udev->cmdr_size, udev->data_size);
554617b2 Andy Grover  2016-08-25  452   
spin_unlock_irq(>cmdr_lock);
554617b2 Andy Grover  2016-08-25  453   return 
TCM_INVALID_CDB_FIELD;
554617b2 Andy Grover  2016-08-25  454   }
7c9e7a6f Andy Grover  2014-10-01  455
26418649 Sheng Yang   2016-02-26  456   while 
(!is_ring_space_avail(udev, command_size, data_length)) {
7c9e7a6f Andy Grover  2014-10-01  457   int ret;
7c9e7a6f Andy Grover  2014-10-01  458   DEFINE_WAIT(__wait);
7c9e7a6f Andy Grover  2014-10-01  459
7c9e7a6f Andy Grover  2014-10-01  460   
prepare_to_wait(>wait_cmdr, &__wait, TASK_INTERRUPTIBLE);
7c9e7a6f Andy Grover  2014-10-01  461
7c9e7a6f Andy Grover  2014-10-01  462   pr_debug("sleeping for 
ring space\n");
7c9e7a6f Andy Grover  2014-10-01  463   
spin_unlock_irq(>cmdr_lock);
7c9e7a6f Andy Grover  2014-10-01  464   ret = 
schedule_timeout(msecs_to_jiffies(TCMU_TIME_OUT));
7c9e7a6f Andy Grover  2014-10-01  465   
finish_wait(>wait_cmdr, &__wait);
7c9e7a6f Andy Grover  2014-10-01  466   if (!ret) {
7c9e7a6f Andy Grover  2014-10-01  467   pr_warn("tcmu: 
command timed out\n");
02eb924f Andy Grover  2016-10-06  468   return 
TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE;
7c9e7a6f Andy Grover  2014-10-01  469   }
7c9e7a6f Andy Grover  2014-10-01  470
7c9e7a6f Andy Grover  2014-10-01  471   
spin_lock_irq(>cmdr_lock);
7c9e7a6f Andy Grover  2014-10-01  472
7c9e7a6f Andy Grover  2014-10-01  473   /* We dropped 
cmdr_lock, cmd_head is stale */
7c9e7a6f Andy Grover  2014-10-01  474   cmd_head = mb->cmd_head 
% udev->cmdr_size; /* UAM */
7c9e7a6f Andy Grover

[PATCH] staging: media: atomisp: fix range checking on clk_num

[Colin King]

From: Colin Ian King 

The range checking on clk_num is incorrect; fix these so that invalid
clk_num values are detected correctly.

Detected by static analysis with by PVS-Studio

Signed-off-by: Colin Ian King 
---
 drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c 
b/drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c
index 25e939c50aef..9efdf5790f90 100644
--- a/drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c
+++ b/drivers/staging/media/atomisp/platform/clock/vlv2_plat_clock.c
@@ -67,7 +67,7 @@ int vlv2_plat_set_clock_freq(int clk_num, int freq_type)
 {
void __iomem *addr;
 
-   if (clk_num < 0 && clk_num > MAX_CLK_COUNT) {
+   if (clk_num < 0 || clk_num >= MAX_CLK_COUNT) {
pr_err("Clock number out of range (%d)\n", clk_num);
return -EINVAL;
}
@@ -103,7 +103,7 @@ int vlv2_plat_get_clock_freq(int clk_num)
 {
u32 ret;
 
-   if (clk_num < 0 && clk_num > MAX_CLK_COUNT) {
+   if (clk_num < 0 || clk_num >= MAX_CLK_COUNT) {
pr_err("Clock number out of range (%d)\n", clk_num);
return -EINVAL;
}
@@ -133,7 +133,7 @@ int vlv2_plat_configure_clock(int clk_num, u32 conf)
 {
void __iomem *addr;
 
-   if (clk_num < 0 && clk_num > MAX_CLK_COUNT) {
+   if (clk_num < 0 || clk_num >= MAX_CLK_COUNT) {
pr_err("Clock number out of range (%d)\n", clk_num);
return -EINVAL;
}
@@ -169,7 +169,7 @@ int vlv2_plat_get_clock_status(int clk_num)
 {
int ret;
 
-   if (clk_num < 0 && clk_num > MAX_CLK_COUNT) {
+   if (clk_num < 0 || clk_num >= MAX_CLK_COUNT) {
pr_err("Clock number out of range (%d)\n", clk_num);
return -EINVAL;
}
-- 
2.11.0

[PATCH 5/8] omapdrm: hdmi4: prepare irq handling for HDMI CEC support

[Hans Verkuil]

From: Hans Verkuil 

Pass struct omap_hdmi to the irq handler since it will need access
to hdmi.core.

Do not clear the IRQ_HDMI_CORE bit: that will be controlled by the
HDMI CEC code.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index bd6075e34c94..4a164dc01f15 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -70,7 +70,8 @@ static void hdmi_runtime_put(void)
 
 static irqreturn_t hdmi_irq_handler(int irq, void *data)
 {
-   struct hdmi_wp_data *wp = data;
+   struct omap_hdmi *hdmi = data;
+   struct hdmi_wp_data *wp = >wp;
u32 irqstatus;
 
irqstatus = hdmi_wp_get_irqstatus(wp);
@@ -166,8 +167,8 @@ static int hdmi_power_on_full(struct omap_dss_device 
*dssdev)
return r;
 
/* disable and clear irqs */
-   hdmi_wp_clear_irqenable(wp, 0x);
-   hdmi_wp_set_irqstatus(wp, 0x);
+   hdmi_wp_clear_irqenable(wp, ~HDMI_IRQ_CORE);
+   hdmi_wp_set_irqstatus(wp, ~HDMI_IRQ_CORE);
 
vm = 
 
@@ -242,7 +243,7 @@ static void hdmi_power_off_full(struct omap_dss_device 
*dssdev)
 {
enum omap_channel channel = dssdev->dispc_channel;
 
-   hdmi_wp_clear_irqenable(, 0x);
+   hdmi_wp_clear_irqenable(, ~HDMI_IRQ_CORE);
 
hdmi_wp_video_stop();
 
@@ -726,7 +727,7 @@ static int hdmi4_bind(struct device *dev, struct device 
*master, void *data)
 
r = devm_request_threaded_irq(>dev, irq,
NULL, hdmi_irq_handler,
-   IRQF_ONESHOT, "OMAP HDMI", );
+   IRQF_ONESHOT, "OMAP HDMI", );
if (r) {
DSSERR("HDMI IRQ request failed\n");
goto err;
-- 
2.11.0

[PATCH 8/8] omapdrm: hdmi4: hook up the HDMI CEC support

[Hans Verkuil]

From: Hans Verkuil 

Hook up the HDMI CEC support in the hdmi4 driver.

It add the CEC irq handler, the CEC (un)init calls and tells the CEC
implementation when the physical address changes.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/omapdrm/dss/Kconfig  |  9 +
 drivers/gpu/drm/omapdrm/dss/Makefile |  1 +
 drivers/gpu/drm/omapdrm/dss/hdmi4.c  | 23 ++-
 3 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/Kconfig 
b/drivers/gpu/drm/omapdrm/dss/Kconfig
index d1fa730c7d54..d18e83902b74 100644
--- a/drivers/gpu/drm/omapdrm/dss/Kconfig
+++ b/drivers/gpu/drm/omapdrm/dss/Kconfig
@@ -71,9 +71,18 @@ config OMAP4_DSS_HDMI
bool "HDMI support for OMAP4"
 default y
select OMAP2_DSS_HDMI_COMMON
+   select MEDIA_CEC_EDID
help
  HDMI support for OMAP4 based SoCs.
 
+config OMAP4_DSS_HDMI_CEC
+   bool "Enable HDMI CEC support for OMAP4"
+   depends on OMAP4_DSS_HDMI
+   select MEDIA_CEC_SUPPORT
+   default y
+   ---help---
+ When selected the HDMI transmitter will support the CEC feature.
+
 config OMAP5_DSS_HDMI
bool "HDMI support for OMAP5"
default n
diff --git a/drivers/gpu/drm/omapdrm/dss/Makefile 
b/drivers/gpu/drm/omapdrm/dss/Makefile
index b651ec9751e6..d1c6acfbd134 100644
--- a/drivers/gpu/drm/omapdrm/dss/Makefile
+++ b/drivers/gpu/drm/omapdrm/dss/Makefile
@@ -11,5 +11,6 @@ omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o
 omapdss-$(CONFIG_OMAP2_DSS_HDMI_COMMON) += hdmi_common.o hdmi_wp.o hdmi_pll.o \
hdmi_phy.o
 omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi4.o hdmi4_core.o
+omapdss-$(CONFIG_OMAP4_DSS_HDMI_CEC) += hdmi4_cec.o
 omapdss-$(CONFIG_OMAP5_DSS_HDMI) += hdmi5.o hdmi5_core.o
 ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index e371b47ff6ff..ebe5b27cee6f 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -35,9 +35,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "omapdss.h"
 #include "hdmi4_core.h"
+#include "hdmi4_cec.h"
 #include "dss.h"
 #include "dss_features.h"
 #include "hdmi.h"
@@ -96,6 +98,13 @@ static irqreturn_t hdmi_irq_handler(int irq, void *data)
} else if (irqstatus & HDMI_IRQ_LINK_DISCONNECT) {
hdmi_wp_set_phy_pwr(wp, HDMI_PHYPWRCMD_LDOON);
}
+   if (irqstatus & HDMI_IRQ_CORE) {
+   u32 intr4 = hdmi_read_reg(hdmi->core.base, HDMI_CORE_SYS_INTR4);
+
+   hdmi_write_reg(hdmi->core.base, HDMI_CORE_SYS_INTR4, intr4);
+   if (intr4 & 8)
+   hdmi4_cec_irq(>core);
+   }
 
return IRQ_HANDLED;
 }
@@ -392,6 +401,8 @@ static void hdmi_display_disable(struct omap_dss_device 
*dssdev)
 
DSSDBG("Enter hdmi_display_disable\n");
 
+   hdmi4_cec_set_phys_addr(, CEC_PHYS_ADDR_INVALID);
+
mutex_lock();
 
spin_lock_irqsave(_playing_lock, flags);
@@ -492,7 +503,11 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
}
 
r = read_edid(edid, len);
-
+   if (r >= 256)
+   hdmi4_cec_set_phys_addr(,
+   cec_get_edid_phys_addr(edid, r, NULL));
+   else
+   hdmi4_cec_set_phys_addr(, CEC_PHYS_ADDR_INVALID);
if (need_enable)
hdmi4_core_disable(dssdev);
 
@@ -728,6 +743,10 @@ static int hdmi4_bind(struct device *dev, struct device 
*master, void *data)
if (r)
goto err;
 
+   r = hdmi4_cec_init(pdev, , );
+   if (r)
+   goto err;
+
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
DSSERR("platform_get_irq failed\n");
@@ -772,6 +791,8 @@ static void hdmi4_unbind(struct device *dev, struct device 
*master, void *data)
 
hdmi_uninit_output(pdev);
 
+   hdmi4_cec_uninit();
+
hdmi_pll_uninit();
 
pm_runtime_disable(>dev);
-- 
2.11.0

[PATCH 4/8] omapdrm: hdmi4: make low-level functions available

[Hans Verkuil]

From: Hans Verkuil 

Three low-level functions in hdmi4.c and hdmi4_core.c are
made available for use by the OMAP4 CEC support.

Renamed the prefix to hdmi4 since these are OMAP4 specific.

These function deal with the HDMI core and are needed to
power it up for use with CEC, even when the HPD is low.

Background: even if the HPD is low it should still be possible
to use CEC. Some displays will set the HPD low when they go into standby or
when they switch to another input, but CEC is still available and able
to wake up/change input for such a display.

This is explicitly allowed by the CEC standard.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c  | 12 ++--
 drivers/gpu/drm/omapdrm/dss/hdmi4_core.c |  6 +++---
 drivers/gpu/drm/omapdrm/dss/hdmi4_core.h |  4 
 3 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index e7162c16de2e..bd6075e34c94 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -393,11 +393,11 @@ static void hdmi_display_disable(struct omap_dss_device 
*dssdev)
mutex_unlock();
 }
 
-static int hdmi_core_enable(struct omap_dss_device *dssdev)
+int hdmi4_core_enable(struct omap_dss_device *dssdev)
 {
int r = 0;
 
-   DSSDBG("ENTER omapdss_hdmi_core_enable\n");
+   DSSDBG("ENTER omapdss_hdmi4_core_enable\n");
 
mutex_lock();
 
@@ -415,9 +415,9 @@ static int hdmi_core_enable(struct omap_dss_device *dssdev)
return r;
 }
 
-static void hdmi_core_disable(struct omap_dss_device *dssdev)
+void hdmi4_core_disable(struct omap_dss_device *dssdev)
 {
-   DSSDBG("Enter omapdss_hdmi_core_disable\n");
+   DSSDBG("Enter omapdss_hdmi4_core_disable\n");
 
mutex_lock();
 
@@ -475,7 +475,7 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
need_enable = hdmi.core_enabled == false;
 
if (need_enable) {
-   r = hdmi_core_enable(dssdev);
+   r = hdmi4_core_enable(dssdev);
if (r)
return r;
}
@@ -483,7 +483,7 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
r = read_edid(edid, len);
 
if (need_enable)
-   hdmi_core_disable(dssdev);
+   hdmi4_core_disable(dssdev);
 
return r;
 }
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
index e05b7ac4f7dd..130b6dc3f184 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c
@@ -208,9 +208,9 @@ static void hdmi_core_init(struct hdmi_core_video_config 
*video_cfg)
video_cfg->tclk_sel_clkmult = HDMI_FPLL10IDCK;
 }
 
-static void hdmi_core_powerdown_disable(struct hdmi_core_data *core)
+void hdmi4_core_powerdown_disable(struct hdmi_core_data *core)
 {
-   DSSDBG("Enter hdmi_core_powerdown_disable\n");
+   DSSDBG("Enter hdmi4_core_powerdown_disable\n");
REG_FLD_MOD(core->base, HDMI_CORE_SYS_SYS_CTRL1, 0x1, 0, 0);
 }
 
@@ -336,7 +336,7 @@ void hdmi4_configure(struct hdmi_core_data *core,
hdmi_core_swreset_assert(core);
 
/* power down off */
-   hdmi_core_powerdown_disable(core);
+   hdmi4_core_powerdown_disable(core);
 
v_core_cfg.pkt_mode = HDMI_PACKETMODE24BITPERPIXEL;
v_core_cfg.hdmi_dvi = cfg->hdmi_dvi_mode;
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.h 
b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.h
index a069f96ec6f6..b6ab579e44d2 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.h
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.h
@@ -266,6 +266,10 @@ void hdmi4_configure(struct hdmi_core_data *core, struct 
hdmi_wp_data *wp,
 void hdmi4_core_dump(struct hdmi_core_data *core, struct seq_file *s);
 int hdmi4_core_init(struct platform_device *pdev, struct hdmi_core_data *core);
 
+int hdmi4_core_enable(struct omap_dss_device *dssdev);
+void hdmi4_core_disable(struct omap_dss_device *dssdev);
+void hdmi4_core_powerdown_disable(struct hdmi_core_data *core);
+
 int hdmi4_audio_start(struct hdmi_core_data *core, struct hdmi_wp_data *wp);
 void hdmi4_audio_stop(struct hdmi_core_data *core, struct hdmi_wp_data *wp);
 int hdmi4_audio_config(struct hdmi_core_data *core, struct hdmi_wp_data *wp,
-- 
2.11.0

[PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES

[Hans Verkuil]

From: Hans Verkuil 

The CEC pin was always pulled up, making it impossible to use it.

Change to PIN_INPUT so it can be used by the new CEC support.

Signed-off-by: Hans Verkuil 
---
 arch/arm/boot/dts/omap4-panda-a4.dts | 2 +-
 arch/arm/boot/dts/omap4-panda-es.dts | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts 
b/arch/arm/boot/dts/omap4-panda-a4.dts
index 78d363177762..f1a6476af371 100644
--- a/arch/arm/boot/dts/omap4-panda-a4.dts
+++ b/arch/arm/boot/dts/omap4-panda-a4.dts
@@ -13,7 +13,7 @@
 /* Pandaboard Rev A4+ have external pullups on SCL & SDA */
 _hdmi_pins {
pinctrl-single,pins = <
-   OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0)/* 
hdmi_cec.hdmi_cec */
+   OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0)   /* 
hdmi_cec.hdmi_cec */
OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0)   /* 
hdmi_scl.hdmi_scl */
OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0)   /* 
hdmi_sda.hdmi_sda */
>;
diff --git a/arch/arm/boot/dts/omap4-panda-es.dts 
b/arch/arm/boot/dts/omap4-panda-es.dts
index 119f8e657edc..940fe4f7c5f6 100644
--- a/arch/arm/boot/dts/omap4-panda-es.dts
+++ b/arch/arm/boot/dts/omap4-panda-es.dts
@@ -34,7 +34,7 @@
 /* PandaboardES has external pullups on SCL & SDA */
 _hdmi_pins {
pinctrl-single,pins = <
-   OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0)/* 
hdmi_cec.hdmi_cec */
+   OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0)   /* 
hdmi_cec.hdmi_cec */
OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0)   /* 
hdmi_scl.hdmi_scl */
OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0)   /* 
hdmi_sda.hdmi_sda */
>;
-- 
2.11.0

[PATCH 3/8] omapdrm: hdmi.h: extend hdmi_core_data with CEC fields

[Hans Verkuil]

From: Hans Verkuil 

Extend the hdmi_core_data struct with the additional fields needed
for CEC.

Also fix a simple typo in a comment.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/omapdrm/dss/hdmi.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi.h 
b/drivers/gpu/drm/omapdrm/dss/hdmi.h
index fb6cccd02374..3913859146b9 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi.h
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "omapdss.h"
 #include "dss.h"
@@ -254,6 +255,9 @@ struct hdmi_phy_data {
 
 struct hdmi_core_data {
void __iomem *base;
+   struct hdmi_wp_data *wp;
+   unsigned int core_pwr_cnt;
+   struct cec_adapter *adap;
 };
 
 static inline void hdmi_write_reg(void __iomem *base_addr, const u32 idx,
@@ -361,7 +365,7 @@ struct omap_hdmi {
bool audio_configured;
struct omap_dss_audio audio_config;
 
-   /* This lock should be taken when booleans bellow are touched. */
+   /* This lock should be taken when booleans below are touched. */
spinlock_t audio_playing_lock;
bool audio_playing;
bool display_enabled;
-- 
2.11.0

[PATCH 7/8] omapdrm: hdmi4_cec: add OMAP4 HDMI CEC support

[Hans Verkuil]

From: Hans Verkuil 

Add the source and header for the OMAP4 HDMI CEC support.

This code is not yet hooked up, that will happen in the next patch.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 381 
 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h |  55 +
 2 files changed, 436 insertions(+)
 create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
 create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
new file mode 100644
index ..d86873f2abe6
--- /dev/null
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
@@ -0,0 +1,381 @@
+/*
+ * HDMI CEC
+ *
+ * Based on the CEC code from hdmi_ti_4xxx_ip.c from Android.
+ *
+ * Copyright (C) 2010-2011 Texas Instruments Incorporated - http://www.ti.com/
+ * Authors: Yong Zhi
+ * Mythri pk 
+ *
+ * Heavily modified to use the linux CEC framework:
+ *
+ * Copyright 2016-2017 Cisco Systems, Inc. and/or its affiliates. All rights 
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dss.h"
+#include "hdmi.h"
+#include "hdmi4_core.h"
+#include "hdmi4_cec.h"
+
+/* HDMI CEC */
+#define HDMI_CEC_DEV_ID 0x900
+#define HDMI_CEC_SPEC   0x904
+
+/* Not really a debug register, more a low-level control register */
+#define HDMI_CEC_DBG_3  0x91C
+#define HDMI_CEC_TX_INIT0x920
+#define HDMI_CEC_TX_DEST0x924
+#define HDMI_CEC_SETUP  0x938
+#define HDMI_CEC_TX_COMMAND 0x93C
+#define HDMI_CEC_TX_OPERAND 0x940
+#define HDMI_CEC_TRANSMIT_DATA  0x97C
+#define HDMI_CEC_CA_7_0 0x988
+#define HDMI_CEC_CA_15_80x98C
+#define HDMI_CEC_INT_STATUS_0   0x998
+#define HDMI_CEC_INT_STATUS_1   0x99C
+#define HDMI_CEC_INT_ENABLE_0   0x990
+#define HDMI_CEC_INT_ENABLE_1   0x994
+#define HDMI_CEC_RX_CONTROL 0x9B0
+#define HDMI_CEC_RX_COUNT   0x9B4
+#define HDMI_CEC_RX_CMD_HEADER  0x9B8
+#define HDMI_CEC_RX_COMMAND 0x9BC
+#define HDMI_CEC_RX_OPERAND 0x9C0
+
+#define HDMI_CEC_TX_FIFO_INT_MASK  0x64
+#define HDMI_CEC_RETRANSMIT_CNT_INT_MASK   0x2
+
+#define HDMI_CORE_CEC_RETRY200
+
+static void hdmi_cec_received_msg(struct hdmi_core_data *core)
+{
+   u32 cnt = hdmi_read_reg(core->base, HDMI_CEC_RX_COUNT) & 0xff;
+
+   /* While there are CEC frames in the FIFO */
+   while (cnt & 0x70) {
+   /* and the frame doesn't have an error */
+   if (!(cnt & 0x80)) {
+   struct cec_msg msg = {};
+   unsigned int i;
+
+   /* then read the message */
+   msg.len = cnt & 0xf;
+   msg.msg[0] = hdmi_read_reg(core->base,
+  HDMI_CEC_RX_CMD_HEADER);
+   msg.msg[1] = hdmi_read_reg(core->base,
+  HDMI_CEC_RX_COMMAND);
+   for (i = 0; i < msg.len; i++) {
+   unsigned int reg = HDMI_CEC_RX_OPERAND + i * 4;
+
+   msg.msg[2 + i] =
+   hdmi_read_reg(core->base, reg);
+   }
+   msg.len += 2;
+   cec_received_msg(core->adap, );
+   }
+   /* Clear the current frame from the FIFO */
+   hdmi_write_reg(core->base, HDMI_CEC_RX_CONTROL, 1);
+   /* Wait until the current frame is cleared */
+   while (hdmi_read_reg(core->base, HDMI_CEC_RX_CONTROL) & 1)
+   udelay(1);
+   /*
+* Re-read the count register and loop to see if there are
+* more messages in the FIFO.
+*/
+   cnt = 

[PATCH 2/8] omapdrm: encoder-tpd12s015: keep ls_oe_gpio high if CEC is enabled

[Hans Verkuil]

From: Hans Verkuil 

When the OMAP4 CEC support is enabled the CEC pin should always
be on. So keep ls_oe_gpio high when CONFIG_OMAP4_DSS_HDMI_CEC
is set.

Background: even if the HPD is low it should still be possible
to use CEC. Some displays will set the HPD low when they go into standby or
when they switch to another input, but CEC is still available and able
to wake up/change input for such a display.

This is explicitly allowed by the CEC standard.

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c 
b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
index 58276a48112e..757554e6d62f 100644
--- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
+++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c
@@ -46,6 +46,9 @@ static int tpd_connect(struct omap_dss_device *dssdev,
dssdev->dst = dst;
 
gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 1);
+#ifdef CONFIG_OMAP4_DSS_HDMI_CEC
+   gpiod_set_value_cansleep(ddata->ls_oe_gpio, 1);
+#endif
/* DC-DC converter needs at max 300us to get to 90% of 5V */
udelay(300);
 
@@ -64,6 +67,7 @@ static void tpd_disconnect(struct omap_dss_device *dssdev,
return;
 
gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 0);
+   gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0);
 
dst->src = NULL;
dssdev->dst = NULL;
@@ -146,11 +150,15 @@ static int tpd_read_edid(struct omap_dss_device *dssdev,
if (!gpiod_get_value_cansleep(ddata->hpd_gpio))
return -ENODEV;
 
+#ifndef CONFIG_OMAP4_DSS_HDMI_CEC
gpiod_set_value_cansleep(ddata->ls_oe_gpio, 1);
+#endif
 
r = in->ops.hdmi->read_edid(in, edid, len);
 
+#ifndef CONFIG_OMAP4_DSS_HDMI_CEC
gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0);
+#endif
 
return r;
 }
-- 
2.11.0

[PATCH 6/8] omapdrm: hdmi4: refcount hdmi_power_on/off_core

[Hans Verkuil]

From: Hans Verkuil 

The hdmi_power_on/off_core functions can be called multiple times:
when the HPD changes and when the HDMI CEC support needs to power
the HDMI core.

So use a counter to know when to really power on or off the HDMI core.

Also call hdmi4_core_powerdown_disable() in hdmi_power_on_core() to
power up the HDMI core (needed for CEC).

Signed-off-by: Hans Verkuil 
---
 drivers/gpu/drm/omapdrm/dss/hdmi4.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c 
b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index 4a164dc01f15..e371b47ff6ff 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -124,14 +124,19 @@ static int hdmi_power_on_core(struct omap_dss_device 
*dssdev)
 {
int r;
 
+   if (hdmi.core.core_pwr_cnt++)
+   return 0;
+
r = regulator_enable(hdmi.vdda_reg);
if (r)
-   return r;
+   goto err_reg_enable;
 
r = hdmi_runtime_get();
if (r)
goto err_runtime_get;
 
+   hdmi4_core_powerdown_disable();
+
/* Make selection of HDMI in DSS */
dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
 
@@ -141,12 +146,17 @@ static int hdmi_power_on_core(struct omap_dss_device 
*dssdev)
 
 err_runtime_get:
regulator_disable(hdmi.vdda_reg);
+err_reg_enable:
+   hdmi.core.core_pwr_cnt--;
 
return r;
 }
 
 static void hdmi_power_off_core(struct omap_dss_device *dssdev)
 {
+   if (--hdmi.core.core_pwr_cnt)
+   return;
+
hdmi.core_enabled = false;
 
hdmi_runtime_put();
-- 
2.11.0

[PATCH 0/8] omapdrm: add OMAP4 CEC support

[Hans Verkuil]

From: Hans Verkuil 

This patch series adds support for the OMAP4 HDMI CEC IP core.

Most of the patches leading up to the actual CEC implementation
make changes to the HDMI core support. The reason for this is
that CEC has to be enabled even if the HPD is low: some displays will
set the HPD low when they go into standby or when they switch to another
input, but CEC is still available and able to wake up/change input for
such a display.
 
This corner case is explicitly allowed by the CEC standard, and such
displays really exist, even in modern displays.

So CEC has to be able to wake up the HDMI core, even when there is no
HPD.

I also looked at implementing CEC monitoring (i.e. 'snooping' the CEC
bus for messages between other CEC devices), but I couldn't figure
that out. The omap4 datasheet does not give sufficient information
on how it is supposed to work. There is a CEC_SN bit in CEC_DBG_3 and
a 'CEC Snoop Initiator' field in CEC_DBG_2, but no information on
how to use those registers. Trying to enable CEC_SN gave me weird
results, so I decided to leave that feature out.

Links to CEC documentation and utilities:

Public API:

https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/cec/cec-api.html

Kernel API:

https://www.linuxtv.org/downloads/v4l-dvb-apis-new/kapi/cec-core.html

CEC utilities (esp. cec-ctl):

https://git.linuxtv.org/v4l-utils.git/ (master branch)

To test:

First configure the CEC adapter as a playback device:

cec-ctl --playback

Then detect and query any other CEC devices, such as a CEC-enabled display:

cec-ctl -S

Regards,

Hans

Hans Verkuil (8):
  arm: omap4: enable CEC pin for Pandaboard A4 and ES
  omapdrm: encoder-tpd12s015: keep ls_oe_gpio high if CEC is enabled
  omapdrm: hdmi.h: extend hdmi_core_data with CEC fields
  omapdrm: hdmi4: make low-level functions available
  omapdrm: hdmi4: prepare irq handling for HDMI CEC support
  omapdrm: hdmi4: refcount hdmi_power_on/off_core
  omapdrm: hdmi4_cec: add OMAP4 HDMI CEC support
  omapdrm: hdmi4: hook up the HDMI CEC support

 arch/arm/boot/dts/omap4-panda-a4.dts   |   2 +-
 arch/arm/boot/dts/omap4-panda-es.dts   |   2 +-
 .../gpu/drm/omapdrm/displays/encoder-tpd12s015.c   |   8 +
 drivers/gpu/drm/omapdrm/dss/Kconfig|   9 +
 drivers/gpu/drm/omapdrm/dss/Makefile   |   1 +
 drivers/gpu/drm/omapdrm/dss/hdmi.h |   6 +-
 drivers/gpu/drm/omapdrm/dss/hdmi4.c|  58 +++-
 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c| 381 +
 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h|  55 +++
 drivers/gpu/drm/omapdrm/dss/hdmi4_core.c   |   6 +-
 drivers/gpu/drm/omapdrm/dss/hdmi4_core.h   |   4 +
 11 files changed, 513 insertions(+), 19 deletions(-)
 create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c
 create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h

-- 
2.11.0

Do You Received My Last Mail

[Barrister John Cliff]

Good Day

I am Barrister John Cliff, a regional managing director (A.D.B BANK)
Ouagadougou Burkina Faso, in my department we have US$9,500.
million united state dollars, to transfer into your account as a
dormant fund.If you are interested to use this fund to help the
orphans around the world contact me with my private email address at
(barr.johncliff2...@outlook.fr) and send your personal information for
more details:

Your full names
Your country of origin
Your occupation..
Your Age...
Your Mobile Number.

Best Regards
Barrister John Cliff

Re: [PATCH 2/6] drm: writeback: Add out-fences for writeback connectors

[Boris Brezillon]

On Fri, 25 Nov 2016 16:49:00 +
Brian Starkey  wrote:

> Add the OUT_FENCE_PTR property to writeback connectors, to enable
> userspace to get a fence which will signal once the writeback is
> complete. It is not allowed to request an out-fence without a
> framebuffer attached to the connector.
> 
> A timeline is added to drm_writeback_connector for use by the writeback
> out-fences.
> 
> In the case of a commit failure or DRM_MODE_ATOMIC_TEST_ONLY, the fence
> is set to -1.
> 
> Changes from v2:
>  - Rebase onto Gustavo Padovan's v9 explicit sync series
>  - Change out_fence_ptr type to s32 __user *

Don't know what happened, but I still see s32 __user * types in this
patch (I had to patch it to make in work on top of 4.11-rc1).

Re: [PATCH 1/6] drm: Add writeback connector type

[Boris Brezillon]

On Fri, 25 Nov 2016 16:48:59 +
Brian Starkey  wrote:


>  
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index b5c6a8e..6bbd93f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -86,6 +86,7 @@ struct drm_conn_prop_enum_list {
>   { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
>   { DRM_MODE_CONNECTOR_DSI, "DSI" },
>   { DRM_MODE_CONNECTOR_DPI, "DPI" },
> + { DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },

Is there a reason we have a Writeback connector, but keep using a
Virtual encoder to connect it to the CRTC? Wouldn't it make more sense
to also add a Writeback encoder?

>  };
>  
>  void drm_connector_ida_init(void)
> @@ -235,7 +236,8 @@ int drm_connector_init(struct drm_device *dev,
>   list_add_tail(>head, >connector_list);
>   config->num_connector++;
>  
> - if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL)
> + if ((connector_type != DRM_MODE_CONNECTOR_VIRTUAL) &&
> + (connector_type != DRM_MODE_CONNECTOR_WRITEBACK))

Nitpick: you don't need the extra parenthesis:

if (connector_type != DRM_MODE_CONNECTOR_VIRTUAL &&
connector_type != DRM_MODE_CONNECTOR_WRITEBACK)

>   drm_object_attach_property(>base,
> config->edid_property,
> 0);



> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 34f9741..dc4910d6 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -214,6 +214,19 @@ struct drm_connector_state {
>   struct drm_encoder *best_encoder;
>  
>   struct drm_atomic_state *state;
> +
> + /**
> +  * @writeback_job: Writeback job for writeback connectors
> +  *
> +  * Holds the framebuffer for a writeback connector. As the writeback
> +  * completion may be asynchronous to the normal commit cycle, the
> +  * writeback job lifetime is managed separately from the normal atomic
> +  * state by this object.
> +  *
> +  * See also: drm_writeback_queue_job() and
> +  * drm_writeback_signal_completion()
> +  */
> + struct drm_writeback_job *writeback_job;

Maybe I'm wrong, but is feels weird to have the writeback_job field
directly embedded in drm_connector_state, while drm_writeback_connector
inherits from drm_connector.

IMO, either you decide to directly put the drm_writeback_connector's
job_xxx fields in drm_connector and keep the drm_connector_state as is,
or you create a drm_writeback_connector_state which inherits from
drm_connector_state and embeds the writeback_job field.

Anyway, wait for Daniel's feedback before doing this change.

>  };
>  
>  /**
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index bf9991b2..3d3d07f 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -634,6 +634,20 @@ struct drm_mode_config {
>*/
>   struct drm_property *suggested_y_property;
>  
> + /**
> +  * @writeback_fb_id_property: Property for writeback connectors, storing
> +  * the ID of the output framebuffer.
> +  * See also: drm_writeback_connector_init()
> +  */
> + struct drm_property *writeback_fb_id_property;
> + /**
> +  * @writeback_pixel_formats_property: Property for writeback connectors,
> +  * storing an array of the supported pixel formats for the writeback
> +  * engine (read-only).
> +  * See also: drm_writeback_connector_init()
> +  */
> + struct drm_property *writeback_pixel_formats_property;
> +
>   /* dumb ioctl parameters */
>   uint32_t preferred_depth, prefer_shadow;
>  
> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> new file mode 100644
> index 000..6b2ac45
> --- /dev/null
> +++ b/include/drm/drm_writeback.h
> @@ -0,0 +1,78 @@
> +/*
> + * (C) COPYRIGHT 2016 ARM Limited. All rights reserved.
> + * Author: Brian Starkey 
> + *
> + * This program is free software and is provided to you under the terms of 
> the
> + * GNU General Public License version 2 as published by the Free Software
> + * Foundation, and any use by you of this program is subject to the terms
> + * of such GNU licence.
> + */
> +
> +#ifndef __DRM_WRITEBACK_H__
> +#define __DRM_WRITEBACK_H__
> +#include 
> +#include 
> +
> +struct drm_writeback_connector {
> + struct drm_connector base;

AFAIU, a writeback connector will always require an 'dummy' encoder to
make the DRM framework happy (AFAIK, a connector is always connected to
a CRTC through an encoder).

Wouldn't it make more sense to have a drm_encoder object embedded in
drm_writeback_connector so that people don't have to declare an extra
structure containing both the drm_writeback_connector connector and a
drm_encoder? Is there a good reason to keep them separate?

> +
> + /**
> +  * 

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

[Russell King - ARM Linux]

On Fri, Apr 14, 2017 at 09:56:07AM +0200, Marek Szyprowski wrote:
> >>This would be however quite large task, especially taking into account
> >>all current users of DMA-buf framework...
> >Yeah it will be a large task.
> 
> Maybe once scatterlist are switched to pfns, changing dmabuf internal
> memory representation to pfn array might be much easier.

Switching to a PFN array won't work either as we have no cross-arch
way to translate PFNs to a DMA address and vice versa.  Yes, we have
them in ARM, but they are an _implementation detail_ of ARM's
DMA API support, they are not for use by drivers.

So, the very first problem that needs solving is this:

  How do we go from a coherent DMA allocation for device X to a set
  of DMA addresses for device Y.

Essentially, we need a way of remapping the DMA buffer for use with
another device, and returning a DMA address suitable for that device.
This could well mean that we need to deal with setting up an IOMMU
mapping.  My guess is that this needs to happen at the DMA coherent
API level - the DMA coherent API needs to be augmented with support
for this.  I'll call this "DMA coherent remap".

We then need to think about how to pass this through the dma-buf API.
dma_map_sg() is done by the exporter, who should know what kind of
memory is being exported.  The exporter can avoid calling dma_map_sg()
if it knows in advance that it is exporting DMA coherent memory.
Instead, the exporter can simply create a scatterlist with the DMA
address and DMA length prepopulated with the results of the DMA
coherent remap operation above.

What the scatterlist can't carry in this case is a set of valid
struct page pointers, and an importer must not walk the scatterlist
expecting to get at the virtual address parameters or struct page
pointers.

On the mmap() side of things, remember that DMA coherent allocations
may require special mapping into userspace, and which can only be
mapped by the DMA coherent mmap support.  kmap etc will also need to
be different.  So it probably makes sense for DMA coherent dma-buf
exports to use a completely separate set of dma_buf_ops from the
streaming version.

I think this is the easiest approach to solving the problem without
needing massive driver changes all over the kernel.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH 6/6] drm: mali-dp: Add writeback connector

[Boris Brezillon]

On Fri, 25 Nov 2016 16:49:04 +
Brian Starkey  wrote:

> +static int
> +malidp_mw_encoder_atomic_check(struct drm_encoder *encoder,
> +struct drm_crtc_state *crtc_state,
> +struct drm_connector_state *conn_state)
> +{
> + struct malidp_mw_connector_state *mw_state = to_mw_state(conn_state);
> + struct malidp_drm *malidp = encoder->dev->dev_private;
> + struct drm_framebuffer *fb;
> + int i, n_planes;
> +
> + if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
> + return 0;
> +
> + fb = conn_state->writeback_job->fb;
> + if ((fb->width != crtc_state->mode.hdisplay) ||
> + (fb->height != crtc_state->mode.vdisplay)) {
> + DRM_DEBUG_KMS("Invalid framebuffer size %ux%u\n",
> + fb->width, fb->height);
> + return -EINVAL;
> + }

These checks look pretty generic to me. Shouldn't we have a default
helper doing that?

> +
> + mw_state->format =
> + malidp_hw_get_format_id(>dev->map, SE_MEMWRITE,
> + fb->pixel_format);
> + if (mw_state->format == MALIDP_INVALID_FORMAT_ID) {

Same goes here. By adding a format_types table similar to what is
exposed in drm_plane [1], we could do this check in the core. The only
thing left to the driver is the 4CC -> driver-specific-id conversion.

> + struct drm_format_name_buf format_name;
> +
> + DRM_DEBUG_KMS("Invalid pixel format %s\n",
> +   drm_get_format_name(fb->pixel_format, 
> _name));
> + return -EINVAL;
> + }
> +
> + n_planes = drm_format_num_planes(fb->pixel_format);
> + for (i = 0; i < n_planes; i++) {
> + struct drm_gem_cma_object *obj = drm_fb_cma_get_gem_obj(fb, i);
> + if (!malidp_hw_pitch_valid(malidp->dev, fb->pitches[i])) {
> + DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
> +   fb->pitches[i], i);
> + return -EINVAL;
> + }
> + mw_state->pitches[i] = fb->pitches[i];
> + mw_state->addrs[i] = obj->paddr + fb->offsets[i];
> + }
> + mw_state->n_planes = n_planes;
> +
> + return 0;
> +}


[1]http://lxr.free-electrons.com/source/include/drm/drm_plane.h#L482

Re: [RFC PATCH v3 0/6] Introduce writeback connectors

[Boris Brezillon]

Hi Brian,

On Fri, 25 Nov 2016 16:48:58 +
Brian Starkey  wrote:

> Hi,
> 
> This is v3 of my series introducing a new connector type:
>  DRM_MODE_CONNECTOR_WRITEBACK
> See v1 and v2 here: [1] [2]
> 
> Writeback connectors are used to expose the memory writeback engines
> found in some display controllers, which can write a CRTC's
> composition result to a memory buffer.
> This is useful e.g. for testing, screen-recording, screenshots,
> wireless display, display cloning, memory-to-memory composition.
> 
> Writeback connectors are given a WRITEBACK_FB_ID property (which acts
> slightly differently to FB_ID, so gets a new name), as well as
> a PIXEL_FORMATS blob to list the supported writeback formats, and
> OUT_FENCE_PTR to be used for out-fences.
> 
> The changes since v2 are in the commit messages of each commit.
> 
> The main differences are:
>  - Subclass drm_connector as drm_writeback_connector
>  - Slight relaxation of core checks, to allow
>(connector->crtc && !connector->fb)
>  - Dropped PIXEL_FORMATS_SIZE, which was redundant
>  - Reworked the event interface, drivers don't need to deal with the
>fence directly
>  - Re-ordered the commits to introduce writeback out-fences up-front.
> 
> I've kept RFC on this series because the event reporting (introduction
> of drm_writeback_job) is probably up for debate.
> 
> v4 will be accompanied by igt tests.

I plan to add writeback support to the VC4 driver and wanted to know if
anything has changed since this v3 (IOW, do you have a v4 + igt tests
ready)?

> 
> As always, I look forward to any comments.

I'll try to review these patches. Keep in mind that I didn't follow the
initial discussions and might suggest things or ask questions that have
already been answered in previous versions of this series or on IRC.

Regards,

Boris

Greetings.

[Sarah JOHNSON]

Good Day Dearest.

My name is Sarah JOHNSON I am 18 years old, the only daughter of late Mr. 
Raymond JOHNSON from Burkina Faso, I am contacting you to help me relocate to 
your country to continue my university education in  your country, before my 
father died he gave me a deposit slip document of ($7,000,000 USD) and made me 
understand that it was because of his position in the government that his 
government associates planed and poisoned him on a business trip with them to 
France and he advised me to look for a faithful and reliable foreigner who will 
help me to transfer this money to his country and help me to relocate over 
there to continue my studies.

I hope you will help me with the good faith and trust I have in you, after you 
have secured the money and settle my education, I will give you 30% of the 
money for your good and kind assistance to me. Please Contact me 
e-Mail:sarah.johnson197...@yahoo.com 

I am waiting on your reply

Regards,

Sarah.

Re: [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

[Christoph Hellwig]

On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote:
> Very straightforward conversion to the new function in all four spots.

I think the right fix here is to switch dm-crypt to the ahash API
that takes a scatterlist.

Re: [PATCH 03/22] libiscsi: Make use of new the sg_map helper function

[Christoph Hellwig]

On Thu, Apr 13, 2017 at 04:05:16PM -0600, Logan Gunthorpe wrote:
> Convert the kmap and kmap_atomic uses to the sg_map function. We now
> store the flags for the kmap instead of a boolean to indicate
> atomicitiy. We also propogate a possible kmap error down and create
> a new ISCSI_TCP_INTERNAL_ERR error type for this.

Can you split out the new error handling into a separate prep patch
which should go to the iscsi maintainers ASAP?

Re: [PATCH 01/22] scatterlist: Introduce sg_map helper functions

[Christoph Hellwig]

> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 0007b79..b95934b 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -37,6 +37,9 @@
>  
>  #include 
>  
> +/* Prevent the highmem.h macro from aliasing ops->kunmap_atomic */
> +#undef kunmap_atomic
> +
>  static inline int is_dma_buf_file(struct file *);
>  
>  struct dma_buf_list {

I think the right fix here is to rename the operation to unmap_atomic
and send out a little patch for that ASAP.

> + *   Flags can be any of:
> + *   * SG_KMAP- Use kmap to create the mapping
> + *   * SG_KMAP_ATOMIC - Use kmap_atomic to map the page atommically.
> + *  Thus, the rules of that function apply: the cpu
> + *  may not sleep until it is unmaped.
> + *
> + *   Also, consider carefully whether this function is appropriate. It is
> + *   largely not recommended for new code and if the sgl came from another
> + *   subsystem and you don't know what kind of memory might be in the list
> + *   then you definitely should not call it. Non-mappable memory may be in
> + *   the sgl and thus this function may fail unexpectedly.
> + **/
> +static inline void *sg_map_offset(struct scatterlist *sg, size_t offset,
> +int flags)

I'd rather have separate functions for kmap vs kmap_atomic instead of
the flags parameter.  And while you're at it just always pass the 0
offset parameter instead of adding a wrapper..

Otherwise this looks good to me.

Re: [PATCH] staging/media: make atomisp vlv2_plat_clock explicitly non-modular

[Greg Kroah-Hartman]

On Wed, Apr 12, 2017 at 09:57:55PM -0400, Paul Gortmaker wrote:
> The Makefile / Kconfig currently controlling compilation of this code is:
> 
> clock/Makefile:obj-$(CONFIG_INTEL_ATOMISP) += vlv2_plat_clock.o
> 
> atomisp/Kconfig:menuconfig INTEL_ATOMISP
> atomisp/Kconfig:bool "Enable support to Intel MIPI camera drivers"
> 
> ...meaning that it currently is not being built as a module by anyone.
> 
> Lets remove the modular code that is essentially orphaned, so that
> when reading the driver there is no doubt it is builtin-only.
> 
> Since module_init was already not in use by this driver, the init
> ordering remains unchanged with this commit.
> 
> Also note that MODULE_DEVICE_TABLE is a no-op for non-modular code.
> 
> We also delete the MODULE_LICENSE tag etc. since all that information
> is already contained at the top of the file in the comments.
> 
> Cc: Mauro Carvalho Chehab 
> Cc: Greg Kroah-Hartman 
> Cc: Alan Cox 
> Cc: linux-media@vger.kernel.org
> Cc: de...@driverdev.osuosl.org
> Signed-off-by: Paul Gortmaker 

I'm pretty sure we want this code to be built as a module, so maybe a
Kconfig change would resolve the issue instead?

Alan, any thoughts?

thanks,

greg k-h

Re: [PATCH 14/14] atomisp: remove UDS kernel code

[Greg KH]

On Fri, Apr 14, 2017 at 03:27:08AM +0800, kbuild test robot wrote:
> Hi Alan,
> 
> [auto build test ERROR on next-20170412]
> [cannot apply to linuxtv-media/master v4.9-rc8 v4.9-rc7 v4.9-rc6 v4.11-rc6]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Alan-Cox/staging-atomisp-use-local-variable-to-reduce-number-of-references/20170413-112312
> config: i386-allmodconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All errors (new ones prefixed by >>):
> 
> >> make[7]: *** No rule to make target 
> >> 'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/uds/uds_1.0/ia_css_uds.host.o',
> >>  needed by 'drivers/staging/media/atomisp/pci/atomisp2/atomisp.o'.
>make[7]: *** No rule to make target 
> 'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/fixedbds/fixedbds_1.0/ia_css_fixedbds.host.o',
>  needed by 'drivers/staging/media/atomisp/pci/atomisp2/atomisp.o'.
>make[7]: Target '__build' not remade because of errors.

This too is odd, are you not rebuilding everything properly when a file
is removed?  This works for me here.

thanks,

greg k-h

Re: [PATCH 12/14] atomisp: remove fixedbds kernel code

[Greg KH]

On Thu, Apr 13, 2017 at 07:53:58PM +0800, kbuild test robot wrote:
> Hi Alan,
> 
> [auto build test ERROR on next-20170412]
> [cannot apply to linuxtv-media/master v4.9-rc8 v4.9-rc7 v4.9-rc6 v4.11-rc6]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
> 
> url:
> https://github.com/0day-ci/linux/commits/Alan-Cox/staging-atomisp-use-local-variable-to-reduce-number-of-references/20170413-112312
> config: i386-allmodconfig (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386 
> 
> All errors (new ones prefixed by >>):
> 
> >> make[7]: *** No rule to make target 
> >> 'drivers/staging/media/atomisp/pci/atomisp2/css2400/isp/kernels/fixedbds/fixedbds_1.0/ia_css_fixedbds.host.o',
> >>  needed by 'drivers/staging/media/atomisp/pci/atomisp2/atomisp.o'.
>make[7]: Target '__build' not remade because of errors.

That's an odd error, this works fine for me here.

greg k-h

Re: [PATCH] arm: dma: fix sharing of coherent DMA memory without struct page

[Marek Szyprowski]

Hi Shuah,

On 2017-04-11 00:50, Shuah Khan wrote:

On 04/06/2017 06:01 AM, Marek Szyprowski wrote:

On 2017-04-05 18:02, Shuah Khan wrote:

When coherent DMA memory without struct page is shared, importer
fails to find the page and runs into kernel page fault when it
tries to dmabuf_ops_attach/map_sg/map_page the invalid page found
in the sg_table. Please see www.spinics.net/lists/stable/msg164204.html
for more information on this problem.

This solution allows coherent DMA memory without struct page to be
shared by providing a way for the exporter to tag the DMA buffer as
a special buffer without struct page association and passing the
information in sg_table to the importer. This information is used
in attach/map_sg to avoid cleaning D-cache and mapping.

The details of the change are:

Framework:
- Add a new dma_attrs field to struct scatterlist.
- Add a new DMA_ATTR_DEV_COHERENT_NOPAGE attribute to clearly identify
Coherent memory without struct page.
- Add a new dma_check_dev_coherent() interface to check if memory is
the device coherent area. There is no way to tell where the memory
returned by dma_alloc_attrs() came from.

Exporter logic:
- Add logic to vb2_dc_alloc() to call dma_check_dev_coherent() and set
DMA_ATTR_DEV_COHERENT_NOPAGE based the results of the check. This is
done in the exporter context.
- Add logic to arm_dma_get_sgtable() to identify memory without struct
page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute. If this attr is
set, arm_dma_get_sgtable() will set page as the cpu_addr and update
dma_address and dma_attrs fields in struct scatterlist for this sgl.
This is done in exporter context when buffer is exported. With this
Note: This change is made on top of Russell King's patch that added
!pfn_valid(pfn) check to arm_dma_get_sgtable() to error out on invalid
pages. Coherent memory without struct page will trigger this error.

Importer logic:
- Add logic to vb2_dc_dmabuf_ops_attach() to identify memory without
struct page using DMA_ATTR_DEV_COHERENT_NOPAGE attribute when it copies
the sg_table from the exporter. It will copy dma_attrs and dma_address
fields. With this logic, dmabuf_ops_attach will no longer trip on an
invalid page.
- Add logic to arm_dma_map_sg() to avoid mapping the page when sg_table
has DMA_ATTR_DEV_COHERENT_NOPAGE buffer.
- Add logic to arm_dma_unmap_sg() to do nothing for sg entries with
DMA_ATTR_DEV_COHERENT_NOPAGE attribute.

Without this change the following use-case that runs into kernel
pagefault when importer tries to attach the exported buffer.

With this change it works: (what a relief after watching pagefaults for
weeks!!)

gst-launch-1.0 filesrc location=~/GH3_MOV_HD.mp4 ! qtdemux ! h264parse ! 
v4l2video4dec capture-io-mode=dmabuf ! v4l2video7convert 
output-io-mode=dmabuf-import ! kmssink force-modesetting=true

I am sending RFC patch to get feedback on the approach and see if I missed
anything.

Frankly, once You decided to hack around dma-buf and issues with coherent,
carved out memory, it might be a bit better to find the ultimate solution
instead of the another hack. Please note that it will still not allow to
share a buffer allocated from carved-out memory and a device, which is
behind IOMMU.

With your patch s5p-mfc patch series does address the problem for this
use-case for 4.12 onwards. However I am still concerned about prior
release and this pagefault is bad.


Right. It should simply fail with error code instead of pagefault.


Invalid page test partially solves the problem. Would it helpful to
at least prevent the pagfault with a definitive test. Please see my
response to Russell. Let me know your thoughts on that.


I thought a bit about this and the current shape of dma-buf code.

IMHO the proper way of solving all those issues would be to replace
dma-buf internal representation of the memory from struct scatter_list
to pfn array. This would really solve the problem of buffers which
cannot be properly represented by scatter lists/struct pages and would
even allow sharing buffers between all kinds of devices. Scatter-lists
are also quite over-engineered structures to represent a single buffer
(pfn array is a bit more compact representation). Also there is a lots
of buggy code which use scatter-list in a bit creative way (like
assuming that each page maps to a single scatter list entry for
example). The only missing piece, required for such change would be
extending DMA-mapping with dma_map_pfn() interface.

I agree with you on scatterlists being clumsy. Changing over to pfn array
could simplify things. I am exploring a slightly different option that
might not require too many changes. I will respond with concrete ideas
later on this week.


It looks that a similar issue is being worked on, see the following thread:
https://lkml.org/lkml/2017/4/13/710


This would be however quite large task, especially taking into account
all current users of DMA-buf