cron job: media_tree daily build: ERRORS
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: Wed Apr 19 05:00:16 CEST 2017 media-tree git hash:ee0fe833d96793853335844b6d99fb76bd12cbeb media_build git hash: 1af19680bde3e227d64d99ff5fdc43eb343a3b28 v4l-utils git hash: b514d615166bdc0901a4c71261b87db31e89f464 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: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS 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: ERRORS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS 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: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS 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: ERRORS 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 sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [Intel-gfx] [PATCH] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro
Hi Logan, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc7 next-20170418] [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/dma-buf-Rename-dma-ops-to-prevent-conflict-with-kunmap_atomic-macro/20170419-082521 config: arm64-defconfig (attached as .config) compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm64 All errors (new ones prefixed by >>): >> drivers/gpu/drm/tegra/gem.c:115:2: error: unknown field 'map' specified in >> initializer .map = tegra_bo_kmap, ^ >> drivers/gpu/drm/tegra/gem.c:116:2: error: unknown field 'unmap' specified in >> initializer .unmap = tegra_bo_kunmap, ^ >> drivers/gpu/drm/tegra/gem.c:622:2: error: unknown field 'kmap_atomic' >> specified in initializer .kmap_atomic = tegra_gem_prime_kmap_atomic, ^ >> drivers/gpu/drm/tegra/gem.c:622:17: error: initialization from incompatible >> pointer type [-Werror=incompatible-pointer-types] .kmap_atomic = tegra_gem_prime_kmap_atomic, ^~~ drivers/gpu/drm/tegra/gem.c:622:17: note: (near initialization for 'tegra_gem_prime_dmabuf_ops.begin_cpu_access') >> drivers/gpu/drm/tegra/gem.c:623:2: error: unknown field 'kunmap_atomic' >> specified in initializer .kunmap_atomic = tegra_gem_prime_kunmap_atomic, ^ drivers/gpu/drm/tegra/gem.c:623:19: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types] .kunmap_atomic = tegra_gem_prime_kunmap_atomic, ^ drivers/gpu/drm/tegra/gem.c:623:19: note: (near initialization for 'tegra_gem_prime_dmabuf_ops.end_cpu_access') >> drivers/gpu/drm/tegra/gem.c:624:2: error: unknown field 'kmap' specified in >> initializer .kmap = tegra_gem_prime_kmap, ^ >> drivers/gpu/drm/tegra/gem.c:625:2: error: unknown field 'kunmap' specified >> in initializer .kunmap = tegra_gem_prime_kunmap, ^ cc1: some warnings being treated as errors vim +/map +115 drivers/gpu/drm/tegra/gem.c 109 .get = tegra_bo_get, 110 .put = tegra_bo_put, 111 .pin = tegra_bo_pin, 112 .unpin = tegra_bo_unpin, 113 .mmap = tegra_bo_mmap, 114 .munmap = tegra_bo_munmap, > 115 .map = tegra_bo_kmap, > 116 .unmap = tegra_bo_kunmap, 117 }; 118 119 static int tegra_bo_iommu_map(struct tegra_drm *tegra, struct tegra_bo *bo) --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH] dma-buf: Rename dma-ops to prevent conflict with kunmap_atomic macro
Seeing the kunmap_atomic dma_buf_op shares the same name with a macro
in higmem.h, the former can be aliased if any dma-buf user includes
that header.
I'm personally trying to include highmem.h inside scatterlist.h and this
breaks the dma-buf code proper.
Christoph Hellwig suggested [1] renaming it and pushing this patch ASAP.
To maintain consistency I've renamed all four of kmap* and kunmap* to be
map* and unmap*. (Even though only kmap_atomic presently conflicts.)
[1] https://www.spinics.net/lists/target-devel/msg15070.html
Signed-off-by: Logan Gunthorpe
---
drivers/dma-buf/dma-buf.c | 16
drivers/gpu/drm/armada/armada_gem.c| 8
drivers/gpu/drm/drm_prime.c| 8
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 8
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 8
drivers/gpu/drm/tegra/gem.c| 4 ++--
drivers/gpu/drm/udl/udl_dmabuf.c | 8
drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 8
drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++--
drivers/media/v4l2-core/videobuf2-dma-sg.c | 4 ++--
drivers/media/v4l2-core/videobuf2-vmalloc.c| 4 ++--
drivers/staging/android/ion/ion.c | 8
include/linux/dma-buf.h| 22 +++---
13 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 0007b79..7cc2bfe 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -405,8 +405,8 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
|| !exp_info->ops->map_dma_buf
|| !exp_info->ops->unmap_dma_buf
|| !exp_info->ops->release
- || !exp_info->ops->kmap_atomic
- || !exp_info->ops->kmap
+ || !exp_info->ops->map_atomic
+ || !exp_info->ops->map
|| !exp_info->ops->mmap)) {
return ERR_PTR(-EINVAL);
}
@@ -872,7 +872,7 @@ void *dma_buf_kmap_atomic(struct dma_buf *dmabuf, unsigned
long page_num)
{
WARN_ON(!dmabuf);
- return dmabuf->ops->kmap_atomic(dmabuf, page_num);
+ return dmabuf->ops->map_atomic(dmabuf, page_num);
}
EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
@@ -889,8 +889,8 @@ void dma_buf_kunmap_atomic(struct dma_buf *dmabuf, unsigned
long page_num,
{
WARN_ON(!dmabuf);
- if (dmabuf->ops->kunmap_atomic)
- dmabuf->ops->kunmap_atomic(dmabuf, page_num, vaddr);
+ if (dmabuf->ops->unmap_atomic)
+ dmabuf->ops->unmap_atomic(dmabuf, page_num, vaddr);
}
EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
@@ -907,7 +907,7 @@ void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long
page_num)
{
WARN_ON(!dmabuf);
- return dmabuf->ops->kmap(dmabuf, page_num);
+ return dmabuf->ops->map(dmabuf, page_num);
}
EXPORT_SYMBOL_GPL(dma_buf_kmap);
@@ -924,8 +924,8 @@ void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long
page_num,
{
WARN_ON(!dmabuf);
- if (dmabuf->ops->kunmap)
- dmabuf->ops->kunmap(dmabuf, page_num, vaddr);
+ if (dmabuf->ops->unmap)
+ dmabuf->ops->unmap(dmabuf, page_num, vaddr);
}
EXPORT_SYMBOL_GPL(dma_buf_kunmap);
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
index 1597458..d6c2a5d 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -529,10 +529,10 @@ static const struct dma_buf_ops
armada_gem_prime_dmabuf_ops = {
.map_dma_buf= armada_gem_prime_map_dma_buf,
.unmap_dma_buf = armada_gem_prime_unmap_dma_buf,
.release= drm_gem_dmabuf_release,
- .kmap_atomic= armada_gem_dmabuf_no_kmap,
- .kunmap_atomic = armada_gem_dmabuf_no_kunmap,
- .kmap = armada_gem_dmabuf_no_kmap,
- .kunmap = armada_gem_dmabuf_no_kunmap,
+ .map_atomic = armada_gem_dmabuf_no_kmap,
+ .unmap_atomic = armada_gem_dmabuf_no_kunmap,
+ .map= armada_gem_dmabuf_no_kmap,
+ .unmap = armada_gem_dmabuf_no_kunmap,
.mmap = armada_gem_dmabuf_mmap,
};
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 25aa455..48ffd25 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -402,10 +402,10 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops
= {
.map_dma_buf = drm_gem_map_dma_buf,
.unmap_dma_buf = drm_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
- .kmap = drm_gem_dmabuf_kmap,
- .kmap_atomic = drm_gem_dmabuf_kmap_atomic,
- .kunmap = drm_gem_dmabuf_kunmap,
- .kunmap_atomic = drm_gem_dmabuf_kunmap_atomic,
+ .map
[linuxtv-media:master 1530/1538] warning: (VIDEO_EM28XX_V4L2) selects VIDEO_OV2640 which has unmet direct dependencies (MEDIA_SUPPORT && ..)
tree: git://linuxtv.org/media_tree.git master head: ee0fe833d96793853335844b6d99fb76bd12cbeb commit: bb42fc4ad442d4de78b4a16233db98a5396988ff [1530/1538] [media] em28xx: add missing auto-selections for build config: x86_64-randconfig-s0-04190251 (attached as .config) compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7 reproduce: git checkout bb42fc4ad442d4de78b4a16233db98a5396988ff # save the attached .config to linux build tree make ARCH=x86_64 All warnings (new ones prefixed by >>): warning: (VIDEO_EM28XX_V4L2) selects VIDEO_OV2640 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_V4L2 && I2C && GPIOLIB && MEDIA_CAMERA_SUPPORT) --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH] rc-core: use the full 32 bits for NEC scancodes in wakefilters
The new sysfs wakefilter API will expose the difference between the NEC
protocols to userspace for no good reason and once exposed, it will be much
more difficult to change the logic.
By only allowing full NEC32 scancodes to be set, any heuristics in the kernel
can be avoided.
This is the minimalistic version of the full NEC32 patch posted here:
http://www.spinics.net/lists/linux-media/msg114603.html
Signed-off-by: David Härdeman
---
drivers/media/rc/rc-main.c | 17 -
drivers/media/rc/winbond-cir.c | 32 ++--
2 files changed, 6 insertions(+), 43 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 6ec73357fa47..8a2a2973e718 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -742,8 +742,6 @@ static int rc_validate_filter(struct rc_dev *dev,
[RC_TYPE_SONY15] = 0xff007f,
[RC_TYPE_SONY20] = 0x1fff7f,
[RC_TYPE_JVC] = 0x,
- [RC_TYPE_NEC] = 0x,
- [RC_TYPE_NECX] = 0xff,
[RC_TYPE_NEC32] = 0x,
[RC_TYPE_SANYO] = 0x1f,
[RC_TYPE_MCIR2_KBD] = 0x,
@@ -759,14 +757,9 @@ static int rc_validate_filter(struct rc_dev *dev,
enum rc_type protocol = dev->wakeup_protocol;
switch (protocol) {
+ case RC_TYPE_NEC:
case RC_TYPE_NECX:
- if s >> 16) ^ ~(s >> 8)) & 0xff) == 0)
- return -EINVAL;
- break;
- case RC_TYPE_NEC32:
- if s >> 24) ^ ~(s >> 16)) & 0xff) == 0)
- return -EINVAL;
- break;
+ return -EINVAL;
case RC_TYPE_RC6_MCE:
if ((s & 0x) != 0x800f)
return -EINVAL;
@@ -1330,7 +1323,7 @@ static ssize_t store_filter(struct device *device,
/*
* This is the list of all variants of all protocols, which is used by
* the wakeup_protocols sysfs entry. In the protocols sysfs entry some
- * some protocols are grouped together (e.g. nec = nec + necx + nec32).
+ * some protocols are grouped together.
*
* For wakeup we need to know the exact protocol variant so the hardware
* can be programmed exactly what to expect.
@@ -1345,9 +1338,7 @@ static const char * const proto_variant_names[] = {
[RC_TYPE_SONY12] = "sony-12",
[RC_TYPE_SONY15] = "sony-15",
[RC_TYPE_SONY20] = "sony-20",
- [RC_TYPE_NEC] = "nec",
- [RC_TYPE_NECX] = "nec-x",
- [RC_TYPE_NEC32] = "nec-32",
+ [RC_TYPE_NEC32] = "nec",
[RC_TYPE_SANYO] = "sanyo",
[RC_TYPE_MCIR2_KBD] = "mcir2-kbd",
[RC_TYPE_MCIR2_MSE] = "mcir2-mse",
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index 5a4d4a611197..6ef0e7232356 100644
--- a/drivers/media/rc/winbond-cir.c
+++ b/drivers/media/rc/winbond-cir.c
@@ -714,34 +714,6 @@ wbcir_shutdown(struct pnp_dev *device)
proto = IR_PROTOCOL_RC5;
break;
- case RC_TYPE_NEC:
- mask[1] = bitrev8(mask_sc);
- mask[0] = mask[1];
- mask[3] = bitrev8(mask_sc >> 8);
- mask[2] = mask[3];
-
- match[1] = bitrev8(wake_sc);
- match[0] = ~match[1];
- match[3] = bitrev8(wake_sc >> 8);
- match[2] = ~match[3];
-
- proto = IR_PROTOCOL_NEC;
- break;
-
- case RC_TYPE_NECX:
- mask[1] = bitrev8(mask_sc);
- mask[0] = mask[1];
- mask[2] = bitrev8(mask_sc >> 8);
- mask[3] = bitrev8(mask_sc >> 16);
-
- match[1] = bitrev8(wake_sc);
- match[0] = ~match[1];
- match[2] = bitrev8(wake_sc >> 8);
- match[3] = bitrev8(wake_sc >> 16);
-
- proto = IR_PROTOCOL_NEC;
- break;
-
case RC_TYPE_NEC32:
mask[0] = bitrev8(mask_sc);
mask[1] = bitrev8(mask_sc >> 8);
@@ -1087,8 +1059,8 @@ wbcir_probe(struct pnp_dev *device, const struct
pnp_device_id *dev_id)
data->dev->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
data->dev->rx_resolution = US_TO_NS(2);
data->dev->allowed_protocols = RC_BIT_ALL_IR_DECODER;
- data->dev->allowed_wakeup_protocols = RC_BIT_NEC | RC_BIT_NECX |
- RC_BIT_NEC32 | RC_BIT_RC5 | RC_BIT_RC6_0 |
+ data->dev->allowed_wakeup_protocols =
+ RC_BIT_NEC | RC_BIT_RC5 | RC_BIT_RC6_0 |
RC_BIT_RC6_6A_20 | RC_BIT_RC6_6A_24 |
RC_BIT_RC6_6A_32 | RC_BIT_RC6_MCE;
data->dev->wakeup_protocol = RC_TYPE_RC6_MCE;
Re: [PATCH 1/6] drm: Add writeback connector type
Hi Brian,
On Tue, 18 Apr 2017 18:34:43 +0100
Brian Starkey wrote:
> >> @@ -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.
>
> I did spend a decent amount of time looking at tracking the writeback
> state along with the normal connector state. I couldn't come up with
> anything I liked.
>
> As the comment mentions, one of the problems is that you have to make
> sure the relevant parts of the connector_state stay around until the
> writeback is finished. That means you've got to block before
> "swap_state()" until the previous writeback is done, and that
> effectively limits your frame rate to refresh/2.
>
> The Mali-DP HW doesn't have that limitation - we can queue up a new
> commit while the current writeback is ongoing. For that reason I
> didn't want to impose such a limitation in the framework.
>
> In v1 I allowed that by making the Mali-DP driver hold its own
> references to the relevant bits of the state for as long as it needed
> them. In v3 I moved most of that code back to the core (in part
> because Gustavo didn't like me signalling the DRM-"owned" fence from
> my driver code directly). I think the new approach of "queue_job()"
> and "signal_job()" reduces the amount of tricky code in drivers, and
> is generally more clear (also familiar, when compared to vsync
> events).
>
> I'm certain there's other ways to do it (refcount atomic states?), but
> it seemed like a biggish overhaul to achieve what would basically be
> the same thing.
>
> I was expecting each driver supporting writeback to have its own
> different requirements around writeback lifetime/duration. For example
> I think VC4 specifically came up, in that its writeback could take
> several frames, whereas on Mali-DP we either finish within the frame
> or we fail.
>
> Letting the driver manage its writeback_job lifetime seemed like a
> reasonable way to handle all that, with the documentation stating the
> only behaviour which is guaranteed to work on all drivers:
>
>* Userspace should wait for this fence to signal before making another
>* commit affecting any of the same CRTCs, Planes or Connectors.
>* **Failure to do so will result in undefined behaviour.**
>* For this reason it is strongly recommended that all userspace
>* applications making use of writeback connectors *always* retrieve an
>* out-fence for the commit and use it appropriately.
>
>
>
> ... so all of that is why the _job fields don't live in a *_state
> structure directly, and instead have to live in the separately-managed
> structure pointed to by ->writeback_job.
>
> Now, I did look at creating drm_writeback_connector_state, but as it
> would only be holding the job pointer (see above) it didn't seem worth
> scattering around the
>
> if (conn_state->connector->connector_type ==
> DRM_MODE_CONNECTOR_WRITEBACK)
>
> checks everywhere before up-casting - {clear,reset,duplicate}_state(),
> prepare_signalling(), complete_signalling(), etc. It just touched a
> lot of code for the sake of an extra pointer field in each connector
> state.
>
> I can easily revisit that part if you like.
I think there's a misunderstanding. I was just suggesting to be
consistent in the inheritance vs 'one object to handle everything'
approach.
I'm perfectly fine with embedding the writeback_job pointer directly in
drm_connector_state, but then it would IMO make more sense to do the
same for the drm_connector object (embed drm_writeback_connector fields
into drm_connector instead of making drm_writeback_connector inherit
from drm_connector).
Anyway, that's just a detail.
>
> >
> >Anyway, wait for Daniel's feedback before doing this change.
> >
>
> Am I expecting some more feedback from Daniel?
No, I was just saying that before doing the changes I was suggesting,
you should wait for Daniel's opinion, because I might be wrong.
>
> >> };
> >>
> >> /**
> >
[PATCHv4 01/12] cma: Store a name in the cma structure
Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
useful to have an explicit name attached to each region. Store the name
in each CMA structure.
Signed-off-by: Laura Abbott
---
arch/powerpc/kvm/book3s_hv_builtin.c | 3 ++-
drivers/base/dma-contiguous.c| 5 +++--
include/linux/cma.h | 4 +++-
mm/cma.c | 17 +++--
mm/cma.h | 1 +
mm/cma_debug.c | 2 +-
6 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c
b/arch/powerpc/kvm/book3s_hv_builtin.c
index 4d6c64b..b739ff8 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -100,7 +100,8 @@ void __init kvm_cma_reserve(void)
(unsigned long)selected_size / SZ_1M);
align_size = HPT_ALIGN_PAGES << PAGE_SHIFT;
cma_declare_contiguous(0, selected_size, 0, align_size,
- KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, &kvm_cma);
+ KVM_CMA_CHUNK_ORDER - PAGE_SHIFT, false, "kvm_cma",
+ &kvm_cma);
}
}
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index b55804c..ea9726e 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -165,7 +165,8 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
{
int ret;
- ret = cma_declare_contiguous(base, size, limit, 0, 0, fixed, res_cma);
+ ret = cma_declare_contiguous(base, size, limit, 0, 0, fixed,
+ "reserved", res_cma);
if (ret)
return ret;
@@ -258,7 +259,7 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
return -EINVAL;
}
- err = cma_init_reserved_mem(rmem->base, rmem->size, 0, &cma);
+ err = cma_init_reserved_mem(rmem->base, rmem->size, 0, rmem->name,
&cma);
if (err) {
pr_err("Reserved memory: unable to setup CMA region\n");
return err;
diff --git a/include/linux/cma.h b/include/linux/cma.h
index 03f32d0..d41d1f8 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -21,13 +21,15 @@ struct cma;
extern unsigned long totalcma_pages;
extern phys_addr_t cma_get_base(const struct cma *cma);
extern unsigned long cma_get_size(const struct cma *cma);
+extern const char *cma_get_name(const struct cma *cma);
extern int __init cma_declare_contiguous(phys_addr_t base,
phys_addr_t size, phys_addr_t limit,
phys_addr_t alignment, unsigned int order_per_bit,
- bool fixed, struct cma **res_cma);
+ bool fixed, const char *name, struct cma **res_cma);
extern int cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
unsigned int order_per_bit,
+ const char *name,
struct cma **res_cma);
extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int
align,
gfp_t gfp_mask);
diff --git a/mm/cma.c b/mm/cma.c
index a6033e3..43c1b2c 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -53,6 +53,11 @@ unsigned long cma_get_size(const struct cma *cma)
return cma->count << PAGE_SHIFT;
}
+const char *cma_get_name(const struct cma *cma)
+{
+ return cma->name ? cma->name : "(undefined)";
+}
+
static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
int align_order)
{
@@ -168,6 +173,7 @@ core_initcall(cma_init_reserved_areas);
*/
int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
unsigned int order_per_bit,
+const char *name,
struct cma **res_cma)
{
struct cma *cma;
@@ -198,6 +204,13 @@ int __init cma_init_reserved_mem(phys_addr_t base,
phys_addr_t size,
* subsystems (like slab allocator) are available.
*/
cma = &cma_areas[cma_area_count];
+ if (name) {
+ cma->name = name;
+ } else {
+ cma->name = kasprintf(GFP_KERNEL, "cma%d\n", cma_area_count);
+ if (!cma->name)
+ return -ENOMEM;
+ }
cma->base_pfn = PFN_DOWN(base);
cma->count = size >> PAGE_SHIFT;
cma->order_per_bit = order_per_bit;
@@ -229,7 +242,7 @@ int __init cma_init_reserved_mem(phys_addr_t base,
phys_addr_t size,
int __init cma_declare_contiguous(phys_addr_t base,
phys_addr_t size, phys_addr_t limit,
phys_addr_t alignment, unsigned int order_per_bit,
- bool fixed, struct cma **res_cma)
+ bool fixed, const char *name, struct
[PATCHv4 05/12] staging: android: ion: Break the ABI in the name of forward progress
Several of the Ion ioctls were designed in such a way that they
necessitate compat ioctls. We're breaking a bunch of other ABIs and
cleaning stuff up anyway so let's follow the ioctl guidelines and clean
things up while everyone is busy converting things over anyway. As part
of this, also remove the useless alignment field from the allocation
structure.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Makefile | 3 -
drivers/staging/android/ion/compat_ion.c | 152 ---
drivers/staging/android/ion/compat_ion.h | 29 --
drivers/staging/android/ion/ion-ioctl.c | 1 -
drivers/staging/android/ion/ion.c| 5 +-
drivers/staging/android/uapi/ion.h | 19 ++--
6 files changed, 11 insertions(+), 198 deletions(-)
delete mode 100644 drivers/staging/android/ion/compat_ion.c
delete mode 100644 drivers/staging/android/ion/compat_ion.h
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index 66d0c4a..a892afa 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -2,6 +2,3 @@ obj-$(CONFIG_ION) +=ion.o ion-ioctl.o ion_heap.o \
ion_page_pool.o ion_system_heap.o \
ion_carveout_heap.o ion_chunk_heap.o
obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
-ifdef CONFIG_COMPAT
-obj-$(CONFIG_ION) += compat_ion.o
-endif
diff --git a/drivers/staging/android/ion/compat_ion.c
b/drivers/staging/android/ion/compat_ion.c
deleted file mode 100644
index 5037ddd..000
--- a/drivers/staging/android/ion/compat_ion.c
+++ /dev/null
@@ -1,152 +0,0 @@
-/*
- * drivers/staging/android/ion/compat_ion.c
- *
- * Copyright (C) 2013 Google, Inc.
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#include
-#include
-#include
-
-#include "ion.h"
-#include "compat_ion.h"
-
-/* See drivers/staging/android/uapi/ion.h for the definition of these structs
*/
-struct compat_ion_allocation_data {
- compat_size_t len;
- compat_size_t align;
- compat_uint_t heap_id_mask;
- compat_uint_t flags;
- compat_int_t handle;
-};
-
-struct compat_ion_handle_data {
- compat_int_t handle;
-};
-
-#define COMPAT_ION_IOC_ALLOC _IOWR(ION_IOC_MAGIC, 0, \
- struct compat_ion_allocation_data)
-#define COMPAT_ION_IOC_FREE_IOWR(ION_IOC_MAGIC, 1, \
- struct compat_ion_handle_data)
-
-static int compat_get_ion_allocation_data(
- struct compat_ion_allocation_data __user *data32,
- struct ion_allocation_data __user *data)
-{
- compat_size_t s;
- compat_uint_t u;
- compat_int_t i;
- int err;
-
- err = get_user(s, &data32->len);
- err |= put_user(s, &data->len);
- err |= get_user(s, &data32->align);
- err |= put_user(s, &data->align);
- err |= get_user(u, &data32->heap_id_mask);
- err |= put_user(u, &data->heap_id_mask);
- err |= get_user(u, &data32->flags);
- err |= put_user(u, &data->flags);
- err |= get_user(i, &data32->handle);
- err |= put_user(i, &data->handle);
-
- return err;
-}
-
-static int compat_get_ion_handle_data(
- struct compat_ion_handle_data __user *data32,
- struct ion_handle_data __user *data)
-{
- compat_int_t i;
- int err;
-
- err = get_user(i, &data32->handle);
- err |= put_user(i, &data->handle);
-
- return err;
-}
-
-static int compat_put_ion_allocation_data(
- struct compat_ion_allocation_data __user *data32,
- struct ion_allocation_data __user *data)
-{
- compat_size_t s;
- compat_uint_t u;
- compat_int_t i;
- int err;
-
- err = get_user(s, &data->len);
- err |= put_user(s, &data32->len);
- err |= get_user(s, &data->align);
- err |= put_user(s, &data32->align);
- err |= get_user(u, &data->heap_id_mask);
- err |= put_user(u, &data32->heap_id_mask);
- err |= get_user(u, &data->flags);
- err |= put_user(u, &data32->flags);
- err |= get_user(i, &data->handle);
- err |= put_user(i, &data32->handle);
-
- return err;
-}
-
-long compat_ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
-{
- long ret;
-
- if (!filp->f_op->unlocked_ioctl)
- return -ENOTTY;
-
- switch (cmd) {
- case COMPAT_ION_IOC_ALLOC:
- {
- struct compat_ion_allocat
[PATCHv4 03/12] staging: android: ion: Use CMA APIs directly
When CMA was first introduced, its primary use was for DMA allocation
and the only way to get CMA memory was to call dma_alloc_coherent. This
put Ion in an awkward position since there was no device structure
readily available and setting one up messed up the coherency model.
These days, CMA can be allocated directly from the APIs. Switch to using
this model to avoid needing a dummy device. This also mitigates some of
the caching problems (e.g. dma_alloc_coherent only returning uncached
memory).
Signed-off-by: Laura Abbott
---
v4: Put some #ifdef around CMA heap functions. This is ugly but gets removed
a few patches later.
---
drivers/staging/android/ion/Kconfig| 7 +++
drivers/staging/android/ion/Makefile | 3 +-
drivers/staging/android/ion/ion_cma_heap.c | 97 --
drivers/staging/android/ion/ion_heap.c | 4 ++
4 files changed, 39 insertions(+), 72 deletions(-)
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index 206c4de..15108c4 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,3 +10,10 @@ menuconfig ION
If you're not using Android its probably safe to
say N here.
+config ION_CMA_HEAP
+ bool "Ion CMA heap support"
+ depends on ION && CMA
+ help
+ Choose this option to enable CMA heaps with Ion. This heap is backed
+ by the Contiguous Memory Allocator (CMA). If your system has these
+ regions, you should say Y here.
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index 26672a0..66d0c4a 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o \
ion_page_pool.o ion_system_heap.o \
- ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
+ ion_carveout_heap.o ion_chunk_heap.o
+obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
ifdef CONFIG_COMPAT
obj-$(CONFIG_ION) += compat_ion.o
endif
diff --git a/drivers/staging/android/ion/ion_cma_heap.c
b/drivers/staging/android/ion/ion_cma_heap.c
index d562fd7..f3e0f59 100644
--- a/drivers/staging/android/ion/ion_cma_heap.c
+++ b/drivers/staging/android/ion/ion_cma_heap.c
@@ -19,24 +19,19 @@
#include
#include
#include
-#include
+#include
+#include
#include "ion.h"
#include "ion_priv.h"
struct ion_cma_heap {
struct ion_heap heap;
- struct device *dev;
+ struct cma *cma;
};
#define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
-struct ion_cma_buffer_info {
- void *cpu_addr;
- dma_addr_t handle;
- struct sg_table *table;
-};
-
/* ION CMA heap operations functions */
static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
@@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap *heap, struct
ion_buffer *buffer,
unsigned long flags)
{
struct ion_cma_heap *cma_heap = to_cma_heap(heap);
- struct device *dev = cma_heap->dev;
- struct ion_cma_buffer_info *info;
-
- dev_dbg(dev, "Request buffer allocation len %ld\n", len);
-
- if (buffer->flags & ION_FLAG_CACHED)
- return -EINVAL;
+ struct sg_table *table;
+ struct page *pages;
+ int ret;
- info = kzalloc(sizeof(*info), GFP_KERNEL);
- if (!info)
+ pages = cma_alloc(cma_heap->cma, len, 0, GFP_KERNEL);
+ if (!pages)
return -ENOMEM;
- info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
- GFP_HIGHUSER | __GFP_ZERO);
-
- if (!info->cpu_addr) {
- dev_err(dev, "Fail to allocate buffer\n");
+ table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
+ if (!table)
goto err;
- }
- info->table = kmalloc(sizeof(*info->table), GFP_KERNEL);
- if (!info->table)
+ ret = sg_alloc_table(table, 1, GFP_KERNEL);
+ if (ret)
goto free_mem;
- if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle,
- len))
- goto free_table;
- /* keep this for memory release */
- buffer->priv_virt = info;
- buffer->sg_table = info->table;
- dev_dbg(dev, "Allocate buffer %p\n", buffer);
+ sg_set_page(table->sgl, pages, len, 0);
+
+ buffer->priv_virt = pages;
+ buffer->sg_table = table;
return 0;
-free_table:
- kfree(info->table);
free_mem:
- dma_free_coherent(dev, len, info->cpu_addr, info->handle);
+ kfree(table);
err:
- kfree(info);
+ cma_release(cma_heap->cma, pages, buffer->size);
return -ENOMEM;
}
static void ion_cma_free(struct ion_buffer *buffer)
{
struct ion_cma_heap *cma_heap = to_cma_heap(buffer->heap);
[PATCHv4 02/12] cma: Introduce cma_for_each_area
Frameworks (e.g. Ion) may want to iterate over each possible CMA area to
allow for enumeration. Introduce a function to allow a callback.
Signed-off-by: Laura Abbott
---
include/linux/cma.h | 2 ++
mm/cma.c| 14 ++
2 files changed, 16 insertions(+)
diff --git a/include/linux/cma.h b/include/linux/cma.h
index d41d1f8..3e8fbf5 100644
--- a/include/linux/cma.h
+++ b/include/linux/cma.h
@@ -34,4 +34,6 @@ extern int cma_init_reserved_mem(phys_addr_t base,
phys_addr_t size,
extern struct page *cma_alloc(struct cma *cma, size_t count, unsigned int
align,
gfp_t gfp_mask);
extern bool cma_release(struct cma *cma, const struct page *pages, unsigned
int count);
+
+extern int cma_for_each_area(int (*it)(struct cma *cma, void *data), void
*data);
#endif
diff --git a/mm/cma.c b/mm/cma.c
index 43c1b2c..978b4a1 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -504,3 +504,17 @@ bool cma_release(struct cma *cma, const struct page
*pages, unsigned int count)
return true;
}
+
+int cma_for_each_area(int (*it)(struct cma *cma, void *data), void *data)
+{
+ int i;
+
+ for (i = 0; i < cma_area_count; i++) {
+ int ret = it(&cma_areas[i], data);
+
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
--
2.7.4
[PATCHv4 04/12] staging: android: ion: Stop butchering the DMA address
Now that we have proper caching, stop setting the DMA address manually.
It should be set after properly calling dma_map.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 3d979ef5..65638f5 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -81,8 +81,7 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap
*heap,
{
struct ion_buffer *buffer;
struct sg_table *table;
- struct scatterlist *sg;
- int i, ret;
+ int ret;
buffer = kzalloc(sizeof(*buffer), GFP_KERNEL);
if (!buffer)
@@ -119,20 +118,6 @@ static struct ion_buffer *ion_buffer_create(struct
ion_heap *heap,
INIT_LIST_HEAD(&buffer->vmas);
INIT_LIST_HEAD(&buffer->attachments);
mutex_init(&buffer->lock);
- /*
-* this will set up dma addresses for the sglist -- it is not
-* technically correct as per the dma api -- a specific
-* device isn't really taking ownership here. However, in practice on
-* our systems the only dma_address space is physical addresses.
-* Additionally, we can't afford the overhead of invalidating every
-* allocation via dma_map_sg. The implicit contract here is that
-* memory coming from the heaps is ready for dma, ie if it has a
-* cached mapping that mapping has been invalidated
-*/
- for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i) {
- sg_dma_address(sg) = sg_phys(sg);
- sg_dma_len(sg) = sg->length;
- }
mutex_lock(&dev->buffer_lock);
ion_buffer_add(dev, buffer);
mutex_unlock(&dev->buffer_lock);
--
2.7.4
[PATCHv4 06/12] staging: android: ion: Get rid of ion_phys_addr_t
Once upon a time, phys_addr_t was not everywhere in the kernel. These
days it is used enough places that having a separate Ion type doesn't
make sense. Remove the extra type and just use phys_addr_t directly.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.h | 12 ++--
drivers/staging/android/ion/ion_carveout_heap.c | 10 +-
drivers/staging/android/ion/ion_chunk_heap.c| 6 +++---
drivers/staging/android/ion/ion_heap.c | 4 ++--
4 files changed, 12 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index 3b4bff5..e8a6ffe 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -28,14 +28,6 @@ struct ion_mapper;
struct ion_client;
struct ion_buffer;
-/*
- * This should be removed some day when phys_addr_t's are fully
- * plumbed in the kernel, and all instances of ion_phys_addr_t should
- * be converted to phys_addr_t. For the time being many kernel interfaces
- * do not accept phys_addr_t's that would have to
- */
-#define ion_phys_addr_t unsigned long
-
/**
* struct ion_platform_heap - defines a heap in the given platform
* @type: type of the heap from ion_heap_type enum
@@ -53,9 +45,9 @@ struct ion_platform_heap {
enum ion_heap_type type;
unsigned int id;
const char *name;
- ion_phys_addr_t base;
+ phys_addr_t base;
size_t size;
- ion_phys_addr_t align;
+ phys_addr_t align;
void *priv;
};
diff --git a/drivers/staging/android/ion/ion_carveout_heap.c
b/drivers/staging/android/ion/ion_carveout_heap.c
index e0e360f..1419a89 100644
--- a/drivers/staging/android/ion/ion_carveout_heap.c
+++ b/drivers/staging/android/ion/ion_carveout_heap.c
@@ -30,10 +30,10 @@
struct ion_carveout_heap {
struct ion_heap heap;
struct gen_pool *pool;
- ion_phys_addr_t base;
+ phys_addr_t base;
};
-static ion_phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
+static phys_addr_t ion_carveout_allocate(struct ion_heap *heap,
unsigned long size)
{
struct ion_carveout_heap *carveout_heap =
@@ -46,7 +46,7 @@ static ion_phys_addr_t ion_carveout_allocate(struct ion_heap
*heap,
return offset;
}
-static void ion_carveout_free(struct ion_heap *heap, ion_phys_addr_t addr,
+static void ion_carveout_free(struct ion_heap *heap, phys_addr_t addr,
unsigned long size)
{
struct ion_carveout_heap *carveout_heap =
@@ -63,7 +63,7 @@ static int ion_carveout_heap_allocate(struct ion_heap *heap,
unsigned long flags)
{
struct sg_table *table;
- ion_phys_addr_t paddr;
+ phys_addr_t paddr;
int ret;
table = kmalloc(sizeof(*table), GFP_KERNEL);
@@ -96,7 +96,7 @@ static void ion_carveout_heap_free(struct ion_buffer *buffer)
struct ion_heap *heap = buffer->heap;
struct sg_table *table = buffer->sg_table;
struct page *page = sg_page(table->sgl);
- ion_phys_addr_t paddr = PFN_PHYS(page_to_pfn(page));
+ phys_addr_t paddr = PFN_PHYS(page_to_pfn(page));
ion_heap_buffer_zero(buffer);
diff --git a/drivers/staging/android/ion/ion_chunk_heap.c
b/drivers/staging/android/ion/ion_chunk_heap.c
index 46e13f6..606f25f 100644
--- a/drivers/staging/android/ion/ion_chunk_heap.c
+++ b/drivers/staging/android/ion/ion_chunk_heap.c
@@ -27,7 +27,7 @@
struct ion_chunk_heap {
struct ion_heap heap;
struct gen_pool *pool;
- ion_phys_addr_t base;
+ phys_addr_t base;
unsigned long chunk_size;
unsigned long size;
unsigned long allocated;
@@ -151,8 +151,8 @@ struct ion_heap *ion_chunk_heap_create(struct
ion_platform_heap *heap_data)
chunk_heap->heap.ops = &chunk_heap_ops;
chunk_heap->heap.type = ION_HEAP_TYPE_CHUNK;
chunk_heap->heap.flags = ION_HEAP_FLAG_DEFER_FREE;
- pr_debug("%s: base %lu size %zu \n", __func__,
-chunk_heap->base, heap_data->size);
+ pr_debug("%s: base %pa size %zu \n", __func__,
+&chunk_heap->base, heap_data->size);
return &chunk_heap->heap;
diff --git a/drivers/staging/android/ion/ion_heap.c
b/drivers/staging/android/ion/ion_heap.c
index 66f8fc5..c974623 100644
--- a/drivers/staging/android/ion/ion_heap.c
+++ b/drivers/staging/android/ion/ion_heap.c
@@ -345,9 +345,9 @@ struct ion_heap *ion_heap_create(struct ion_platform_heap
*heap_data)
}
if (IS_ERR_OR_NULL(heap)) {
- pr_err("%s: error creating heap %s type %d base %lu size %zu\n",
+ pr_err("%s: error creating heap %s type %d base %pa size %zu\n",
__func__, heap_data->name, heap_data->type,
- heap_data->base, heap_data->size);
+ &heap_data->base, heap_data->size);
[PATCHv4 07/12] staging: android: ion: Collapse internal header files
Ion current has ion_priv.h and ion.h as header files. ion.h was intended
to be used for public APIs but Ion never ended up really having anything
public. Combine the two headers so there is only one internal header.
Signed-off-by: Laura Abbott
---
v4: minor cleanup suggested by Emil Velikov
---
drivers/staging/android/ion/ion-ioctl.c | 1 -
drivers/staging/android/ion/ion.c | 1 -
drivers/staging/android/ion/ion.h | 479
drivers/staging/android/ion/ion_carveout_heap.c | 1 -
drivers/staging/android/ion/ion_chunk_heap.c| 1 -
drivers/staging/android/ion/ion_cma_heap.c | 1 -
drivers/staging/android/ion/ion_heap.c | 1 -
drivers/staging/android/ion/ion_page_pool.c | 3 +-
drivers/staging/android/ion/ion_priv.h | 453 --
drivers/staging/android/ion/ion_system_heap.c | 1 -
10 files changed, 402 insertions(+), 540 deletions(-)
delete mode 100644 drivers/staging/android/ion/ion_priv.h
diff --git a/drivers/staging/android/ion/ion-ioctl.c
b/drivers/staging/android/ion/ion-ioctl.c
index 91b5c2b..4e7bf16 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -19,7 +19,6 @@
#include
#include "ion.h"
-#include "ion_priv.h"
union ion_ioctl_arg {
struct ion_fd_data fd;
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index fbab1e3..e1fb865 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -39,7 +39,6 @@
#include
#include "ion.h"
-#include "ion_priv.h"
bool ion_buffer_cached(struct ion_buffer *buffer)
{
diff --git a/drivers/staging/android/ion/ion.h
b/drivers/staging/android/ion/ion.h
index e8a6ffe..fd49403 100644
--- a/drivers/staging/android/ion/ion.h
+++ b/drivers/staging/android/ion/ion.h
@@ -14,24 +14,26 @@
*
*/
-#ifndef _LINUX_ION_H
-#define _LINUX_ION_H
+#ifndef _ION_H
+#define _ION_H
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
#include
+#include
#include "../uapi/ion.h"
-struct ion_handle;
-struct ion_device;
-struct ion_heap;
-struct ion_mapper;
-struct ion_client;
-struct ion_buffer;
-
/**
* struct ion_platform_heap - defines a heap in the given platform
* @type: type of the heap from ion_heap_type enum
- * @id:unique identifier for heap. When allocating higher
numbers
+ * @id:unique identifier for heap. When allocating higher
numb ers
* will be allocated from first. At allocation these are passed
* as a bit mask and therefore can not exceed ION_NUM_HEAP_IDS.
* @name: used for debug purposes
@@ -52,114 +54,433 @@ struct ion_platform_heap {
};
/**
- * struct ion_platform_data - array of platform heaps passed from board file
- * @nr:number of structures in the array
- * @heaps: array of platform_heap structions
+ * struct ion_buffer - metadata for a particular buffer
+ * @ref: reference count
+ * @node: node in the ion_device buffers tree
+ * @dev: back pointer to the ion_device
+ * @heap: back pointer to the heap the buffer came from
+ * @flags: buffer specific flags
+ * @private_flags: internal buffer specific flags
+ * @size: size of the buffer
+ * @priv_virt: private data to the buffer representable as
+ * a void *
+ * @lock: protects the buffers cnt fields
+ * @kmap_cnt: number of times the buffer is mapped to the kernel
+ * @vaddr: the kernel mapping if kmap_cnt is not zero
+ * @sg_table: the sg table for the buffer if dmap_cnt is not zero
+ * @pages: flat array of pages in the buffer -- used by fault
+ * handler and only valid for buffers that are faulted in
+ * @vmas: list of vma's mapping this buffer
+ * @handle_count: count of handles referencing this buffer
+ * @task_comm: taskcomm of last client to reference this buffer in a
+ * handle, used for debugging
+ * @pid: pid of last client to reference this buffer in a
+ * handle, used for debugging
+ */
+struct ion_buffer {
+ struct kref ref;
+ union {
+ struct rb_node node;
+ struct list_head list;
+ };
+ struct ion_device *dev;
+ struct ion_heap *heap;
+ unsigned long flags;
+ unsigned long private_flags;
+ size_t size;
+ void *priv_virt;
+ struct mutex lock;
+ int kmap_cnt;
+ void *vaddr;
+ struct sg_table *sg_table;
+ struct page **pages;
+ struct list_head vmas;
+ struct list_head attachments;
+ /* used to track orphaned buffers */
+ int handle_count;
+ char task_comm[TASK_COMM_LEN];
+ pid_t pid;
+};
+v
[PATCHv4 09/12] staging: android: ion: Drop ion_map_kernel interface
Nobody uses this interface externally. Drop it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion.c | 59 ---
1 file changed, 59 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 7d40233..5a82bea 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -424,22 +424,6 @@ static void *ion_buffer_kmap_get(struct ion_buffer *buffer)
return vaddr;
}
-static void *ion_handle_kmap_get(struct ion_handle *handle)
-{
- struct ion_buffer *buffer = handle->buffer;
- void *vaddr;
-
- if (handle->kmap_cnt) {
- handle->kmap_cnt++;
- return buffer->vaddr;
- }
- vaddr = ion_buffer_kmap_get(buffer);
- if (IS_ERR(vaddr))
- return vaddr;
- handle->kmap_cnt++;
- return vaddr;
-}
-
static void ion_buffer_kmap_put(struct ion_buffer *buffer)
{
buffer->kmap_cnt--;
@@ -462,49 +446,6 @@ static void ion_handle_kmap_put(struct ion_handle *handle)
ion_buffer_kmap_put(buffer);
}
-void *ion_map_kernel(struct ion_client *client, struct ion_handle *handle)
-{
- struct ion_buffer *buffer;
- void *vaddr;
-
- mutex_lock(&client->lock);
- if (!ion_handle_validate(client, handle)) {
- pr_err("%s: invalid handle passed to map_kernel.\n",
- __func__);
- mutex_unlock(&client->lock);
- return ERR_PTR(-EINVAL);
- }
-
- buffer = handle->buffer;
-
- if (!handle->buffer->heap->ops->map_kernel) {
- pr_err("%s: map_kernel is not implemented by this heap.\n",
- __func__);
- mutex_unlock(&client->lock);
- return ERR_PTR(-ENODEV);
- }
-
- mutex_lock(&buffer->lock);
- vaddr = ion_handle_kmap_get(handle);
- mutex_unlock(&buffer->lock);
- mutex_unlock(&client->lock);
- return vaddr;
-}
-EXPORT_SYMBOL(ion_map_kernel);
-
-void ion_unmap_kernel(struct ion_client *client, struct ion_handle *handle)
-{
- struct ion_buffer *buffer;
-
- mutex_lock(&client->lock);
- buffer = handle->buffer;
- mutex_lock(&buffer->lock);
- ion_handle_kmap_put(handle);
- mutex_unlock(&buffer->lock);
- mutex_unlock(&client->lock);
-}
-EXPORT_SYMBOL(ion_unmap_kernel);
-
static struct mutex debugfs_mutex;
static struct rb_root *ion_root_client;
static int is_client_alive(struct ion_client *client)
--
2.7.4
[PATCHv4 12/12] staging/android: Update Ion TODO list
Most of the items have been taken care of by a clean up series. Remove the completed items and add a few new ones. Signed-off-by: Laura Abbott --- drivers/staging/android/TODO | 21 - 1 file changed, 4 insertions(+), 17 deletions(-) diff --git a/drivers/staging/android/TODO b/drivers/staging/android/TODO index 8f3ac37..5f14247 100644 --- a/drivers/staging/android/TODO +++ b/drivers/staging/android/TODO @@ -7,23 +7,10 @@ TODO: ion/ - - Remove ION_IOC_SYNC: Flushing for devices should be purely a kernel internal - interface on top of dma-buf. flush_for_device needs to be added to dma-buf - first. - - Remove ION_IOC_CUSTOM: Atm used for cache flushing for cpu access in some - vendor trees. Should be replaced with an ioctl on the dma-buf to expose the - begin/end_cpu_access hooks to userspace. - - Clarify the tricks ion plays with explicitly managing coherency behind the - dma api's back (this is absolutely needed for high-perf gpu drivers): Add an - explicit coherency management mode to flush_for_device to be used by drivers - which want to manage caches themselves and which indicates whether cpu caches - need flushing. - - With those removed there's probably no use for ION_IOC_IMPORT anymore either - since ion would just be the central allocator for shared buffers. - - Add dt-binding to expose cma regions as ion heaps, with the rule that any - such cma regions must already be used by some device for dma. I.e. ion only - exposes existing cma regions and doesn't reserve unecessarily memory when - booting a system which doesn't use ion. + - Add dt-bindings for remaining heaps (chunk and carveout heaps). This would + involve putting appropriate bindings in a memory node for Ion to find. + - Split /dev/ion up into multiple nodes (e.g. /dev/ion/heap0) + - Better test framework (integration with VGEM was suggested) Please send patches to Greg Kroah-Hartman and Cc: Arve Hjønnevåg and Riley Andrews -- 2.7.4
[PATCHv4 10/12] staging: android: ion: Remove ion_handle and ion_client
ion_handle was introduced as an abstraction to represent a reference to
a buffer via an ion_client. As frameworks outside of Ion evolved, the dmabuf
emerged as the preferred standard for use in the kernel. This has made
the ion_handle an unnecessary abstraction and prone to race
conditions. ion_client is also now only used internally. We have enough
mechanisms for race conditions and leaks already so just drop ion_handle
and ion_client. This also includes ripping out most of the debugfs
infrastructure since much of that was tied to clients and handles.
The debugfs infrastructure was prone to give confusing data (orphaned
allocations) so it can be replaced with something better if people
actually want it.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/ion-ioctl.c | 53 +--
drivers/staging/android/ion/ion.c | 701 ++--
drivers/staging/android/ion/ion.h | 77 +---
drivers/staging/android/uapi/ion.h | 25 +-
4 files changed, 51 insertions(+), 805 deletions(-)
diff --git a/drivers/staging/android/ion/ion-ioctl.c
b/drivers/staging/android/ion/ion-ioctl.c
index 4e7bf16..76427e4 100644
--- a/drivers/staging/android/ion/ion-ioctl.c
+++ b/drivers/staging/android/ion/ion-ioctl.c
@@ -21,9 +21,7 @@
#include "ion.h"
union ion_ioctl_arg {
- struct ion_fd_data fd;
struct ion_allocation_data allocation;
- struct ion_handle_data handle;
struct ion_heap_query query;
};
@@ -48,8 +46,6 @@ static int validate_ioctl_arg(unsigned int cmd, union
ion_ioctl_arg *arg)
static unsigned int ion_ioctl_dir(unsigned int cmd)
{
switch (cmd) {
- case ION_IOC_FREE:
- return _IOC_WRITE;
default:
return _IOC_DIR(cmd);
}
@@ -57,8 +53,6 @@ static unsigned int ion_ioctl_dir(unsigned int cmd)
long ion_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
- struct ion_client *client = filp->private_data;
- struct ion_handle *cleanup_handle = NULL;
int ret = 0;
unsigned int dir;
union ion_ioctl_arg data;
@@ -86,61 +80,28 @@ long ion_ioctl(struct file *filp, unsigned int cmd,
unsigned long arg)
switch (cmd) {
case ION_IOC_ALLOC:
{
- struct ion_handle *handle;
+ int fd;
- handle = ion_alloc(client, data.allocation.len,
+ fd = ion_alloc(data.allocation.len,
data.allocation.heap_id_mask,
data.allocation.flags);
- if (IS_ERR(handle))
- return PTR_ERR(handle);
+ if (fd < 0)
+ return fd;
- data.allocation.handle = handle->id;
+ data.allocation.fd = fd;
- cleanup_handle = handle;
- break;
- }
- case ION_IOC_FREE:
- {
- struct ion_handle *handle;
-
- mutex_lock(&client->lock);
- handle = ion_handle_get_by_id_nolock(client,
-data.handle.handle);
- if (IS_ERR(handle)) {
- mutex_unlock(&client->lock);
- return PTR_ERR(handle);
- }
- ion_free_nolock(client, handle);
- ion_handle_put_nolock(handle);
- mutex_unlock(&client->lock);
- break;
- }
- case ION_IOC_SHARE:
- {
- struct ion_handle *handle;
-
- handle = ion_handle_get_by_id(client, data.handle.handle);
- if (IS_ERR(handle))
- return PTR_ERR(handle);
- data.fd.fd = ion_share_dma_buf_fd(client, handle);
- ion_handle_put(handle);
- if (data.fd.fd < 0)
- ret = data.fd.fd;
break;
}
case ION_IOC_HEAP_QUERY:
- ret = ion_query_heaps(client, &data.query);
+ ret = ion_query_heaps(&data.query);
break;
default:
return -ENOTTY;
}
if (dir & _IOC_READ) {
- if (copy_to_user((void __user *)arg, &data, _IOC_SIZE(cmd))) {
- if (cleanup_handle)
- ion_free(client, cleanup_handle);
+ if (copy_to_user((void __user *)arg, &data, _IOC_SIZE(cmd)))
return -EFAULT;
- }
}
return ret;
}
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 5a82bea..9eeb06f 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -90,7 +90,6 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap
*heap,
buffer->heap = heap;
buffer->flags = flags;
- kref_init(&buffer->ref);
ret = heap->ops->allocate(heap,
[PATCHv4 08/12] staging: android: ion: Rework heap registration/enumeration
The current model of Ion heap registration is based on the outdated
model of board files. The replacement for board files (devicetree)
isn't a good replacement for what Ion wants to do. In actuality, Ion
wants to show what memory is available in the system for something else
to figure out what to use. Switch to a model where Ion creates its
device unconditionally and heaps are registed as available regions.
Currently, only system and CMA heaps are converted over to the new
model. Carveout and chunk heaps can be converted over when someone wants
to figure out how.
Signed-off-by: Laura Abbott
---
drivers/staging/android/ion/Kconfig | 25 +
drivers/staging/android/ion/Makefile| 7 +--
drivers/staging/android/ion/ion.c | 28 +-
drivers/staging/android/ion/ion.h | 40 +-
drivers/staging/android/ion/ion_carveout_heap.c | 10
drivers/staging/android/ion/ion_chunk_heap.c| 9
drivers/staging/android/ion/ion_cma_heap.c | 24 +++--
drivers/staging/android/ion/ion_heap.c | 71 -
drivers/staging/android/ion/ion_system_heap.c | 38 -
9 files changed, 85 insertions(+), 167 deletions(-)
diff --git a/drivers/staging/android/ion/Kconfig
b/drivers/staging/android/ion/Kconfig
index 15108c4..a517b2d 100644
--- a/drivers/staging/android/ion/Kconfig
+++ b/drivers/staging/android/ion/Kconfig
@@ -10,6 +10,31 @@ menuconfig ION
If you're not using Android its probably safe to
say N here.
+config ION_SYSTEM_HEAP
+ bool "Ion system heap"
+ depends on ION
+ help
+ Choose this option to enable the Ion system heap. The system heap
+ is backed by pages from the buddy allocator. If in doubt, say Y.
+
+config ION_CARVEOUT_HEAP
+ bool "Ion carveout heap support"
+ depends on ION
+ help
+ Choose this option to enable carveout heaps with Ion. Carveout heaps
+ are backed by memory reserved from the system. Allocation times are
+ typically faster at the cost of memory not being used. Unless you
+ know your system has these regions, you should say N here.
+
+config ION_CHUNK_HEAP
+ bool "Ion chunk heap support"
+ depends on ION
+ help
+ Choose this option to enable chunk heaps with Ion. This heap is
+ similar in function the carveout heap but memory is broken down
+ into smaller chunk sizes, typically corresponding to a TLB size.
+ Unless you know your system has these regions, you should say N here.
+
config ION_CMA_HEAP
bool "Ion CMA heap support"
depends on ION && CMA
diff --git a/drivers/staging/android/ion/Makefile
b/drivers/staging/android/ion/Makefile
index a892afa..eb7eeed 100644
--- a/drivers/staging/android/ion/Makefile
+++ b/drivers/staging/android/ion/Makefile
@@ -1,4 +1,5 @@
-obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o \
- ion_page_pool.o ion_system_heap.o \
- ion_carveout_heap.o ion_chunk_heap.o
+obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o
+obj-$(CONFIG_ION_SYSTEM_HEAP) += ion_system_heap.o ion_page_pool.o
+obj-$(CONFIG_ION_CARVEOUT_HEAP) += ion_carveout_heap.o
+obj-$(CONFIG_ION_CHUNK_HEAP) += ion_chunk_heap.o
obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index e1fb865..7d40233 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -40,6 +40,9 @@
#include "ion.h"
+static struct ion_device *internal_dev;
+static int heap_id = 0;
+
bool ion_buffer_cached(struct ion_buffer *buffer)
{
return !!(buffer->flags & ION_FLAG_CACHED);
@@ -1198,9 +1201,10 @@ static int debug_shrink_get(void *data, u64 *val)
DEFINE_SIMPLE_ATTRIBUTE(debug_shrink_fops, debug_shrink_get,
debug_shrink_set, "%llu\n");
-void ion_device_add_heap(struct ion_device *dev, struct ion_heap *heap)
+void ion_device_add_heap(struct ion_heap *heap)
{
struct dentry *debug_file;
+ struct ion_device *dev = internal_dev;
if (!heap->ops->allocate || !heap->ops->free)
pr_err("%s: can not add heap with invalid ops struct.\n",
@@ -1217,6 +1221,7 @@ void ion_device_add_heap(struct ion_device *dev, struct
ion_heap *heap)
heap->dev = dev;
down_write(&dev->lock);
+ heap->id = heap_id++;
/*
* use negative heap->id to reverse the priority -- when traversing
* the list later attempt higher id numbers first
@@ -1256,14 +1261,14 @@ void ion_device_add_heap(struct ion_device *dev, struct
ion_heap *heap)
}
EXPORT_SYMBOL(ion_device_add_heap);
-struct ion_device *ion_device_create(void)
+int ion_device_create(void)
{
struct ion_device *idev;
int ret;
idev = kzalloc(sizeof(*idev), GFP_KERNEL);
if (!idev)
- return
[PATCHv4 11/12] staging: android: ion: Set query return value
This never got set in the ioctl. Properly set a return value of 0 on success. Signed-off-by: Laura Abbott --- drivers/staging/android/ion/ion.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c index 9eeb06f..d6fd350 100644 --- a/drivers/staging/android/ion/ion.c +++ b/drivers/staging/android/ion/ion.c @@ -498,6 +498,7 @@ int ion_query_heaps(struct ion_heap_query *query) } query->cnt = cnt; + ret = 0; out: up_read(&dev->lock); return ret; -- 2.7.4
[PATCHv4 00/12] Ion cleanup in preparation for moving out of staging
Hi, This is v4 of the series to cleanup to Ion. Greg took some of the patches that weren't CMA related already. There was a minor bisectability problem with the CMA APIs so this is a new version to address that. I also addressed some minor comments on the patch to collapse header files. Thanks, Laura Laura Abbott (12): cma: Store a name in the cma structure cma: Introduce cma_for_each_area staging: android: ion: Use CMA APIs directly staging: android: ion: Stop butchering the DMA address staging: android: ion: Break the ABI in the name of forward progress staging: android: ion: Get rid of ion_phys_addr_t staging: android: ion: Collapse internal header files staging: android: ion: Rework heap registration/enumeration staging: android: ion: Drop ion_map_kernel interface staging: android: ion: Remove ion_handle and ion_client staging: android: ion: Set query return value staging/android: Update Ion TODO list arch/powerpc/kvm/book3s_hv_builtin.c| 3 +- drivers/base/dma-contiguous.c | 5 +- drivers/staging/android/TODO| 21 +- drivers/staging/android/ion/Kconfig | 32 + drivers/staging/android/ion/Makefile| 11 +- drivers/staging/android/ion/compat_ion.c| 152 - drivers/staging/android/ion/compat_ion.h| 29 - drivers/staging/android/ion/ion-ioctl.c | 55 +- drivers/staging/android/ion/ion.c | 812 ++-- drivers/staging/android/ion/ion.h | 386 --- drivers/staging/android/ion/ion_carveout_heap.c | 21 +- drivers/staging/android/ion/ion_chunk_heap.c| 16 +- drivers/staging/android/ion/ion_cma_heap.c | 120 ++-- drivers/staging/android/ion/ion_heap.c | 68 -- drivers/staging/android/ion/ion_page_pool.c | 3 +- drivers/staging/android/ion/ion_priv.h | 453 - drivers/staging/android/ion/ion_system_heap.c | 39 +- drivers/staging/android/uapi/ion.h | 36 +- include/linux/cma.h | 6 +- mm/cma.c| 31 +- mm/cma.h| 1 + mm/cma_debug.c | 2 +- 22 files changed, 524 insertions(+), 1778 deletions(-) delete mode 100644 drivers/staging/android/ion/compat_ion.c delete mode 100644 drivers/staging/android/ion/compat_ion.h delete mode 100644 drivers/staging/android/ion/ion_priv.h -- 2.7.4
Re: [PATCH 6/6] drm: mali-dp: Add writeback connector
On Fri, Apr 14, 2017 at 11:47:00AM +0200, Boris Brezillon wrote:
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?
Yeah makes sense. These should be common to everyone until
cropping/scaling support is added.
+
+ mw_state->format =
+ malidp_hw_get_format_id(&malidp->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.
Yeah could do, but given our driver requires us to run through the
whole table to get the HW ID anyway it seemed like totally wasted
effort to do the same thing in the core.
It's probably a negligible overhead, but it's also unnecessary for
100% of the current writeback implementations ;-)
If a different driver is implemented such that the HW ID lookup isn't
an exhaustive list search then we could add a helper for them to use
which checks the blob.
Cheers,
-Brian
+ struct drm_format_name_buf format_name;
+
+ DRM_DEBUG_KMS("Invalid pixel format %s\n",
+ drm_get_format_name(fb->pixel_format,
&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: [PATCH 2/6] drm: writeback: Add out-fences for writeback connectors
On Fri, Apr 14, 2017 at 12:11:14PM +0200, Boris Brezillon wrote: 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). Yeah this really confused me too when rebasing. Given that this patch predates Gustavo's change to s32 I can only assume I typo'd and meant s64 in this commit message. -Brian
Re: [PATCH 1/6] drm: Add writeback connector type
Hi Boris,
On Fri, Apr 14, 2017 at 12:08:23PM +0200, Boris Brezillon wrote:
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?
Only that a writeback connector is functionally and conceptually quite
different from the existing connector types, whereas the "encoder"
(which realistically only exists because the framework forces it to)
acts pretty much like any other.
};
void drm_connector_ida_init(void)
@@ -235,7 +236,8 @@ int drm_connector_init(struct drm_device *dev,
list_add_tail(&connector->head, &config->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)
Yeah fair enough, I can drop them.
drm_object_attach_property(&connector->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.
I did spend a decent amount of time looking at tracking the writeback
state along with the normal connector state. I couldn't come up with
anything I liked.
As the comment mentions, one of the problems is that you have to make
sure the relevant parts of the connector_state stay around until the
writeback is finished. That means you've got to block before
"swap_state()" until the previous writeback is done, and that
effectively limits your frame rate to refresh/2.
The Mali-DP HW doesn't have that limitation - we can queue up a new
commit while the current writeback is ongoing. For that reason I
didn't want to impose such a limitation in the framework.
In v1 I allowed that by making the Mali-DP driver hold its own
references to the relevant bits of the state for as long as it needed
them. In v3 I moved most of that code back to the core (in part
because Gustavo didn't like me signalling the DRM-"owned" fence from
my driver code directly). I think the new approach of "queue_job()"
and "signal_job()" reduces the amount of tricky code in drivers, and
is generally more clear (also familiar, when compared to vsync
events).
I'm certain there's other ways to do it (refcount atomic states?), but
it seemed like a biggish overhaul to achieve what would basically be
the same thing.
I was expecting each driver supporting writeback to have its own
different requirements around writeback lifetime/duration. For example
I think VC4 specifically came up, in that its writeback could take
several frames, whereas on Mali-DP we either finish within the frame
or we fail.
Letting the driver manage its writeback_job lifetime seemed like a
reasonable way to handle all that, with the documentation stating the
only behaviour which is guaranteed to work on all drivers:
* Userspace should wait for this fence to signal before making another
* commit affecting any of the same CRTCs, Planes or Connectors.
* **Failure to do so will result in und
Re: [RFC PATCH v3 0/6] Introduce writeback connectors
Hi Boris, On Fri, Apr 14, 2017 at 11:35:17AM +0200, Boris Brezillon wrote: 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)? Oh that's good to hear. I've got a v4 (just rebased for the most part), but was holding off sending it until having some "proper" userspace to support it. Unfortunately in the meantime we've had some team changes which mean I'm not really able to work on it to move things forward - Liviu might be able to pick this up. I'll collect together what I have and send it out anyway. It includes some functional tests in igt, but I'm not sure if that meets the "new uapi needs userspace" bar. 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. Thanks, -Brian Regards, Boris
[PATCH v3] [media] uvcvideo: Add iFunction or iInterface to device names.
Permits distinguishing between two /dev/videoX entries from the same
physical UVC device (that naturally share the same iProduct name).
This change matches current Windows behavior by prioritizing iFunction
over iInterface, but unlike Windows it displays both iProduct and
iFunction/iInterface strings when both are available.
Signed-off-by: Peter Boström
---
drivers/media/usb/uvc/uvc_driver.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 04bf35063c4c..5676d916933d 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1998,6 +1998,7 @@ static int uvc_probe(struct usb_interface *intf,
{
struct usb_device *udev = interface_to_usbdev(intf);
struct uvc_device *dev;
+ int additional_name;
int ret;
if (id->idVendor && id->idProduct)
@@ -2029,9 +2030,26 @@ static int uvc_probe(struct usb_interface *intf,
strlcpy(dev->name, udev->product, sizeof dev->name);
else
snprintf(dev->name, sizeof dev->name,
- "UVC Camera (%04x:%04x)",
- le16_to_cpu(udev->descriptor.idVendor),
- le16_to_cpu(udev->descriptor.idProduct));
+"UVC Camera (%04x:%04x)",
+le16_to_cpu(udev->descriptor.idVendor),
+le16_to_cpu(udev->descriptor.idProduct));
+
+ /*
+* Add iFunction or iInterface to names when available as additional
+* distinguishers between interfaces. iFunction is prioritized over
+* iInterface which matches Windows behavior at the point of writing.
+*/
+ additional_name = intf->cur_altsetting->desc.iInterface;
+ if (intf->intf_assoc && intf->intf_assoc->iFunction != 0)
+ additional_name = intf->intf_assoc->iFunction;
+ if (additional_name != 0) {
+ size_t len;
+
+ strlcat(dev->name, ": ", sizeof(dev->name));
+ len = strlen(dev->name);
+ usb_string(udev, additional_name, dev->name + len,
+ sizeof(dev->name) - len);
+ }
/* Parse the Video Class control descriptor. */
if (uvc_parse_control(dev) < 0) {
--
2.12.2.816.g281164-goog
RE: [PATCH v3 5/7] doc_rst: media: New SDR formats PC16, PC18 & PC20
Hi Laurent,
Thanks for the review comments.
> On Tuesday 07 Feb 2017 15:02:35 Ramesh Shanmugasundaram wrote:
> > This patch adds documentation for the three new SDR formats
> >
> > V4L2_SDR_FMT_PCU16BE
> > V4L2_SDR_FMT_PCU18BE
> > V4L2_SDR_FMT_PCU20BE
> >
> > Signed-off-by: Ramesh Shanmugasundaram
> > ---
> > .../media/uapi/v4l/pixfmt-sdr-pcu16be.rst | 55
> +++
> > .../media/uapi/v4l/pixfmt-sdr-pcu18be.rst | 55
> +++
> > .../media/uapi/v4l/pixfmt-sdr-pcu20be.rst | 54
> +++
> > Documentation/media/uapi/v4l/sdr-formats.rst | 3 ++
> > 4 files changed, 167 insertions(+)
> > create mode 100644
> > Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
> > create mode 100644
> > Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
> > create mode 100644
> > Documentation/media/uapi/v4l/pixfmt-sdr-pcu20be.rst
> >
> > diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
> > b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst new file mode
> > 100644 index 000..2de1b1a
> > --- /dev/null
> > +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu16be.rst
> > @@ -0,0 +1,55 @@
> > +.. -*- coding: utf-8; mode: rst -*-
> > +
> > +.. _V4L2-SDR-FMT-PCU16BE:
> > +
> > +**
> > +V4L2_SDR_FMT_PCU16BE ('PC16')
> > +**
> > +
> > +Planar complex unsigned 16-bit big endian IQ sample
> > +
> > +Description
> > +===
> > +
> > +This format contains a sequence of complex number samples. Each
> > +complex number consist of two parts called In-phase and Quadrature
> > +(IQ). Both I and Q are represented as a 16 bit unsigned big endian
> > +number stored in
> > +32 bit space. The remaining unused bits within the 32 bit space will
> > +be padded with 0. I value starts first and Q value starts at an
> > +offset equalling half of the buffer size (i.e.) offset =
> > +buffersize/2. Out of the 16 bits, bit 15:2 (14 bit) is data and bit
> > +1:0 (2 bit) can be any value.
>
> This sounds very strange to me. Are the two lower bits always random ?
> What is that used for ?
It could be zeros or it could be status bits in case of MAX2175 (if enabled). I
mentioned any value because the user app does not have any assumptions on these
bits value.
>
> > +**Byte Order.**
> > +Each cell is one byte.
> > +
> > +.. flat-table::
> > +:header-rows: 1
> > +:stub-columns: 0
> > +
> > +* - Offset:
> > + - Byte B0
> > + - Byte B1
> > + - Byte B2
> > + - Byte B3
> > +* - start + 0:
> > + - I'\ :sub:`0[13:6]`
> > + - I'\ :sub:`0[5:0]; B1[1:0]=pad`
> > + - pad
> > + - pad
> > +* - start + 4:
> > + - I'\ :sub:`1[13:6]`
> > + - I'\ :sub:`1[5:0]; B1[1:0]=pad`
> > + - pad
> > + - pad
> > +* - ...
> > +* - start + offset:
> > + - Q'\ :sub:`0[13:6]`
> > + - Q'\ :sub:`0[5:0]; B1[1:0]=pad`
> > + - pad
> > + - pad
> > +* - start + offset + 4:
> > + - Q'\ :sub:`1[13:6]`
> > + - Q'\ :sub:`1[5:0]; B1[1:0]=pad`
> > + - pad
> > + - pad
> > diff --git a/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
> > b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst new file mode
> > 100644 index 000..da8b26b
> > --- /dev/null
> > +++ b/Documentation/media/uapi/v4l/pixfmt-sdr-pcu18be.rst
> > @@ -0,0 +1,55 @@
> > +.. -*- coding: utf-8; mode: rst -*-
> > +
> > +.. _V4L2-SDR-FMT-PCU18BE:
> > +
> > +**
> > +V4L2_SDR_FMT_PCU18BE ('PC18')
> > +**
> > +
> > +Planar complex unsigned 18-bit big endian IQ sample
> > +
> > +Description
> > +===
> > +
> > +This format contains a sequence of complex number samples. Each
> > +complex number consist of two parts called In-phase and Quadrature
> > +(IQ). Both I and Q are represented as a 18 bit unsigned big endian
> > +number stored in
> > +32 bit space. The remaining unused bits within the 32 bit space will
> > +be padded with 0. I value starts first and Q value starts at an
> > +offset equalling half of the buffer size (i.e.) offset =
> > +buffersize/2. Out of the 18 bits, bit 17:2 (16 bit) is data and bit
> > +1:0 (2 bit) can be any value.
> > +
> > +**Byte Order.**
> > +Each cell is one byte.
> > +
> > +.. flat-table::
> > +:header-rows: 1
> > +:stub-columns: 0
> > +
> > +* - Offset:
> > + - Byte B0
> > + - Byte B1
> > + - Byte B2
> > + - Byte B3
> > +* - start + 0:
> > + - I'\ :sub:`0[17:10]`
> > + - I'\ :sub:`0[9:2]`
> > + - I'\ :sub:`0[1:0]; B2[5:0]=pad`
> > + - pad
> > +* - start + 4:
> > + - I'\ :sub:`1[17:10]`
> > + - I'\ :sub:`1[9:2]`
> > + - I'\ :sub:`1[1:0]; B2[5:0]=pad`
> > + - pad
> > +* - ...
> > +* - start + offset:
> > + - Q'\ :sub:`0[17:10]`
> > + - Q'\ :sub:`0[9:2]`
> > + - Q'\ :sub:`0[1:0]; B2[5:0]=pad`
> > + - pa
RE: [PATCH v3 7/7] media: platform: rcar_drif: Add DRIF support
Hi Laurent, Many thanks for your time & the review comments. I have agreed to most of the comments and a few need further discussion. Could you please take a look at those? > On Tuesday 07 Feb 2017 15:02:37 Ramesh Shanmugasundaram wrote: > > This patch adds Digital Radio Interface (DRIF) support to R-Car Gen3 > SoCs. > > The driver exposes each instance of DRIF as a V4L2 SDR device. A DRIF > > device represents a channel and each channel can have one or two > > sub-channels respectively depending on the target board. > > > > DRIF supports only Rx functionality. It receives samples from a RF > > frontend tuner chip it is interfaced with. The combination of DRIF and > > the tuner device, which is registered as a sub-device, determines the > > receive sample rate and format. > > > > In order to be compliant as a V4L2 SDR device, DRIF needs to bind with > > the tuner device, which can be provided by a third party vendor. DRIF > > acts as a slave device and the tuner device acts as a master > > transmitting the samples. The driver allows asynchronous binding of a > > tuner device that is registered as a v4l2 sub-device. The driver can > > learn about the tuner it is interfaced with based on port endpoint > > properties of the device in device tree. The V4L2 SDR device inherits > > the controls exposed by the tuner device. > > > > The device can also be configured to use either one or both of the > > data pins at runtime based on the master (tuner) configuration. > > > > Signed-off-by: Ramesh Shanmugasundaram > > > > --- > > drivers/media/platform/Kconfig | 25 + > > drivers/media/platform/Makefile|1 + > > drivers/media/platform/rcar_drif.c | 1534 > > + > > 3 files changed, 1560 insertions(+) > > create mode 100644 drivers/media/platform/rcar_drif.c > > [snip] > > > diff --git a/drivers/media/platform/rcar_drif.c > > b/drivers/media/platform/rcar_drif.c new file mode 100644 index > > 000..88950e3 > > --- /dev/null > > +++ b/drivers/media/platform/rcar_drif.c > > @@ -0,0 +1,1534 @@ > > [snip] > > > +/* > > + * The R-Car DRIF is a receive only MSIOF like controller with an > > + * external master device driving the SCK. It receives data into a > > +FIFO, > > + * then this driver uses the SYS-DMAC engine to move the data from > > + * the device to memory. > > + * > > + * Each DRIF channel DRIFx (as per datasheet) contains two internal > > + * channels DRIFx0 & DRIFx1 within itself with each having its own > > resources > > + * like module clk, register set, irq and dma. These internal > > + channels > > share > > + * common CLK & SYNC from master. The two data pins D0 & D1 shall be > > + * considered to represent the two internal channels. This internal > > + split > > + * is not visible to the master device. > > + * > > + * Depending on the master device, a DRIF channel can use > > + * (1) both internal channels (D0 & D1) to receive data in parallel > > + (or) > > + * (2) one internal channel (D0 or D1) to receive data > > + * > > + * The primary design goal of this controller is to act as Digitial > > + Radio > > s/Digitial/Digital/ Agreed > > > + * Interface that receives digital samples from a tuner device. Hence > > + the > > + * driver exposes the device as a V4L2 SDR device. In order to > > + qualify as > > + * a V4L2 SDR device, it should possess tuner interface as mandated > > + by the > > + * framework. This driver expects a tuner driver (sub-device) to bind > > + * asynchronously with this device and the combined drivers shall > > + expose > > + * a V4L2 compliant SDR device. The DRIF driver is independent of the > > + * tuner vendor. > > + * > > + * The DRIF h/w can support I2S mode and Frame start synchronization > > + pulse > > mode. > > + * This driver is tested for I2S mode only because of the > > + availability of > > + * suitable master devices. Hence, not all configurable options of > > + DRIF h/w > > + * like lsb/msb first, syncdl, dtdl etc. are exposed via DT and I2S > > defaults > > + * are used. These can be exposed later if needed after testing. > > + */ > > [snip] > > > +#define to_rcar_drif_buf_pair(sdr, ch_num, > > idx)(sdr->ch[!(ch_num)]->buf[idx]) > > You should enclose both sdr and idx in parenthesis, as they can be > expressions. Agreed. > > > + > > +#define for_each_rcar_drif_channel(ch, ch_mask)\ > > + for_each_set_bit(ch, ch_mask, RCAR_DRIF_MAX_CHANNEL) > > + > > +static const unsigned int num_hwbufs = 32; > > Is there a specific reason to make this a static const instead of a > #define ? Just style only. The #define needs a RCAR_DRIF_ prefix and I used this value in few places. The #define makes the statements longer. > > > +/* Debug */ > > +static unsigned int debug; > > +module_param(debug, uint, 0644); > > +MODULE_PARM_DESC(debug, "activate debug info"); > > + > > +#define rdrif_dbg(level, sdr, fmt, arg...) \ > > + v4l2_dbg(level, debug, &sdr->
Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function
On 18/04/17 09:50 AM, Konrad Rzeszutek Wilk wrote: > I am not sure if you know, but you can add on each patch the respective > maintainer via 'CC'. That way you can have certain maintainers CCed only > on the subsystems they cover. You put it after (or before) your SoB and > git send-email happilly picks it up. Yes, but I've seen some maintainers complain when they receive a patch with no context (ie. cover letter and first patch). So I chose to do it this way. I expect in this situation, no matter what you do, someone is going to complain about the approach chosen. Thanks anyway for the tip. Logan
[PATCH] rc-core: use the full 32 bits for NEC scancodes
Using the full 32 bits for all kinds of NEC scancodes simplifies rc-core
and the nec decoder without any loss of functionality. At the same time
it ensures that scancodes for NEC16/NEC24/NEC32 do not overlap and
removes lots of duplication (as you can see from the patch, the same NEC
disambiguation logic is contained in several different drivers).
Using NEC32 also removes ambiguity. For example, consider these two NEC
messages:
NEC16 message to address 0x05, command 0x03
NEC24 message to address 0x0005, command 0x03
They'll both have scancode 0x0503, and there's no way to tell which
message was received.
In order to maintain backwards compatibility, some heuristics are added
in rc-main.c to convert scancodes to NEC32 as necessary when userspace
adds entries to the keytable using the regular input ioctls. These
heuristics are essentially the same as the ones that are currently in
drivers/media/rc/img-ir/img-ir-nec.c (which are rendered unecessary
with this patch).
The reason this has to be done now is that the newer sysfs wakefilter API
will expose the difference between the NEC protocols to userspace for no
good reason and once exposed, it will be much more difficult to change the
logic.
Signed-off-by: David Härdeman
---
drivers/media/rc/igorplugusb.c |4 +
drivers/media/rc/img-ir/img-ir-nec.c | 92 +++---
drivers/media/rc/ir-nec-decoder.c| 63 ---
drivers/media/rc/rc-main.c | 74 ---
drivers/media/rc/winbond-cir.c | 32 +---
5 files changed, 89 insertions(+), 176 deletions(-)
diff --git a/drivers/media/pci/cx88/cx88-input.c
b/drivers/media/pci/cx88/cx88-input.c
index 01f2e472a2a0..61c46763ac97 100644
--- a/drivers/media/pci/cx88/cx88-input.c
+++ b/drivers/media/pci/cx88/cx88-input.c
@@ -146,7 +146,7 @@ static void cx88_ir_handle_key(struct cx88_IR *ir)
scancode = RC_SCANCODE_NECX(addr, cmd);
if (0 == (gpio & ir->mask_keyup))
- rc_keydown_notimeout(ir->dev, RC_TYPE_NECX, scancode,
+ rc_keydown_notimeout(ir->dev, RC_TYPE_NEC, scancode,
0);
else
rc_keyup(ir->dev);
@@ -348,7 +348,7 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev
*pci)
* 002-T mini RC, provided with newer PV hardware
*/
ir_codes = RC_MAP_PIXELVIEW_MK12;
- rc_type = RC_BIT_NECX;
+ rc_type = RC_BIT_NEC;
ir->gpio_addr = MO_GP1_IO;
ir->mask_keyup = 0x80;
ir->polling = 10; /* ms */
diff --git a/drivers/media/pci/saa7134/saa7134-input.c
b/drivers/media/pci/saa7134/saa7134-input.c
index 78849c19f68a..47d8e055ddd3 100644
--- a/drivers/media/pci/saa7134/saa7134-input.c
+++ b/drivers/media/pci/saa7134/saa7134-input.c
@@ -338,7 +338,7 @@ static int get_key_beholdm6xx(struct IR_i2c *ir, enum
rc_type *protocol,
if (data[9] != (unsigned char)(~data[8]))
return 0;
- *protocol = RC_TYPE_NECX;
+ *protocol = RC_TYPE_NEC;
*scancode = RC_SCANCODE_NECX(data[11] << 8 | data[10], data[9]);
*toggle = 0;
return 1;
@@ -1028,7 +1028,7 @@ void saa7134_probe_i2c_ir(struct saa7134_dev *dev)
dev->init_data.name = "BeholdTV";
dev->init_data.get_key = get_key_beholdm6xx;
dev->init_data.ir_codes = RC_MAP_BEHOLD;
- dev->init_data.type = RC_BIT_NECX;
+ dev->init_data.type = RC_BIT_NEC;
info.addr = 0x2d;
break;
case SAA7134_BOARD_AVERMEDIA_CARDBUS_501:
diff --git a/drivers/media/rc/igorplugusb.c b/drivers/media/rc/igorplugusb.c
index cb6d4f1247da..9e3119c94368 100644
--- a/drivers/media/rc/igorplugusb.c
+++ b/drivers/media/rc/igorplugusb.c
@@ -203,8 +203,8 @@ static int igorplugusb_probe(struct usb_interface *intf,
* for the NEC protocol and many others.
*/
rc->allowed_protocols = RC_BIT_ALL_IR_DECODER & ~(RC_BIT_NEC |
- RC_BIT_NECX | RC_BIT_NEC32 | RC_BIT_RC6_6A_20 |
- RC_BIT_RC6_6A_24 | RC_BIT_RC6_6A_32 | RC_BIT_RC6_MCE |
+ RC_BIT_RC6_6A_20 | RC_BIT_RC6_6A_24 |
+ RC_BIT_RC6_6A_32 | RC_BIT_RC6_MCE |
RC_BIT_SONY20 | RC_BIT_SANYO);
rc->priv = ir;
diff --git a/drivers/media/rc/img-ir/img-ir-nec.c
b/drivers/media/rc/img-ir/img-ir-nec.c
index 044fd42b22a0..56159bb44f9c 100644
--- a/drivers/media/rc/img-ir/img-ir-nec.c
+++ b/drivers/media/rc/img-ir/img-ir-nec.c
@@ -28,28 +28,15 @@ static int img_ir_nec_scancode(int len, u64 raw, u64
enabled_protocols,
addr_inv = (raw >> 8) & 0xff;
data = (raw >> 16) & 0xff;
data_inv = (raw >> 24) & 0xff;
- if ((data_inv ^ data) != 0xff) {
- /* 32-bit NEC (
Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function
On Tue, Apr 18, 2017 at 09:42:20AM -0600, Logan Gunthorpe wrote:
>
>
> On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote:
> > Interesting that you didn't CC any of the maintainers. Could you
> > do that in the future please?
>
> Please read the cover letter. The distribution list for the patchset
> would have been way too large to cc every maintainer (even as limited as
> it was, I had mailing lists yelling at me). My plan was to get buy in
I am not sure if you know, but you can add on each patch the respective
maintainer via 'CC'. That way you can have certain maintainers CCed only
on the subsystems they cover. You put it after (or before) your SoB and
git send-email happilly picks it up.
It does mean that for every patch you have to run something like this:
$ more add_cc
#!/bin/bash
git diff HEAD^.. > /tmp/a
echo "---"
scripts/get_maintainer.pl --no-l /tmp/a | while read file
do
echo "Cc: $file"
done
Or such.
> for the first patch, get it merged and resend the rest independently to
> their respective maintainers. Of course, though, I'd be open to other
> suggestions.
>
> >>>
> >>> Signed-off-by: Logan Gunthorpe
> >>> ---
> >>> drivers/block/xen-blkfront.c | 33 +++--
> >>> 1 file changed, 27 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> >>> index 5067a0a..7dcf41d 100644
> >>> --- a/drivers/block/xen-blkfront.c
> >>> +++ b/drivers/block/xen-blkfront.c
> >>> @@ -807,8 +807,19 @@ static int blkif_queue_rw_req(struct request *req,
> >>> struct blkfront_ring_info *ri
> >>> BUG_ON(sg->offset + sg->length > PAGE_SIZE);
> >>>
> >>> if (setup.need_copy) {
> >>> - setup.bvec_off = sg->offset;
> >>> - setup.bvec_data = kmap_atomic(sg_page(sg));
> >>> + setup.bvec_off = 0;
> >>> + setup.bvec_data = sg_map(sg, SG_KMAP_ATOMIC);
> >>> + if (IS_ERR(setup.bvec_data)) {
> >>> + /*
> >>> + * This should really never happen unless
> >>> + * the code is changed to use memory that is
> >>> + * not mappable in the sg. Seeing there is a
> >>> + * questionable error path out of here,
> >>> + * we WARN.
> >>> + */
> >>> + WARN(1, "Non-mappable memory used in sg!");
> >>> + return 1;
> >>> + }
> >> ...
> >>
> >> Perhaps add a flag to mark failure as 'unexpected' and trace (and panic?)
> >> inside sg_map().
>
> Thanks, that's a good suggestion. I'll make the change for v2.
>
> Logan
Re: [PATCH 05/22] drm/i915: Make use of the new sg_map helper function
On 18/04/17 12:44 AM, Daniel Vetter wrote: > On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote: >> This is a single straightforward conversion from kmap to sg_map. >> >> Signed-off-by: Logan Gunthorpe > > Acked-by: Daniel Vetter > > Probably makes sense to merge through some other tree, but please be aware > of the considerable churn rate in i915 (i.e. make sure your tree is in > linux-next before you send a pull request for this). Plane B would be to > get the prep patch in first and then merge the i915 conversion one kernel > release later. Yes, as per what I said in my cover letter, I was leaning towards a "Plan B" style approach. Logan
Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function
On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote:
> Interesting that you didn't CC any of the maintainers. Could you
> do that in the future please?
Please read the cover letter. The distribution list for the patchset
would have been way too large to cc every maintainer (even as limited as
it was, I had mailing lists yelling at me). My plan was to get buy in
for the first patch, get it merged and resend the rest independently to
their respective maintainers. Of course, though, I'd be open to other
suggestions.
>>>
>>> Signed-off-by: Logan Gunthorpe
>>> ---
>>> drivers/block/xen-blkfront.c | 33 +++--
>>> 1 file changed, 27 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
>>> index 5067a0a..7dcf41d 100644
>>> --- a/drivers/block/xen-blkfront.c
>>> +++ b/drivers/block/xen-blkfront.c
>>> @@ -807,8 +807,19 @@ static int blkif_queue_rw_req(struct request *req,
>>> struct blkfront_ring_info *ri
>>> BUG_ON(sg->offset + sg->length > PAGE_SIZE);
>>>
>>> if (setup.need_copy) {
>>> - setup.bvec_off = sg->offset;
>>> - setup.bvec_data = kmap_atomic(sg_page(sg));
>>> + setup.bvec_off = 0;
>>> + setup.bvec_data = sg_map(sg, SG_KMAP_ATOMIC);
>>> + if (IS_ERR(setup.bvec_data)) {
>>> + /*
>>> +* This should really never happen unless
>>> +* the code is changed to use memory that is
>>> +* not mappable in the sg. Seeing there is a
>>> +* questionable error path out of here,
>>> +* we WARN.
>>> +*/
>>> + WARN(1, "Non-mappable memory used in sg!");
>>> + return 1;
>>> + }
>> ...
>>
>> Perhaps add a flag to mark failure as 'unexpected' and trace (and panic?)
>> inside sg_map().
Thanks, that's a good suggestion. I'll make the change for v2.
Logan
Re: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function
On Tue, Apr 18, 2017 at 02:13:59PM +, David Laight wrote:
> From: Logan Gunthorpe
> > Sent: 13 April 2017 23:05
> > Straightforward conversion to the new helper, except due to
> > the lack of error path, we have to warn if unmapable memory
> > is ever present in the sgl.
Interesting that you didn't CC any of the maintainers. Could you
do that in the future please?
> >
> > Signed-off-by: Logan Gunthorpe
> > ---
> > drivers/block/xen-blkfront.c | 33 +++--
> > 1 file changed, 27 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> > index 5067a0a..7dcf41d 100644
> > --- a/drivers/block/xen-blkfront.c
> > +++ b/drivers/block/xen-blkfront.c
> > @@ -807,8 +807,19 @@ static int blkif_queue_rw_req(struct request *req,
> > struct blkfront_ring_info *ri
> > BUG_ON(sg->offset + sg->length > PAGE_SIZE);
> >
> > if (setup.need_copy) {
> > - setup.bvec_off = sg->offset;
> > - setup.bvec_data = kmap_atomic(sg_page(sg));
> > + setup.bvec_off = 0;
> > + setup.bvec_data = sg_map(sg, SG_KMAP_ATOMIC);
> > + if (IS_ERR(setup.bvec_data)) {
> > + /*
> > +* This should really never happen unless
> > +* the code is changed to use memory that is
> > +* not mappable in the sg. Seeing there is a
> > +* questionable error path out of here,
> > +* we WARN.
> > +*/
> > + WARN(1, "Non-mappable memory used in sg!");
> > + return 1;
> > + }
> ...
>
> Perhaps add a flag to mark failure as 'unexpected' and trace (and panic?)
> inside sg_map().
>
> David
>
>
> ___
> Linux-nvdimm mailing list
> linux-nvd...@lists.01.org
> https://lists.01.org/mailman/listinfo/linux-nvdimm
RE: [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function
From: Logan Gunthorpe
> Sent: 13 April 2017 23:05
> Straightforward conversion to the new helper, except due to
> the lack of error path, we have to warn if unmapable memory
> is ever present in the sgl.
>
> Signed-off-by: Logan Gunthorpe
> ---
> drivers/block/xen-blkfront.c | 33 +++--
> 1 file changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 5067a0a..7dcf41d 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -807,8 +807,19 @@ static int blkif_queue_rw_req(struct request *req,
> struct blkfront_ring_info *ri
> BUG_ON(sg->offset + sg->length > PAGE_SIZE);
>
> if (setup.need_copy) {
> - setup.bvec_off = sg->offset;
> - setup.bvec_data = kmap_atomic(sg_page(sg));
> + setup.bvec_off = 0;
> + setup.bvec_data = sg_map(sg, SG_KMAP_ATOMIC);
> + if (IS_ERR(setup.bvec_data)) {
> + /*
> + * This should really never happen unless
> + * the code is changed to use memory that is
> + * not mappable in the sg. Seeing there is a
> + * questionable error path out of here,
> + * we WARN.
> + */
> + WARN(1, "Non-mappable memory used in sg!");
> + return 1;
> + }
...
Perhaps add a flag to mark failure as 'unexpected' and trace (and panic?)
inside sg_map().
David
Re: [PATCHv3 13/22] staging: android: ion: Use CMA APIs directly
On Mon, Apr 03, 2017 at 11:57:55AM -0700, Laura Abbott wrote:
> When CMA was first introduced, its primary use was for DMA allocation
> and the only way to get CMA memory was to call dma_alloc_coherent. This
> put Ion in an awkward position since there was no device structure
> readily available and setting one up messed up the coherency model.
> These days, CMA can be allocated directly from the APIs. Switch to using
> this model to avoid needing a dummy device. This also mitigates some of
> the caching problems (e.g. dma_alloc_coherent only returning uncached
> memory).
>
> Signed-off-by: Laura Abbott
> ---
> drivers/staging/android/ion/Kconfig| 7 +++
> drivers/staging/android/ion/Makefile | 3 +-
> drivers/staging/android/ion/ion_cma_heap.c | 97
> --
> 3 files changed, 35 insertions(+), 72 deletions(-)
>
> diff --git a/drivers/staging/android/ion/Kconfig
> b/drivers/staging/android/ion/Kconfig
> index 206c4de..15108c4 100644
> --- a/drivers/staging/android/ion/Kconfig
> +++ b/drivers/staging/android/ion/Kconfig
> @@ -10,3 +10,10 @@ menuconfig ION
> If you're not using Android its probably safe to
> say N here.
>
> +config ION_CMA_HEAP
> + bool "Ion CMA heap support"
> + depends on ION && CMA
> + help
> + Choose this option to enable CMA heaps with Ion. This heap is backed
> + by the Contiguous Memory Allocator (CMA). If your system has these
> + regions, you should say Y here.
> diff --git a/drivers/staging/android/ion/Makefile
> b/drivers/staging/android/ion/Makefile
> index 26672a0..66d0c4a 100644
> --- a/drivers/staging/android/ion/Makefile
> +++ b/drivers/staging/android/ion/Makefile
> @@ -1,6 +1,7 @@
> obj-$(CONFIG_ION) += ion.o ion-ioctl.o ion_heap.o \
> ion_page_pool.o ion_system_heap.o \
> - ion_carveout_heap.o ion_chunk_heap.o ion_cma_heap.o
> + ion_carveout_heap.o ion_chunk_heap.o
> +obj-$(CONFIG_ION_CMA_HEAP) += ion_cma_heap.o
> ifdef CONFIG_COMPAT
> obj-$(CONFIG_ION) += compat_ion.o
> endif
> diff --git a/drivers/staging/android/ion/ion_cma_heap.c
> b/drivers/staging/android/ion/ion_cma_heap.c
> index d562fd7..f3e0f59 100644
> --- a/drivers/staging/android/ion/ion_cma_heap.c
> +++ b/drivers/staging/android/ion/ion_cma_heap.c
> @@ -19,24 +19,19 @@
> #include
> #include
> #include
> -#include
> +#include
> +#include
>
> #include "ion.h"
> #include "ion_priv.h"
>
> struct ion_cma_heap {
> struct ion_heap heap;
> - struct device *dev;
> + struct cma *cma;
> };
>
> #define to_cma_heap(x) container_of(x, struct ion_cma_heap, heap)
>
> -struct ion_cma_buffer_info {
> - void *cpu_addr;
> - dma_addr_t handle;
> - struct sg_table *table;
> -};
> -
>
> /* ION CMA heap operations functions */
> static int ion_cma_allocate(struct ion_heap *heap, struct ion_buffer *buffer,
> @@ -44,93 +39,53 @@ static int ion_cma_allocate(struct ion_heap *heap, struct
> ion_buffer *buffer,
> unsigned long flags)
> {
> struct ion_cma_heap *cma_heap = to_cma_heap(heap);
> - struct device *dev = cma_heap->dev;
> - struct ion_cma_buffer_info *info;
> -
> - dev_dbg(dev, "Request buffer allocation len %ld\n", len);
> -
> - if (buffer->flags & ION_FLAG_CACHED)
> - return -EINVAL;
> + struct sg_table *table;
> + struct page *pages;
> + int ret;
>
> - info = kzalloc(sizeof(*info), GFP_KERNEL);
> - if (!info)
> + pages = cma_alloc(cma_heap->cma, len, 0, GFP_KERNEL);
> + if (!pages)
> return -ENOMEM;
>
> - info->cpu_addr = dma_alloc_coherent(dev, len, &(info->handle),
> - GFP_HIGHUSER | __GFP_ZERO);
> -
> - if (!info->cpu_addr) {
> - dev_err(dev, "Fail to allocate buffer\n");
> + table = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
> + if (!table)
> goto err;
> - }
>
> - info->table = kmalloc(sizeof(*info->table), GFP_KERNEL);
> - if (!info->table)
> + ret = sg_alloc_table(table, 1, GFP_KERNEL);
> + if (ret)
> goto free_mem;
>
> - if (dma_get_sgtable(dev, info->table, info->cpu_addr, info->handle,
> - len))
> - goto free_table;
> - /* keep this for memory release */
> - buffer->priv_virt = info;
> - buffer->sg_table = info->table;
> - dev_dbg(dev, "Allocate buffer %p\n", buffer);
> + sg_set_page(table->sgl, pages, len, 0);
> +
> + buffer->priv_virt = pages;
> + buffer->sg_table = table;
> return 0;
>
> -free_table:
> - kfree(info->table);
> free_mem:
> - dma_free_coherent(dev, len, info->cpu_addr, info->handle);
> + kfree(table);
> err:
> - kfree(info);
> + cma_release(cma_heap->cma, pages, buffer->size);
> return -ENOMEM;
> }
>
> static void ion_cma_free(struct ion_buffer *buffer)
Re: em28xx i2c writing error
On Mon, Apr 17, 2017 at 3:55 AM, Mauro Carvalho Chehab wrote: > Em Sat, 15 Apr 2017 20:28:20 +0200 > Anders Eriksson escreveu: > >> Hi Mauro, >> >> I've two devices using this driver, and whenever I have them both in >> use I eventually (between 10K and 100K secs uptime) i2c write errors >> such as in the log below. If only have one of the devices in use, the >> machine is stable. >> >> The machine never recovers from the error. >> >> All help apreciated. >> -Anders >> >> >> >> [0.00] Booting Linux on physical CPU 0xf00 >> [0.00] Initializing cgroup subsys cpuset >> [0.00] Initializing cgroup subsys cpu >> [0.00] Initializing cgroup subsys cpuacct >> [0.00] Linux version 4.4.15-v7+ (dc4@dc4-XPS13-9333) (gcc >> version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #897 >> SMP Tue Jul 12 18:42:55 BST 2016 >> [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), >> cr=10c5387d >> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing >> instruction cache >> [0.00] Machine model: Raspberry Pi 2 Model B Rev 1.1 > > Hmm.. RPi2... that explains a lot ;) > > I've seen similar behaviors on some arm devices with just one device. > > That's likely due to some problem with isochronous transfers at the > USB host driver. > > The thing is that ISOC transfers are heavily used by USB cameras: > they require that the USB chip would provide a steady throughput > that can eat up to 60% of the USB maximum bitrate, with just one > video stream. > > My experience says that several USB drivers can't sustain such > bit rates for a long time. > > The RPi tree uses an out-of-tree driver for the USB host driver > (otgdwc - I guess). Upstream uses a different driver (dwc2). > My recent experiences with upstream(dwc2) and USB cameras > is even worse: it doesn't work, if the camera supports only > ISOC frames. > > I'll eventually try to fix the upstream driver if I find > spare time for it, but I won't touch at the proprietary > driver that is shipped with the downstream Kernel. > Hi, I'd appreciate any attempt to fix this. My experience is that it (the rpi2 with otgdwc) bugs out after 10k-100k of uptime, and can sustain parallel recordings (using both tv-receivers), so the rest of the systems seems to be working ok. I'd be happy to try out any patches you create for the upstream driver. Br, Anders
Re: [PATCH v3] [media] staging: css2400: fix checkpatch error
On Wed, Mar 29, 2017 at 10:50:08AM +0300, Haim Daniel wrote: > isp_capture_defs.h: clean up ERROR: Macros with complex values should be > enclosed in parentheses > > Signed-off-by: Haim Daniel > --- > .../pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h | 2 > +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git > a/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h > > b/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h > index aa413df..117c7a2 100644 > --- > a/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h > +++ > b/drivers/staging/media/atomisp/pci/atomisp2/css2400/css_2401_csi2p_system/hrt/isp_capture_defs.h > @@ -19,7 +19,7 @@ > #define _ISP_CAPTURE_BITS_PER_ELEM32 /* only for data, not > SOP */ > #define _ISP_CAPTURE_BYTES_PER_ELEM > (_ISP_CAPTURE_BITS_PER_ELEM/8 ) > #define _ISP_CAPTURE_BYTES_PER_WORD 32 /* 256/8 */ > -#define _ISP_CAPTURE_ELEM_PER_WORD > _ISP_CAPTURE_BYTES_PER_WORD / _ISP_CAPTURE_BYTES_PER_ELEM > +#define _ISP_CAPTURE_ELEM_PER_WORD > (_ISP_CAPTURE_BYTES_PER_WORD / _ISP_CAPTURE_BYTES_PER_ELEM) Why only fix one of these instances? And why is this define even needed? No one touches it, right? Also, please cc: Alan on patches to this driver when you resend. You are using scripts/get_maintainer.pl, right? thanks, greg k-h
Re: dvb-tools: dvbv5-scan segfaults with DVB-T2 HD service that just started in Germany
On Thu, Mar 30, 2017 at 17:13:34 -0300, Mauro Carvalho Chehab wrote: > Hi Gregor, > > Em Wed, 29 Mar 2017 20:45:06 +0200 > Gregor Jasny escreveu: > > > Hello Mauro & list, > > > > could you please have a look at the dvbv5-scan crash report below? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859008 > > > > Is there anything else you need to debug this? > > I'm able to reproduce it on a Debian machine here too, but so far, > I was unable to discover what's causing it. I'll try to find some time > to take a better look on it. Hi, can I help in some way to find the cause of crash? Regards, Tino
Re: et8ek8 camera on Nokia N900: trying to understand what is going on with modes
Hi Pavel, On Wed, Apr 12, 2017 at 11:11:59PM +0200, Pavel Machek wrote: > Hi! > > 5Mpix mode does not work on N900, which is something I'd like to > understand. et8ek8_mode contains huge tables of register settings and > parameter values, but it seems that they are not really independend. > > To test that theory, I started with checking values against each > other. > > This is the work so far, it is neither complete nor completely working > at the moment. Perhaps someone wants to play... You might seek to try lowering the pixel clock on the sensor to see whether it makes any difference. I don't think there's been any changes to how the sensor is programmed since the original software was shipped with the device. That doesn't apply to the SoC and the clock tree in the SoC however. I wonder if there could be changes in clock frequencies and how the ISP is clocked. The omap3isp driver has changed heavily as well. Just my 5 Euro cents (they have no smaller coins around here). -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [PATCH for v4.12 1/3] cec: Kconfig cleanup
2017-04-18 10:45 GMT+02:00 Hans Verkuil :
> From: Hans Verkuil
>
> The Kconfig options for the CEC subsystem were a bit messy. In
> addition there were two cec sources (cec-edid.c and cec-notifier.c)
> that were outside of the media/cec directory, which was weird.
>
> Move those sources to media/cec as well.
>
> The cec-edid and cec-notifier functionality is now part of the cec
> module and these are no longer separate modules.
>
> Also remove the MEDIA_CEC_EDID config option and include it with the
> main CEC config option (which defined CEC_EDID anyway).
>
> Added static inlines to cec-edid.h for dummy functions when CEC_CORE
> isn't defined.
>
> CEC drivers should now depend on CEC_CORE.
>
> CEC drivers that need the cec-notifier functionality must explicitly
> select CEC_NOTIFIER.
>
> The s5p-cec and stih-cec drivers depended on VIDEO_DEV instead of
> CEC_CORE, fix that as well.
>
> Signed-off-by: Hans Verkuil
Thanks for this clean up.
Acked-by: Benjamin Gaignard
> ---
> MAINTAINERS | 2 --
> drivers/media/Kconfig| 26 ---
> drivers/media/Makefile | 14 ++--
> drivers/media/cec/Kconfig| 13
> drivers/media/cec/Makefile | 8 +++--
> drivers/media/{ => cec}/cec-edid.c | 4 ---
> drivers/media/{ => cec}/cec-notifier.c | 0
> drivers/media/i2c/Kconfig| 9 ++---
> drivers/media/platform/Kconfig | 56
>
> drivers/media/platform/vivid/Kconfig | 3 +-
> drivers/media/usb/pulse8-cec/Kconfig | 2 +-
> drivers/media/usb/rainshadow-cec/Kconfig | 2 +-
> include/media/cec-edid.h | 29 +
> include/media/cec.h | 2 +-
> 14 files changed, 91 insertions(+), 79 deletions(-)
> create mode 100644 drivers/media/cec/Kconfig
> rename drivers/media/{ => cec}/cec-edid.c (97%)
> rename drivers/media/{ => cec}/cec-notifier.c (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7d3b9993e4ba..1b0049934cf9 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3075,8 +3075,6 @@ S:Supported
> F: Documentation/media/kapi/cec-core.rst
> F: Documentation/media/uapi/cec
> F: drivers/media/cec/
> -F: drivers/media/cec-edid.c
> -F: drivers/media/cec-notifier.c
> F: drivers/media/rc/keymaps/rc-cec.c
> F: include/media/cec.h
> F: include/media/cec-edid.h
> diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
> index 9e9ded44e8a8..b72edd27f880 100644
> --- a/drivers/media/Kconfig
> +++ b/drivers/media/Kconfig
> @@ -81,27 +81,15 @@ config MEDIA_RC_SUPPORT
> Say Y when you have a TV or an IR device.
>
> config MEDIA_CEC_SUPPORT
> - bool "HDMI CEC support"
> - select MEDIA_CEC_EDID
> - ---help---
> - Enable support for HDMI CEC (Consumer Electronics Control),
> - which is an optional HDMI feature.
> -
> - Say Y when you have an HDMI receiver, transmitter or a USB CEC
> - adapter that supports HDMI CEC.
> -
> -config MEDIA_CEC_DEBUG
> - bool "HDMI CEC debugfs interface"
> - depends on MEDIA_CEC_SUPPORT && DEBUG_FS
> - ---help---
> - Turns on the DebugFS interface for CEC devices.
> + bool "HDMI CEC support"
> + ---help---
> + Enable support for HDMI CEC (Consumer Electronics Control),
> + which is an optional HDMI feature.
>
> -config MEDIA_CEC_EDID
> - bool
> + Say Y when you have an HDMI receiver, transmitter or a USB CEC
> + adapter that supports HDMI CEC.
>
> -config MEDIA_CEC_NOTIFIER
> - bool
> - select MEDIA_CEC_EDID
> +source "drivers/media/cec/Kconfig"
>
> #
> # Media controller
> diff --git a/drivers/media/Makefile b/drivers/media/Makefile
> index 8b36a571d443..523fea3648ad 100644
> --- a/drivers/media/Makefile
> +++ b/drivers/media/Makefile
> @@ -2,20 +2,10 @@
> # Makefile for the kernel multimedia device drivers.
> #
>
> -ifeq ($(CONFIG_MEDIA_CEC_EDID),y)
> - obj-$(CONFIG_MEDIA_SUPPORT) += cec-edid.o
> -endif
> -
> -ifeq ($(CONFIG_MEDIA_CEC_NOTIFIER),y)
> - obj-$(CONFIG_MEDIA_SUPPORT) += cec-notifier.o
> -endif
> -
> -ifeq ($(CONFIG_MEDIA_CEC_SUPPORT),y)
> - obj-$(CONFIG_MEDIA_SUPPORT) += cec/
> -endif
> -
> media-objs := media-device.o media-devnode.o media-entity.o
>
> +obj-$(CONFIG_CEC_CORE) += cec/
> +
> #
> # I2C drivers should come before other drivers, otherwise they'll fail
> # when compiled as builtin drivers
> diff --git a/drivers/media/cec/Kconfig b/drivers/media/cec/Kconfig
> new file mode 100644
> index ..24b53187ee52
> --- /dev/null
> +++ b/drivers/media/cec/Kconfig
> @@ -0,0 +1,13 @@
> +config CEC_CORE
> + tristate
> + depends on MEDIA_CEC_SUPPORT
> + default y
> +
> +config MEDIA_CEC_NOTIFIER
> + bool
> +
> +config MEDIA_CEC_DEBUG
> + bool "HDMI CEC debugfs interface"
> + depends on MEDIA_CE
Re: [PATCH 40/40] media: imx: set and propagate empty field, colorimetry params
On Thu, 2017-04-13 at 09:40 -0700, Steve Longerbeam wrote: [...] > >> @@ -804,12 +804,29 @@ static void prp_try_fmt(struct prp_priv *priv, > >> &sdformat->format.height, > >> infmt->height / 4, MAX_H_SRC, > >> H_ALIGN_SRC, S_ALIGN); > >> + > >> + /* > >> + * The Image Converter produces fixed quantization > >> + * (full range for RGB, limited range for YUV), and > >> + * uses a fixed Y`CbCr encoding (V4L2_YCBCR_ENC_601). > >> + * For colorspace and transfer func, just propagate > >> + * from the sink. > >> + */ > >> + sdformat->format.quantization = > >> + ((*cc)->cs != IPUV3_COLORSPACE_YUV) ? > >> + V4L2_QUANTIZATION_FULL_RANGE : > >> + V4L2_QUANTIZATION_LIM_RANGE; > >> + sdformat->format.ycbcr_enc = V4L2_YCBCR_ENC_601; > > > > Support for V4L2_YCBCR_ENC_709 and quantization options could be added > > to the IPUv3 core code, so this limitation could be relaxed later. > > Yes, I was going to mention that too. We can add coefficient tables > to ipu-ic for all the encodings enumerated in enum v4l2_ycbcr_encoding. Exactly. > I know that quantization is programmable in the DP, but is it in the > IC? AFAICT there is none. We have a freely programmable 4x3 matrix multiplication both before and after processing in each task, and there is a saturation mode switch that can limit the first component to (16...235) and the other two to (16...240). That should be enough for at least full/limited range YCbCr quantizations. So we apparently can't saturate to limited range RGB, but for example full-range -> limited-range RGB conversions should be perfectly possible. regards Philipp
Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
Hi!
> That self-referencing mux-controls property looks a bit superfluous:
>
> mux: video-multiplexer {
> mux-controls = <&mux>;
> };
>
> Other than that, I'm completely fine with splitting the compatible into
> something like video-mux-gpio and video-mux-mmio and reusing the
> mux-gpios property for video-mux-gpio.
Agreed, I overseen that.
> > You should be able to use code in drivers/mux as a library...
>
> This is a good idea in principle, but this requires some rework of the
> mux subsystem, and that subsystem hasn't even landed yet. For now I'd
> like to focus on getting the DT bindings right.
>
> I'd honestly prefer to not add this rework as a requirement for the i.MX
> media drivers to get into staging.
Hmm. staging/ normally accepts code with bigger design problems than
that.
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
[PATCH for v4.12 3/3] cec: add MEDIA_CEC_RC config option
From: Hans Verkuil
Add an explicit config option to select whether the CEC remote control
messages are to be passed on to the RC subsystem or not.
Signed-off-by: Hans Verkuil
---
drivers/media/cec/Kconfig| 8 +++-
drivers/media/cec/cec-adap.c | 4 ++--
drivers/media/cec/cec-core.c | 12 ++--
3 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/media/cec/Kconfig b/drivers/media/cec/Kconfig
index 24b53187ee52..f944d93e3167 100644
--- a/drivers/media/cec/Kconfig
+++ b/drivers/media/cec/Kconfig
@@ -6,8 +6,14 @@ config CEC_CORE
config MEDIA_CEC_NOTIFIER
bool
+config MEDIA_CEC_RC
+ bool "HDMI CEC RC integration"
+ depends on CEC_CORE && RC_CORE
+ ---help---
+ Pass on CEC remote control messages to the RC framework.
+
config MEDIA_CEC_DEBUG
bool "HDMI CEC debugfs interface"
- depends on MEDIA_CEC_SUPPORT && DEBUG_FS
+ depends on CEC_CORE && DEBUG_FS
---help---
Turns on the DebugFS interface for CEC devices.
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index 25d0a835921f..f5fe01c9da8a 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -1732,7 +1732,7 @@ static int cec_receive_notify(struct cec_adapter *adap,
struct cec_msg *msg,
!(adap->log_addrs.flags &
CEC_LOG_ADDRS_FL_ALLOW_RC_PASSTHRU))
break;
-#if IS_REACHABLE(CONFIG_RC_CORE)
+#ifdef CONFIG_MEDIA_CEC_RC
switch (msg->msg[2]) {
/*
* Play function, this message can have variable length
@@ -1769,7 +1769,7 @@ static int cec_receive_notify(struct cec_adapter *adap,
struct cec_msg *msg,
if (!(adap->capabilities & CEC_CAP_RC) ||
!(adap->log_addrs.flags &
CEC_LOG_ADDRS_FL_ALLOW_RC_PASSTHRU))
break;
-#if IS_REACHABLE(CONFIG_RC_CORE)
+#ifdef CONFIG_MEDIA_CEC_RC
rc_keyup(adap->rc);
#endif
break;
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index 430f5e052ab3..a21fca7f7883 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -220,7 +220,7 @@ struct cec_adapter *cec_allocate_adapter(const struct
cec_adap_ops *ops,
struct cec_adapter *adap;
int res;
-#if !IS_REACHABLE(CONFIG_RC_CORE)
+#ifndef CONFIG_MEDIA_CEC_RC
caps &= ~CEC_CAP_RC;
#endif
@@ -256,7 +256,7 @@ struct cec_adapter *cec_allocate_adapter(const struct
cec_adap_ops *ops,
return ERR_PTR(res);
}
-#if IS_REACHABLE(CONFIG_RC_CORE)
+#ifdef CONFIG_MEDIA_CEC_RC
if (!(caps & CEC_CAP_RC))
return adap;
@@ -305,7 +305,7 @@ int cec_register_adapter(struct cec_adapter *adap,
adap->owner = parent->driver->owner;
adap->devnode.dev.parent = parent;
-#if IS_REACHABLE(CONFIG_RC_CORE)
+#ifdef CONFIG_MEDIA_CEC_RC
if (adap->capabilities & CEC_CAP_RC) {
adap->rc->dev.parent = parent;
res = rc_register_device(adap->rc);
@@ -322,7 +322,7 @@ int cec_register_adapter(struct cec_adapter *adap,
res = cec_devnode_register(&adap->devnode, adap->owner);
if (res) {
-#if IS_REACHABLE(CONFIG_RC_CORE)
+#ifdef CONFIG_MEDIA_CEC_RC
/* Note: rc_unregister also calls rc_free */
rc_unregister_device(adap->rc);
adap->rc = NULL;
@@ -357,7 +357,7 @@ void cec_unregister_adapter(struct cec_adapter *adap)
if (IS_ERR_OR_NULL(adap))
return;
-#if IS_REACHABLE(CONFIG_RC_CORE)
+#ifdef CONFIG_MEDIA_CEC_RC
/* Note: rc_unregister also calls rc_free */
rc_unregister_device(adap->rc);
adap->rc = NULL;
@@ -381,7 +381,7 @@ void cec_delete_adapter(struct cec_adapter *adap)
kthread_stop(adap->kthread);
if (adap->kthread_config)
kthread_stop(adap->kthread_config);
-#if IS_REACHABLE(CONFIG_RC_CORE)
+#ifdef CONFIG_MEDIA_CEC_RC
rc_free_device(adap->rc);
#endif
kfree(adap);
--
2.11.0
[PATCH for v4.12 2/3] cec.h: merge cec-edid.h into cec.h
From: Hans Verkuil Drop the separate cec-edid.h header and merge it into cec.h. There was really no need to have a separate header for this. Signed-off-by: Hans Verkuil --- MAINTAINERS | 1 - drivers/media/cec/cec-edid.c | 2 +- drivers/media/cec/cec-notifier.c | 1 + drivers/media/platform/s5p-cec/s5p_cec.c | 1 - include/media/cec-edid.h | 133 --- include/media/cec-notifier.h | 2 +- include/media/cec.h | 102 +++- 7 files changed, 104 insertions(+), 138 deletions(-) delete mode 100644 include/media/cec-edid.h diff --git a/MAINTAINERS b/MAINTAINERS index 1b0049934cf9..8cc0104f14aa 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3077,7 +3077,6 @@ F:Documentation/media/uapi/cec F: drivers/media/cec/ F: drivers/media/rc/keymaps/rc-cec.c F: include/media/cec.h -F: include/media/cec-edid.h F: include/media/cec-notifier.h F: include/uapi/linux/cec.h F: include/uapi/linux/cec-funcs.h diff --git a/drivers/media/cec/cec-edid.c b/drivers/media/cec/cec-edid.c index c63dc81d2a29..38e3fec6152b 100644 --- a/drivers/media/cec/cec-edid.c +++ b/drivers/media/cec/cec-edid.c @@ -20,7 +20,7 @@ #include #include #include -#include +#include /* * This EDID is expected to be a CEA-861 compliant, which means that there are diff --git a/drivers/media/cec/cec-notifier.c b/drivers/media/cec/cec-notifier.c index 5f5209a73665..74dc1c32080e 100644 --- a/drivers/media/cec/cec-notifier.c +++ b/drivers/media/cec/cec-notifier.c @@ -24,6 +24,7 @@ #include #include +#include #include #include diff --git a/drivers/media/platform/s5p-cec/s5p_cec.c b/drivers/media/platform/s5p-cec/s5p_cec.c index 4688f0879f55..664937b61fa4 100644 --- a/drivers/media/platform/s5p-cec/s5p_cec.c +++ b/drivers/media/platform/s5p-cec/s5p_cec.c @@ -25,7 +25,6 @@ #include #include #include -#include #include #include "exynos_hdmi_cec.h" diff --git a/include/media/cec-edid.h b/include/media/cec-edid.h deleted file mode 100644 index 242781fd377f.. --- a/include/media/cec-edid.h +++ /dev/null @@ -1,133 +0,0 @@ -/* - * cec-edid - HDMI Consumer Electronics Control & EDID helpers - * - * Copyright 2016 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. - */ - -#ifndef _MEDIA_CEC_EDID_H -#define _MEDIA_CEC_EDID_H - -#include - -#define CEC_PHYS_ADDR_INVALID 0x -#define cec_phys_addr_exp(pa) \ - ((pa) >> 12), ((pa) >> 8) & 0xf, ((pa) >> 4) & 0xf, (pa) & 0xf - -#if IS_ENABLED(CONFIG_CEC_CORE) - -/** - * cec_get_edid_phys_addr() - find and return the physical address - * - * @edid: pointer to the EDID data - * @size: size in bytes of the EDID data - * @offset:If not %NULL then the location of the physical address - * bytes in the EDID will be returned here. This is set to 0 - * if there is no physical address found. - * - * Return: the physical address or CEC_PHYS_ADDR_INVALID if there is none. - */ -u16 cec_get_edid_phys_addr(const u8 *edid, unsigned int size, - unsigned int *offset); - -/** - * cec_set_edid_phys_addr() - find and set the physical address - * - * @edid: pointer to the EDID data - * @size: size in bytes of the EDID data - * @phys_addr: the new physical address - * - * This function finds the location of the physical address in the EDID - * and fills in the given physical address and updates the checksum - * at the end of the EDID block. It does nothing if the EDID doesn't - * contain a physical address. - */ -void cec_set_edid_phys_addr(u8 *edid, unsigned int size, u16 phys_addr); - -/** - * cec_phys_addr_for_input() - calculate the PA for an input - * - * @phys_addr: the physical address of the parent - * @input: the number of the input port, must be between 1 and 15 - * - * This function calculates a new physical address based on the input - * port number. For example: - * - * PA = 0.0.0.0 and input = 2 becomes 2.0.0.0 - * - * PA = 3.0.0.0 and input = 1 becomes 3.1.0.0 - * - * PA = 3.2.1.0 and input = 5 becomes 3.2.1.5 - * - * PA = 3.2.1.3 and input = 5 becomes f.f.f.f since it maxed out the depth. - *
[PATCH for v4.12 1/3] cec: Kconfig cleanup
From: Hans Verkuil
The Kconfig options for the CEC subsystem were a bit messy. In
addition there were two cec sources (cec-edid.c and cec-notifier.c)
that were outside of the media/cec directory, which was weird.
Move those sources to media/cec as well.
The cec-edid and cec-notifier functionality is now part of the cec
module and these are no longer separate modules.
Also remove the MEDIA_CEC_EDID config option and include it with the
main CEC config option (which defined CEC_EDID anyway).
Added static inlines to cec-edid.h for dummy functions when CEC_CORE
isn't defined.
CEC drivers should now depend on CEC_CORE.
CEC drivers that need the cec-notifier functionality must explicitly
select CEC_NOTIFIER.
The s5p-cec and stih-cec drivers depended on VIDEO_DEV instead of
CEC_CORE, fix that as well.
Signed-off-by: Hans Verkuil
---
MAINTAINERS | 2 --
drivers/media/Kconfig| 26 ---
drivers/media/Makefile | 14 ++--
drivers/media/cec/Kconfig| 13
drivers/media/cec/Makefile | 8 +++--
drivers/media/{ => cec}/cec-edid.c | 4 ---
drivers/media/{ => cec}/cec-notifier.c | 0
drivers/media/i2c/Kconfig| 9 ++---
drivers/media/platform/Kconfig | 56
drivers/media/platform/vivid/Kconfig | 3 +-
drivers/media/usb/pulse8-cec/Kconfig | 2 +-
drivers/media/usb/rainshadow-cec/Kconfig | 2 +-
include/media/cec-edid.h | 29 +
include/media/cec.h | 2 +-
14 files changed, 91 insertions(+), 79 deletions(-)
create mode 100644 drivers/media/cec/Kconfig
rename drivers/media/{ => cec}/cec-edid.c (97%)
rename drivers/media/{ => cec}/cec-notifier.c (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7d3b9993e4ba..1b0049934cf9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3075,8 +3075,6 @@ S:Supported
F: Documentation/media/kapi/cec-core.rst
F: Documentation/media/uapi/cec
F: drivers/media/cec/
-F: drivers/media/cec-edid.c
-F: drivers/media/cec-notifier.c
F: drivers/media/rc/keymaps/rc-cec.c
F: include/media/cec.h
F: include/media/cec-edid.h
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 9e9ded44e8a8..b72edd27f880 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -81,27 +81,15 @@ config MEDIA_RC_SUPPORT
Say Y when you have a TV or an IR device.
config MEDIA_CEC_SUPPORT
- bool "HDMI CEC support"
- select MEDIA_CEC_EDID
- ---help---
- Enable support for HDMI CEC (Consumer Electronics Control),
- which is an optional HDMI feature.
-
- Say Y when you have an HDMI receiver, transmitter or a USB CEC
- adapter that supports HDMI CEC.
-
-config MEDIA_CEC_DEBUG
- bool "HDMI CEC debugfs interface"
- depends on MEDIA_CEC_SUPPORT && DEBUG_FS
- ---help---
- Turns on the DebugFS interface for CEC devices.
+ bool "HDMI CEC support"
+ ---help---
+ Enable support for HDMI CEC (Consumer Electronics Control),
+ which is an optional HDMI feature.
-config MEDIA_CEC_EDID
- bool
+ Say Y when you have an HDMI receiver, transmitter or a USB CEC
+ adapter that supports HDMI CEC.
-config MEDIA_CEC_NOTIFIER
- bool
- select MEDIA_CEC_EDID
+source "drivers/media/cec/Kconfig"
#
# Media controller
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index 8b36a571d443..523fea3648ad 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -2,20 +2,10 @@
# Makefile for the kernel multimedia device drivers.
#
-ifeq ($(CONFIG_MEDIA_CEC_EDID),y)
- obj-$(CONFIG_MEDIA_SUPPORT) += cec-edid.o
-endif
-
-ifeq ($(CONFIG_MEDIA_CEC_NOTIFIER),y)
- obj-$(CONFIG_MEDIA_SUPPORT) += cec-notifier.o
-endif
-
-ifeq ($(CONFIG_MEDIA_CEC_SUPPORT),y)
- obj-$(CONFIG_MEDIA_SUPPORT) += cec/
-endif
-
media-objs := media-device.o media-devnode.o media-entity.o
+obj-$(CONFIG_CEC_CORE) += cec/
+
#
# I2C drivers should come before other drivers, otherwise they'll fail
# when compiled as builtin drivers
diff --git a/drivers/media/cec/Kconfig b/drivers/media/cec/Kconfig
new file mode 100644
index ..24b53187ee52
--- /dev/null
+++ b/drivers/media/cec/Kconfig
@@ -0,0 +1,13 @@
+config CEC_CORE
+ tristate
+ depends on MEDIA_CEC_SUPPORT
+ default y
+
+config MEDIA_CEC_NOTIFIER
+ bool
+
+config MEDIA_CEC_DEBUG
+ bool "HDMI CEC debugfs interface"
+ depends on MEDIA_CEC_SUPPORT && DEBUG_FS
+ ---help---
+ Turns on the DebugFS interface for CEC devices.
diff --git a/drivers/media/cec/Makefile b/drivers/media/cec/Makefile
index d6686337275f..402a6c62a3e8 100644
--- a/drivers/media/cec/Makefile
+++ b/drivers/media/cec/Makefile
@@ -1,5 +1,7 @@
-cec-objs := cec-core.o cec-adap.o cec-api.o
+cec-objs := cec-core.o cec-ad
[PATCH for v4.12 0/3] cec: clean up Kconfig, headers
From: Hans Verkuil
This patch series cleans up the various CEC config options.
In particular it adds a CEC_CORE config option which is what CEC drivers
should depend on, and it removes the MEDIA_CEC_EDID config option which
was rather pointless.
Finally it adds a new option to explicitly enable the RC passthrough
support in CEC.
It also moves cec-edid.c and cec-notifier.c to the media/cec directory
and merges them into the cec module instead of having separate modules
for these. And the cec-edid.h header is merged into cec.h.
CEC drivers now just depend on CEC_CORE. And if the CEC drivers needs
the CEC notifier framework, then it has to select CEC_NOTIFIER.
I would like to see this merged for 4.12 before more CEC drivers get
merged.
Regards,
Hans
Hans Verkuil (3):
cec: Kconfig cleanup
cec.h: merge cec-edid.h into cec.h
cec: add MEDIA_CEC_RC config option
MAINTAINERS | 3 -
drivers/media/Kconfig| 26 +++-
drivers/media/Makefile | 14 +
drivers/media/cec/Kconfig| 19 ++
drivers/media/cec/Makefile | 8 ++-
drivers/media/cec/cec-adap.c | 4 +-
drivers/media/cec/cec-core.c | 12 ++--
drivers/media/{ => cec}/cec-edid.c | 6 +-
drivers/media/{ => cec}/cec-notifier.c | 1 +
drivers/media/i2c/Kconfig| 9 +--
drivers/media/platform/Kconfig | 56 -
drivers/media/platform/s5p-cec/s5p_cec.c | 1 -
drivers/media/platform/vivid/Kconfig | 3 +-
drivers/media/usb/pulse8-cec/Kconfig | 2 +-
drivers/media/usb/rainshadow-cec/Kconfig | 2 +-
include/media/cec-edid.h | 104 ---
include/media/cec-notifier.h | 2 +-
include/media/cec.h | 104 ++-
18 files changed, 180 insertions(+), 196 deletions(-)
create mode 100644 drivers/media/cec/Kconfig
rename drivers/media/{ => cec}/cec-edid.c (96%)
rename drivers/media/{ => cec}/cec-notifier.c (99%)
delete mode 100644 include/media/cec-edid.h
--
2.11.0
Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
Hi Pavel,
On Fri, 2017-04-14 at 22:32 +0200, Pavel Machek wrote:
> 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 = <&gpio 0>, <&gpio 1>;
> > #mux-control-cells = <0>;
> > }
> >
> > video-multiplexer {
> > compatible = "video-multiplexer"
> > mux-controls = <&mux>;
> >
> > 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,
I agree.
> so it should be something like:
>
> video-multiplexer {
> compatible = "video-multiplexer-gpio"
> mux-gpios = <&gpio 0>, <&gpio 1>;
> #mux-control-cells = <0>;
>
> mux-controls = <&mux>;
>
> ports {
> /* ... */
> }
> }
That self-referencing mux-controls property looks a bit superfluous:
mux: video-multiplexer {
mux-controls = <&mux>;
};
Other than that, I'm completely fine with splitting the compatible into
something like video-mux-gpio and video-mux-mmio and reusing the
mux-gpios property for video-mux-gpio.
> You should be able to use code in drivers/mux as a library...
This is a good idea in principle, but this requires some rework of the
mux subsystem, and that subsystem hasn't even landed yet. For now I'd
like to focus on getting the DT bindings right.
I'd honestly prefer to not add this rework as a requirement for the i.MX
media drivers to get into staging.
regards
Philipp
Re: Looking for device driver advice
Hi Niklas, On Sun, Apr 16, 2017 at 07:42:20PM +0200, Niklas Söderlund wrote: > Hi, > > On 2017-04-16 13:51:21 +0300, Sakari Ailus wrote: > > Hi Hans and Patrick, > > > > On Wed, Apr 12, 2017 at 01:37:33PM +0200, Hans Verkuil wrote: > > > Hi Patrick, > > > > > > On 04/10/2017 10:13 PM, Patrick Doyle wrote: > > > > I am looking for advice regarding the construction of a device driver > > > > for a MIPI CSI2 imager (a Sony IMX241) that is connected to a > > > > MIPI<->Parallel converter (Toshiba TC358748) wired into a parallel > > > > interface on a Soc (a Microchip/Atmel SAMAD2x device.) > > > > > > > > The Sony imager is controlled and configured via I2C, as is the > > > > Toshiba converter. I could write a single driver that configures both > > > > devices and treats them as a single device that just happens to use 2 > > > > i2c addresses. I could use the i2c_new_dummy() API to construct the > > > > device abstraction for the second physical device at probe time for > > > > the first physical device. > > > > > > > > Or I could do something smarter (or at least different), specifying > > > > the two devices independently via my device tree file, perhaps linking > > > > them together via "port" nodes. Currently, I use the "port" node > > > > concept to link an i2c imager to the Image System Controller (isc) > > > > node in the SAMA5 device. Perhaps that generalizes to a chain of > > > > nodes linked together... I don't know. > > > > > > That would be the right solution. Unfortunately the atmel-isc.c driver > > > (at least the version in the mainline kernel) only supports a single > > > subdev device. At least, as far as I can see. > > I also think that two subdevices implemented in two separate drivers is > the way to go. As it really is two different pieces of hardware, > right? > > > > > There have been multiple cases recently where the media pipeline can have > > sub-devices controlled by more than two drivers. We need to have a common > > approach on how we do handle such cases. > > I agree that a common approach to the problem of when one subdevices can > be controlled by more then one driver is needed. In this case however I > think something else also needs to be defined. If I understand Hans and > Patrick the issues is not that the hardware can be controlled by more > then one driver. Instead it is that the atmel-isc.c driver only probes > DT for one subdevice, so implementing it as more then one subdevices is > problematic. If I misunderstand the problem please let me know. The pipeline is (again, unless I'm mistaken): sensor -> csi2-parallel converter -> SoC So not very much unlike it's elsewhere. > > If I understand the problem correctly it could be solved by modifying > the atmel-isc.c driver to look for more then one subdevice in DT. But a > common approach for drivers to find and bind arbitrary number of > subdevices would be better, finding an approach that also solves the > case where one subdevice can be used by more then one driver would be > better still. If this common case also could cover the case where one DT > node represents a driver which registers more then one subdevice which > then can be used by different other drivers I would be very happy and a > lot of my headaches would go away :-) > > > > > For instance, how is the entire DT graph parsed or when and how are the > > device nodes created? > > > > Parsing the graph should probably be initiated by the master driver but > > instead implemented in the framework as it's a non-trivial task and common > > to all such drivers. Another equestion is how do we best support this also > > on existing drivers. > > I agree that the master device probably should initiate the DT graph > parsing and if possible there should be as much support as possible in > the framework. One extra consideration here is that there might be more > then one master device which uses the same subdevices. I have such cases Good point. I.e. you have two source pads that are connected to two different master devices? > today where different instances of the same driver use the same set of > subdevices. Is this the intended state of matters? Or do I miss something? :-) > > > > > I actually have a small documentation patch on handling streaming control in > > such cases as there are choices now to be made not thought about when the > > sub-device ops were originally addeed. I'll cc you to that. > > > > We do have a similar case currently in i.MX6, Nokia N9 (OMAP3) and on some I meant to say Nokia N900, not N9. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
