Documentation: rapidio: move sysfs interface to ABI
Hi In Documentation/rapidio/sysfs.txt, there is a description of the sysfs interface which could be moved to Documentation/ABI (as a bus interface under testing). Would such a change be useful? The ABI documentation format looks like the following: What: (the full sysfs path of the attribute) Date: (date of creation) KernelVersion: (kernel version it first showed up in) Contact: (primary contact) Description: (long description on usage) I am doing this in an exercise to move sysfs ABI interfaces (which are documented) to their right place i.e. in Documentation/ABI along with the rest. Aishwarya -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Documentation: infiniband: move sysfs interface to ABI
Hi In Documentation/infiniband/sysfs.txt, there is a description of the infiniband sysfs interface and there also exists Documentation/ABI/testing/sysfs-class-infiniband which is out of date. Would it be useful to move out the interface completely from Documentation/infiniband/sysfs.txt to the ABI? The ABI documentation format looks like the following: What: (the full sysfs path of the attribute) Date: (date of creation) KernelVersion: (kernel version it first showed up in) Contact: (primary contact) Description: (long description on usage) I am doing this in an exercise to move sysfs ABI interfaces (which are documented) to their right place i.e. in Documentation/ABI along with the rest. Aishwarya -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Documentation: rapidio: move sysfs interface to ABI
On Mon, Jan 08, 2018 at 11:58:12AM +0300, Ozgur wrote: > > > 08.01.2018, 11:38, "Aishwarya Pant" : > > Hi > > Hello, > > > In Documentation/rapidio/sysfs.txt, there is a description of the sysfs > > interface which could be moved to Documentation/ABI (as a bus interface > > under > > testing). > > > > Would such a change be useful? > > > > The ABI documentation format looks like the following: > > > > What: (the full sysfs path of the attribute) > > Date: (date of creation) > > KernelVersion: (kernel version it first showed up in) > > Contact: (primary contact) > > Description: (long description on usage) > > Please you make the change you want after send your patch it diff format, > right? > I think a better decision can be made. This is the idea. If this change is acceptable, then I can make a patch and send it for review. Aishwarya > > > I am doing this in an exercise to move sysfs ABI interfaces (which are > > documented) to their right place i.e. in Documentation/ABI along with the > > rest. > > > > Aishwarya > > Regards > > Ozgur -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Documentation: rapidio: move sysfs interface to ABI
08.01.2018, 11:38, "Aishwarya Pant" : > Hi Hello, > In Documentation/rapidio/sysfs.txt, there is a description of the sysfs > interface which could be moved to Documentation/ABI (as a bus interface under > testing). > > Would such a change be useful? > > The ABI documentation format looks like the following: > > What: (the full sysfs path of the attribute) > Date: (date of creation) > KernelVersion: (kernel version it first showed up in) > Contact: (primary contact) > Description: (long description on usage) Please you make the change you want after send your patch it diff format, right? I think a better decision can be made. > I am doing this in an exercise to move sysfs ABI interfaces (which are > documented) to their right place i.e. in Documentation/ABI along with the > rest. > > Aishwarya Regards Ozgur -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Documentation: rapidio: move sysfs interface to ABI
08.01.2018, 12:03, "Aishwarya Pant" : > On Mon, Jan 08, 2018 at 11:58:12AM +0300, Ozgur wrote: >> 08.01.2018, 11:38, "Aishwarya Pant" : >> > Hi >> >> Hello, >> >> > In Documentation/rapidio/sysfs.txt, there is a description of the sysfs >> > interface which could be moved to Documentation/ABI (as a bus interface >> under >> > testing). >> > >> > Would such a change be useful? >> > >> > The ABI documentation format looks like the following: >> > >> > What: (the full sysfs path of the attribute) >> > Date: (date of creation) >> > KernelVersion: (kernel version it first showed up in) >> > Contact: (primary contact) >> > Description: (long description on usage) >> >> Please you make the change you want after send your patch it diff format, >> right? >> I think a better decision can be made. > > This is the idea. If this change is acceptable, then I can make a patch and > send > it for review. Hm, I think firstly you should send the patch then everybody checked and change is decided. Regards Ozgur > Aishwarya > >> > I am doing this in an exercise to move sysfs ABI interfaces (which are >> > documented) to their right place i.e. in Documentation/ABI along with the >> rest. >> > >> > Aishwarya >> >> Regards >> >> Ozgur -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] dmaengine: doc: fix bullet list formatting
On Sat, Dec 30, 2017 at 11:53:06PM +0100, Luca Ceresoli wrote: > The bullet list documenting the 'struct dma_device' fields has several > nesting errors, making it render improperly. It also has incoherent > formatting: some fields have a description in the same bullet, some in > a sub-bullet. Applied both, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RESEND] cgroup, docs: document the root cgroup behavior of cpu and io controllers
Hello, On Thu, Jan 04, 2018 at 10:57:00PM +0100, Maciej S. Szmigiero wrote: > Currently, cgroups v2 documentation contains only a generic remark that > "How resource consumption in the root cgroup is governed is up to each > controller", which isn't really telling users much, who need to dig in the > code and / or commit messages to learn the exact behavior. I don't think we want to fully guarantee the current behavior. On the scheduler side, I don't think it's likely to change but blkio side *might* change. Can you please collect the root behavior in a separte section and clearly note that the behaviors are subject to change? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures
[Sorry everyone for the late response, I went away on vacation and pushed this
off until I returned.]
On 12/13/2017 07:45 AM, Lorenzo Pieralisi wrote:
> [+Mark, Graeme]
>
> In $SUBJECT, s/avialable/available
>
> On Mon, Dec 11, 2017 at 10:50:58AM -0500, Prarit Bhargava wrote:
>> Other architectures can use SPCR to setup an early console or console
>> but the current code is ARM64 specific.
>
> I see nothing ARM64 specific in current code (apart from some
> ACPICA macros with an ARM tag in them) please explain to me
> what's preventing you to reuse current code on x86.
Ah, I didn't notice that. I thought the ACPICA macros were ARM specific. I'll
rework this patchset with that in mind.
>
>> Change the name of parse_spcr() to acpi_parse_spcr(). Add a weak
>> function acpi_arch_setup_console() that can be used for arch-specific
>> setup. Move flags into ACPI code. Update the Documention on the use of
>> the SPCR.
>>
>> [v2]: Don't return an error in the baud_rate check of acpi_parse_spcr().
>> Keep ACPI_SPCR_TABLE selected for ARM64. Fix 8-bit port access width
>> mmio value. Move baud rate check earlier.
>
> This does not belong in the commit log.
Yes, but some maintainers like to see what changed between v1 & v2.
>
>> Signed-off-by: Prarit Bhargava
>> Cc: linux-doc@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> Cc: linux...@vger.kernel.org
>> Cc: linux-a...@vger.kernel.org
>> Cc: linux-ser...@vger.kernel.org
>> Cc: Bhupesh Sharma
>> Cc: Lv Zheng
>> Cc: Thomas Gleixner
>> Cc: Ingo Molnar
>> Cc: "H. Peter Anvin"
>> Cc: x...@kernel.org
>> Cc: Jonathan Corbet
>> Cc: Catalin Marinas
>> Cc: Will Deacon
>> Cc: "Rafael J. Wysocki"
>> Cc: Timur Tabi
>> ---
>> Documentation/admin-guide/kernel-parameters.txt | 6 +-
>> arch/arm64/kernel/acpi.c| 128 -
>> drivers/acpi/Kconfig| 7 +-
>> drivers/acpi/spcr.c | 175
>> ++--
>> drivers/tty/serial/earlycon.c | 15 +-
>> include/linux/acpi.h| 11 +-
>> include/linux/serial_core.h | 2 -
>> 7 files changed, 184 insertions(+), 160 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>> b/Documentation/admin-guide/kernel-parameters.txt
>> index 6571fbfdb2a1..0d173289c67e 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -914,9 +914,9 @@
>>
>> earlycon= [KNL] Output early console device and options.
>>
>> -When used with no options, the early console is
>> -determined by the stdout-path property in device
>> -tree's chosen node.
>> +[ARM64] The early console is determined by the
>> +stdout-path property in device tree's chosen node,
>> +or determined by the ACPI SPCR table.
>>
>> cdns,[,options]
>> Start an early, polled-mode console on a Cadence
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index b3162715ed78..b3e33bbdf3b7 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -25,7 +25,6 @@
>> #include
>> #include
>> #include
>> -#include
>>
>> #include
>> #include
>> @@ -177,6 +176,128 @@ static int __init acpi_fadt_sanity_check(void)
>> return ret;
>> }
>>
>> +/*
>> + * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as
>> + * occasionally getting stuck as 1. To avoid the potential for a hang, check
>> + * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART
>> + * implementations, so only do so if an affected platform is detected in
>> + * acpi_parse_spcr().
>> + */
>> +bool qdf2400_e44_present;
>> +EXPORT_SYMBOL(qdf2400_e44_present);
>
> My eyes, this is horrible but it is not introduced by this patch. It
> would have been much better if:
>
> drivers/tty/serial/amba-pl011.c
>
> parsed the SPCR table (again) to detect it instead of relying on this
> horrible exported flag.
It looks like Timur & you had a discussion and the current consensus is to keep
the code the same.
>
>> +
>> +/*
>> + * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY
>> bit.
>> + * Detect them by examining the OEM fields in the SPCR header, similar to
>> PCI
>> + * quirk detection in pci_mcfg.c.
>> + */
>> +static bool qdf2400_erratum_44_present(struct acpi_table_header *h)
>> +{
>> +if (memcmp(h->oem_id, "QCOM ", ACPI_OEM_ID_SIZE))
>> +return false;
>> +
>> +if (!memcmp(h->oem_table_id, "QDF2432 ", ACPI_OEM_TABLE_ID_SIZE))
>> +return true;
>> +
>> +if (!memcmp(h->oem_table_id, "QDF2400 ", ACPI_OEM_TABLE_ID_SIZE) &&
>> +h->oem_revision == 1)
>> +return true;
>> +
Re: [PATCH 02/11] media: videobuf2: Add new uAPI for DVB streaming I/O
Hi Mauro,
Thanks for this patch series, nice to see this moving forward.
Some comments below (note the wrong queue_setup code in particular since that
relates to my comment about the '[PATCH v3] media: videobuf2-core: don't go out
of the buffer range' patch).
On 12/21/2017 05:18 PM, Mauro Carvalho Chehab wrote:
> From: Satendra Singh Thakur
>
> Adds a new uAPI for DVB to use streaming I/O which is implemented
> based on videobuf2, using those new ioctls:
>
> - DMX_REQBUFS: Request kernel to allocate buffers which count and size
> are dedicated by user.
> - DMX_QUERYBUF: Get the buffer information like a memory offset which
> will mmap() and be shared with user-space.
> - DMX_EXPBUF: Just for testing whether buffer-exporting success or not.
> - DMX_QBUF: Pass the buffer to kernel-space.
> - DMX_DQBUF:Get back the buffer which may contain TS data.
>
> Originally developed by: Junghak Sung , as
> seen at:
> https://patchwork.linuxtv.org/patch/31613/
> https://patchwork.kernel.org/patch/7334301/
>
> The original patch was written before merging VB2-core functionalities
> upstream. When such series was added, several adjustments were made,
> fixing some issues with V4L2, causing the original patch to be
> non-trivially rebased.
>
> After rebased, a few bugs in the patch were fixed. The patch was
> also enhanced it and polling functionality got added.
>
> The main changes over the original patch are:
>
> dvb_vb2_fill_buffer():
> - Set the size of the outgoing buffer after while loop using
> vb2_set_plane_payload;
>
> - Added NULL check for source buffer as per normal convention
> of demux driver, this is called twice, first time with valid
> buffer second time with NULL pointer, if its not handled,
its -> it's
> it will result in crash
>
> - Restricted spinlock for only list_* operations
>
> dvb_vb2_init():
> - Restricted q->io_modes to only VB2_MMAP as its the only
> supported mode
>
> dvb_vb2_release():
> - Replaced the && in if condiion with &, because otherwise
condition
> it was always getting satisfied.
>
> dvb_vb2_stream_off():
> - Added list_del code for enqueud buffers upon stream off
enqueued
>
> dvb_vb2_poll():
> - Added this new function in order to support polling
>
> dvb_demux_poll() and dvb_dvr_poll()
> - dvb_vb2_poll() is now called from these functions
>
> - Ported this patch and latest videobuf2 to lower kernel versions and
> tested auto scan.
>
> [mche...@s-opensource.com: checkpatch fixes]
> Co-developed-by: Junghak Sung
> Signed-off-by: Junghak Sung
> Signed-off-by: Geunyoung Kim
> Acked-by: Seung-Woo Kim
> Acked-by: Inki Dae
> Signed-off-by: Satendra Singh Thakur
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/dvb-core/Makefile | 2 +-
> drivers/media/dvb-core/dmxdev.c | 196 +++---
> drivers/media/dvb-core/dmxdev.h | 4 +
> drivers/media/dvb-core/dvb_vb2.c | 423
> +++
> drivers/media/dvb-core/dvb_vb2.h | 72 +++
> include/uapi/linux/dvb/dmx.h | 66 +-
> 6 files changed, 733 insertions(+), 30 deletions(-)
> create mode 100644 drivers/media/dvb-core/dvb_vb2.c
> create mode 100644 drivers/media/dvb-core/dvb_vb2.h
>
> diff --git a/drivers/media/dvb-core/Makefile b/drivers/media/dvb-core/Makefile
> index 47e2e391bfb8..bbc65dfa0a8e 100644
> --- a/drivers/media/dvb-core/Makefile
> +++ b/drivers/media/dvb-core/Makefile
> @@ -7,6 +7,6 @@ dvb-net-$(CONFIG_DVB_NET) := dvb_net.o
>
> dvb-core-objs := dvbdev.o dmxdev.o dvb_demux.o \
>dvb_ca_en50221.o dvb_frontend.o\
> - $(dvb-net-y) dvb_ringbuffer.o dvb_math.o
> + $(dvb-net-y) dvb_ringbuffer.o dvb_vb2.o dvb_math.o
>
> obj-$(CONFIG_DVB_CORE) += dvb-core.o
> diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c
> index 18e4230865be..4cbb9003a1ed 100644
> --- a/drivers/media/dvb-core/dmxdev.c
> +++ b/drivers/media/dvb-core/dmxdev.c
> @@ -28,6 +28,7 @@
> #include
> #include
> #include "dmxdev.h"
> +#include "dvb_vb2.h"
>
> static int debug;
>
> @@ -138,14 +139,8 @@ static int dvb_dvr_open(struct inode *inode, struct file
> *file)
> return -ENODEV;
> }
>
> - if ((file->f_flags & O_ACCMODE) == O_RDWR) {
> - if (!(dmxdev->capabilities & DMXDEV_CAP_DUPLEX)) {
> - mutex_unlock(&dmxdev->mutex);
> - return -EOPNOTSUPP;
> - }
> - }
> -
> - if ((file->f_flags & O_ACCMODE) == O_RDONLY) {
> + if (((file->f_flags & O_ACCMODE) == O_RDONLY) ||
> + ((file->f_flags & O_ACCMODE) == O_RDWR)) {
> void *mem;
>
> if (!dvbdev->readers) {
> @@ -158,6 +153,8 @@ static int dvb_dvr_open(struct inode *inode, struct file
> *file)
> r
Re: [PATCH 02/11] media: videobuf2: Add new uAPI for DVB streaming I/O
A quick follow-up:
On 01/08/2018 02:54 PM, Hans Verkuil wrote:
>> +/*
>> + * Videobuf operations
>> + */
>> +int dvb_vb2_init(struct dvb_vb2_ctx *ctx, const char *name, int nonblocking)
>> +{
>> +struct vb2_queue *q = &ctx->vb_q;
>> +int ret;
>> +
>> +memset(ctx, 0, sizeof(struct dvb_vb2_ctx));
>> +q->type = DVB_BUF_TYPE_CAPTURE;
>
> We don't support DVB_BUF_TYPE_OUTPUT? Shouldn't this information come from the
> driver?
>
>> +/**capture type*/
>
> Why /** ?
>
>> +q->is_output = 0;
>
> Can be dropped unless we support DVB_BUF_TYPE_OUTPUT.
>
>> +/**only mmap is supported currently*/
>
> /** ?
>
>> +q->io_modes = VB2_MMAP;
>> +q->drv_priv = ctx;
>> +q->buf_struct_size = sizeof(struct dvb_buffer);
>> +q->min_buffers_needed = 1;
>> +q->ops = &dvb_vb2_qops;
>> +q->mem_ops = &vb2_vmalloc_memops;
>> +q->buf_ops = &dvb_vb2_buf_ops;
>> +q->num_buffers = 0;
>
> Not needed, is zeroed in the memset above.
>
> I'm also missing q->timestamp_flags: should be set to
> V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC.
Ignore this, see my comments later on.
>
>> +ret = vb2_core_queue_init(q);
>> +if (ret) {
>> +ctx->state = DVB_VB2_STATE_NONE;
>> +dprintk(1, "[%s] errno=%d\n", ctx->name, ret);
>> +return ret;
>> +}
>> +
>> +mutex_init(&ctx->mutex);
>> +spin_lock_init(&ctx->slock);
>> +INIT_LIST_HEAD(&ctx->dvb_q);
>> +
>> +strncpy(ctx->name, name, DVB_VB2_NAME_MAX);
>
> I believe strlcpy is recommended.
>
>> +ctx->nonblocking = nonblocking;
>> +ctx->state = DVB_VB2_STATE_INIT;
>> +
>> +dprintk(3, "[%s]\n", ctx->name);
>> +
>> +return 0;
>> +}
>> diff --git a/include/uapi/linux/dvb/dmx.h b/include/uapi/linux/dvb/dmx.h
>> index c10f1324b4ca..e212aa18ad78 100644
>> --- a/include/uapi/linux/dvb/dmx.h
>> +++ b/include/uapi/linux/dvb/dmx.h
>> @@ -211,6 +211,64 @@ struct dmx_stc {
>> __u64 stc;
>> };
>>
>> +/**
>> + * struct dmx_buffer - dmx buffer info
>> + *
>> + * @index: id number of the buffer
>> + * @bytesused: number of bytes occupied by data in the buffer
>> (payload);
>> + * @offset: for buffers with memory == DMX_MEMORY_MMAP;
>> + * offset from the start of the device memory for this plane,
>> + * (or a "cookie" that should be passed to mmap() as offset)
>
> Since we only support MMAP this is always a 'cookie' in practice. So I think
> this
> should just be:
>
> A "cookie" that should be passed to mmap() as offset.
>
>> + * @length: size in bytes of the buffer
>> + *
>> + * Contains data exchanged by application and driver using one of the
>> streaming
>> + * I/O methods.
>> + */
>> +struct dmx_buffer {
>> +__u32 index;
>> +__u32 bytesused;
>> +__u32 offset;
>
> I suggest making this a __u64: that way we can handle pointers as well in
> the future if we need them (as we do for the USERPTR case for V4L2).
>
> Should this also be wrapped in a union? Useful when adding dmabuf support in
> the
> future.
>
> Do you think there is any use-case for multiplanar formats in the future?
> With perhaps meta data in a separate plane? Having to add support for this
> later
> has proven to be very painful, so we need to be as certain as possible that
> this isn't going to happen. Otherwise it's better to prepare for this right
> now.
>
>> +__u32 length;
>> +__u32 reserved[4];
>
> I do believe you need a memory field as well. It's only MMAP today, but in
> the future DMABUF will most likely be supported as well and you need to be
> able to tell what memory mode is being used.
>
>> +};
There is no 'flags' field here. But without that you cannot check the buffer
states, esp. the ERROR state. Or can that never happen?
Would a timestamp field be useful, if only for debugging?
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] media: videobuf2: Add new uAPI for DVB streaming I/O
Em Mon, 8 Jan 2018 14:54:51 +0100
Hans Verkuil escreveu:
> Hi Mauro,
>
> Thanks for this patch series, nice to see this moving forward.
>
> Some comments below (note the wrong queue_setup code in particular since that
> relates to my comment about the '[PATCH v3] media: videobuf2-core: don't go
> out
> of the buffer range' patch).
>
> On 12/21/2017 05:18 PM, Mauro Carvalho Chehab wrote:
> > From: Satendra Singh Thakur
> >
> > Adds a new uAPI for DVB to use streaming I/O which is implemented
> > based on videobuf2, using those new ioctls:
> >
> > - DMX_REQBUFS: Request kernel to allocate buffers which count and size
> > are dedicated by user.
> > - DMX_QUERYBUF: Get the buffer information like a memory offset which
> > will mmap() and be shared with user-space.
> > - DMX_EXPBUF: Just for testing whether buffer-exporting success or not.
> > - DMX_QBUF: Pass the buffer to kernel-space.
> > - DMX_DQBUF:Get back the buffer which may contain TS data.
> >
> > Originally developed by: Junghak Sung , as
> > seen at:
> > https://patchwork.linuxtv.org/patch/31613/
> > https://patchwork.kernel.org/patch/7334301/
> >
> > The original patch was written before merging VB2-core functionalities
> > upstream. When such series was added, several adjustments were made,
> > fixing some issues with V4L2, causing the original patch to be
> > non-trivially rebased.
> >
> > After rebased, a few bugs in the patch were fixed. The patch was
> > also enhanced it and polling functionality got added.
> >
> > The main changes over the original patch are:
> >
> > dvb_vb2_fill_buffer():
> > - Set the size of the outgoing buffer after while loop using
> > vb2_set_plane_payload;
> >
> > - Added NULL check for source buffer as per normal convention
> > of demux driver, this is called twice, first time with valid
> > buffer second time with NULL pointer, if its not handled,
>
> its -> it's
>
> > it will result in crash
> >
> > - Restricted spinlock for only list_* operations
> >
> > dvb_vb2_init():
> > - Restricted q->io_modes to only VB2_MMAP as its the only
> > supported mode
> >
> > dvb_vb2_release():
> > - Replaced the && in if condiion with &, because otherwise
>
> condition
>
> > it was always getting satisfied.
> >
> > dvb_vb2_stream_off():
> > - Added list_del code for enqueud buffers upon stream off
>
> enqueued
>
> >
> > dvb_vb2_poll():
> > - Added this new function in order to support polling
> >
> > dvb_demux_poll() and dvb_dvr_poll()
> > - dvb_vb2_poll() is now called from these functions
> >
> > - Ported this patch and latest videobuf2 to lower kernel versions and
> > tested auto scan.
Too late to change it, as the patch was already merged, as per
Michel's suggestion.
> > [mche...@s-opensource.com: checkpatch fixes]
> > Co-developed-by: Junghak Sung
> > Signed-off-by: Junghak Sung
> > Signed-off-by: Geunyoung Kim
> > Acked-by: Seung-Woo Kim
> > Acked-by: Inki Dae
> > Signed-off-by: Satendra Singh Thakur
> > Signed-off-by: Mauro Carvalho Chehab
> > ---
> > drivers/media/dvb-core/Makefile | 2 +-
> > drivers/media/dvb-core/dmxdev.c | 196 +++---
> > drivers/media/dvb-core/dmxdev.h | 4 +
> > drivers/media/dvb-core/dvb_vb2.c | 423
> > +++
> > drivers/media/dvb-core/dvb_vb2.h | 72 +++
> > include/uapi/linux/dvb/dmx.h | 66 +-
> > 6 files changed, 733 insertions(+), 30 deletions(-)
> > create mode 100644 drivers/media/dvb-core/dvb_vb2.c
> > create mode 100644 drivers/media/dvb-core/dvb_vb2.h
> >
> > diff --git a/drivers/media/dvb-core/Makefile
> > b/drivers/media/dvb-core/Makefile
> > index 47e2e391bfb8..bbc65dfa0a8e 100644
> > --- a/drivers/media/dvb-core/Makefile
> > +++ b/drivers/media/dvb-core/Makefile
> > @@ -7,6 +7,6 @@ dvb-net-$(CONFIG_DVB_NET) := dvb_net.o
> >
> > dvb-core-objs := dvbdev.o dmxdev.o dvb_demux.o \
> > dvb_ca_en50221.o dvb_frontend.o\
> > -$(dvb-net-y) dvb_ringbuffer.o dvb_math.o
> > +$(dvb-net-y) dvb_ringbuffer.o dvb_vb2.o dvb_math.o
> >
> > obj-$(CONFIG_DVB_CORE) += dvb-core.o
> > diff --git a/drivers/media/dvb-core/dmxdev.c
> > b/drivers/media/dvb-core/dmxdev.c
> > index 18e4230865be..4cbb9003a1ed 100644
> > --- a/drivers/media/dvb-core/dmxdev.c
> > +++ b/drivers/media/dvb-core/dmxdev.c
> > @@ -28,6 +28,7 @@
> > #include
> > #include
> > #include "dmxdev.h"
> > +#include "dvb_vb2.h"
> >
> > static int debug;
> >
> > @@ -138,14 +139,8 @@ static int dvb_dvr_open(struct inode *inode, struct
> > file *file)
> > return -ENODEV;
> > }
> >
> > - if ((file->f_flags & O_ACCMODE) == O_RDWR) {
> > - if (!(dmxdev->capabilities & DMXDEV_CAP_DUPLEX)) {
> > - mutex_unlock(&dmxdev->mutex);
> > - return -EOPNOTSUPP;
> > - }
> > -
Re: [PATCH 02/11] media: videobuf2: Add new uAPI for DVB streaming I/O
Em Mon, 8 Jan 2018 15:26:50 +0100
Hans Verkuil escreveu:
> A quick follow-up:
>
> On 01/08/2018 02:54 PM, Hans Verkuil wrote:
> >> +/*
> >> + * Videobuf operations
> >> + */
> >> +int dvb_vb2_init(struct dvb_vb2_ctx *ctx, const char *name, int
> >> nonblocking)
> >> +{
> >> + struct vb2_queue *q = &ctx->vb_q;
> >> + int ret;
> >> +
> >> + memset(ctx, 0, sizeof(struct dvb_vb2_ctx));
> >> + q->type = DVB_BUF_TYPE_CAPTURE;
> >
> > We don't support DVB_BUF_TYPE_OUTPUT? Shouldn't this information come from
> > the
> > driver?
> >
> >> + /**capture type*/
> >
> > Why /** ?
> >
> >> + q->is_output = 0;
> >
> > Can be dropped unless we support DVB_BUF_TYPE_OUTPUT.
> >
> >> + /**only mmap is supported currently*/
> >
> > /** ?
> >
> >> + q->io_modes = VB2_MMAP;
> >> + q->drv_priv = ctx;
> >> + q->buf_struct_size = sizeof(struct dvb_buffer);
> >> + q->min_buffers_needed = 1;
> >> + q->ops = &dvb_vb2_qops;
> >> + q->mem_ops = &vb2_vmalloc_memops;
> >> + q->buf_ops = &dvb_vb2_buf_ops;
> >> + q->num_buffers = 0;
> >
> > Not needed, is zeroed in the memset above.
> >
> > I'm also missing q->timestamp_flags: should be set to
> > V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC.
>
> Ignore this, see my comments later on.
>
> >
> >> + ret = vb2_core_queue_init(q);
> >> + if (ret) {
> >> + ctx->state = DVB_VB2_STATE_NONE;
> >> + dprintk(1, "[%s] errno=%d\n", ctx->name, ret);
> >> + return ret;
> >> + }
> >> +
> >> + mutex_init(&ctx->mutex);
> >> + spin_lock_init(&ctx->slock);
> >> + INIT_LIST_HEAD(&ctx->dvb_q);
> >> +
> >> + strncpy(ctx->name, name, DVB_VB2_NAME_MAX);
> >
> > I believe strlcpy is recommended.
> >
> >> + ctx->nonblocking = nonblocking;
> >> + ctx->state = DVB_VB2_STATE_INIT;
> >> +
> >> + dprintk(3, "[%s]\n", ctx->name);
> >> +
> >> + return 0;
> >> +}
>
>
>
> >> diff --git a/include/uapi/linux/dvb/dmx.h b/include/uapi/linux/dvb/dmx.h
> >> index c10f1324b4ca..e212aa18ad78 100644
> >> --- a/include/uapi/linux/dvb/dmx.h
> >> +++ b/include/uapi/linux/dvb/dmx.h
> >> @@ -211,6 +211,64 @@ struct dmx_stc {
> >>__u64 stc;
> >> };
> >>
> >> +/**
> >> + * struct dmx_buffer - dmx buffer info
> >> + *
> >> + * @index:id number of the buffer
> >> + * @bytesused:number of bytes occupied by data in the buffer
> >> (payload);
> >> + * @offset: for buffers with memory == DMX_MEMORY_MMAP;
> >> + *offset from the start of the device memory for this
> >> plane,
> >> + *(or a "cookie" that should be passed to mmap() as
> >> offset)
> >
> > Since we only support MMAP this is always a 'cookie' in practice. So I
> > think this
> > should just be:
> >
> > A "cookie" that should be passed to mmap() as offset.
> >
> >> + * @length: size in bytes of the buffer
> >> + *
> >> + * Contains data exchanged by application and driver using one of the
> >> streaming
> >> + * I/O methods.
> >> + */
> >> +struct dmx_buffer {
> >> + __u32 index;
> >> + __u32 bytesused;
> >> + __u32 offset;
> >
> > I suggest making this a __u64: that way we can handle pointers as well in
> > the future if we need them (as we do for the USERPTR case for V4L2).
> >
> > Should this also be wrapped in a union? Useful when adding dmabuf support
> > in the
> > future.
> >
> > Do you think there is any use-case for multiplanar formats in the future?
> > With perhaps meta data in a separate plane? Having to add support for this
> > later
> > has proven to be very painful, so we need to be as certain as possible that
> > this isn't going to happen. Otherwise it's better to prepare for this right
> > now.
> >
> >> + __u32 length;
> >> + __u32 reserved[4];
> >
> > I do believe you need a memory field as well. It's only MMAP today, but in
> > the future DMABUF will most likely be supported as well and you need to be
> > able to tell what memory mode is being used.
> >
> >> +};
>
> There is no 'flags' field here. But without that you cannot check the buffer
> states, esp. the ERROR state. Or can that never happen?
On DVB, there is a protocol stack there that allows checking errors,
either MPEG-TS (current standards) or IP/MMT - for the new, yet to be
implemented ATSC version 3 standard.
Even if we add an error state, userspace will just ignore, as it will
need to verify the packet CRC checks.
> Would a timestamp field be useful, if only for debugging?
I don't see how a timestamp will help here for debugging. Probably,
adding event trace points would work better, but we have those
already at vb2-core.
Anyway, as this is kAPI only, we can add it later as needed.
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: remove stale crossrelease_stacktrace parameter
The cross-release lockdep functionality has been removed in
e966eaeeb623f0997 ("locking/lockdep: Remove the cross-release locking
checks"), leaving the kernel parameter docs behind. The code handling
the parameter does not exist so this is a plain documentation change.
Signed-off-by: David Sterba
---
Documentation/admin-guide/kernel-parameters.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index af7104aaffd9..a626465dd877 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -713,9 +713,6 @@
It will be ignored when crashkernel=X,high is not used
or memory reserved is below 4G.
- crossrelease_fullstack
- [KNL] Allow to record full stack trace in cross-release
-
cryptomgr.notests
[KNL] Disable crypto self-tests
--
2.15.1
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RESEND] cgroup, docs: document the root cgroup behavior of cpu and io controllers
Hello, On 08.01.2018 13:15, Tejun Heo wrote: > Hello, > > On Thu, Jan 04, 2018 at 10:57:00PM +0100, Maciej S. Szmigiero wrote: >> Currently, cgroups v2 documentation contains only a generic remark that >> "How resource consumption in the root cgroup is governed is up to each >> controller", which isn't really telling users much, who need to dig in the >> code and / or commit messages to learn the exact behavior. > > I don't think we want to fully guarantee the current behavior. On the > scheduler side, I don't think it's likely to change but blkio side > *might* change. Can you please collect the root behavior in a separte > section and clearly note that the behaviors are subject to change? Will do. > Thanks. > Maciej -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: security/credentials.rst: explain need to sort group_list
On Sat, 6 Jan 2018 12:20:13 -0800 Matthew Wilcox wrote: > I've been thinking about all the kernel-doc we have that's completely > unincorporated. I've also been thinking about core-api/kernel-api.rst > which to my mind is completely unreadable in its current form -- look at > https://www.kernel.org/doc/html/latest/core-api/kernel-api.html and you > wouldn't really know there's anything in it beyond the List Management > Functions. Yes, it's a mess. > I think the right path forward is to have kernel-api.rst be the dumping > ground for all the files with kernel-doc but nothing more. That gives > us somewhere to link to. That's kind of what it is now :) Note that we have a script now (scripts/find-unused-docs.sh) that can seek out kerneldoc comments that aren't yet pulled in to the RST document tree. > Then we need little stories about how all the functions in a subsystem > fit together. For example, we can create a list.rst which explains how > this is a doubly-linked list that you use by embedding a list_head into > your data structure, and has O(1) insertion/deletion, etc, etc. Then we > would move all the list.h kernel-doc from kernel-api.rst into list.rst. > > Is this a reasonable strategy to follow? Does anyone have a better > strategy? That more-or-less corresponds to what I've been aiming at. All of Documentation/ currently is a bit of a dumping ground; I'd really like to knit it together into something coherent and useful. Progress on that front has been slower than I would have liked - I've been distracted by a number of other things. Funny, I've never heard of that happening before. The "little stories", incidentally, can also go into DOC: sections in the source itself. There's a bit of tension, though, between doing that and putting the stories in the RST files. The former approach puts the docs where they might be most useful and most likely to be updated, but it can also leave the RST files as a collection of kerneldoc directives that is rather unhelpful to read in unprocessed form. Since the whole idea is to not require any sort of processing to make the docs useful, I don't entirely like that outcome. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: security/credentials.rst: explain need to sort group_list
On Mon, 08 Jan 2018 10:39:14 +1100 NeilBrown wrote: > > There is value in using the c:func syntax, as it will generate > > cross-references to the kerneldoc comments for those functions. In this > > case, it would appear that these comments exist, but nobody has pulled > > them into the docs yet. I took the liberty of adding :c:func: references > > to this patch on its way into docs-next so that things will Just Work on > > that happy day when somebody adds the function documentation. > > Is this the sort of thing that might result in that happy day? > I didn't spend tooo much time on it, in case including the > kernel-doc in credentials.rst like this was the wrong direction. >From a very quick look, yes. I'll take a closer look soon. Life has been a bit ... busy ... around here... Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 2/7] soc: qcom: Add device tree binding for GENI SE
On 1/2/2018 8:46 AM, Rob Herring wrote:
On Wed, Dec 27, 2017 at 09:27:21AM -0700, Karthikeyan Ramasubramanian wrote:
Add device tree binding support for the QCOM GENI SE driver.
Signed-off-by: Karthikeyan Ramasubramanian
---
.../devicetree/bindings/soc/qcom/qcom,geni-se.txt | 15 +++
1 file changed, 15 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
new file mode 100644
index 000..5108b62
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
@@ -0,0 +1,15 @@
+Qualcomm Technologies, Inc. GENI Serial Engine Driver
+
+GENI Serial Engine Driver manages the GENI firmware based Qualcomm Universal
+Peripheral (QUP) Wrapper. GENI SE Driver also manages the common aspects of
+individual Serial Engines that composes the QUP Wrapper.
Bindings describe h/w, not drivers.
I will update the bindings to describe just the h/w and remove any
driver description.
+
+Required properties:
+- compatible: Must be "qcom,geni-se-qup".
Only one version of the h/w?
There is more than one hardware version. The h/w provides registers to
identify the hardware version. The driver currently uses those registers
to support any version-specific operations. So I am not sure if the
compatible field needs to reflect the h/w version.
+- reg: Must contain QUP register address and length.
+
+Example:
+ qup_0: qcom,geni_se_qup_0@8c {
Don't use '_' in node names.
I will update the bindings to not use '_'.
+ compatible = "qcom,geni-se-qup";
+ reg = <0x8c 0x6000>;
+ }
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Regards,
Karthik.
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 2/7] soc: qcom: Add device tree binding for GENI SE
On 1/2/2018 8:47 AM, Rob Herring wrote: On Wed, Dec 27, 2017 at 09:27:21AM -0700, Karthikeyan Ramasubramanian wrote: Add device tree binding support for the QCOM GENI SE driver. Also, "dt-bindings: ..." is the preferred subject prefix. Same for the rest of the series. I will update the subject-prefix. Signed-off-by: Karthikeyan Ramasubramanian --- .../devicetree/bindings/soc/qcom/qcom,geni-se.txt | 15 +++ 1 file changed, 15 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Regards, Karthik. -- Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 4/7] i2c: Add device tree bindings for GENI I2C Controller
On 1/2/2018 8:51 AM, Rob Herring wrote:
On Wed, Dec 27, 2017 at 09:27:23AM -0700, Karthikeyan Ramasubramanian wrote:
Add device tree binding support for I2C Controller in GENI based
QUP Wrapper.
Signed-off-by: Sagar Dharia
Signed-off-by: Karthikeyan Ramasubramanian
---
.../devicetree/bindings/i2c/i2c-qcom-geni.txt | 39 ++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-qcom-geni.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-qcom-geni.txt
b/Documentation/devicetree/bindings/i2c/i2c-qcom-geni.txt
new file mode 100644
index 000..d2fa9ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-qcom-geni.txt
@@ -0,0 +1,39 @@
+Qualcomm Technologies Inc. GENI based I2C Controller driver
+
+Required properties:
+ - compatible: Should be:
+ * "qcom,i2c-geni.
Only 1 version?
The Serial Engine used by I2C protocol has the same version as the QUP
h/w version. The QUP Wrapper driver exposes an interface function to get
the h/w version so that I2C controller driver can support
version-specific operations, if any.
+ - reg: Should contain QUP register address and length.
+ - interrupts: Should contain I2C interrupt.
+ - clocks: Serial engine core clock, and AHB clocks needed by the device.
Are there really clocks for a firmware based device or these are just
clocks in the parent serial engine?
The clocks are required to derive the protocol clock. The clocks are
also required by the Serial Engine to access the System Memory during
DMA mode of operation.
+ - pinctrl-names/pinctrl-0/1: The GPIOs assigned to this core. The names
+ should be "active" and "sleep" for the pin confuguration when core is active
+ or when entering sleep state.
+ - #address-cells: Should be <1> Address cells for i2c device address
+ - #size-cells: Should be <0> as i2c addresses have no size component
+ - qcom,wrapper-core: Wrapper QUP core containing this I2C controller.
Probably these devices should be child nodes of the QUP core node.
I will update it in the next patch.
+
+Optional property:
+ - qcom,clk-freq-out : Desired I2C bus clock frequency in Hz.
+ When missing default to 40Hz.
There's a standard property for this.
I will update to use the standard property.
+
+Child nodes should conform to i2c bus binding.
+
+Example:
+
+i2c@a94000 {
+ compatible = "qcom,i2c-geni";
+ reg = <0xa94000 0x4000>;
+ interrupts = ;
+ clock-names = "se-clk", "m-ahb", "s-ahb";
+ clocks = <&clock_gcc GCC_QUPV3_WRAP0_S5_CLK>,
+ <&clock_gcc GCC_QUPV3_WRAP_0_M_AHB_CLK>,
+ <&clock_gcc GCC_QUPV3_WRAP_0_S_AHB_CLK>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&qup_1_i2c_5_active>;
+ pinctrl-1 = <&qup_1_i2c_5_sleep>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ qcom,wrapper-core = <&qup_0>;
+ qcom,clk-freq-out = <40>;
+};
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Regards,
Karthik.
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Tools to fix/prevent broken Documentation file references
Hello,
I personally am happy with the more organized Documentation/ tree. But
as everyone knows, there's still a bit of breakage. Not the most fun
to fix. However, it seems some tools could help ease this process /
prevent future breakage. I listed a couple below. If either seem worth
pursuing, I'd be happy to take up implementing them. Else, or if
they've already been discussed, please let me know.
(1) Currently, checkpatch.pl checks for deleted/moved/added files and
asks if MAINTAINERS needs to be updated (if MAINTAINERS isn't modified
in the diff). It'd be nice to extend checkpatch.pl to, when it sees a
deleted/moved file, grep for that file name. If there are any hits,
have it be an error. Perhaps people might want this only under the
--strict flag though...
(2) Part of the process of updating references could be automated.
Here's a experimentation-quality script that uses git to find what the
file was renamed to:
set -o pipefail
guess_new_name() {
old_name=$1
git rev-list -n 1 HEAD -- "$old_name" |
xargs -r git show |
grep -A 1 "^rename from $old_name$" |
tail -n 1 |
cut -d' ' -f3-
}
for file in $(git ls-files | grep -v '^scripts/')
do
for old_name in $(grep -hoP 'Documentation/[^\s$%"*{}<>\]\[\(\)\\）]+\b'
"$file")
do
[ -e "$old_name" ] || {
printf '%s: %s -> ' "$file" "$old_name"
new_name=$(guess_new_name "$old_name")
if [ $? -eq 0 ]
then
echo "$new_name"
sed -i'' "s|$old_name|$new_name|" "$file" || exit 1
else
echo NONE
fi
}
done
done
It works quite well. I thought it might be worth improving a little
(caching, recursively making sure the new name exists, ...?) and
putting it in the tree.
Of course, option (1) naturally works for all files, not just
Documentation/ files. Option (2) could be generic as well I guess,
with a better regex (and a longer runtime...).
Cheers,
Genki
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
