* powerpc/ps3: Set driver coherent_dma_mask
From: Michael Ellerman @ 2018-07-23 15:11 UTC (permalink / raw)
To: Geoff Levand, Alan Stern, Takashi Iwai, Jaroslav Kysela
Cc: linux-usb, linuxppc-dev@lists.ozlabs.org
On Wed, 2018-07-18 at 22:08:33 UTC, Geoff Levand wrote:
> Set the coherent_dma_mask for the PS3 ehci, ohci, and snd devices.
>
> Silences WARN_ON_ONCE messages emitted by the dma_alloc_attrs() routine.
>
> Reported-by: Fredrik Noring <noring@nocrew.org>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/48e91846865cd61bfdb701eb737de2
cheers
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: powerpc/ps3: Set driver coherent_dma_mask
From: Michael Ellerman @ 2018-07-23 15:11 UTC (permalink / raw)
To: Geoff Levand, Alan Stern, Takashi Iwai, Jaroslav Kysela
Cc: linux-usb, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <068ebcfa-7cd0-bd06-42e7-577a4624f0b0@infradead.org>
On Wed, 2018-07-18 at 22:08:33 UTC, Geoff Levand wrote:
> Set the coherent_dma_mask for the PS3 ehci, ohci, and snd devices.
>
> Silences WARN_ON_ONCE messages emitted by the dma_alloc_attrs() routine.
>
> Reported-by: Fredrik Noring <noring@nocrew.org>
> Signed-off-by: Geoff Levand <geoff@infradead.org>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/48e91846865cd61bfdb701eb737de2
cheers
^ permalink raw reply
* Re: [PATCH 4.4 000/107] 4.4.144-stable review
From: Nathan Chancellor @ 2018-07-23 15:11 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches,
ben.hutchings, lkft-triage, stable
In-Reply-To: <20180723122413.003644357@linuxfoundation.org>
On Mon, Jul 23, 2018 at 02:40:54PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.144 release.
> There are 107 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jul 25 12:23:53 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.144-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Merged, compiled with -Werror, and installed onto my Pixel 2 XL.
No initial issues noticed in dmesg or general usage.
Thanks!
Nathan
^ permalink raw reply
* Re: [RFC PATCH ghak90 (was ghak32) V3 02/10] audit: log container info of syscalls
From: Richard Guy Briggs @ 2018-07-23 15:11 UTC (permalink / raw)
To: Steve Grubb
Cc: Paul Moore, cgroups, containers, linux-api, linux-audit,
linux-fsdevel, linux-kernel, netdev, ebiederm, luto, carlos,
dhowells, viro, simo, Eric Paris, serge
In-Reply-To: <3318670.y8SpQ3RC2W@x2>
On 2018-07-23 09:19, Steve Grubb wrote:
> On Sunday, July 22, 2018 4:55:10 PM EDT Richard Guy Briggs wrote:
> > On 2018-07-22 09:32, Steve Grubb wrote:
> > > On Saturday, July 21, 2018 4:29:30 PM EDT Richard Guy Briggs wrote:
> > > > > > + * audit_log_contid - report container info
> > > > > > + * @tsk: task to be recorded
> > > > > > + * @context: task or local context for record
> > > > > > + * @op: contid string description
> > > > > > + */
> > > > > > +int audit_log_contid(struct task_struct *tsk,
> > > > > > + struct audit_context *context, char
> > > > > > *op)
> > > > > > +{
> > > > > > + struct audit_buffer *ab;
> > > > > > +
> > > > > > + if (!audit_contid_set(tsk))
> > > > > > + return 0;
> > > > > > + /* Generate AUDIT_CONTAINER record with container ID */
> > > > > > + ab = audit_log_start(context, GFP_KERNEL, AUDIT_CONTAINER);
> > > > > > + if (!ab)
> > > > > > + return -ENOMEM;
> > > > > > + audit_log_format(ab, "op=%s contid=%llu",
> > > > > > + op, audit_get_contid(tsk));
> > > > >
> > > > > Can you explain your reason for including an "op" field in this
> > > > > record
> > > > > type? I've been looking at the rest of the patches in this patchset
> > > > > and it seems to be used more as an indicator of the record's
> > > > > generating context rather than any sort of audit container ID
> > > > > operation.
> > > >
> > > > "action" might work, but that's netfilter and numeric... "kind"?
> > > > Nothing else really seems to fit from a field name, type or lack of
> > > > searchability perspective.
> > > >
> > > > Steve, do you have an opinion?
> > >
> > > We only have 1 sample event where we have op=task. What are the other
> > > possible values?
> >
> > For the AUDIT_CONTAINER record we have op= "task", "target" (from the
> > ptrace and signals patch), "tty".
> >
> > For the AUDIT_CONTAINER_ID record we have "op=set".
>
> Since the purpose of this record is to log the container id, I think that is
> all that is needed. We can get the context from the other records in the
> event. I'd suggest dropping the "op" field.
Ok, the information above it for two different audit container
identifier records. Which one should drop the "op=" field? Both? Or
just the AUDIT_CONTAINER record? The AUDIT_CONTAINER_ID record (which
might be renamed) could use it to distinguish a "set" record from a
dropped audit container identifier that is no longer registered by any
task or namespace.
> -Steve
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/6] accel/tcg: Support execution from MMIO and small MMU regions
From: Cédric Le Goater @ 2018-07-23 15:11 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel
Cc: patches, Richard Henderson, Emilio G . Cota, Paolo Bonzini,
Edgar E. Iglesias, KONRAD Frederic
In-Reply-To: <20180710160013.26559-1-peter.maydell@linaro.org>
On 07/10/2018 06:00 PM, Peter Maydell wrote:
> This series adds support to TCG for executing from MMIO regions
> and small MMU regions. The basic principle is that if get_page_addr_code()
> finds that the region is not backed by a full page of RAM then it
> returns -1, and tb_gen_code() then generates a non-cached TB
> containing a single instruction. Execution from these regions
> thus performs the instruction fetch every time, ensuring that we
> get the read-from-MMIO and check-small-MMU-region permissions
> checks right.
>
> This means that the code path for "generate bus fault for failing
> to load an instruction" no longer goes through get_page_addr_code(),
> but instead via each target's translate code and its calls to
> the cpu_ld*_code() or similar functions. Patch 1 makes sure we
> can distinguish insn fetches from data loads when generating the
> bus fault exceptions. (Aside: I have assumed that all cpu_ld*_code()
> loads should trigger iside faults rather than dside. Hopefully this
> is true...)
>
> Patches 2 and 3 make trivial fixes to various callers of
> get_page_addr_code(); patch 4 does the work of generating our
> single-insn TBs. Patch 5 can then remove all the code that
> (mis)handles MMIO regions from get_page_addr_code(). Finally
> patch 6 drops the target/arm workarounds for not having support
> for executing from small MPU regions.
>
> Note for the Xilinx folks: this patchset makes the mmio-exec
> testcase for running from the SPI flash pass. Cedric: you might
> like to test the aspeed image you had that relies on execution
> from an MMIO region too.
For the series,
Tested-by: Cédric Le Goater <clg@kaod.org>
Thanks,
C.
>
> The diffstat is pretty satisfying for a patchset that adds
> a feature, but it actually undersells it: this code renders the
> hw/misc/mmio_interface.c and the mmio_ptr related code in memory.c
> and the xilinx-spips device all obsolete, so there are another
> couple of hundred lines of code to be deleted there. I opted not
> to include that in this patchset, for ease of review.
>
> NB: I tested this with icount, but there are potentially
> some weird things that could happen with interactions between
> icount's io-recompile and execution from an MMIO device
> that returns different instructions each time it's read.
>
> thanks
> -- PMM
>
>
> Peter Maydell (6):
> accel/tcg: Pass read access type through to io_readx()
> accel/tcg: Handle get_page_addr_code() returning -1 in hashtable
> lookups
> accel/tcg: Handle get_page_addr_code() returning -1 in
> tb_check_watchpoint()
> accel/tcg: tb_gen_code(): Create single-insn TB for execution from
> non-RAM
> accel/tcg: Return -1 for execution from MMIO regions in
> get_page_addr_code()
> target/arm: Allow execution from small regions
>
> accel/tcg/softmmu_template.h | 11 ++--
> include/qom/cpu.h | 6 +++
> accel/tcg/cpu-exec.c | 3 ++
> accel/tcg/cputlb.c | 100 +++++------------------------------
> accel/tcg/translate-all.c | 23 +++++++-
> memory.c | 3 +-
> target/arm/helper.c | 23 --------
> 7 files changed, 52 insertions(+), 117 deletions(-)
>
^ permalink raw reply
* Re: [Qemu-arm] [PATCH 0/6] accel/tcg: Support execution from MMIO and small MMU regions
From: Cédric Le Goater @ 2018-07-23 15:11 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel
Cc: patches, KONRAD Frederic, Emilio G . Cota, Paolo Bonzini,
Richard Henderson
In-Reply-To: <20180710160013.26559-1-peter.maydell@linaro.org>
On 07/10/2018 06:00 PM, Peter Maydell wrote:
> This series adds support to TCG for executing from MMIO regions
> and small MMU regions. The basic principle is that if get_page_addr_code()
> finds that the region is not backed by a full page of RAM then it
> returns -1, and tb_gen_code() then generates a non-cached TB
> containing a single instruction. Execution from these regions
> thus performs the instruction fetch every time, ensuring that we
> get the read-from-MMIO and check-small-MMU-region permissions
> checks right.
>
> This means that the code path for "generate bus fault for failing
> to load an instruction" no longer goes through get_page_addr_code(),
> but instead via each target's translate code and its calls to
> the cpu_ld*_code() or similar functions. Patch 1 makes sure we
> can distinguish insn fetches from data loads when generating the
> bus fault exceptions. (Aside: I have assumed that all cpu_ld*_code()
> loads should trigger iside faults rather than dside. Hopefully this
> is true...)
>
> Patches 2 and 3 make trivial fixes to various callers of
> get_page_addr_code(); patch 4 does the work of generating our
> single-insn TBs. Patch 5 can then remove all the code that
> (mis)handles MMIO regions from get_page_addr_code(). Finally
> patch 6 drops the target/arm workarounds for not having support
> for executing from small MPU regions.
>
> Note for the Xilinx folks: this patchset makes the mmio-exec
> testcase for running from the SPI flash pass. Cedric: you might
> like to test the aspeed image you had that relies on execution
> from an MMIO region too.
For the series,
Tested-by: Cédric Le Goater <clg@kaod.org>
Thanks,
C.
>
> The diffstat is pretty satisfying for a patchset that adds
> a feature, but it actually undersells it: this code renders the
> hw/misc/mmio_interface.c and the mmio_ptr related code in memory.c
> and the xilinx-spips device all obsolete, so there are another
> couple of hundred lines of code to be deleted there. I opted not
> to include that in this patchset, for ease of review.
>
> NB: I tested this with icount, but there are potentially
> some weird things that could happen with interactions between
> icount's io-recompile and execution from an MMIO device
> that returns different instructions each time it's read.
>
> thanks
> -- PMM
>
>
> Peter Maydell (6):
> accel/tcg: Pass read access type through to io_readx()
> accel/tcg: Handle get_page_addr_code() returning -1 in hashtable
> lookups
> accel/tcg: Handle get_page_addr_code() returning -1 in
> tb_check_watchpoint()
> accel/tcg: tb_gen_code(): Create single-insn TB for execution from
> non-RAM
> accel/tcg: Return -1 for execution from MMIO regions in
> get_page_addr_code()
> target/arm: Allow execution from small regions
>
> accel/tcg/softmmu_template.h | 11 ++--
> include/qom/cpu.h | 6 +++
> accel/tcg/cpu-exec.c | 3 ++
> accel/tcg/cputlb.c | 100 +++++------------------------------
> accel/tcg/translate-all.c | 23 +++++++-
> memory.c | 3 +-
> target/arm/helper.c | 23 --------
> 7 files changed, 52 insertions(+), 117 deletions(-)
>
^ permalink raw reply
* Re: [Qemu-devel] [RFC PATCH] hw/s390x/virtio-ccw: Consolidate calls to virtio_ccw_unrealize()
From: Cornelia Huck @ 2018-07-23 15:12 UTC (permalink / raw)
To: Thomas Huth
Cc: David Hildenbrand, qemu-s390x, Christian Borntraeger,
Michael S. Tsirkin, Alexander Graf, Richard Henderson, qemu-devel
In-Reply-To: <1532356951-18210-1-git-send-email-thuth@redhat.com>
On Mon, 23 Jul 2018 16:42:31 +0200
Thomas Huth <thuth@redhat.com> wrote:
> Currently, every virtio-ccw device explicitely sets its unrealize
> function to virtio_ccw_unrealize() in its class_init function.
> We can simplify this by using this unrealize function in the common
> virtio_ccw_busdev_unrealize() function if no other device unrealize
> function has been set.
Sounds sensible to consolidate that.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
> hw/s390x/virtio-ccw.c | 18 +++++-------------
> 1 file changed, 5 insertions(+), 13 deletions(-)
>
> @@ -1705,7 +1695,11 @@ static void virtio_ccw_busdev_unrealize(DeviceState *dev, Error **errp)
> VirtioCcwDevice *_dev = (VirtioCcwDevice *)dev;
> VirtIOCCWDeviceClass *_info = VIRTIO_CCW_DEVICE_GET_CLASS(dev);
>
> - _info->unrealize(_dev, errp);
> + if (_info->unrealize) {
> + _info->unrealize(_dev, errp);
> + } else {
> + virtio_ccw_unrealize(_dev, errp);
> + }
However, I think it is better to call virtio_ccw_unrealize()
unconditionally here (as we want to make sure it is always invoked) and
call ->unrealize from there if set. That also mirrors what we do for
realize.
> }
>
> static void virtio_ccw_busdev_unplug(HotplugHandler *hotplug_dev,
^ permalink raw reply
* Re: [PATCH 4.9 00/28] 4.9.115-stable review
From: Nathan Chancellor @ 2018-07-23 15:12 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches,
ben.hutchings, lkft-triage, stable
In-Reply-To: <20180723122425.241418073@linuxfoundation.org>
On Mon, Jul 23, 2018 at 02:25:00PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.115 release.
> There are 28 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Jul 25 12:24:13 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.115-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Merged, compiled with -Werror, and installed onto my OnePlus 6.
No initial issues noticed in dmesg or general usage.
Thanks!
Nathan
^ permalink raw reply
* Re: [NOT YET PULL] Trial of labeling lines in code snippets
From: Akira Yokosawa @ 2018-07-23 15:12 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: perfbook, Akira Yokosawa
In-Reply-To: <76c70153-62c6-e675-fc53-9ce233337552@gmail.com>
On 2018/07/24 00:09:37 +0900, Akira Yokosawa wrote:
> On 2018/07/22 15:49:06 -0700, Paul E. McKenney wrote:
>> On Mon, Jul 23, 2018 at 12:43:05AM +0900, Akira Yokosawa wrote:
>>> On 2018/07/21 09:51:03 -0700, Paul E. McKenney wrote:
>>>> On Sat, Jul 21, 2018 at 09:19:53AM +0900, Akira Yokosawa wrote:
>>>>> Hi Paul,
>>>>>
>>>>> So, an experimental branch to label particular lines in code
>>>>> snippets is ready for review.
>>>>> The branch is based on current master of yours.
>>>>>
>>>>> I've converted 4 code snippets in Section 4.2. and updated
>>>>> corresponding code samples (sans forkjoin.c because it is
>>>>> quite simplified in Listing 4.1).
>>>>>
>>>>> Does this approach look reasonable to you?
>>>>
>>>> This does look promising, thank you! Please give me some time to think
>>>> this over a bit. My normal approach would end up with very long labels
>>>> in the code, which might be OK. The argument against is that tying the
>>>> listing caption to the actual code might not be a great thing.
>>>
>>> One idea is to embed meta labels in code samples.
>>> When converting them to a proper Verbatim sources, short labels such
>>> as " //\lnlbl{foo}" can be converted to long ones such as
>>> "%lnlbl[ln:<chapter>:<basename of snippet file>:foo]" in the script
>>> to remove " //".
>>>
>>> To do this, we need to embed extra meta data as comments in sample
>>> code.
>>>
>>> For example, the source of waitall() function (in api-pthread.h) can be
>>> written as the following (in the form of \lnlbl{}):
>>>
>>> ----
>>> /*
>>> * Wait on all child processes.
>>> */
>>> static __inline__ void waitall(void)
>>> {
>>> // \begin{snippet}[chapter=toolsoftrade,name=waitall,commandchars=[\%\[\]]
>>> int pid;
>>> int status;
>>>
>>> for (;;) { //\lnlbl{loopa}
>>> pid = wait(&status); //\lnlb{wait}
>>> if (pid == -1) {
>>> if (errno == ECHILD) //\lnlb{ECHILD}
>>> break; //\lnlbl{break}
>>> perror("wait"); //\lnlbl{perror}
>>> exit(EXIT_FAILURE); //\lnlbl{exit}
>>> }
>>> poll(NULL, 0, 1);
>>> } //\lnlbl{loopb}
>>> }
>>> // \end{snippet}
>>> ...
>>> ----
>>>
>>> , and it can be extracted and converted into CodeSamples/api-pthread/waitall.tex
>>> in the following way (including substitution of escape charactors):
>>>
>>> \begin{Verbatim}[commandchars=[\%\[\]]
>>> int pid;
>>> int status;
>>>
>>> for (;;) {%lnlbl[ln:toolsoftrade:waitall:loopa]
>>> pid = wait(&status);%lnlbl[ln:toolsoftrade:waitall:wait]
>>> if (pid == -1) {
>>> if (errno == ECHILD)%lnlbl[ln:toolsoftrade:waitall:ECHILD]
>>> break;%lnlbl[ln:toolsoftrade:break]
>>> perror("wait");%lnlbl[ln:toolsoftrade:perror]
>>> exit(EXIT_FAILURE);%lnlbl[ln:toolsoftrade:exit]
>>> }
>>> poll(NULL, 0, 1);
>>> }%lnlbl[ln:toolsoftrade:loopb]
>>> }
>>> \end{Verbatim}
>>>
>>> This file can be read in toolsoftrade.tex in the following way:
>>>
>>> ---
>>> \begin{listing}[tbp]
>>> \input{CodeSamples/api-pthread/waitall}
>>> \caption{Using the \tco{wait()} Primitive}
>>> \label{lst:toolsoftrade:Using the wait() Primitive}
>>> \end{listing}
>>> ---
>>>
>>> The conversion script should not be so hard to implement.
>>> Update of build scripts should also be possible to automate these
>>> conversions.
>>>
>>> If you'd like to use the caption of the listing in the final labels,
>>> the caption should also be given in the meta \begin{snippet} command.
>>> But for lines in code snippets, using file names as labels sounds
>>> reasonable to me.
>>
>> I believe that your scheme is pretty close. My thought is directory,
>> file, function, label. You have all but file already. That allows
>> captions to change without changing the line label, which seems like a
>> good thing.
>
> In the end, "chapter=foo,name=bar,func=baz" can be expressed as
> "labelprefix=foo:bar:baz in the option to meta \begin{snippet} command.
I meant:
"labelprefix=foo:bar:baz"
Akira
> So you can put any string you like there.
>
> I'll do v2 of the trial branch along this scheme, hopefully
> including build script/Makefile updates. Maybe in a week or so.
>
> Thanks, Akira
>
>>
>> Seem reasonable?
>>
>> Thanx, Paul
>>
>>> Thoughts?
>>>
>>> Thanks, Akira
>>>
>>>>
>>>> Again, looks promising, thank you!
>>>>
>>>> Thanx, Paul
>>>>
>>>>> Thanks, Akira
>>>>>
>>>>> ---
>>>>> The following changes since commit e3191997557e0d33b862e267fb4d5971e879ca07:
>>>>>
>>>>> utilities: Provide scripts instead of broken symlinks (2018-07-18 11:40:57 -0700)
>>>>>
>>>>> are available in the git repository at:
>>>>>
>>>>> https://github.com/akiyks/perfbook trial-fancyvrb
>>>>>
>>>>> for you to fetch changes up to 2154a175e469e6238c89d4c494d204a9ddbaa20a:
>>>>>
>>>>> [EXP] Update hyphen2endash (2018-07-21 09:17:34 +0900)
>>>>>
>>>>> ----------------------------------------------------------------
>>>>> Akira Yokosawa (3):
>>>>> [EXP] toolsoftrade: Add labels in code samples as comments
>>>>> [EXP] toolsoftrade: Reference line in code snippets by label
>>>>> [EXP] Update hyphen2endash
>>>>>
>>>>> CodeSamples/api-pthreads/api-pthreads.h | 14 +-
>>>>> CodeSamples/toolsoftrade/forkjoinvar.c | 10 +-
>>>>> CodeSamples/toolsoftrade/pcreate.c | 5 +-
>>>>> perfbook.tex | 6 +
>>>>> toolsoftrade/toolsoftrade.tex | 221 +++++++++++++++++---------------
>>>>> utilities/hyphen2endash.sh | 3 +
>>>>> 6 files changed, 141 insertions(+), 118 deletions(-)
>>>>>
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH -next v4 2/3] media: ov772x: use SCCB regmap
From: Sakari Ailus @ 2018-07-23 15:13 UTC (permalink / raw)
To: Akinobu Mita
Cc: linux-media, linux-i2c, linux-kernel, Mark Brown, Peter Rosin,
Sebastian Reichel, Wolfram Sang, Sylwester Nawrocki, Jacopo Mondi,
Laurent Pinchart, Hans Verkuil, Sakari Ailus,
Mauro Carvalho Chehab
In-Reply-To: <1531756070-8560-3-git-send-email-akinobu.mita@gmail.com>
Hi Mita-san,
On Tue, Jul 17, 2018 at 12:47:49AM +0900, Akinobu Mita wrote:
> Convert ov772x register access to use SCCB regmap.
>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Peter Rosin <peda@axentia.se>
> Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> Cc: Jacopo Mondi <jacopo+renesas@jmondi.org>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Hans Verkuil <hans.verkuil@cisco.com>
> Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
> Cc: Mauro Carvalho Chehab <mchehab@s-opensource.com>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
> ---
> drivers/media/i2c/Kconfig | 1 +
> drivers/media/i2c/ov772x.c | 192 +++++++++++++++++++--------------------------
> 2 files changed, 82 insertions(+), 111 deletions(-)
I'll pick the two patches up when the SCCB regmap support has reached media
tree master. Thanks.
--
Sakari Ailus
e-mail: sakari.ailus@iki.fi
^ permalink raw reply
* Re: [PATCH 5/7] btrfs: warn for num_devices below 0
From: Anand Jain @ 2018-07-23 14:15 UTC (permalink / raw)
To: dsterba, linux-btrfs
In-Reply-To: <20180723140103.GN26141@twin.jikos.cz>
On 07/23/2018 10:01 PM, David Sterba wrote:
> On Mon, Jul 16, 2018 at 10:58:10PM +0800, Anand Jain wrote:
>> In preparation to de-duplicate a section of code where we deduce the
>> num_devices, use warn instead of bug.
>>
>> Signed-off-by: Anand Jain <anand.jain@oracle.com>
>> ---
>> fs/btrfs/volumes.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>> index 7f4973fc2b52..0f4c512aa6b4 100644
>> --- a/fs/btrfs/volumes.c
>> +++ b/fs/btrfs/volumes.c
>> @@ -3726,7 +3726,7 @@ int btrfs_balance(struct btrfs_fs_info *fs_info,
>> num_devices = fs_info->fs_devices->num_devices;
>> btrfs_dev_replace_read_lock(&fs_info->dev_replace);
>> if (btrfs_dev_replace_is_ongoing(&fs_info->dev_replace)) {
>> - BUG_ON(num_devices < 1);
>> + WARN_ON(num_devices < 1);
>
> I wonder if there any valid cases when there are 0 devices when balance
> is started, ie. before num_devices gets decremented.
num_devices counts the in-memory devices of a fsid.
On a mounted FS num_devices > 0 always.
> The WARN_ON is either redundant or should be turned to a proper sanity
> check.
Yes is redundant. I suggest to delete it.
Thanks, Anand
>> num_devices--;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [MODERATED] Re: BUG: disabling SMT from BIOS
From: Josh Poimboeuf @ 2018-07-23 15:13 UTC (permalink / raw)
To: speck
In-Reply-To: <nycvar.YFH.7.76.1807231600230.997@cbobk.fhfr.pm>
On Mon, Jul 23, 2018 at 04:03:50PM +0200, speck for Jiri Kosina wrote:
> On Mon, 23 Jul 2018, speck for Josh Poimboeuf wrote:
>
> > This permanently disables SMT on my system, regardless of the BIOS
> > settings.
>
> I see, we're setting _NOT_SUPPORTED before the sibling map has been
> established.
>
> > I suspect it needs to be called later, after the other CPUs have been
> > brought online.
>
> Either that, but that will basically mean redefining the CPU_SMT_ENABLED
> meaning, and I actually think the current semantics makes more sense.
>
> How about this instead? (still untested)
That seems like only half the fix, because the 'control' file still
allows you to pretend to turn SMT off and on.
How about this one?
-----
From: Josh Poimboeuf <jpoimboe@redhat.com>
Subject: [PATCH] cpu/hotplug: detect SMT disabled by BIOS
If SMT is disabled in BIOS, the CPU code doesn't properly detect it.
The /sys/devices/system/cpu/smt/control file shows 'on', and the 'l1tf'
vulnerabilities file shows SMT as vulnerable.
Fix it by forcing 'cpu_smt_control' to CPU_SMT_NOT_SUPPORTED in such a
case. Unfortunately the detection can only be done after bringing all
the CPUs online, so we have to overwrite any previous writes to the
variable.
Reported-by: Joe Mario <jmario@redhat.com>
Fixes: f048c399e0f7 ("x86/topology: Provide topology_smt_supported()")
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
kernel/cpu.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 37eec872042b..2bc3d2f5b2a5 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -2125,6 +2125,15 @@ static const struct attribute_group cpuhp_smt_attr_group = {
static int __init cpu_smt_state_init(void)
{
+ /*
+ * If SMT was disabled by BIOS, detect it here, after the CPUs have
+ * been brought online. This ensures the smt/l1tf sysfs entries are
+ * consistent with reality. Note this may overwrite cpu_smt_control's
+ * previous setting.
+ */
+ if (topology_max_smt_threads() == 1)
+ cpu_smt_control = CPU_SMT_NOT_SUPPORTED;
+
return sysfs_create_group(&cpu_subsys.dev_root->kobj,
&cpuhp_smt_attr_group);
}
--
2.17.0
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH for-3.0] qapi: Make 'allow-oob' optional in SchemaInfoCommand
From: Eric Blake @ 2018-07-23 15:14 UTC (permalink / raw)
To: Markus Armbruster, qemu-devel; +Cc: peterx
In-Reply-To: <20180718090557.17248-1-armbru@redhat.com>
On 07/18/2018 04:05 AM, Markus Armbruster wrote:
> Making 'allow-oob' optional in SchemaInfoCommand permits omitting it
> in the common case. Shrinks query-qmp-schema's output from 122.1KiB
> to 118.6KiB for me.
>
> Note that out-of-band execution is still experimental (you have to
> configure the monitor with x-oob=on to use it).
>
> Signed-off-by: Markus Armbruster <armbru@redhat.com>
> ---
I see you have already posted the pull request, but the idea makes sense
to me. In general, making what was previously always output now be
optional can risk confusing a client that depends on the value being
present; but since allow-oob has not always been present, and since it
is still gated by x-oob=on, any sane client using OOB can easily be
coded to treat an absent indication as not allowing oob for that
particular command.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: sync the OVACKFLG to PRIQ consumer register
From: Jean-Philippe Brucker @ 2018-07-23 15:14 UTC (permalink / raw)
To: Zhongmiao, Zhangshaokun,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Leizhen (ThunderTown)
Cc: Will Deacon
In-Reply-To: <8CD08B4737CACA4ABE0228F45E441A916382021E-0LhPdUyVHB9UuCJht5byYAK1hpo4iccwjNknBlVQO8k@public.gmane.org>
Hi,
On 23/07/18 15:43, Zhongmiao wrote:
> Yeah, I haven't tested smmu eventq overflow , so i'm not sure if there is any problem with smmu eventq. However, the code shows that there is also a problem after the smmu eventq overflows. ^_^…….
There really shouldn't be any problem with the eventq. Handling the
event overflow in my patch is mostly cosmetic and can be removed. See
the Event queue overflow section of the SMMUv3 specification (IHI0070B):
"Note: In terms of delivering events, a queue in an unacknowledged
overflow state does not behave any differently to normal queue state. If
software were to consume events and free space but leave overflow
unacknowledged, new events could be recorded."
Thanks,
Jean
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* [PATCH] iommu/arm-smmu-v3: sync the OVACKFLG to PRIQ consumer register
From: Jean-Philippe Brucker @ 2018-07-23 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8CD08B4737CACA4ABE0228F45E441A916382021E@DGGEMM501-MBX.china.huawei.com>
Hi,
On 23/07/18 15:43, Zhongmiao wrote:
> Yeah, I haven't tested smmu eventq overflow , so i'm not sure if there is any problem with smmu eventq. However, the code shows that there is also a problem after the smmu eventq overflows. ^_^??.
There really shouldn't be any problem with the eventq. Handling the
event overflow in my patch is mostly cosmetic and can be removed. See
the Event queue overflow section of the SMMUv3 specification (IHI0070B):
"Note: In terms of delivering events, a queue in an unacknowledged
overflow state does not behave any differently to normal queue state. If
software were to consume events and free space but leave overflow
unacknowledged, new events could be recorded."
Thanks,
Jean
^ permalink raw reply
* [PATCH 1/4] drm/amdgpu: clean up coding style a bit
From: Christian König @ 2018-07-23 15:14 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
No need to bitcast a boolean and even if we should use "!!" instead.
Signed-off-by: Christian König <christian.koenig@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 258b6f73cbdf..e451a3f25beb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -328,35 +328,35 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file
case AMDGPU_HW_IP_GFX:
type = AMD_IP_BLOCK_TYPE_GFX;
for (i = 0; i < adev->gfx.num_gfx_rings; i++)
- ring_mask |= ((adev->gfx.gfx_ring[i].ready ? 1 : 0) << i);
+ ring_mask |= adev->gfx.gfx_ring[i].ready << i;
ib_start_alignment = 32;
ib_size_alignment = 32;
break;
case AMDGPU_HW_IP_COMPUTE:
type = AMD_IP_BLOCK_TYPE_GFX;
for (i = 0; i < adev->gfx.num_compute_rings; i++)
- ring_mask |= ((adev->gfx.compute_ring[i].ready ? 1 : 0) << i);
+ ring_mask |= adev->gfx.compute_ring[i].ready << i;
ib_start_alignment = 32;
ib_size_alignment = 32;
break;
case AMDGPU_HW_IP_DMA:
type = AMD_IP_BLOCK_TYPE_SDMA;
for (i = 0; i < adev->sdma.num_instances; i++)
- ring_mask |= ((adev->sdma.instance[i].ring.ready ? 1 : 0) << i);
+ ring_mask |= adev->sdma.instance[i].ring.ready << i;
ib_start_alignment = 256;
ib_size_alignment = 4;
break;
case AMDGPU_HW_IP_UVD:
type = AMD_IP_BLOCK_TYPE_UVD;
for (i = 0; i < adev->uvd.num_uvd_inst; i++)
- ring_mask |= ((adev->uvd.inst[i].ring.ready ? 1 : 0) << i);
+ ring_mask |= adev->uvd.inst[i].ring.ready << i;
ib_start_alignment = 64;
ib_size_alignment = 64;
break;
case AMDGPU_HW_IP_VCE:
type = AMD_IP_BLOCK_TYPE_VCE;
for (i = 0; i < adev->vce.num_rings; i++)
- ring_mask |= ((adev->vce.ring[i].ready ? 1 : 0) << i);
+ ring_mask |= adev->vce.ring[i].ready << i;
ib_start_alignment = 4;
ib_size_alignment = 1;
break;
@@ -365,27 +365,27 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file
for (i = 0; i < adev->uvd.num_uvd_inst; i++)
for (j = 0; j < adev->uvd.num_enc_rings; j++)
ring_mask |=
- ((adev->uvd.inst[i].ring_enc[j].ready ? 1 : 0) <<
- (j + i * adev->uvd.num_enc_rings));
+ adev->uvd.inst[i].ring_enc[j].ready <<
+ (j + i * adev->uvd.num_enc_rings);
ib_start_alignment = 64;
ib_size_alignment = 64;
break;
case AMDGPU_HW_IP_VCN_DEC:
type = AMD_IP_BLOCK_TYPE_VCN;
- ring_mask = adev->vcn.ring_dec.ready ? 1 : 0;
+ ring_mask = adev->vcn.ring_dec.ready;
ib_start_alignment = 16;
ib_size_alignment = 16;
break;
case AMDGPU_HW_IP_VCN_ENC:
type = AMD_IP_BLOCK_TYPE_VCN;
for (i = 0; i < adev->vcn.num_enc_rings; i++)
- ring_mask |= ((adev->vcn.ring_enc[i].ready ? 1 : 0) << i);
+ ring_mask |= adev->vcn.ring_enc[i].ready << i;
ib_start_alignment = 64;
ib_size_alignment = 1;
break;
case AMDGPU_HW_IP_VCN_JPEG:
type = AMD_IP_BLOCK_TYPE_VCN;
- ring_mask = adev->vcn.ring_jpeg.ready ? 1 : 0;
+ ring_mask = adev->vcn.ring_jpeg.ready;
ib_start_alignment = 16;
ib_size_alignment = 16;
break;
--
2.14.1
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* RE: [PATCH] net: phy: use generic clause 45 autonegotiation done
From: Camelia Alexandra Groza @ 2018-07-23 15:14 UTC (permalink / raw)
To: Andrew Lunn, rmk+kernel@armlinux.org.uk, f.fainelli@gmail.com,
davem@davemloft.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <VI1PR04MB4799F126865F4A5C115D1B16F2520@VI1PR04MB4799.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Camelia Alexandra Groza
> Sent: Thursday, July 19, 2018 15:47
> To: Andrew Lunn <andrew@lunn.ch>
> Cc: rmk+kernel@armlinux.org.uk; f.fainelli@gmail.com;
> davem@davemloft.net; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: RE: [PATCH] net: phy: use generic clause 45 autonegotiation done
>
> > -----Original Message-----
> > From: Andrew Lunn [mailto:andrew@lunn.ch]
> > Sent: Wednesday, July 18, 2018 17:39
> > To: Camelia Alexandra Groza <camelia.groza@nxp.com>
> > Cc: f.fainelli@gmail.com; davem@davemloft.net; netdev@vger.kernel.org;
> > linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH] net: phy: use generic clause 45 autonegotiation
> > done
> >
> > On Wed, Jul 18, 2018 at 04:12:15PM +0300, Camelia Groza wrote:
> > > Only Clause 22 PHYs can use genphy_aneg_done(). Use
> > > genphy_c45_aneg_done() for PHYs that implement Clause 45 without
> the
> > > Clause 22 register set.
> > >
> > > This change follows the model of phy_restart_aneg() which
> > > differentiates between the two implementations in a similar way.
> >
> > Hi Camelia
> >
> > What about phy_config_aneg()? I would assume any sort of auto-neg
> > action needs to check for c45 without c22, before calling a genphy_
> > function. Do you think it is possible to write a
> > genphy_c45_config_aneg()? If not, we might want to return -
> EOPNOTSUPP.
>
> Hi Andrew,
>
> Adding Russell to the thread as well, since he wrote the c45 helpers.
>
> Sure, I'll send a v2 with an additional generic phy_config_aneg(). I'll stick to
> returning -EOPNOTSUPP for c22-less PHYs for now.
Since the phy_config_aneg() call isn't synced on the net tree yet, I sent the second patch independently on net-next [1]. Please review this patch separately if it's ok.
[1] https://patchwork.ozlabs.org/patch/947831/
Thank you,
Camelia
^ permalink raw reply
* [PATCH 2/4] drm/amdgpu: expose only the first UVD instance for now
From: Christian König @ 2018-07-23 15:14 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20180723151441.46790-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
Going to completely rework the context to ring mapping with Nayan's GSoC
work, but for now just stopping to expose the second UVD instance should
do it.
Signed-off-by: Christian König <christian.koenig@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 13 +++++--------
drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c | 9 ++-------
2 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index e451a3f25beb..75da3c41f3b3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -286,7 +286,7 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file
struct drm_crtc *crtc;
uint32_t ui32 = 0;
uint64_t ui64 = 0;
- int i, j, found;
+ int i, found;
int ui32_size = sizeof(ui32);
if (!info->return_size || !info->return_pointer)
@@ -348,8 +348,7 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file
break;
case AMDGPU_HW_IP_UVD:
type = AMD_IP_BLOCK_TYPE_UVD;
- for (i = 0; i < adev->uvd.num_uvd_inst; i++)
- ring_mask |= adev->uvd.inst[i].ring.ready << i;
+ ring_mask |= adev->uvd.inst[0].ring.ready;
ib_start_alignment = 64;
ib_size_alignment = 64;
break;
@@ -362,11 +361,9 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file
break;
case AMDGPU_HW_IP_UVD_ENC:
type = AMD_IP_BLOCK_TYPE_UVD;
- for (i = 0; i < adev->uvd.num_uvd_inst; i++)
- for (j = 0; j < adev->uvd.num_enc_rings; j++)
- ring_mask |=
- adev->uvd.inst[i].ring_enc[j].ready <<
- (j + i * adev->uvd.num_enc_rings);
+ for (i = 0; i < adev->uvd.num_enc_rings; i++)
+ ring_mask |=
+ adev->uvd.inst[0].ring_enc[i].ready << i;
ib_start_alignment = 64;
ib_size_alignment = 64;
break;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c
index ea9850c9224d..d8357290ad09 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c
@@ -66,8 +66,6 @@ static int amdgpu_identity_map(struct amdgpu_device *adev,
u32 ring,
struct amdgpu_ring **out_ring)
{
- u32 instance;
-
switch (mapper->hw_ip) {
case AMDGPU_HW_IP_GFX:
*out_ring = &adev->gfx.gfx_ring[ring];
@@ -79,16 +77,13 @@ static int amdgpu_identity_map(struct amdgpu_device *adev,
*out_ring = &adev->sdma.instance[ring].ring;
break;
case AMDGPU_HW_IP_UVD:
- instance = ring;
- *out_ring = &adev->uvd.inst[instance].ring;
+ *out_ring = &adev->uvd.inst[0].ring;
break;
case AMDGPU_HW_IP_VCE:
*out_ring = &adev->vce.ring[ring];
break;
case AMDGPU_HW_IP_UVD_ENC:
- instance = ring / adev->uvd.num_enc_rings;
- *out_ring =
- &adev->uvd.inst[instance].ring_enc[ring%adev->uvd.num_enc_rings];
+ *out_ring = &adev->uvd.inst[0].ring_enc[ring];
break;
case AMDGPU_HW_IP_VCN_DEC:
*out_ring = &adev->vcn.ring_dec;
--
2.14.1
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* [PATCH 3/4] drm/amdgpu: add support for inplace IB patching for MM engines
From: Christian König @ 2018-07-23 15:14 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20180723151441.46790-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
We are going to need that for the second UVD instance on Vega20.
Signed-off-by: Christian König <christian.koenig@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 22 +++++++++++++++-------
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +
3 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index a9f09daeffa3..73f2f8d987cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1751,6 +1751,7 @@ amdgpu_get_sdma_instance(struct amdgpu_ring *ring)
#define amdgpu_vm_write_pte(adev, ib, pe, value, count, incr) ((adev)->vm_manager.vm_pte_funcs->write_pte((ib), (pe), (value), (count), (incr)))
#define amdgpu_vm_set_pte_pde(adev, ib, pe, addr, count, incr, flags) ((adev)->vm_manager.vm_pte_funcs->set_pte_pde((ib), (pe), (addr), (count), (incr), (flags)))
#define amdgpu_ring_parse_cs(r, p, ib) ((r)->funcs->parse_cs((p), (ib)))
+#define amdgpu_ring_patch_cs(r, p, ib) ((r)->funcs->patch_cs((p), (ib)))
#define amdgpu_ring_test_ring(r) (r)->funcs->test_ring((r))
#define amdgpu_ring_test_ib(r, t) (r)->funcs->test_ib((r), (t))
#define amdgpu_ring_get_rptr(r) (r)->funcs->get_rptr((r))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 7c5cc33d0cda..b7840e4bb958 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -916,7 +916,7 @@ static int amdgpu_cs_ib_vm_chunk(struct amdgpu_device *adev,
int r;
/* Only for UVD/VCE VM emulation */
- if (p->ring->funcs->parse_cs) {
+ if (p->ring->funcs->parse_cs || p->ring->funcs->patch_cs) {
unsigned i, j;
for (i = 0, j = 0; i < p->nchunks && j < p->job->num_ibs; i++) {
@@ -957,12 +957,20 @@ static int amdgpu_cs_ib_vm_chunk(struct amdgpu_device *adev,
offset = m->start * AMDGPU_GPU_PAGE_SIZE;
kptr += va_start - offset;
- memcpy(ib->ptr, kptr, chunk_ib->ib_bytes);
- amdgpu_bo_kunmap(aobj);
-
- r = amdgpu_ring_parse_cs(ring, p, j);
- if (r)
- return r;
+ if (p->ring->funcs->parse_cs) {
+ memcpy(ib->ptr, kptr, chunk_ib->ib_bytes);
+ amdgpu_bo_kunmap(aobj);
+
+ r = amdgpu_ring_parse_cs(ring, p, j);
+ if (r)
+ return r;
+ } else {
+ ib->ptr = (uint32_t *)kptr;
+ r = amdgpu_ring_patch_cs(ring, p, j);
+ amdgpu_bo_kunmap(aobj);
+ if (r)
+ return r;
+ }
j++;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
index 5018c0b6bf1a..24c082381488 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
@@ -123,6 +123,7 @@ struct amdgpu_ring_funcs {
void (*set_wptr)(struct amdgpu_ring *ring);
/* validating and patching of IBs */
int (*parse_cs)(struct amdgpu_cs_parser *p, uint32_t ib_idx);
+ int (*patch_cs)(struct amdgpu_cs_parser *p, uint32_t ib_idx);
/* constants to calculate how many DW are needed for an emit */
unsigned emit_frame_size;
unsigned emit_ib_size;
--
2.14.1
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* [PATCH 4/4] drm/amdgpu: patch the IBs for the second UVD instance v2
From: Christian König @ 2018-07-23 15:14 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20180723151441.46790-1-christian.koenig-5C7GfCeVMHo@public.gmane.org>
Patch the IBs for the second UVD instance so that userspace don't need
to care about the instance they submit to.
v2: use direct IB patching
Signed-off-by: Christian König <christian.koenig@amd.com>
---
drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
index db5f3d78ab12..0895b80fcd37 100644
--- a/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c
@@ -1205,6 +1205,32 @@ static int uvd_v7_0_ring_test_ring(struct amdgpu_ring *ring)
return r;
}
+/**
+ * uvd_v7_0_enc_ring_test_ring - test if UVD ENC ring is working
+ *
+ * @ring: the engine to test on
+ *
+ */
+static int uvd_v7_0_ring_patch_cs(struct amdgpu_cs_parser *p, uint32_t ib_idx)
+{
+ struct amdgpu_ib *ib = &p->job->ibs[ib_idx];
+ unsigned i;
+
+ /* No patching necessary for the first instance */
+ if (!p->ring->me)
+ return 0;
+
+ for (i = 0; i < ib->length_dw; i += 2) {
+ uint32_t reg = amdgpu_get_ib_value(p, ib_idx, i);
+
+ reg -= p->adev->reg_offset[UVD_HWIP][0][1];
+ reg += p->adev->reg_offset[UVD_HWIP][1][1];
+
+ amdgpu_set_ib_value(p, ib_idx, i, reg);
+ }
+ return 0;
+}
+
/**
* uvd_v7_0_ring_emit_ib - execute indirect buffer
*
@@ -1697,6 +1723,7 @@ static const struct amdgpu_ring_funcs uvd_v7_0_ring_vm_funcs = {
.get_rptr = uvd_v7_0_ring_get_rptr,
.get_wptr = uvd_v7_0_ring_get_wptr,
.set_wptr = uvd_v7_0_ring_set_wptr,
+ .patch_cs = uvd_v7_0_ring_patch_cs,
.emit_frame_size =
6 + /* hdp invalidate */
SOC15_FLUSH_GPU_TLB_NUM_WREG * 6 +
--
2.14.1
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply related
* Regression with crc32c selection?
From: Holger Hoffstätte @ 2018-07-23 14:13 UTC (permalink / raw)
To: linux-btrfs
Hi,
While backporting a bunch of fixes to my own 4.16.x tree
(4.17 had a few too many bugs for my taste) I also ended up merging:
df91f56adce1f: libcrc32c: Add crc32c_impl function
9678c54388b6a: btrfs: Remove custom crc32c init code
..which AFAIK went into 4.17 and seemed harmless enough; after fixing up
a trivial context conflict it builds, runs, all good..except that btrfs
(apprently?) no longer uses the preferred crc32c-intel module, but the
crc32c-generic one instead.
In order to rule out any mistakes on my part I built 4.18.0-rc6 and it
seems to have the same problem:
Jul 23 15:55:09 ragnarok kernel: raid6: sse2x1 gen() 11267 MB/s
Jul 23 15:55:09 ragnarok kernel: raid6: sse2x1 xor() 8110 MB/s
Jul 23 15:55:09 ragnarok kernel: raid6: sse2x2 gen() 13409 MB/s
Jul 23 15:55:09 ragnarok kernel: raid6: sse2x2 xor() 9137 MB/s
Jul 23 15:55:09 ragnarok kernel: raid6: sse2x4 gen() 15884 MB/s
Jul 23 15:55:09 ragnarok kernel: raid6: sse2x4 xor() 10579 MB/s
Jul 23 15:55:09 ragnarok kernel: raid6: using algorithm sse2x4 gen() 15884 MB/s
Jul 23 15:55:09 ragnarok kernel: raid6: .... xor() 10579 MB/s, rmw enabled
Jul 23 15:55:09 ragnarok kernel: raid6: using ssse3x2 recovery algorithm
Jul 23 15:55:09 ragnarok kernel: xor: automatically using best checksumming function avx
Jul 23 15:55:09 ragnarok kernel: Btrfs loaded, crc32c=crc32c-generic
I understand that the new crc32c_impl() function changed from
crypto_tfm_alg_driver_name() to crypto_shash_driver_name() - could this
be the reason? The module is loaded just fine, but apprently not used:
$lsmod | grep crc32
crc32_pclmul 16384 0
crc32c_intel 24576 0
In other words, is this supposed to happen or is my kernel config somehow
no longer right? It worked before and doesn't look too wrong:
$grep CRC /etc/kernels/kernel-config-x86_64-4.18.0-rc6
# CONFIG_PCIE_ECRC is not set
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=m
CONFIG_CRYPTO_CRC32=m
CONFIG_CRYPTO_CRC32_PCLMUL=m
# CONFIG_CRYPTO_CRCT10DIF is not set
CONFIG_CRC_CCITT=m
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=y
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC4 is not set
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=y
# CONFIG_CRC8 is not set
Ultimately btrfs (and everything else) works, but the process of how
the kernel selects a crc32c implementation seems rather mysterious to me. :/
Any insights welcome. If it's a regression I can gladly test fixes.
cheers
Holger
^ permalink raw reply
* option: Do not try to bind to ADB interfaces
From: Lars Melin @ 2018-07-23 15:15 UTC (permalink / raw)
To: Romain Izard, Johan Hovold, Greg Kroah-Hartman
Cc: linux-usb, linux-kernel, stable
On 7/23/2018 21:02, Romain Izard wrote:
> Some modems now use the Android Debug Bridge to provide a debugging
> interface, and some phones can also export serial ports managed by the
> "option" driver.
>
> The ADB daemon running in userspace tries to use USB interfaces with
> bDeviceClass=0xFF, bDeviceSubClass=0x42, bDeviceProtocol=1
>
> Prevent the option driver from binding to those interfaces, as they
> will not be serial ports.
You are assuming that an interface with these attributes are always a
ADB interface - that is wrong. Vendor specific class (0xff) is not
standardized to be something specific.
> This can fix issues like:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781256
>
You are trying to solve a 4++ years old bug report where it was assumed
that the option driver was the culprit. The device in question, a
Qualcomm modem with vid/pid 05c6:9025 has never been included in option.
rgds
Lars
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] option: Do not try to bind to ADB interfaces
From: Lars Melin @ 2018-07-23 15:15 UTC (permalink / raw)
To: Romain Izard, Johan Hovold, Greg Kroah-Hartman
Cc: linux-usb, linux-kernel, stable
In-Reply-To: <20180723140220.7166-1-romain.izard.pro@gmail.com>
On 7/23/2018 21:02, Romain Izard wrote:
> Some modems now use the Android Debug Bridge to provide a debugging
> interface, and some phones can also export serial ports managed by the
> "option" driver.
>
> The ADB daemon running in userspace tries to use USB interfaces with
> bDeviceClass=0xFF, bDeviceSubClass=0x42, bDeviceProtocol=1
>
> Prevent the option driver from binding to those interfaces, as they
> will not be serial ports.
You are assuming that an interface with these attributes are always a
ADB interface - that is wrong. Vendor specific class (0xff) is not
standardized to be something specific.
> This can fix issues like:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781256
>
You are trying to solve a 4++ years old bug report where it was assumed
that the option driver was the culprit. The device in question, a
Qualcomm modem with vid/pid 05c6:9025 has never been included in option.
rgds
Lars
^ permalink raw reply
* Re: [Qemu-devel] [PULL 0/2] QAPI and monitor patches for 2018-07-23 (3.0.0-rc2)
From: Peter Maydell @ 2018-07-23 15:15 UTC (permalink / raw)
To: Markus Armbruster; +Cc: QEMU Developers
In-Reply-To: <20180723131356.27466-1-armbru@redhat.com>
On 23 July 2018 at 14:13, Markus Armbruster <armbru@redhat.com> wrote:
> The following changes since commit 6598f0cdad6acc6674c4f060fa46e537228c2c47:
>
> po: Don't include comments with location (2018-07-23 10:50:54 +0100)
>
> are available in the Git repository at:
>
> git://repo.or.cz/qemu/armbru.git tags/pull-qapi-2018-07-23
>
> for you to fetch changes up to 62aa1d887ff9fc76adb488d31447d126a78f4b8f:
>
> monitor: Fix unsafe sharing of @cur_mon among threads (2018-07-23 14:00:03 +0200)
>
> ----------------------------------------------------------------
> QAPI and monitor patches for 2018-07-23 (3.0.0-rc2)
>
> This pull request consists of a late external interface tweak and a
> thread safety fix, both related to QMP out-of-band execution.
>
> ----------------------------------------------------------------
> Markus Armbruster (1):
> qapi: Make 'allow-oob' optional in SchemaInfoCommand
>
> Peter Xu (1):
> monitor: Fix unsafe sharing of @cur_mon among threads
>
> include/monitor/monitor.h | 2 +-
> monitor.c | 2 +-
> qapi/introspect.json | 6 +++---
> scripts/qapi/introspect.py | 10 +++++-----
> stubs/monitor.c | 2 +-
> tests/test-util-sockets.c | 2 +-
> 6 files changed, 12 insertions(+), 12 deletions(-)
Applied, thanks.
> armbru@dusky:~/work/qemu$ rm *patch
> armbru@dusky:~/work/qemu$ git-format-patch --subject-prefix PULL master
> 0000-cover-letter.patch
> 0001-qapi-Make-allow-oob-optional-in-SchemaInfoCommand.patch
> 0002-monitor-Fix-unsafe-sharing-of-cur_mon-among-threads.patch
...stray cut-n-paste? :-)
-- PMM
^ permalink raw reply
* Re: [PATCH 2/2] blktests: add test for ANA state transition
From: Hannes Reinecke @ 2018-07-23 14:14 UTC (permalink / raw)
To: Chaitanya Kulkarni
Cc: Christoph Hellwig, Sagi Grimberg, Keith Busch,
linux-nvme@lists.infradead.org, linux-block@vger.kernel.org,
Hannes Reinecke, osandov@osandov.com
In-Reply-To: <BYAPR04MB450272E60922653AFF77D47B86500@BYAPR04MB4502.namprd04.prod.outlook.com>
On 07/21/2018 11:29 PM, Chaitanya Kulkarni wrote:
> From: linux-block-owner@vger.kernel.org <linux-block-owner@vger.kernel.org> on behalf of Hannes Reinecke <hare@suse.de>
> Sent: Tuesday, July 17, 2018 6:31 AM
> To: Omar Sandoval
> Cc: Christoph Hellwig; Sagi Grimberg; Keith Busch; linux-nvme@lists.infradead.org; linux-block@vger.kernel.org; Hannes Reinecke; Hannes Reinecke
> Subject: [PATCH 2/2] blktests: add test for ANA state transition
>
>
> Signed-off-by: Hannes Reinecke <hare@suse.com>
> ---
> tests/nvme/014 | 158 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> tests/nvme/014.out | 17 ++++++
> 2 files changed, 175 insertions(+)
> create mode 100755 tests/nvme/014
> create mode 100644 tests/nvme/014.out
>
> diff --git a/tests/nvme/014 b/tests/nvme/014
> new file mode 100755
> index 0000000..4b57229
> --- /dev/null
> +++ b/tests/nvme/014
> @@ -0,0 +1,158 @@
> +#!/bin/bash
> +#
> +# Regression test for ANA base support
> +#
> +# Copyright (C) 2018 Hannes Reinecke
> +#
> +# This program is free software: you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation, either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# 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.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program. If not, see <http://www.gnu.org/licenses/>.
>
>
> Licenses - GNU Project - Free Software Foundation
> www.gnu.org
> Published software should be free software.To make it free software, you need to release it under
> a free software license. We normally use the GNU General Public License (GNU GPL), specifying version 3
> or any later version, but occasionally we use other free software licenses.
>
I don't mind, I just copied it over from testcase 10...
> +
> +. tests/nvme/rc
> +
> +DESCRIPTION="test ANA optimized/transitioning/inaccessible support"
> +QUICK=1
> +
> +switch_nvmet_anagroup() {
> + local port1="$1"
> + local port2="$2"
> + local mode="$3"
> +
> + echo "ANA state ${mode}"
> +
> + if [ "${mode}" = "change" ] ; then
> + _set_nvmet_anagroup_state "${port1}" "1" "change"
> + _set_nvmet_anagroup_state "${port1}" "2" "change"
> + _set_nvmet_anagroup_state "${port2}" "1" "change"
> + _set_nvmet_anagroup_state "${port2}" "2" "change"
> + elif [ "${mode}" = "failover" ] ; then
> + _set_nvmet_anagroup_state "${port1}" "1" "inaccessible"
> + _set_nvmet_anagroup_state "${port1}" "2" "optimized"
> + _set_nvmet_anagroup_state "${port2}" "1" "optimized"
> + _set_nvmet_anagroup_state "${port2}" "2" "inaccessible"
> + else
> + _set_nvmet_anagroup_state "${port1}" "1" "optimized"
> + _set_nvmet_anagroup_state "${port1}" "2" "inaccessible"
> + _set_nvmet_anagroup_state "${port2}" "1" "inaccessible"
> + _set_nvmet_anagroup_state "${port2}" "2" "optimized"
> + fi
> +}
> +
> +_display_ana_state() {
> + local grpid state
> [CK] Newliine here ?
Okay
> + for nvme in /sys/class/nvme/* ; do
> + for c in ${nvme}/nvme* ; do
> + if [ ! -d ${c} ] ; then
> + echo "${nvme##*/}: ANA disabled"
> + continue
> + fi
> + grpid="$(cat "${c}/ana_grpid")"
> + state="$(cat "${c}/ana_state")"
> + echo "${c##*/}: grpid ${grpid} state ${state}"
> + done
> + done
> +}
>
> I think we need to move above functions to the ${BLKTESTS_HOME}/tests/nvme/rc.
Okay, can do.
> +
> +_switch_ana_states() {
> + local port1=$1
> + local port2=$2
> +
> [CK] Please remove the extra line.
> +}
> [CK] I was not able to find a caller for above function, I'm I missing something ?
> +
Yeah, that's an older function which got left over during refactoring.
> +requires() {
> + _have_program nvme && _have_module nvme-loop && _have_module loop && \
> + _have_configfs && _have_fio
> [CK] Missing nvmet module from the above list.
> +}
>
> Can we split following test function into small routines, it will be easier to review and
> maintain?
>
> +
> +test() {
> + echo "Running ${TEST_NAME}"
> +
> + modprobe nvmet
> + modprobe nvme-loop
> +
> + local port1
> + port1="$(_create_nvmet_port "loop")"
> [CK] Can we initialize variables at the time of declaration or after declaration of all the
> variables ?
Sure. But we should do it consistently; the older tests also do not
follow these rules...
> + ag1="$(_create_nvmet_anagroup "${port1}")"
> [CK] Not sure if we need ag1 variable.
>
Yeah, it's more for symmetry than anything else.
> +
> + local port2
> [CK] Can we plese declare all the variable at the top please see tests/nvme/006-013
> to maintain uniform style ?
Sure. But see above; not all tests follow the same scheme.
> + port2="$(_create_nvmet_port "loop")"
> + ag2="$(_create_nvmet_anagroup "${port2}")"
> +
> + truncate -s 1G "$TMPDIR/img1"
> +
> + local loop_dev1
> + loop_dev1="$(losetup -f --show "$TMPDIR/img1")"
> +
> + _create_nvmet_subsystem "blktests-subsystem-1" "${loop_dev1}" \
> + "91fdba0d-f87b-4c25-b80f-db7be1418b9e" "1"
> +
> + truncate -s 1G "$TMPDIR/img2"
> +
> [CK] Do we really need img2 ? is it possible to use the img1 as we are not doing data verification ?
Yes. There's an issue with the current implementation which fails to
signal a namespace state change for the _second_ namepsace.
(That's the one patch I've sent to the current ANA implementation from hch)
> + local loop_dev2
> + loop_dev2="$(losetup -f --show "$TMPDIR/img2")"
> +
> + _create_nvmet_ns "blktests-subsystem-1" "2" "${loop_dev2}" \
> + "9aed0138-bfd9-46f5-92ac-24c70377fd49" "2"
> +
> + _add_nvmet_subsys_to_port "${port1}" "blktests-subsystem-1"
> + _add_nvmet_subsys_to_port "${port2}" "blktests-subsystem-1"
> +
> + switch_nvmet_anagroup "${port1}" "${port2}" failback
> +
> + nvme connect -t loop -a "${port1}" -n blktests-subsystem-1
> + nvme connect -t loop -a "${port2}" -n blktests-subsystem-1
> +
> + _display_ana_state
> +
> + _run_fio_rand_io --size=256m --filename="/dev/nvme0n1" &
> [CK] Hardcoded value for ns, on my machine I have PCIe ns with "/dev/nvme0n1",
> can we please make sure this is the right block device for the namespace that we just
> configured ?
Yeah, I know. Will see what I can do.
> + trap "kill $!" EXIT
> +
> + sleep 10
> +
> + switch_nvmet_anagroup "${port1}" "${port2}" "change"
> +
> + # Insert a delay to allow the AEN to be processed
> + sleep 1
> +
> + _display_ana_state
> +
> + sleep 6
> +
> + switch_nvmet_anagroup "${port1}" "${port2}" "failover"
> +
> + # Insert a delay to allow the AEN to be processed
> + sleep 1
> +
> + _display_ana_state
> +
> + wait
> + trap - EXIT
> +
> + nvme disconnect -n blktests-subsystem-1
> +
> + _remove_nvmet_subsystem_from_port "${port1}" "blktests-subsystem-1"
> + _remove_nvmet_subsystem_from_port "${port2}" "blktests-subsystem-1"
> + _remove_nvmet_ns "blktests-subsystem-1" "2"
> + _remove_nvmet_subsystem "blktests-subsystem-1"
> + _remove_nvmet_anagroup "${port1}" "2"
> + _remove_nvmet_port "${port1}"
> + _remove_nvmet_anagroup "${port2}" "2"
> [CK] Plase make the groupid local varible instead of hard coding "2".
Hmm. Not easy. But I'll have a look.
Thanks for the review.
Cheers,
Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.