* Re: [RFC 0/2] iommu: arm-smmu: Add support for early direct mappings
From: Will Deacon @ 2020-05-27 11:03 UTC (permalink / raw)
To: John Stultz
Cc: linux-arm-msm, Joerg Roedel, Bjorn Andersson, iommu,
Thierry Reding, linux-tegra, Robin Murphy, linux-arm-kernel
In-Reply-To: <CALAqxLVmomdKJCwh=e-PX+8-seDX0RXA81FzmG4sEyJmbXBh9A@mail.gmail.com>
Hi John, Bjorn,
On Tue, May 26, 2020 at 01:34:45PM -0700, John Stultz wrote:
> On Thu, May 14, 2020 at 12:34 PM <bjorn.andersson@linaro.org> wrote:
> >
> > On Thu 27 Feb 18:57 PST 2020, Bjorn Andersson wrote:
> >
> > Rob, Will, we're reaching the point where upstream has enough
> > functionality that this is becoming a critical issue for us.
> >
> > E.g. Lenovo Yoga C630 is lacking this and a single dts patch to boot
> > mainline with display, GPU, WiFi and audio working and the story is
> > similar on several devboards.
> >
> > As previously described, the only thing I want is the stream mapping
> > related to the display controller in place, either with the CB with
> > translation disabled or possibly with a way to specify the framebuffer
> > region (although this turns out to mess things up in the display
> > driver...)
> >
> > I did pick this up again recently and concluded that by omitting the
> > streams for the USB controllers causes an instability issue seen on one
> > of the controller to disappear. So I would prefer if we somehow could
> > have a mechanism to only pick the display streams and the context
> > allocation for this.
> >
> >
> > Can you please share some pointers/insights/wishes for how we can
> > conclude on this subject?
>
> Ping? I just wanted to follow up on this discussion as this small
> series is crucial for booting mainline on the Dragonboard 845c
> devboard. It would be really valuable to be able to get some solution
> upstream so we can test mainline w/o adding additional patches.
Sorry, it's been insanely busy recently and I haven't had a chance to think
about this on top of everything else. We're also carrying a hack in Android
for you :)
> The rest of the db845c series has been moving forward smoothly, but
> this set seems to be very stuck with no visible progress since Dec.
>
> Are there any pointers for what folks would prefer to see?
I've had a chat with Robin about this. Originally, I was hoping that
people would all work together towards an idyllic future where firmware
would be able to describe arbitrary pre-existing mappings for devices,
irrespective of the IOMMU through which they master and Linux could
inherit this configuration. However, that hasn't materialised (there was
supposed to be an IORT update, but I don't know what happened to that)
and, in actual fact, the problem that you have on db845 is /far/ more
restricted than the general problem.
Could you please try hacking something along the following lines and see
how you get on? You may need my for-joerg/arm-smmu/updates branch for
all the pieces:
1. Use the ->cfg_probe() callback to reserve the SMR/S2CRs you need
"pinning" and configure for bypass.
2. Use the ->def_domain_type() callback to return IOMMU_DOMAIN_IDENTITY
for the display controller
I /think/ that's sufficient, but note that it differs from the current
approach because we don't end up reserving a CB -- bypass is configured
in the S2CR instead. Some invalidation might therefore be needed in
->cfg_probe() after unhooking the CB.
Thanks, and please yell if you run into problems with this approach.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] i2c: xiic: Support disabling multi-master in DT
From: Wolfram Sang @ 2020-05-27 11:07 UTC (permalink / raw)
To: Laine Jaakko EXT
Cc: Rob Herring, Shubhrajyoti Datta, devicetree@vger.kernel.org,
michal.simek@xilinx.com, linux-i2c@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <AM0PR06MB51857F4CDC7AE643CE160F9ED4A60@AM0PR06MB5185.eurprd06.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 1490 bytes --]
Hi Jaako,
> The changes required to this patch at XIIC driver from suggested DT
> changes are pretty minor. Basically only checking a different
> property, reversing logic and some naming changes. I can make these
> changes already for the driver if this solution is what will be
> chosen, or would you prefer to still think about this?
I think we can go forward this way. Although I didn't find an example, I
am quite sure YAML format can have exclusive properties. If not, it
should be added ;) I'll try again to get some information from people
more experienced with YAML. But we don't depend on it.
> Regarding the device tree changes: I am not very familiar with the
> needed documentation changes, YAML bindings or what needs to be done
> for new bindings in general. Would you prefer to still consider them
> and/or get these subsystem level bindings done by someone more
> familiar with them? Another option would be for me to try find time to
> do the suggested bindings changes anyway, but it will likely require
> some effort from me to familiarize with device tree bindings changes
> and schedule the time for it.
No need to. Luckily, the I2C main bindings file is still text, so it is
easy to modify. I will send a patch out in a few minutes, so you can
base your driver code on that. Converting to YAML is a completely
different step, not related to your patch here. (Sidenote: I am looking
for volunteers to do that)
I think this covers it?
Happy hacking,
Wolfram
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 24/26] arm64: mte: Introduce early param to disable MTE support
From: Catalin Marinas @ 2020-05-27 11:12 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arch, Vladimir Murzin, Patrick Daly, Szabolcs Nagy,
Andrey Konovalov, Kevin Brodsky, linux-mm, Vincenzo Frascino,
Peter Collingbourne, Dave P Martin, linux-arm-kernel
In-Reply-To: <20200527095504.GB11111@willie-the-truck>
On Wed, May 27, 2020 at 10:55:05AM +0100, Will Deacon wrote:
> On Tue, May 26, 2020 at 07:11:53PM -0700, Patrick Daly wrote:
> > On Fri, May 22, 2020 at 11:37:15AM +0100, Catalin Marinas wrote:
> > > On Thu, May 21, 2020 at 10:57:10PM -0700, Patrick Daly wrote:
> > > > On Mon, May 18, 2020 at 06:20:55PM +0100, Catalin Marinas wrote:
> > > > > On Mon, May 18, 2020 at 12:31:03PM +0100, Will Deacon wrote:
> > > > > > On Mon, May 18, 2020 at 12:26:30PM +0100, Vladimir Murzin wrote:
> > > > > > > On 5/15/20 6:16 PM, Catalin Marinas wrote:
> > > > > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > > > > > > > index f2a93c8679e8..7436e7462b85 100644
> > > > > > > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > > > > > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > > > > > > @@ -373,6 +373,10 @@
> > > > > > > > arcrimi= [HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards
> > > > > > > > Format: <io>,<irq>,<nodeID>
> > > > > > > >
> > > > > > > > + arm64.mte_disable=
> > > > > > > > + [ARM64] Disable Linux support for the Memory
> > > > > > > > + Tagging Extension (both user and in-kernel).
> > > > > > > > +
> > > > > > >
> > > > > > > Should it really to take parameter (on/off/true/false)? It may lead to expectation
> > > > > > > that arm64.mte_disable=false should enable MT and, yes, double negatives make it
> > > > > > > look ugly, so if we do need parameter, can it be arm64.mte=on/off/true/false?
> > > > > >
> > > > > > I don't think "performance analysis" is a good justification for this
> > > > > > parameter tbh. We don't tend to add these options for other architectural
> > > > > > features, and I don't see why MTE is any different in this regard.
> > > > >
> > > > > There is an expectation of performance impact with MTE enabled,
> > > > > especially if it's running in synchronous mode. For the in-kernel MTE,
> > > > > we could add a parameter which sets sync vs async at boot time rather
> > > > > than a big disable knob. It won't affect user space however.
> > > > >
> > > > > The other 'justification' is if your hardware has weird unexpected
> > > > > behaviour but I'd like this handled via errata workarounds.
> > > > >
> > > > > I'll let the people who asked for this to chip in ;). I agree with you
> > > > > that we rarely add these (and I rejected a similar option a few weeks
> > > > > ago on the AMU patchset).
> > > >
> > > > We've been looking into other ways this on/off behavior could be achieved.
> > >
> > > The actual question here is what the on/off behaviour is needed for. We
> > > can figure out the best mechanism for this once we know what we want to
> > > achieve. My wild guess above was performance analysis but that can be
> > > toggled by either kernel boot parameter or run-time sysctl (or just the
> > > Kconfig option).
> > >
> > > If it is about forcing user space not to use MTE, we may look into some
> > > other sysctl controls (we already have one for the tagged address ABI).
> >
> > We want to allow the end user to be able to easily "opt out" of MTE in favour
> > of better power, perf and battery life.
>
> Who is "the end user" in this case?
Good question. I have a suspicion it's still the (kernel) developer ;).
> If MTE is bad enough for power, performance and battery life that we need a
> kill switch, then perhaps we shouldn't enable it by default and the few
> people that want to use it can build a kernel with it enabled. However, then
> I don't really see what MTE buys you over the existing KASAN implementations.
MTE is faster than KASan (with async mode the fastest), however I'd
expect it to still be noticeable compared to no-MTE. It's a trade-off if
you want to find security bugs in your code on a large scale.
> I thought the general idea was that you could run in the (cheap) "async"
> mode, and then re-run in the more expensive "sync" mode to further diagnose
> any failures. That model seems to work well with these patches, since
> reporting is disabled by default. Are you saying that there is a
> significant penalty incurred even when reporting is not enabled?
The tag checking mode is controlled by the user on a per-process basis.
The modes and hardware perf/power expectations:
1. no tag checking - no expected performance penalty from the hardware
perspective (tags not fetched from memory).
2. async tag checking - tags fetched from memory but checked
asynchronously, so it allows the hardware to perform as well as it
can (I don't have numbers yet). Probably a small degradation vs (1).
3. sync tag checking - there is an expectation of further perf/power
degradation vs (2).
In addition to the hardware aspects above, you have the software cost
for colouring memory both on allocation and on free. By default, a
malloc()/free() wouldn't touch the memory (maybe some red zones) but
with MTE the libc will have to set the colour. That's faster than a
memset since it need to store 4 bits for every 16 bytes of address but
slower than not doing it at all. For a calloc(), The memset + tag
setting can be combined in a single DC instruction.
So, it really depends on what the user is doing. If we want a knob where
the user doesn't even attempt to colour pages (not even (1) above),
maybe a user space env variable parsed by the libc is a better option.
While MTE and the tagged addr ABI are complementary (one can still set
PROT_MTE without enabling the tagged addr ABI), most likely a libc
implementation would try to enable the latter before using MTE. We
already have a sysctl to force the tagged addr ABI off. The side-effect
is that MTE will be disabled in the C library, so assuming no run-time
cost (the libc people to confirm).
The tagged addr sysctl doesn't cover the in-kernel MTE but we can leave
the discussion for when we have the patches.
> Anyway, we don't offer global runtime/cmdline switches for the vast majority
> of other architectural features -- instead, we choose a sensible default,
> and I think we should do the same here.
The sensible defaults are currently "off" with a user opt-in. I think
the question is whether we need a "safety" knob at the kernel level like
we did with the sysctl abi.tagged_addr_disabled or we leave it to the
user as it sees fit (e.g. env variables) since it doesn't affect the
kernel (unlike the tagged addr ABI).
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 15/26] arm64: mte: Allow user control of the tag check mode via prctl()
From: Catalin Marinas @ 2020-05-27 11:16 UTC (permalink / raw)
To: Dave Martin
Cc: linux-arch, Szabolcs Nagy, Andrey Konovalov, Kevin Brodsky,
Peter Collingbourne, linux-mm, Vincenzo Frascino, Will Deacon,
linux-arm-kernel
In-Reply-To: <20200527083218.GS5031@arm.com>
On Wed, May 27, 2020 at 09:32:20AM +0100, Dave P Martin wrote:
> On Wed, May 27, 2020 at 08:46:59AM +0100, Will Deacon wrote:
> > On Fri, May 15, 2020 at 06:16:01PM +0100, Catalin Marinas wrote:
> > > By default, even if PROT_MTE is set on a memory range, there is no tag
> > > check fault reporting (SIGSEGV). Introduce a set of option to the
> > > exiting prctl(PR_SET_TAGGED_ADDR_CTRL) to allow user control of the tag
> > > check fault mode:
> > >
> > > PR_MTE_TCF_NONE - no reporting (default)
> > > PR_MTE_TCF_SYNC - synchronous tag check fault reporting
> > > PR_MTE_TCF_ASYNC - asynchronous tag check fault reporting
> > >
> > > These options translate into the corresponding SCTLR_EL1.TCF0 bitfield,
> > > context-switched by the kernel. Note that uaccess done by the kernel is
> > > not checked and cannot be configured by the user.
> > >
> > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Will Deacon <will@kernel.org>
> > > ---
> > >
> > > Notes:
> > > v3:
> > > - Use SCTLR_EL1_TCF0_NONE instead of 0 for consistency.
> > > - Move mte_thread_switch() in this patch from an earlier one. In
> > > addition, it is called after the dsb() in __switch_to() so that any
> > > asynchronous tag check faults have been registered in the TFSR_EL1
> > > registers (to be added with the in-kernel MTE support.
> > >
> > > v2:
> > > - Handle SCTLR_EL1_TCF0_NONE explicitly for consistency with PR_MTE_TCF_NONE.
> > > - Fix SCTLR_EL1 register setting in flush_mte_state() (thanks to Peter
> > > Collingbourne).
> > > - Added ISB to update_sctlr_el1_tcf0() since, with the latest
> > > architecture update/fix, the TCF0 field is used by the uaccess
> > > routines.
> > >
> > > arch/arm64/include/asm/mte.h | 14 ++++++
> > > arch/arm64/include/asm/processor.h | 3 ++
> > > arch/arm64/kernel/mte.c | 77 ++++++++++++++++++++++++++++++
> > > arch/arm64/kernel/process.c | 26 ++++++++--
> > > include/uapi/linux/prctl.h | 6 +++
> > > 5 files changed, 123 insertions(+), 3 deletions(-)
> >
> > Dave is working on man pages for prctl() (and I think also ptrace). I think
> > it would be /very/ useful for us to have some RFC patches on top of his work
> > adding documentation for the MTE interactions, as we found some other minor
> > issues/inconsistencies as a direct result of writing and reviewing the man
> > page for our existing interfaces.
>
> I have a local draft for the address tagging and MTE prctls already btw.
> I hadn't posted them yet so as to focus on nailing the "easy" stuff down
> ;)
That's great Dave. Thanks!
> If I have time I'll try and get them posted today so that people can
> take a look before next week.
Feel free to post them whenever you can. I'll include them in v5 (likely
to be posted after the merging window).
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC RESEND 0/3] Introduce cpufreq minimum load QoS
From: Benjamin GAIGNARD @ 2020-05-27 11:17 UTC (permalink / raw)
To: Valentin Schneider
Cc: len.brown@intel.com, Alexandre TORGUE, linux-pm@vger.kernel.org,
viresh.kumar@linaro.org, pavel@ucw.cz, rjw@rjwysocki.net,
linux-kernel@vger.kernel.org, mcoquelin.stm32@gmail.com,
Hugues FRUCHET, mchehab@kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <jhjk10xu1tq.mognet@arm.com>
On 5/27/20 12:09 PM, Valentin Schneider wrote:
> Hi Benjamin,
>
> On 26/05/20 16:16, Benjamin Gaignard wrote:
>> A first round [1] of discussions and suggestions have already be done on
>> this series but without found a solution to the problem. I resend it to
>> progress on this topic.
>>
> Apologies for sleeping on that previous thread.
>
> So what had been suggested over there was to use uclamp to boost the
> frequency of the handling thread; however if you use threaded IRQs you
> get RT threads, which already get the max frequency by default (at least
> with schedutil).
>
> Does that not work for you, and if so, why?
That doesn't work because almost everything is done by the hardware blocks
without charge the CPU so the thread isn't running. I have done the
tests with schedutil
and ondemand scheduler (which is the one I'm targeting). I have no
issues when using
performance scheduler because it always keep the highest frequencies.
>
>> When start streaming from the sensor the CPU load could remain very low
>> because almost all the capture pipeline is done in hardware (i.e. without
>> using the CPU) and let believe to cpufreq governor that it could use lower
>> frequencies. If the governor decides to use a too low frequency that
>> becomes a problem when we need to acknowledge the interrupt during the
>> blanking time.
>> The delay to ack the interrupt and perform all the other actions before
>> the next frame is very short and doesn't allow to the cpufreq governor to
>> provide the required burst of power. That led to drop the half of the frames.
>>
>> To avoid this problem, DCMI driver informs the cpufreq governors by adding
>> a cpufreq minimum load QoS resquest.
>>
>> Benjamin
>>
>> [1] https://lkml.org/lkml/2020/4/24/360
>>
>> Benjamin Gaignard (3):
>> PM: QoS: Introduce cpufreq minimum load QoS
>> cpufreq: governor: Use minimum load QoS
>> media: stm32-dcmi: Inform cpufreq governors about cpu load needs
>>
>> drivers/cpufreq/cpufreq_governor.c | 5 +
>> drivers/media/platform/stm32/stm32-dcmi.c | 8 ++
>> include/linux/pm_qos.h | 12 ++
>> kernel/power/qos.c | 213 ++++++++++++++++++++++++++++++
>> 4 files changed, 238 insertions(+)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 8/9] spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
From: Mark Brown @ 2020-05-27 11:18 UTC (permalink / raw)
To: dillon min
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Noralf Trønnes, Hua Dillon, p.zabel, linux-clk, Dave Airlie,
Michael Turquette, linux-stm32, Linux Kernel Mailing List,
open list:DRM PANEL DRIVERS, linux-spi, Stephen Boyd,
Andy Shevchenko, Rob Herring, thierry.reding, Maxime Coquelin,
Daniel Vetter, Sam Ravnborg, Linus Walleij, Linux ARM,
Alexandre Torgue
In-Reply-To: <CAL9mu0JA=XRTj_HONQGtj74X05TAV0__dW2At0AAeymwNvJhEw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 218 bytes --]
On Wed, May 27, 2020 at 06:45:53PM +0800, dillon min wrote:
> sorry, forget to remove these two patch from this submits, will not
> include it in later submits
> which ack other's review result.
Ah, OK - no problem.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/5] vexpress: modularize power reset driver
From: Anders Roxell @ 2020-05-27 11:26 UTC (permalink / raw)
To: soc; +Cc: robh, linus.walleij, Anders Roxell, linux-kernel,
linux-arm-kernel
Hi,
This patchset contains a bugfixe, a cleanup and fixes allmodconfig build breakages
on arm and arm64. Also making the vexpress power reset driver a module.
Cheers,
Anders
Anders Roxell (5):
power: vexpress: add suppress_bind_attrs to true
power: vexpress: cleanup: use builtin_platform_driver
Revert "ARM: vexpress: Don't select VEXPRESS_CONFIG"
power: reset: vexpress: fix build issue
power: vexpress: make the reset driver a module
arch/arm/mach-vexpress/Kconfig | 2 +-
drivers/power/reset/Kconfig | 3 ++-
drivers/power/reset/vexpress-poweroff.c | 8 +++++++-
3 files changed, 10 insertions(+), 3 deletions(-)
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/5] power: vexpress: add suppress_bind_attrs to true
From: Anders Roxell @ 2020-05-27 11:26 UTC (permalink / raw)
To: soc; +Cc: robh, linus.walleij, Anders Roxell, linux-kernel,
linux-arm-kernel
In-Reply-To: <20200527112608.3886105-1-anders.roxell@linaro.org>
Make sure that the POWER_RESET_VEXPRESS driver won't have bind/unbind
attributes available via the sysfs, so lets be explicit here and use
".suppress_bind_attrs = true" to prevent userspace from doing something
silly.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
drivers/power/reset/vexpress-poweroff.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/power/reset/vexpress-poweroff.c b/drivers/power/reset/vexpress-poweroff.c
index 90cbaa8341e3..0bf9ab8653ae 100644
--- a/drivers/power/reset/vexpress-poweroff.c
+++ b/drivers/power/reset/vexpress-poweroff.c
@@ -143,6 +143,7 @@ static struct platform_driver vexpress_reset_driver = {
.driver = {
.name = "vexpress-reset",
.of_match_table = vexpress_reset_of_match,
+ .suppress_bind_attrs = true,
},
};
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/5] power: vexpress: cleanup: use builtin_platform_driver
From: Anders Roxell @ 2020-05-27 11:26 UTC (permalink / raw)
To: soc; +Cc: robh, linus.walleij, Anders Roxell, linux-kernel,
linux-arm-kernel
In-Reply-To: <20200527112608.3886105-1-anders.roxell@linaro.org>
Use the helper macro for builtin drivers taht don't do anything special
in driver init. This removes some boilerplate code.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
drivers/power/reset/vexpress-poweroff.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/power/reset/vexpress-poweroff.c b/drivers/power/reset/vexpress-poweroff.c
index 0bf9ab8653ae..1fdbcbd95fc2 100644
--- a/drivers/power/reset/vexpress-poweroff.c
+++ b/drivers/power/reset/vexpress-poweroff.c
@@ -146,9 +146,4 @@ static struct platform_driver vexpress_reset_driver = {
.suppress_bind_attrs = true,
},
};
-
-static int __init vexpress_reset_init(void)
-{
- return platform_driver_register(&vexpress_reset_driver);
-}
-device_initcall(vexpress_reset_init);
+builtin_platform_driver(vexpress_reset_driver);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 3/5] Revert "ARM: vexpress: Don't select VEXPRESS_CONFIG"
From: Anders Roxell @ 2020-05-27 11:26 UTC (permalink / raw)
To: soc; +Cc: robh, linus.walleij, Anders Roxell, linux-kernel,
linux-arm-kernel
In-Reply-To: <20200527112608.3886105-1-anders.roxell@linaro.org>
This reverts commit 848685c25da99d871bbd87369f3c3d6eead661ac.
Due to when I set 'depends on VEXPRESS_CONFOG=Y' in 'config
POWER_RESET_VEXPRESS' to get an allmodconfig build on arm64 to build,
and allmodconfig build on arm fails if this patch isn't reverted.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
arch/arm/mach-vexpress/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 8391a5b3cd78..065e12991663 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -19,6 +19,7 @@ menuconfig ARCH_VEXPRESS
select POWER_SUPPLY
select REGULATOR if MMC_ARMMMCI
select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select VEXPRESS_CONFIG
help
This option enables support for systems using Cortex processor based
ARM core and logic (FPGA) tiles on the Versatile Express motherboard,
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/5] power: reset: vexpress: fix build issue
From: Anders Roxell @ 2020-05-27 11:26 UTC (permalink / raw)
To: soc; +Cc: robh, linus.walleij, Anders Roxell, linux-kernel,
linux-arm-kernel
In-Reply-To: <20200527112608.3886105-1-anders.roxell@linaro.org>
An allmodconfig kernel makes CONFIG_VEXPRESS_CONFIG a module and
CONFIG_POWER_RESET_VEXPRESS builtin. That makes us see this build
error:
aarch64-linux-gnu-ld: drivers/power/reset/vexpress-poweroff.o: in function `vexpress_reset_probe':
../drivers/power/reset/vexpress-poweroff.c:119: undefined reference to `devm_regmap_init_vexpress_config'
../drivers/power/reset/vexpress-poweroff.c:119:(.text+0x48c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
`devm_regmap_init_vexpress_config'
make[1]: *** [/srv/src/kernel/next/Makefile:1126: vmlinux] Error 1
Rework so that POWER_RESET_VEXPRESS depends on 'VEXPRESS_CONFIG=y'.
Fixes: d06cfe3f123c ("bus: vexpress-config: Merge vexpress-syscfg into vexpress-config")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
---
drivers/power/reset/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 4dfac618b942..f07b982c8dff 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -191,7 +191,7 @@ config POWER_RESET_VERSATILE
config POWER_RESET_VEXPRESS
bool "ARM Versatile Express power-off and reset driver"
depends on ARM || ARM64
- depends on VEXPRESS_CONFIG
+ depends on VEXPRESS_CONFIG=y
help
Power off and reset support for the ARM Ltd. Versatile
Express boards.
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 5/5] power: vexpress: make the reset driver a module
From: Anders Roxell @ 2020-05-27 11:26 UTC (permalink / raw)
To: soc; +Cc: robh, linus.walleij, Anders Roxell, linux-kernel,
linux-arm-kernel
In-Reply-To: <20200527112608.3886105-1-anders.roxell@linaro.org>
Today the vexpress power driver can only be builtin. Rework so it's
possible for the vexpress power driver to be a module.
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
arch/arm/mach-vexpress/Kconfig | 1 -
drivers/power/reset/Kconfig | 5 +++--
drivers/power/reset/vexpress-poweroff.c | 12 +++++++++++-
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 065e12991663..4b54d8cf897d 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -15,7 +15,6 @@ menuconfig ARCH_VEXPRESS
select NO_IOPORT_MAP
select PLAT_VERSATILE
select POWER_RESET
- select POWER_RESET_VEXPRESS
select POWER_SUPPLY
select REGULATOR if MMC_ARMMMCI
select REGULATOR_FIXED_VOLTAGE if REGULATOR
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index f07b982c8dff..8468d42b0198 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -189,9 +189,10 @@ config POWER_RESET_VERSATILE
reference boards.
config POWER_RESET_VEXPRESS
- bool "ARM Versatile Express power-off and reset driver"
+ tristate "ARM Versatile Express power-off and reset driver"
depends on ARM || ARM64
- depends on VEXPRESS_CONFIG=y
+ depends on VEXPRESS_CONFIG
+ default VEXPRESS_CONFIG
help
Power off and reset support for the ARM Ltd. Versatile
Express boards.
diff --git a/drivers/power/reset/vexpress-poweroff.c b/drivers/power/reset/vexpress-poweroff.c
index 1fdbcbd95fc2..b1eef95132d9 100644
--- a/drivers/power/reset/vexpress-poweroff.c
+++ b/drivers/power/reset/vexpress-poweroff.c
@@ -5,6 +5,7 @@
*/
#include <linux/delay.h>
+#include <linux/module.h>
#include <linux/notifier.h>
#include <linux/of.h>
#include <linux/of_device.h>
@@ -146,4 +147,13 @@ static struct platform_driver vexpress_reset_driver = {
.suppress_bind_attrs = true,
},
};
-builtin_platform_driver(vexpress_reset_driver);
+
+static int __init vexpress_reset_init(void)
+{
+ return platform_driver_register(&vexpress_reset_driver);
+}
+module_init(vexpress_reset_init);
+
+MODULE_AUTHOR("Pawel Moll <pawel.moll@arm.com>");
+MODULE_DESCRIPTION("Vexpress reset driver");
+MODULE_LICENSE("GPL v2");
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH] i2c: xiic: Support disabling multi-master in DT
From: Laine Jaakko EXT @ 2020-05-27 11:27 UTC (permalink / raw)
To: Wolfram Sang
Cc: Rob Herring, Shubhrajyoti Datta, devicetree@vger.kernel.org,
michal.simek@xilinx.com, linux-i2c@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200527110732.GA4875@ninjato>
Thanks Wolfram for helping me out with this.
I will make Version 2 patch with proposed changes.
Happy hacking for you too!
-Jaakko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 06/11] net: ethernet: mtk-star-emac: new driver
From: Arnd Bergmann @ 2020-05-27 11:33 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Edwin Peer, devicetree, Stephane Le Provost, Bartosz Golaszewski,
netdev, Sean Wang, Linux Kernel Mailing List, Pedro Tsai,
Mark Lee, Fabien Parent, Rob Herring,
moderated list:ARM/Mediatek SoC..., clang-built-linux,
Andrew Perepech, John Crispin, Matthias Brugger, Jakub Kicinski,
Nathan Chancellor, David S . Miller, Linux ARM, Heiner Kallweit
In-Reply-To: <CAMRc=MevVsYZFDQif+8Zyv41sSkbS8XqWbKGdCvHooneXz88hg@mail.gmail.com>
On Wed, May 27, 2020 at 10:46 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
> > I don't know if there should be a new label that excludes that
> > assignment for those particular gotos or if new_dma_addr should
> > be initialized to something at the top. Please take a look at
> > addressing this when you get a chance.
> >
> > Cheers,
> > Nathan
>
> Hi Nathan,
>
> Thanks for reporting this! I have a fix ready and will send it shortly.
I already have a workaround for this bug as well as another one
in my tree that I'll send later today after some more testing.
Feel free to wait for that, or just ignore mine if you already have a fix.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V3] arm64/cpufeature: Add get_arm64_ftr_reg_nowarn()
From: Catalin Marinas @ 2020-05-27 11:37 UTC (permalink / raw)
To: Anshuman Khandual
Cc: mark.rutland, suzuki.poulose, linux-kernel, Mark Brown, will,
linux-arm-kernel
In-Reply-To: <1590573876-19120-1-git-send-email-anshuman.khandual@arm.com>
On Wed, May 27, 2020 at 03:34:36PM +0530, Anshuman Khandual wrote:
> +/*
> + * get_arm64_ftr_reg - Looks up a feature register entry using
> + * its sys_reg() encoding. This calls get_arm64_ftr_reg_nowarn().
> + *
> + * returns - Upon success, matching ftr_reg entry for id.
> + * - NULL on failure but with an WARN_ON().
> + */
> +static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id)
> +{
> + struct arm64_ftr_reg *reg;
> +
> + reg = get_arm64_ftr_reg_nowarn(sys_id);
> +
> + /*
> + * Can not really proceed when the search fails here.
> + * Requesting for a non existent register search will
> + * be an error. Warn but let it continue for now.
> + */
> + WARN_ON(!reg);
> + return reg;
I find the comment here slightly confusing: cannot proceed but continue.
Maybe something like:
/*
* Requesting a non-existent register search is an error. Warn
* and let the caller handle it.
*/
Otherwise it looks fine:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] MIPS: BCM63xx: fix 6328 boot selection bit
From: Thomas Bogendoerfer @ 2020-05-27 11:33 UTC (permalink / raw)
To: Álvaro Fernández Rojas
Cc: f.fainelli, linux-kernel, linux-mips, bcm-kernel-feedback-list,
jonas.gorski, linux-arm-kernel
In-Reply-To: <20200526110324.1324754-1-noltari@gmail.com>
On Tue, May 26, 2020 at 01:03:24PM +0200, Álvaro Fernández Rojas wrote:
> MISC_STRAP_BUS_BOOT_SEL_SHIFT is 18 according to Broadcom's GPL source code.
>
> Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
> ---
> arch/mips/include/asm/mach-bcm63xx/bcm63xx_regs.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v12 1/2] media: dt-bindings: media: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem
From: Vishal Sagar @ 2020-05-27 11:40 UTC (permalink / raw)
To: Laurent Pinchart
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Jacopo Mondi,
Dinesh Kumar, Hyun Kwon, Sandip Kothari,
linux-kernel@vger.kernel.org, robh+dt@kernel.org,
hans.verkuil@cisco.com, Luca Ceresoli, Michal Simek,
mchehab@kernel.org, Rob Herring,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <20200524014548.GA6026@pendragon.ideasonboard.com>
Hi Laurent,
> -----Original Message-----
> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Sent: Sunday, May 24, 2020 7:16 AM
> To: Vishal Sagar <vsagar@xilinx.com>
> Cc: Hyun Kwon <hyunk@xilinx.com>; mchehab@kernel.org;
> robh+dt@kernel.org; mark.rutland@arm.com; hans.verkuil@cisco.com; Luca
> Ceresoli <luca@lucaceresoli.net>; Jacopo Mondi <jacopo@jmondi.org>;
> Michal Simek <michals@xilinx.com>; linux-media@vger.kernel.org;
> devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Dinesh Kumar <dineshk@xilinx.com>; Sandip Kothari
> <sandipk@xilinx.com>; Rob Herring <robh@kernel.org>
> Subject: Re: [PATCH v12 1/2] media: dt-bindings: media: xilinx: Add Xilinx MIPI
> CSI-2 Rx Subsystem
>
> Hi Vishal,
>
> On Fri, May 08, 2020 at 01:52:36PM +0000, Vishal Sagar wrote:
> > On Tuesday, May 5, 2020 7:53 PM, Laurent Pinchart wrote:
> > > On Thu, Apr 23, 2020 at 09:00:37PM +0530, Vishal Sagar wrote:
> > > > Add bindings documentation for Xilinx MIPI CSI-2 Rx Subsystem.
> > > >
> > > > The Xilinx MIPI CSI-2 Rx Subsystem consists of a CSI-2 Rx
> > > > controller, a D-PHY in Rx mode and a Video Format Bridge.
> > > >
> > > > Signed-off-by: Vishal Sagar <vishal.sagar@xilinx.com>
> > > > Reviewed-by: Hyun Kwon <hyun.kwon@xilinx.com>
> > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > > Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
> > > > ---
> > > > v12
> > > > - Moved to yaml format
> > > > - Update CSI-2 and D-PHY
> > > > - Mention that bindings for D-PHY not here
> > > > - reset -> video-reset
> > > >
> > > > v11
> > > > - Modify compatible string from 4.0 to 5.0
> > > >
> > > > v10
> > > > - No changes
> > > >
> > > > v9
> > > > - Fix xlnx,vfb description.
> > > > - s/Optional/Required endpoint property.
> > > > - Move data-lanes description from Ports to endpoint property section.
> > > >
> > > > v8
> > > > - Added reset-gpios optional property to assert video_aresetn
> > > >
> > > > v7
> > > > - Removed the control name from dt bindings
> > > > - Updated the example dt node name to csi2rx
> > > >
> > > > v6
> > > > - Added "control" after V4L2_CID_XILINX_MIPICSISS_ACT_LANES as
> > > > suggested by Luca
> > > > - Added reviewed by Rob Herring
> > > >
> > > > v5
> > > > - Incorporated comments by Luca Cersoli
> > > > - Removed DPHY clock from description and example
> > > > - Removed bayer pattern from device tree MIPI CSI IP
> > > > doesn't deal with bayer pattern.
> > > >
> > > > v4
> > > > - Added reviewed by Hyun Kwon
> > > >
> > > > v3
> > > > - removed interrupt parent as suggested by Rob
> > > > - removed dphy clock
> > > > - moved vfb to optional properties
> > > > - Added required and optional port properties section
> > > > - Added endpoint property section
> > > >
> > > > v2
> > > > - updated the compatible string to latest version supported
> > > > - removed DPHY related parameters
> > > > - added CSI v2.0 related property (including VCX for supporting upto 16
> > > > virtual channels).
> > > > - modified csi-pxl-format from string to unsigned int type where the value
> > > > is as per the CSI specification
> > > > - Defined port 0 and port 1 as sink and source ports.
> > > > - Removed max-lanes property as suggested by Rob and Sakari
> > > > .../bindings/media/xilinx/xlnx,csi2rxss.yaml | 215
> > > > ++++++++++++++++++
> > > > 1 file changed, 215 insertions(+) create mode 100644
> > > > Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yam
> > > > l
> > > > b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yam
> > > > l
> > > > new file mode 100644
> > > > index 000000000000..365084e27f7e
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss
> > > > +++ .yam
> > > > +++ l
> > > > @@ -0,0 +1,215 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML
> > > > +1.2
> > > > +---
> > > > +$id:
> > > > +http://devicetree.org/schemas/media/xilinx/xlnx,csi2rxss.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Xilinx MIPI CSI-2 Receiver Subsystem
> > > > +
> > > > +maintainers:
> > > > + - Vishal Sagar <vishal.sagar@xilinx.com>
> > > > +
> > > > +description: |
> > > > + The Xilinx MIPI CSI-2 Receiver Subsystem is used to capture
> > > > +MIPI CSI-2
> > > > + traffic from compliant camera sensors and send the output as
> > > > +AXI4 Stream
> > > > + video data for image processing.
> > > > + The subsystem consists of a MIPI D-PHY in slave mode which
> > > > +captures the
> > > > + data packets. This is passed along the MIPI CSI-2 Rx IP which
> > > > +extracts the
> > > > + packet data. The optional Video Format Bridge (VFB) converts
> > > > +this data to
> > > > + AXI4 Stream video data.
> > > > + For more details, please refer to PG232 Xilinx MIPI CSI-2 Receiver
> Subsystem.
> > > > + Please note that this bindings includes only the MIPI CSI-2 Rx
> > > > +controller
> > > > + and Video Format Bridge and not D-PHY.
> > >
> > > How should the D-PHY be handled, when DPY_EN_REG_IF is set to true ?
> >
> > It was suggested in v3 to have a separate D-PHY phy driver which would be
> initialized / configured from MIPI CSI-2 Rx driver.
> > Currently with the D-PHY register interface enabled, we don't have to
> > really configure anything but the following parameters
> > 1 - init
> > 2 - hs_settle
> > 3 - hs_timeout (High Speed mode timeout)
> > 4 - esc_timeout (Escape mode timeout)
> > 5 - idelay tap
> >
> > The D-PHY Rx can be enabled/disabled and has a soft reset bit.
> > The HS and Escape mode timeout registers can be enabled with a default
> value via the Vivado IP GUI.
> >
> > The above parameters would have to be passed to D-PHY driver as custom
> > control via MIPI CSI-2 Rx driver as these depend on the sensor connected.
> > Probably these can be a new common control in V4L2 framework for CSI Rx
> controllers.
>
> It seems that in that case, regardless of whether we go for a separate PHY
> driver or not, we will be able to extend the DT bindings, either with a phys
> property, or with an additional reg entry. That should be backward-
> compatible, so I'm not concerned.
>
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + items:
> > > > + - enum:
> > > > + - xlnx,mipi-csi2-rx-subsystem-5.0
> > > > +
> > > > + reg:
> > > > + maxItems: 1
> > > > +
> > > > + interrupts:
> > > > + maxItems: 1
> > > > +
> > > > + clocks:
> > > > + description: List of clock specifiers
> > > > + items:
> > > > + - description: AXI Lite clock
> > > > + - description: Video clock
> > > > +
> > > > + clock-names:
> > > > + items:
> > > > + - const: lite_aclk
> > > > + - const: video_aclk
> > > > +
> > > > + xlnx,csi-pxl-format:
> > > > + description: |
> > > > + This denotes the CSI Data type selected in hw design.
> > > > + Packets other than this data type (except for RAW8 and
> > > > + User defined data types) will be filtered out.
> > > > + Possible values are as below -
> > > > + 0x1e - YUV4228B
> > > > + 0x1f - YUV42210B
> > > > + 0x20 - RGB444
> > > > + 0x21 - RGB555
> > > > + 0x22 - RGB565
> > > > + 0x23 - RGB666
> > > > + 0x24 - RGB888
> > > > + 0x28 - RAW6
> > > > + 0x29 - RAW7
> > > > + 0x2a - RAW8
> > > > + 0x2b - RAW10
> > > > + 0x2c - RAW12
> > > > + 0x2d - RAW14
> > > > + 0x2e - RAW16
> > > > + 0x2f - RAW20
> > > > + allOf:
> > > > + - $ref: /schemas/types.yaml#/definitions/uint32
> > > > + - enum: [0x1e, 0x1f, 0x20, 0x21, 0x22, 0x23, 0x24, 0x28,
> > > > + 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f]
> > >
> > > This could also be written
> > >
> > > allOf:
> > > - $ref: /schemas/types.yaml#/definitions/uint32
> > > - anyOf:
> > > - minimum: 0x1e
> > > maximum: 0x24
> > > - minimum: 0x28
> > > maximum: 0x2f
> > >
> > > if you want to make it a bit more compact (in the number of values,
> > > not the number of lines obviously), up to you.
> >
> > Thanks for sharing this method. I will update this in next version.
> >
> > > I will also quote the question (and your answer) from the previous
> > > version:
> > >
> > > > > Isn't this property required only when the VFB is present ?
> > > >
> > > > This will be present irrespective of VFB being enabled.
> > > > With VFB, the data on the bus will be as per Xilinx UG934 which is similar
> to media bus formats.
> > > >
> > > > Without VFB, it will just be plain data as it comes in data packets.
> > > > Refer to the Xilinx PG 232 "Pixel Packing When Video Format Bridge is Not
> Present"
> > > >
> > > > So the driver is currently made to load only in case VFB is enabled.
> > >
> > > I understand that the driver doesn't support the case where the VFB
> > > is disabled, but the DT bindings shouldn't care about that. The
> > > document of
> > > v4.1 of the subsystem states that the width of the video_out port is
> > > then selected under "CSI-2 Options TDATA width" (page 11). I however
> > > don't such such an option described on pages 55 or 56, but there's
> > > an AXIS_TDATA_WIDTH parameter on page 61.
> > >
> > > Is the pixel format relevant when the VFB is disabled ?
> >
> > When the VFB is disabled, all supported data types will be allowed i.e. no
> filtering will occur.
> > But the data output will be in 32/64 bit TDATA width (no dependence on
> > pixels per clock) and will adhere to the "Recommended Memory Storage"
> section of the CSI spec.
> > In this case data being sent on the bus won't compare to what media bus
> format documentation describes.
>
> My understanding is that, in the case xlnx,vfb would be absent (not supported
> in the driver yet), the xlnx,csi-pxl-format should not be set ? If that's correct, I'd
> like to capture that in the bindings already.
That is correct. xlnx,csi-pxl-format is absent when xlnx,vfb is absent.
> It could be expressed by dropping xlnx,csi-pxl-format from the required
> section, and adding
>
> if:
> required:
> - xlnx,vfb
> then:
> required:
> - xlnx,csi-pxl-format
> else:
> properties:
> xlnx,csi-pxl-format: false
>
> As you will have two conditions defined, they should be grouped with
>
> allOf:
> - if:
> required:
> - xlnx,vfb
> then:
> required:
> - xlnx,csi-pxl-format
> else:
> properties:
> xlnx,csi-pxl-format: false
>
> - if:
> not:
> required:
> - xlnx,en-csi-v2-0
> then:
> properties:
> xlnx,en-vcx: false
>
Thanks for sharing on how to add this condition in YAML.
I will update this in the next version.
> > > > +
> > > > + xlnx,vfb:
> > > > + type: boolean
> > > > + description: Present when Video Format Bridge is enabled in
> > > > + IP configuration
> > > > +
> > > > + xlnx,en-csi-v2-0:
> > > > + type: boolean
> > > > + description: Present if CSI v2 is enabled in IP configuration.
> > > > +
> > > > + xlnx,en-vcx:
> > > > + type: boolean
> > > > + description: |
> > > > + When present, there are maximum 16 virtual channels, else
> > > > + only 4. This is present only if xlnx,en-csi-v2-0 is present.
> > >
> > > The last sentence should be removed, and replaced with
> > >
> > > if:
> > > not:
> > > required:
> > > - xlnx,en-csi-v2-0
> > > then:
> > > properties:
> > > xlnx,en-vcx: false
> > >
> > > (to be placed after required: and before additionalProperties:).
> >
> > Got it. Thanks for the tips on YAML.
> > I will update this in next version.
> >
> > > > +
> > > > + xlnx,en-active-lanes:
> > > > + type: boolean
> > > > + description: |
> > > > + Present if the number of active lanes can be re-configured at
> > > > + runtime in the Protocol Configuration Register. Otherwise all lanes,
> > > > + as set in IP configuration, are always active.
> > > > +
> > > > + video-reset-gpios:
> > > > + description: Optional specifier for a GPIO that asserts video_aresetn.
> > > > + maxItems: 1
> > > > +
> > > > + ports:
> > > > + type: object
> > > > +
> > > > + properties:
> > > > + port@0:
> > > > + type: object
> > > > + description: |
> > > > + Input / sink port node, single endpoint describing the
> > > > + CSI-2 transmitter.
> > > > +
> > > > + properties:
> > > > + reg:
> > > > + const: 0
> > > > +
> > > > + endpoint:
> > > > + type: object
> > > > +
> > > > + properties:
> > > > +
> > > > + data-lanes:
> > > > + description: |
> > > > + This is required only in the sink port 0 endpoint which
> > > > + connects to MIPI CSI-2 source like sensor.
> > > > + The possible values are -
> > > > + 1 - For 1 lane enabled in IP.
> > > > + 1 2 - For 2 lanes enabled in IP.
> > > > + 1 2 3 - For 3 lanes enabled in IP.
> > > > + 1 2 3 4 - For 4 lanes enabled in IP.
> > > > + items:
> > > > + - const: 1
> > > > + - const: 2
> > > > + - const: 3
> > > > + - const: 4
> > > > +
> > > > + remote-endpoint: true
> > > > +
> > > > + required:
> > > > + - data-lanes
> > > > + - remote-endpoint
> > > > +
> > > > + additionalProperties: false
> > > > +
> > > > + additionalProperties: false
> > > > +
> > > > + port@1:
> > > > + type: object
> > > > + description: |
> > > > + Output / source port node, endpoint describing modules
> > > > + connected the CSI-2 receiver.
> > > > +
> > > > + properties:
> > > > +
> > > > + reg:
> > > > + const: 1
> > > > +
> > > > + endpoint:
> > > > + type: object
> > > > +
> > > > + properties:
> > > > +
> > > > + remote-endpoint: true
> > > > +
> > > > + required:
> > > > + - remote-endpoint
> > > > +
> > > > + additionalProperties: false
> > > > +
> > > > + additionalProperties: false
> > > > +
> > > > +required:
> > > > + - compatible
> > > > + - reg
> > > > + - interrupts
> > > > + - clocks
> > > > + - clock-names
> > > > + - xlnx,csi-pxl-format
> > > > + - ports
> > > > +
> > > > +additionalProperties: false
> > > > +
> > > > +examples:
> > > > + - |
> > > > + #include <dt-bindings/gpio/gpio.h>
> > > > + xcsi2rxss_1: csi2rx@a0020000 {
> > > > + compatible = "xlnx,mipi-csi2-rx-subsystem-5.0";
> > > > + reg = <0x0 0xa0020000 0x0 0x10000>;
> > > > + interrupt-parent = <&gic>;
> > > > + interrupts = <0 95 4>;
> > > > + xlnx,csi-pxl-format = <0x2a>;
> > > > + xlnx,vfb;
> > > > + xlnx,en-active-lanes;
> > > > + xlnx,en-csi-v2-0;
> > > > + xlnx,en-vcx;
> > > > + clock-names = "lite_aclk", "video_aclk";
> > > > + clocks = <&misc_clk_0>, <&misc_clk_1>;
> > > > + video-reset-gpios = <&gpio 86 GPIO_ACTIVE_LOW>;
> > > > +
> > > > + ports {
> > > > + #address-cells = <1>;
> > > > + #size-cells = <0>;
> > > > +
> > > > + port@0 {
> > > > + /* Sink port */
> > > > + reg = <0>;
> > > > + csiss_in: endpoint {
> > > > + data-lanes = <1 2 3 4>;
> > > > + /* MIPI CSI-2 Camera handle */
> > > > + remote-endpoint = <&camera_out>;
> > > > + };
> > > > + };
> > > > + port@1 {
> > > > + /* Source port */
> > > > + reg = <1>;
> > > > + csiss_out: endpoint {
> > > > + remote-endpoint = <&vproc_in>;
> > > > + };
> > > > + };
> > > > + };
> > > > + };
>
> --
> Regards,
>
> Laurent Pinchart
Regards
Vishal Sagar
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH][v2] iommu: arm-smmu-v3: Copy SMMU table for kdump kernel
From: Prabhakar Kushwaha @ 2020-05-27 11:44 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Kuppuswamy Sathyanarayanan, Ganapatrao Prabhakerrao Kulkarni,
Myron Stowe, Vijay Mohan Pandarathil, Marc Zyngier,
Bhupesh Sharma, kexec mailing list, Robin Murphy, linux-pci,
Prabhakar Kushwaha, Will Deacon, linux-arm-kernel
In-Reply-To: <20200521224946.GA1194148@bjorn-Precision-5520>
Hi Bjorn,
On Fri, May 22, 2020 at 4:19 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Thu, May 21, 2020 at 09:28:20AM +0530, Prabhakar Kushwaha wrote:
> > On Wed, May 20, 2020 at 4:52 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > On Thu, May 14, 2020 at 12:47:02PM +0530, Prabhakar Kushwaha wrote:
> > > > On Wed, May 13, 2020 at 3:33 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
> > > > > On Mon, May 11, 2020 at 07:46:06PM -0700, Prabhakar Kushwaha wrote:
> > > > > > An SMMU Stream table is created by the primary kernel. This table is
> > > > > > used by the SMMU to perform address translations for device-originated
> > > > > > transactions. Any crash (if happened) launches the kdump kernel which
> > > > > > re-creates the SMMU Stream table. New transactions will be translated
> > > > > > via this new table..
> > > > > >
> > > > > > There are scenarios, where devices are still having old pending
> > > > > > transactions (configured in the primary kernel). These transactions
> > > > > > come in-between Stream table creation and device-driver probe.
> > > > > > As new stream table does not have entry for older transactions,
> > > > > > it will be aborted by SMMU.
> > > > > >
> > > > > > Similar observations were found with PCIe-Intel 82576 Gigabit
> > > > > > Network card. It sends old Memory Read transaction in kdump kernel.
> > > > > > Transactions configured for older Stream table entries, that do not
> > > > > > exist any longer in the new table, will cause a PCIe Completion Abort.
> > > > >
> > > > > That sounds like exactly what we want, doesn't it?
> > > > >
> > > > > Or do you *want* DMA from the previous kernel to complete? That will
> > > > > read or scribble on something, but maybe that's not terrible as long
> > > > > as it's not memory used by the kdump kernel.
> > > >
> > > > Yes, Abort should happen. But it should happen in context of driver.
> > > > But current abort is happening because of SMMU and no driver/pcie
> > > > setup present at this moment.
> > >
> > > I don't understand what you mean by "in context of driver." The whole
> > > problem is that we can't control *when* the abort happens, so it may
> > > happen in *any* context. It may happen when a NIC receives a packet
> > > or at some other unpredictable time.
> > >
> > > > Solution of this issue should be at 2 place
> > > > a) SMMU level: I still believe, this patch has potential to overcome
> > > > issue till finally driver's probe takeover.
> > > > b) Device level: Even if something goes wrong. Driver/device should
> > > > able to recover.
> > > >
> > > > > > Returned PCIe completion abort further leads to AER Errors from APEI
> > > > > > Generic Hardware Error Source (GHES) with completion timeout.
> > > > > > A network device hang is observed even after continuous
> > > > > > reset/recovery from driver, Hence device is no more usable.
> > > > >
> > > > > The fact that the device is no longer usable is definitely a problem.
> > > > > But in principle we *should* be able to recover from these errors. If
> > > > > we could recover and reliably use the device after the error, that
> > > > > seems like it would be a more robust solution that having to add
> > > > > special cases in every IOMMU driver.
> > > > >
> > > > > If you have details about this sort of error, I'd like to try to fix
> > > > > it because we want to recover from that sort of error in normal
> > > > > (non-crash) situations as well.
> > > > >
> > > > Completion abort case should be gracefully handled. And device should
> > > > always remain usable.
> > > >
> > > > There are 2 scenario which I am testing with Ethernet card PCIe-Intel
> > > > 82576 Gigabit Network card.
> > > >
> > > > I) Crash testing using kdump root file system: De-facto scenario
> > > > - kdump file system does not have Ethernet driver
> > > > - A lot of AER prints [1], making it impossible to work on shell
> > > > of kdump root file system.
> > >
> > > In this case, I think report_error_detected() is deciding that because
> > > the device has no driver, we can't do anything. The flow is like
> > > this:
> > >
> > > aer_recover_work_func # aer_recover_work
> > > kfifo_get(aer_recover_ring, entry)
> > > dev = pci_get_domain_bus_and_slot
> > > cper_print_aer(dev, ...)
> > > pci_err("AER: aer_status:")
> > > pci_err("AER: [14] CmpltTO")
> > > pci_err("AER: aer_layer=")
> > > if (AER_NONFATAL)
> > > pcie_do_recovery(dev, pci_channel_io_normal)
> > > status = CAN_RECOVER
> > > pci_walk_bus(report_normal_detected)
> > > report_error_detected
> > > if (!dev->driver)
> > > vote = NO_AER_DRIVER
> > > pci_info("can't recover (no error_detected callback)")
> > > *result = merge_result(*, NO_AER_DRIVER)
> > > # always NO_AER_DRIVER
> > > status is now NO_AER_DRIVER
> > >
> > > So pcie_do_recovery() does not call .report_mmio_enabled() or .slot_reset(),
> > > and status is not RECOVERED, so it skips .resume().
> > >
> > > I don't remember the history there, but if a device has no driver and
> > > the device generates errors, it seems like we ought to be able to
> > > reset it.
> >
> > But how to reset the device considering there is no driver.
> > Hypothetically, this case should be taken care by PCIe subsystem to
> > perform reset at PCIe level.
>
> I don't understand your question. The PCI core (not the device
> driver) already does the reset. When pcie_do_recovery() calls
> reset_link(), all devices on the other side of the link are reset.
>
> > > We should be able to field one (or a few) AER errors, reset the
> > > device, and you should be able to use the shell in the kdump kernel.
> > >
> > here kdump shell is usable only problem is a "lot of AER Errors". One
> > cannot see what they are typing.
>
> Right, that's what I expect. If the PCI core resets the device, you
> should get just a few AER errors, and they should stop after the
> device is reset.
>
> > > > - Note kdump shell allows to use makedumpfile, vmcore-dmesg applications.
> > > >
> > > > II) Crash testing using default root file system: Specific case to
> > > > test Ethernet driver in second kernel
> > > > - Default root file system have Ethernet driver
> > > > - AER error comes even before the driver probe starts.
> > > > - Driver does reset Ethernet card as part of probe but no success.
> > > > - AER also tries to recover. but no success. [2]
> > > > - I also tries to remove AER errors by using "pci=noaer" bootargs
> > > > and commenting ghes_handle_aer() from GHES driver..
> > > > than different set of errors come which also never able to recover [3]
> > > >
> >
> > Please suggest your view on this case. Here driver is preset.
> > (driver/net/ethernet/intel/igb/igb_main.c)
> > In this case AER errors starts even before driver probe starts.
> > After probe, driver does the device reset with no success and even AER
> > recovery does not work.
>
> This case should be the same as the one above. If we can change the
> PCI core so it can reset the device when there's no driver, that would
> apply to case I (where there will never be a driver) and to case II
> (where there is no driver now, but a driver will probe the device
> later).
>
Does this means change are required in PCI core.
I tried following changes in pcie_do_recovery() but it did not help.
Same error as before.
-- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
pci_info(dev, "broadcast resume message\n");
pci_walk_bus(bus, report_resume, &status);
@@ -203,7 +207,12 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
return status;
failed:
pci_uevent_ers(dev, PCI_ERS_RESULT_DISCONNECT);
+ pci_reset_function(dev);
+ pci_aer_clear_device_status(dev);
+ pci_aer_clear_nonfatal_status(dev);
--pk
> > Problem mentioned in case I and II goes away if do pci_reset_function
> > during enumeration phase of kdump kernel.
> > can we thought of doing pci_reset_function for all devices in kdump
> > kernel or device specific quirk.
> >
> > --pk
> >
> >
> > > > As per my understanding, possible solutions are
> > > > - Copy SMMU table i.e. this patch
> > > > OR
> > > > - Doing pci_reset_function() during enumeration phase.
> > > > I also tried clearing "M" bit using pci_clear_master during
> > > > enumeration but it did not help. Because driver re-set M bit causing
> > > > same AER error again.
> > > >
> > > >
> > > > -pk
> > > >
> > > > ---------------------------------------------------------------------------------------------------------------------------
> > > > [1] with bootargs having pci=noaer
> > > >
> > > > [ 22.494648] {4}[Hardware Error]: Hardware error from APEI Generic
> > > > Hardware Error Source: 1
> > > > [ 22.512773] {4}[Hardware Error]: event severity: recoverable
> > > > [ 22.518419] {4}[Hardware Error]: Error 0, type: recoverable
> > > > [ 22.544804] {4}[Hardware Error]: section_type: PCIe error
> > > > [ 22.550363] {4}[Hardware Error]: port_type: 0, PCIe end point
> > > > [ 22.556268] {4}[Hardware Error]: version: 3.0
> > > > [ 22.560785] {4}[Hardware Error]: command: 0x0507, status: 0x4010
> > > > [ 22.576852] {4}[Hardware Error]: device_id: 0000:09:00.1
> > > > [ 22.582323] {4}[Hardware Error]: slot: 0
> > > > [ 22.586406] {4}[Hardware Error]: secondary_bus: 0x00
> > > > [ 22.591530] {4}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> > > > [ 22.608900] {4}[Hardware Error]: class_code: 000002
> > > > [ 22.613938] {4}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> > > > [ 22.803534] pci 0000:09:00.1: AER: aer_status: 0x00004000,
> > > > aer_mask: 0x00000000
> > > > [ 22.810838] pci 0000:09:00.1: AER: [14] CmpltTO (First)
> > > > [ 22.817613] pci 0000:09:00.1: AER: aer_layer=Transaction Layer,
> > > > aer_agent=Requester ID
> > > > [ 22.847374] pci 0000:09:00.1: AER: aer_uncor_severity: 0x00062011
> > > > [ 22.866161] mpt3sas_cm0: 63 BIT PCI BUS DMA ADDRESSING SUPPORTED,
> > > > total mem (8153768 kB)
> > > > [ 22.946178] pci 0000:09:00.0: AER: can't recover (no error_detected callback)
> > > > [ 22.995142] pci 0000:09:00.1: AER: can't recover (no error_detected callback)
> > > > [ 23.002300] pcieport 0000:00:09.0: AER: device recovery failed
> > > > [ 23.027607] pci 0000:09:00.1: AER: aer_status: 0x00004000,
> > > > aer_mask: 0x00000000
> > > > [ 23.044109] pci 0000:09:00.1: AER: [14] CmpltTO (First)
> > > > [ 23.060713] pci 0000:09:00.1: AER: aer_layer=Transaction Layer,
> > > > aer_agent=Requester ID
> > > > [ 23.068616] pci 0000:09:00.1: AER: aer_uncor_severity: 0x00062011
> > > > [ 23.122056] pci 0000:09:00.0: AER: can't recover (no error_detected callback)
> > > >
> > > >
> > > > ----------------------------------------------------------------------------------------------------------------------------
> > > > [2] Normal bootargs.
> > > >
> > > > [ 54.252454] {6}[Hardware Error]: Hardware error from APEI Generic
> > > > Hardware Error Source: 1
> > > > [ 54.265827] {6}[Hardware Error]: event severity: recoverable
> > > > [ 54.271473] {6}[Hardware Error]: Error 0, type: recoverable
> > > > [ 54.281605] {6}[Hardware Error]: section_type: PCIe error
> > > > [ 54.287163] {6}[Hardware Error]: port_type: 0, PCIe end point
> > > > [ 54.296955] {6}[Hardware Error]: version: 3.0
> > > > [ 54.301471] {6}[Hardware Error]: command: 0x0507, status: 0x4010
> > > > [ 54.312520] {6}[Hardware Error]: device_id: 0000:09:00.1
> > > > [ 54.317991] {6}[Hardware Error]: slot: 0
> > > > [ 54.322074] {6}[Hardware Error]: secondary_bus: 0x00
> > > > [ 54.327197] {6}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> > > > [ 54.333797] {6}[Hardware Error]: class_code: 000002
> > > > [ 54.351312] {6}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> > > > [ 54.358001] AER: AER recover: Buffer overflow when recovering AER
> > > > for 0000:09:00:1
> > > > [ 54.376852] pcieport 0000:00:09.0: AER: device recovery successful
> > > > [ 54.383034] igb 0000:09:00.1: AER: aer_status: 0x00004000,
> > > > aer_mask: 0x00000000
> > > > [ 54.390348] igb 0000:09:00.1: AER: [14] CmpltTO (First)
> > > > [ 54.397144] igb 0000:09:00.1: AER: aer_layer=Transaction Layer,
> > > > aer_agent=Requester ID
> > > > [ 54.409555] igb 0000:09:00.1: AER: aer_uncor_severity: 0x00062011
> > > > [ 54.551370] AER: AER recover: Buffer overflow when recovering AER
> > > > for 0000:09:00:1
> > > > [ 54.705214] AER: AER recover: Buffer overflow when recovering AER
> > > > for 0000:09:00:1
> > > > [ 54.758703] AER: AER recover: Buffer overflow when recovering AER
> > > > for 0000:09:00:1
> > > > [ 54.865445] AER: AER recover: Buffer overflow when recovering AER
> > > > for 0000:09:00:1
> > > > [ 54.888751] pcieport 0000:00:09.0: AER: device recovery successful
> > > > [ 54.894933] igb 0000:09:00.1: AER: aer_status: 0x00004000,
> > > > aer_mask: 0x00000000
> > > > [ 54.902228] igb 0000:09:00.1: AER: [14] CmpltTO (First)
> > > > [ 54.916059] igb 0000:09:00.1: AER: aer_layer=Transaction Layer,
> > > > aer_agent=Requester ID
> > > > [ 54.923972] igb 0000:09:00.1: AER: aer_uncor_severity: 0x00062011
> > > > [ 55.057272] AER: AER recover: Buffer overflow when recovering AER
> > > > for 0000:09:00:1
> > > > [ 274.571401] AER: AER recover: Buffer overflow when recovering AER
> > > > for 0000:09:00:1
> > > > [ 274.686138] AER: AER recover: Buffer overflow when recovering AER
> > > > for 0000:09:00:1
> > > > [ 274.786134] AER: AER recover: Buffer overflow when recovering AER
> > > > for 0000:09:00:1
> > > > [ 274.886141] AER: AER recover: Buffer overflow when recovering AER
> > > > for 0000:09:00:1
> > > > [ 397.792897] Workqueue: events aer_recover_work_func
> > > > [ 397.797760] Call trace:
> > > > [ 397.800199] __switch_to+0xcc/0x108
> > > > [ 397.803675] __schedule+0x2c0/0x700
> > > > [ 397.807150] schedule+0x58/0xe8
> > > > [ 397.810283] schedule_preempt_disabled+0x18/0x28
> > > > [ 397.810788] AER: AER recover: Buffer overflow when recovering AER
> > > > for 0000:09:00:1
> > > > [ 397.814887] __mutex_lock.isra.9+0x288/0x5c8
> > > > [ 397.814890] __mutex_lock_slowpath+0x1c/0x28
> > > > [ 397.830962] mutex_lock+0x4c/0x68
> > > > [ 397.834264] report_slot_reset+0x30/0xa0
> > > > [ 397.838178] pci_walk_bus+0x68/0xc0
> > > > [ 397.841653] pcie_do_recovery+0xe8/0x248
> > > > [ 397.845562] aer_recover_work_func+0x100/0x138
> > > > [ 397.849995] process_one_work+0x1bc/0x458
> > > > [ 397.853991] worker_thread+0x150/0x500
> > > > [ 397.857727] kthread+0x114/0x118
> > > > [ 397.860945] ret_from_fork+0x10/0x18
> > > > [ 397.864525] INFO: task kworker/223:2:2939 blocked for more than 122 seconds.
> > > > [ 397.871564] Not tainted 5.7.0-rc3+ #68
> > > > [ 397.875819] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> > > > disables this message.
> > > > [ 397.883638] kworker/223:2 D 0 2939 2 0x00000228
> > > > [ 397.889121] Workqueue: ipv6_addrconf addrconf_verify_work
> > > > [ 397.894505] Call trace:
> > > > [ 397.896940] __switch_to+0xcc/0x108
> > > > [ 397.900419] __schedule+0x2c0/0x700
> > > > [ 397.903894] schedule+0x58/0xe8
> > > > [ 397.907023] schedule_preempt_disabled+0x18/0x28
> > > > [ 397.910798] AER: AER recover: Buffer overflow when recovering AER
> > > > for 0000:09:00:1
> > > > [ 397.911630] __mutex_lock.isra.9+0x288/0x5c8
> > > > [ 397.923440] __mutex_lock_slowpath+0x1c/0x28
> > > > [ 397.927696] mutex_lock+0x4c/0x68
> > > > [ 397.931005] rtnl_lock+0x24/0x30
> > > > [ 397.934220] addrconf_verify_work+0x18/0x30
> > > > [ 397.938394] process_one_work+0x1bc/0x458
> > > > [ 397.942390] worker_thread+0x150/0x500
> > > > [ 397.946126] kthread+0x114/0x118
> > > > [ 397.949345] ret_from_fork+0x10/0x18
> > > >
> > > > ---------------------------------------------------------------------------------------------------------------------------------
> > > > [3] with bootargs as pci=noaer and comment ghes_halder_aer() from AER driver
> > > >
> > > > [ 69.037035] igb 0000:09:00.1 enp9s0f1: Reset adapter
> > > > [ 69.348446] {9}[Hardware Error]: Hardware error from APEI Generic
> > > > Hardware Error Source: 0
> > > > [ 69.356698] {9}[Hardware Error]: It has been corrected by h/w and
> > > > requires no further action
> > > > [ 69.365121] {9}[Hardware Error]: event severity: corrected
> > > > [ 69.370593] {9}[Hardware Error]: Error 0, type: corrected
> > > > [ 69.376064] {9}[Hardware Error]: section_type: PCIe error
> > > > [ 69.381623] {9}[Hardware Error]: port_type: 4, root port
> > > > [ 69.387094] {9}[Hardware Error]: version: 3.0
> > > > [ 69.391611] {9}[Hardware Error]: command: 0x0106, status: 0x4010
> > > > [ 69.397777] {9}[Hardware Error]: device_id: 0000:00:09.0
> > > > [ 69.403248] {9}[Hardware Error]: slot: 0
> > > > [ 69.407331] {9}[Hardware Error]: secondary_bus: 0x09
> > > > [ 69.412455] {9}[Hardware Error]: vendor_id: 0x177d, device_id: 0xaf84
> > > > [ 69.419055] {9}[Hardware Error]: class_code: 000406
> > > > [ 69.424093] {9}[Hardware Error]: bridge: secondary_status:
> > > > 0x6000, control: 0x0002
> > > > [ 72.118132] igb 0000:09:00.1 enp9s0f1: igb: enp9s0f1 NIC Link is Up
> > > > 1000 Mbps Full Duplex, Flow Control: RX
> > > > [ 73.995068] igb 0000:09:00.1: Detected Tx Unit Hang
> > > > [ 73.995068] Tx Queue <2>
> > > > [ 73.995068] TDH <0>
> > > > [ 73.995068] TDT <1>
> > > > [ 73.995068] next_to_use <1>
> > > > [ 73.995068] next_to_clean <0>
> > > > [ 73.995068] buffer_info[next_to_clean]
> > > > [ 73.995068] time_stamp <ffff9c1a>
> > > > [ 73.995068] next_to_watch <0000000097d42934>
> > > > [ 73.995068] jiffies <ffff9cd0>
> > > > [ 73.995068] desc.status <168000>
> > > > [ 75.987323] igb 0000:09:00.1: Detected Tx Unit Hang
> > > > [ 75.987323] Tx Queue <2>
> > > > [ 75.987323] TDH <0>
> > > > [ 75.987323] TDT <1>
> > > > [ 75.987323] next_to_use <1>
> > > > [ 75.987323] next_to_clean <0>
> > > > [ 75.987323] buffer_info[next_to_clean]
> > > > [ 75.987323] time_stamp <ffff9c1a>
> > > > [ 75.987323] next_to_watch <0000000097d42934>
> > > > [ 75.987323] jiffies <ffff9d98>
> > > > [ 75.987323] desc.status <168000>
> > > > [ 77.952661] {10}[Hardware Error]: Hardware error from APEI Generic
> > > > Hardware Error Source: 1
> > > > [ 77.971790] {10}[Hardware Error]: event severity: recoverable
> > > > [ 77.977522] {10}[Hardware Error]: Error 0, type: recoverable
> > > > [ 77.983254] {10}[Hardware Error]: section_type: PCIe error
> > > > [ 77.999930] {10}[Hardware Error]: port_type: 0, PCIe end point
> > > > [ 78.005922] {10}[Hardware Error]: version: 3.0
> > > > [ 78.010526] {10}[Hardware Error]: command: 0x0507, status: 0x4010
> > > > [ 78.016779] {10}[Hardware Error]: device_id: 0000:09:00.1
> > > > [ 78.033107] {10}[Hardware Error]: slot: 0
> > > > [ 78.037276] {10}[Hardware Error]: secondary_bus: 0x00
> > > > [ 78.066253] {10}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> > > > [ 78.072940] {10}[Hardware Error]: class_code: 000002
> > > > [ 78.078064] {10}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> > > > [ 78.096202] igb 0000:09:00.1: Detected Tx Unit Hang
> > > > [ 78.096202] Tx Queue <2>
> > > > [ 78.096202] TDH <0>
> > > > [ 78.096202] TDT <1>
> > > > [ 78.096202] next_to_use <1>
> > > > [ 78.096202] next_to_clean <0>
> > > > [ 78.096202] buffer_info[next_to_clean]
> > > > [ 78.096202] time_stamp <ffff9c1a>
> > > > [ 78.096202] next_to_watch <0000000097d42934>
> > > > [ 78.096202] jiffies <ffff9e6a>
> > > > [ 78.096202] desc.status <168000>
> > > > [ 79.587406] {11}[Hardware Error]: Hardware error from APEI Generic
> > > > Hardware Error Source: 0
> > > > [ 79.595744] {11}[Hardware Error]: It has been corrected by h/w and
> > > > requires no further action
> > > > [ 79.604254] {11}[Hardware Error]: event severity: corrected
> > > > [ 79.609813] {11}[Hardware Error]: Error 0, type: corrected
> > > > [ 79.615371] {11}[Hardware Error]: section_type: PCIe error
> > > > [ 79.621016] {11}[Hardware Error]: port_type: 4, root port
> > > > [ 79.626574] {11}[Hardware Error]: version: 3.0
> > > > [ 79.631177] {11}[Hardware Error]: command: 0x0106, status: 0x4010
> > > > [ 79.637430] {11}[Hardware Error]: device_id: 0000:00:09.0
> > > > [ 79.642988] {11}[Hardware Error]: slot: 0
> > > > [ 79.647157] {11}[Hardware Error]: secondary_bus: 0x09
> > > > [ 79.652368] {11}[Hardware Error]: vendor_id: 0x177d, device_id: 0xaf84
> > > > [ 79.659055] {11}[Hardware Error]: class_code: 000406
> > > > [ 79.664180] {11}[Hardware Error]: bridge: secondary_status:
> > > > 0x6000, control: 0x0002
> > > > [ 79.987052] igb 0000:09:00.1: Detected Tx Unit Hang
> > > > [ 79.987052] Tx Queue <2>
> > > > [ 79.987052] TDH <0>
> > > > [ 79.987052] TDT <1>
> > > > [ 79.987052] next_to_use <1>
> > > > [ 79.987052] next_to_clean <0>
> > > > [ 79.987052] buffer_info[next_to_clean]
> > > > [ 79.987052] time_stamp <ffff9c1a>
> > > > [ 79.987052] next_to_watch <0000000097d42934>
> > > > [ 79.987052] jiffies <ffff9f28>
> > > > [ 79.987052] desc.status <168000>
> > > > [ 79.987056] igb 0000:09:00.1: Detected Tx Unit Hang
> > > > [ 79.987056] Tx Queue <3>
> > > > [ 79.987056] TDH <0>
> > > > [ 79.987056] TDT <1>
> > > > [ 79.987056] next_to_use <1>
> > > > [ 79.987056] next_to_clean <0>
> > > > [ 79.987056] buffer_info[next_to_clean]
> > > > [ 79.987056] time_stamp <ffff9e43>
> > > > [ 79.987056] next_to_watch <000000008da33deb>
> > > > [ 79.987056] jiffies <ffff9f28>
> > > > [ 79.987056] desc.status <514000>
> > > > [ 81.986688] igb 0000:09:00.1 enp9s0f1: Reset adapter
> > > > [ 81.986842] igb 0000:09:00.1: Detected Tx Unit Hang
> > > > [ 81.986842] Tx Queue <2>
> > > > [ 81.986842] TDH <0>
> > > > [ 81.986842] TDT <1>
> > > > [ 81.986842] next_to_use <1>
> > > > [ 81.986842] next_to_clean <0>
> > > > [ 81.986842] buffer_info[next_to_clean]
> > > > [ 81.986842] time_stamp <ffff9c1a>
> > > > [ 81.986842] next_to_watch <0000000097d42934>
> > > > [ 81.986842] jiffies <ffff9ff0>
> > > > [ 81.986842] desc.status <168000>
> > > > [ 81.986844] igb 0000:09:00.1: Detected Tx Unit Hang
> > > > [ 81.986844] Tx Queue <3>
> > > > [ 81.986844] TDH <0>
> > > > [ 81.986844] TDT <1>
> > > > [ 81.986844] next_to_use <1>
> > > > [ 81.986844] next_to_clean <0>
> > > > [ 81.986844] buffer_info[next_to_clean]
> > > > [ 81.986844] time_stamp <ffff9e43>
> > > > [ 81.986844] next_to_watch <000000008da33deb>
> > > > [ 81.986844] jiffies <ffff9ff0>
> > > > [ 81.986844] desc.status <514000>
> > > > [ 85.346515] {12}[Hardware Error]: Hardware error from APEI Generic
> > > > Hardware Error Source: 0
> > > > [ 85.354854] {12}[Hardware Error]: It has been corrected by h/w and
> > > > requires no further action
> > > > [ 85.363365] {12}[Hardware Error]: event severity: corrected
> > > > [ 85.368924] {12}[Hardware Error]: Error 0, type: corrected
> > > > [ 85.374483] {12}[Hardware Error]: section_type: PCIe error
> > > > [ 85.380129] {12}[Hardware Error]: port_type: 0, PCIe end point
> > > > [ 85.386121] {12}[Hardware Error]: version: 3.0
> > > > [ 85.390725] {12}[Hardware Error]: command: 0x0507, status: 0x0010
> > > > [ 85.396980] {12}[Hardware Error]: device_id: 0000:09:00.0
> > > > [ 85.402540] {12}[Hardware Error]: slot: 0
> > > > [ 85.406710] {12}[Hardware Error]: secondary_bus: 0x00
> > > > [ 85.411921] {12}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10c9
> > > > [ 85.418609] {12}[Hardware Error]: class_code: 000002
> > > > [ 85.423733] {12}[Hardware Error]: serial number: 0xff1b4580, 0x90e2baff
> > > > [ 85.826695] igb 0000:09:00.1 enp9s0f1: igb: enp9s0f1 NIC Link is Up
> > > > 1000 Mbps Full Duplex, Flow Control: RX
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > > So, If we are in a kdump kernel try to copy SMMU Stream table from
> > > > > > primary/old kernel to preserve the mappings until the device driver
> > > > > > takes over.
> > > > > >
> > > > > > Signed-off-by: Prabhakar Kushwaha <pkushwaha@marvell.com>
> > > > > > ---
> > > > > > Changes for v2: Used memremap in-place of ioremap
> > > > > >
> > > > > > V2 patch has been sanity tested.
> > > > > >
> > > > > > V1 patch has been tested with
> > > > > > A) PCIe-Intel 82576 Gigabit Network card in following
> > > > > > configurations with "no AER error". Each iteration has
> > > > > > been tested on both Suse kdump rfs And default Centos distro rfs.
> > > > > >
> > > > > > 1) with 2 level stream table
> > > > > > ----------------------------------------------------
> > > > > > SMMU | Normal Ping | Flood Ping
> > > > > > -----------------------------------------------------
> > > > > > Default Operation | 100 times | 10 times
> > > > > > -----------------------------------------------------
> > > > > > IOMMU bypass | 41 times | 10 times
> > > > > > -----------------------------------------------------
> > > > > >
> > > > > > 2) with Linear stream table.
> > > > > > -----------------------------------------------------
> > > > > > SMMU | Normal Ping | Flood Ping
> > > > > > ------------------------------------------------------
> > > > > > Default Operation | 100 times | 10 times
> > > > > > ------------------------------------------------------
> > > > > > IOMMU bypass | 55 times | 10 times
> > > > > > -------------------------------------------------------
> > > > > >
> > > > > > B) This patch is also tested with Micron Technology Inc 9200 PRO NVMe
> > > > > > SSD card with 2 level stream table using "fio" in mixed read/write and
> > > > > > only read configurations. It is tested for both Default Operation and
> > > > > > IOMMU bypass mode for minimum 10 iterations across Centos kdump rfs and
> > > > > > default Centos ditstro rfs.
> > > > > >
> > > > > > This patch is not full proof solution. Issue can still come
> > > > > > from the point device is discovered and driver probe called.
> > > > > > This patch has reduced window of scenario from "SMMU Stream table
> > > > > > creation - device-driver" to "device discovery - device-driver".
> > > > > > Usually, device discovery to device-driver is very small time. So
> > > > > > the probability is very low.
> > > > > >
> > > > > > Note: device-discovery will overwrite existing stream table entries
> > > > > > with both SMMU stage as by-pass.
> > > > > >
> > > > > >
> > > > > > drivers/iommu/arm-smmu-v3.c | 36 +++++++++++++++++++++++++++++++++++-
> > > > > > 1 file changed, 35 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
> > > > > > index 82508730feb7..d492d92c2dd7 100644
> > > > > > --- a/drivers/iommu/arm-smmu-v3.c
> > > > > > +++ b/drivers/iommu/arm-smmu-v3.c
> > > > > > @@ -1847,7 +1847,13 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
> > > > > > break;
> > > > > > case STRTAB_STE_0_CFG_S1_TRANS:
> > > > > > case STRTAB_STE_0_CFG_S2_TRANS:
> > > > > > - ste_live = true;
> > > > > > + /*
> > > > > > + * As kdump kernel copy STE table from previous
> > > > > > + * kernel. It still may have valid stream table entries.
> > > > > > + * Forcing entry as false to allow overwrite.
> > > > > > + */
> > > > > > + if (!is_kdump_kernel())
> > > > > > + ste_live = true;
> > > > > > break;
> > > > > > case STRTAB_STE_0_CFG_ABORT:
> > > > > > BUG_ON(!disable_bypass);
> > > > > > @@ -3264,6 +3270,9 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu)
> > > > > > return -ENOMEM;
> > > > > > }
> > > > > >
> > > > > > + if (is_kdump_kernel())
> > > > > > + return 0;
> > > > > > +
> > > > > > for (i = 0; i < cfg->num_l1_ents; ++i) {
> > > > > > arm_smmu_write_strtab_l1_desc(strtab, &cfg->l1_desc[i]);
> > > > > > strtab += STRTAB_L1_DESC_DWORDS << 3;
> > > > > > @@ -3272,6 +3281,23 @@ static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu)
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > +static void arm_smmu_copy_table(struct arm_smmu_device *smmu,
> > > > > > + struct arm_smmu_strtab_cfg *cfg, u32 size)
> > > > > > +{
> > > > > > + struct arm_smmu_strtab_cfg rdcfg;
> > > > > > +
> > > > > > + rdcfg.strtab_dma = readq_relaxed(smmu->base + ARM_SMMU_STRTAB_BASE);
> > > > > > + rdcfg.strtab_base_cfg = readq_relaxed(smmu->base
> > > > > > + + ARM_SMMU_STRTAB_BASE_CFG);
> > > > > > +
> > > > > > + rdcfg.strtab_dma &= STRTAB_BASE_ADDR_MASK;
> > > > > > + rdcfg.strtab = memremap(rdcfg.strtab_dma, size, MEMREMAP_WB);
> > > > > > +
> > > > > > + memcpy_fromio(cfg->strtab, rdcfg.strtab, size);
> > > > > > +
> > > > > > + cfg->strtab_base_cfg = rdcfg.strtab_base_cfg;
> > > > > > +}
> > > > > > +
> > > > > > static int arm_smmu_init_strtab_2lvl(struct arm_smmu_device *smmu)
> > > > > > {
> > > > > > void *strtab;
> > > > > > @@ -3307,6 +3333,9 @@ static int arm_smmu_init_strtab_2lvl(struct arm_smmu_device *smmu)
> > > > > > reg |= FIELD_PREP(STRTAB_BASE_CFG_SPLIT, STRTAB_SPLIT);
> > > > > > cfg->strtab_base_cfg = reg;
> > > > > >
> > > > > > + if (is_kdump_kernel())
> > > > > > + arm_smmu_copy_table(smmu, cfg, l1size);
> > > > > > +
> > > > > > return arm_smmu_init_l1_strtab(smmu);
> > > > > > }
> > > > > >
> > > > > > @@ -3334,6 +3363,11 @@ static int arm_smmu_init_strtab_linear(struct arm_smmu_device *smmu)
> > > > > > reg |= FIELD_PREP(STRTAB_BASE_CFG_LOG2SIZE, smmu->sid_bits);
> > > > > > cfg->strtab_base_cfg = reg;
> > > > > >
> > > > > > + if (is_kdump_kernel()) {
> > > > > > + arm_smmu_copy_table(smmu, cfg, size);
> > > > > > + return 0;
> > > > > > + }
> > > > > > +
> > > > > > arm_smmu_init_bypass_stes(strtab, cfg->num_l1_ents);
> > > > > > return 0;
> > > > > > }
> > > > > > --
> > > > > > 2.18.2
> > > > > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 06/11] net: ethernet: mtk-star-emac: new driver
From: Bartosz Golaszewski @ 2020-05-27 11:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Edwin Peer, devicetree, Stephane Le Provost, Bartosz Golaszewski,
netdev, Sean Wang, Linux Kernel Mailing List, Pedro Tsai,
Mark Lee, Fabien Parent, Rob Herring,
moderated list:ARM/Mediatek SoC..., clang-built-linux,
Andrew Perepech, John Crispin, Matthias Brugger, Jakub Kicinski,
Nathan Chancellor, David S . Miller, Linux ARM, Heiner Kallweit
In-Reply-To: <CAK8P3a3WXGZpeX0E8Kyuo5Rkv5acdkZN6_HNS61Y1=Jh+G+pRQ@mail.gmail.com>
śr., 27 maj 2020 o 13:33 Arnd Bergmann <arnd@arndb.de> napisał(a):
>
> On Wed, May 27, 2020 at 10:46 AM Bartosz Golaszewski <brgl@bgdev.pl> wrote:
>
> > > I don't know if there should be a new label that excludes that
> > > assignment for those particular gotos or if new_dma_addr should
> > > be initialized to something at the top. Please take a look at
> > > addressing this when you get a chance.
> > >
> > > Cheers,
> > > Nathan
> >
> > Hi Nathan,
> >
> > Thanks for reporting this! I have a fix ready and will send it shortly.
>
> I already have a workaround for this bug as well as another one
> in my tree that I'll send later today after some more testing.
>
> Feel free to wait for that, or just ignore mine if you already have a fix.
>
> Arnd
Hi Arnd!
I already posted a fix[1]. Sorry for omitting you, but somehow your
name didn't pop up in get_maintainers.pl.
Bartosz
[1] https://lkml.org/lkml/2020/5/27/378
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] driver/perf: Add PMU driver for the ARM DMC-620 memory controller.
From: Will Deacon @ 2020-05-27 11:50 UTC (permalink / raw)
To: Tuan Phan; +Cc: Mark Rutland, patches, linux-kernel, linux-arm-kernel
In-Reply-To: <1589229894-18863-1-git-send-email-tuanphan@os.amperecomputing.com>
On Mon, May 11, 2020 at 01:44:52PM -0700, Tuan Phan wrote:
> DMC-620 PMU supports 10 total counters that are independently
> programmable for different events and can be individually started and
> stopped.
>
> ACPI is only supported; device tree support is welcomed to be added and
> tested for other platforms.
>
> Usage example:
> #perf stat -e arm_dmc620_10008c000/clk_cycle_count/ -C 0
> Get perf event for clk_cycle_count counter.
>
> #perf stat -e arm_dmc620_10008c000/clkdiv2_allocate,mask=0x1f,match=0x2f,
> incr=2,invert=1/ -C 0
> The above example shows how to specify mask, match, incr,
> invert parameters for clkdiv2_allocate event.
>
> Signed-off-by: Tuan Phan <tuanphan@os.amperecomputing.com>
> ---
> Changes in v2:
> - Removed IRQF_SHARED flag and added support for multiple
> PMUs sharing the same interrupt.
> - Fixed an interrupt handler race condition.
>
> The ACPI binding spec for PMU DMC620 is under beta and located
> in ARM server group under project "ACPI on ARM".
>
> drivers/perf/Kconfig | 8 +
> drivers/perf/Makefile | 1 +
> drivers/perf/arm_dmc620_pmu.c | 869 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 878 insertions(+)
> create mode 100644 drivers/perf/arm_dmc620_pmu.c
Given that this is Arm IP, it would be nice to have a review from somebody
at Arm. I have vague recollections of an internal DMC PMU driver too, but I
don't remember the details.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH v13 1/2] media: dt-bindings: media: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem
From: Vishal Sagar @ 2020-05-27 11:53 UTC (permalink / raw)
To: Laurent Pinchart
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org, Jacopo Mondi,
Dinesh Kumar, Hyun Kwon, Sandip Kothari,
linux-kernel@vger.kernel.org, robh+dt@kernel.org, Michal Simek,
Luca Ceresoli, hans.verkuil@cisco.com, mchehab@kernel.org,
Rob Herring, linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org
In-Reply-To: <20200524020214.GB6026@pendragon.ideasonboard.com>
Hi Laurent,
Thanks for reviewing this series.
> -----Original Message-----
> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Sent: Sunday, May 24, 2020 7:32 AM
> To: Vishal Sagar <vsagar@xilinx.com>
> Cc: Hyun Kwon <hyunk@xilinx.com>; mchehab@kernel.org;
> robh+dt@kernel.org; mark.rutland@arm.com; Michal Simek
> <michals@xilinx.com>; linux-media@vger.kernel.org;
> devicetree@vger.kernel.org; hans.verkuil@cisco.com; linux-arm-
> kernel@lists.infradead.org; linux-kernel@vger.kernel.org; Dinesh Kumar
> <dineshk@xilinx.com>; Sandip Kothari <sandipk@xilinx.com>; Luca Ceresoli
> <luca@lucaceresoli.net>; Jacopo Mondi <jacopo@jmondi.org>; Hyun Kwon
> <hyunk@xilinx.com>; Rob Herring <robh@kernel.org>
> Subject: Re: [PATCH v13 1/2] media: dt-bindings: media: xilinx: Add Xilinx MIPI
> CSI-2 Rx Subsystem
>
> Hi Vishal,
>
> Thank you for the patch.
>
> On Tue, May 12, 2020 at 08:49:46PM +0530, Vishal Sagar wrote:
> > Add bindings documentation for Xilinx MIPI CSI-2 Rx Subsystem.
> >
> > The Xilinx MIPI CSI-2 Rx Subsystem consists of a CSI-2 Rx controller,
> > a D-PHY in Rx mode and a Video Format Bridge.
> >
> > Signed-off-by: Vishal Sagar <vishal.sagar@xilinx.com>
> > Reviewed-by: Hyun Kwon <hyun.kwon@xilinx.com>
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > ---
> > v13
> > - Based on Laurent's suggestions
> > - Fixed the datatypes values as minimum and maximum
> > - condition added for en-vcx property
> >
> > v12
> > - Moved to yaml format
> > - Update CSI-2 and D-PHY
> > - Mention that bindings for D-PHY not here
> > - reset -> video-reset
> >
> > v11
> > - Modify compatible string from 4.0 to 5.0
> >
> > v10
> > - No changes
> >
> > v9
> > - Fix xlnx,vfb description.
> > - s/Optional/Required endpoint property.
> > - Move data-lanes description from Ports to endpoint property section.
> >
> > v8
> > - Added reset-gpios optional property to assert video_aresetn
> >
> > v7
> > - Removed the control name from dt bindings
> > - Updated the example dt node name to csi2rx
> >
> > v6
> > - Added "control" after V4L2_CID_XILINX_MIPICSISS_ACT_LANES as
> > suggested by Luca
> > - Added reviewed by Rob Herring
> >
> > v5
> > - Incorporated comments by Luca Cersoli
> > - Removed DPHY clock from description and example
> > - Removed bayer pattern from device tree MIPI CSI IP
> > doesn't deal with bayer pattern.
> >
> > v4
> > - Added reviewed by Hyun Kwon
> >
> > v3
> > - removed interrupt parent as suggested by Rob
> > - removed dphy clock
> > - moved vfb to optional properties
> > - Added required and optional port properties section
> > - Added endpoint property section
> >
> > v2
> > - updated the compatible string to latest version supported
> > - removed DPHY related parameters
> > - added CSI v2.0 related property (including VCX for supporting upto 16
> > virtual channels).
> > - modified csi-pxl-format from string to unsigned int type where the value
> > is as per the CSI specification
> > - Defined port 0 and port 1 as sink and source ports.
> > - Removed max-lanes property as suggested by Rob and Sakari
> > .../bindings/media/xilinx/xlnx,csi2rxss.yaml | 226 ++++++++++++++++++
> > 1 file changed, 226 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
> > b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
> > new file mode 100644
> > index 000000000000..b0885f461785
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yam
> > +++ l
> > @@ -0,0 +1,226 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/media/xilinx/xlnx,csi2rxss.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Xilinx MIPI CSI-2 Receiver Subsystem
> > +
> > +maintainers:
> > + - Vishal Sagar <vishal.sagar@xilinx.com>
> > +
> > +description: |
> > + The Xilinx MIPI CSI-2 Receiver Subsystem is used to capture MIPI
> > +CSI-2
> > + traffic from compliant camera sensors and send the output as AXI4
> > +Stream
> > + video data for image processing.
> > + The subsystem consists of a MIPI D-PHY in slave mode which captures
> > +the
> > + data packets. This is passed along the MIPI CSI-2 Rx IP which
> > +extracts the
> > + packet data. The optional Video Format Bridge (VFB) converts this
> > +data to
> > + AXI4 Stream video data.
> > + For more details, please refer to PG232 Xilinx MIPI CSI-2 Receiver
> Subsystem.
> > + Please note that this bindings includes only the MIPI CSI-2 Rx
> > +controller
> > + and Video Format Bridge and not D-PHY.
> > +
> > +properties:
> > + compatible:
> > + items:
> > + - enum:
> > + - xlnx,mipi-csi2-rx-subsystem-5.0
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + description: List of clock specifiers
> > + items:
> > + - description: AXI Lite clock
> > + - description: Video clock
> > +
> > + clock-names:
> > + items:
> > + - const: lite_aclk
> > + - const: video_aclk
> > +
> > + xlnx,csi-pxl-format:
> > + description: |
> > + This denotes the CSI Data type selected in hw design.
> > + Packets other than this data type (except for RAW8 and
> > + User defined data types) will be filtered out.
> > + Possible values are as below -
> > + 0x1e - YUV4228B
> > + 0x1f - YUV42210B
> > + 0x20 - RGB444
> > + 0x21 - RGB555
> > + 0x22 - RGB565
> > + 0x23 - RGB666
> > + 0x24 - RGB888
> > + 0x28 - RAW6
> > + 0x29 - RAW7
> > + 0x2a - RAW8
> > + 0x2b - RAW10
> > + 0x2c - RAW12
> > + 0x2d - RAW14
> > + 0x2e - RAW16
> > + 0x2f - RAW20
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32
> > + - anyOf:
> > + - minimum: 0x1e
> > + - maximum: 0x24
> > + - minimum: 0x28
> > + - maximum: 0x2f
> > +
> > + xlnx,vfb:
> > + type: boolean
> > + description: Present when Video Format Bridge is enabled in IP
> > + configuration
> > +
> > + xlnx,en-csi-v2-0:
> > + type: boolean
> > + description: Present if CSI v2 is enabled in IP configuration.
> > +
> > + xlnx,en-vcx:
> > + type: boolean
> > + description: |
> > + When present, there are maximum 16 virtual channels, else only 4.
> > +
> > + xlnx,en-active-lanes:
> > + type: boolean
> > + description: |
> > + Present if the number of active lanes can be re-configured at
> > + runtime in the Protocol Configuration Register. Otherwise all lanes,
> > + as set in IP configuration, are always active.
> > +
> > + video-reset-gpios:
> > + description: Optional specifier for a GPIO that asserts video_aresetn.
> > + maxItems: 1
> > +
> > + ports:
> > + type: object
> > +
> > + properties:
> > + port@0:
> > + type: object
> > + description: |
> > + Input / sink port node, single endpoint describing the
> > + CSI-2 transmitter.
> > +
> > + properties:
> > + reg:
> > + const: 0
> > +
> > + endpoint:
> > + type: object
> > +
> > + properties:
> > +
> > + data-lanes:
> > + description: |
> > + This is required only in the sink port 0 endpoint which
> > + connects to MIPI CSI-2 source like sensor.
> > + The possible values are -
> > + 1 - For 1 lane enabled in IP.
> > + 1 2 - For 2 lanes enabled in IP.
> > + 1 2 3 - For 3 lanes enabled in IP.
> > + 1 2 3 4 - For 4 lanes enabled in IP.
> > + items:
> > + - const: 1
> > + - const: 2
> > + - const: 3
> > + - const: 4
> > +
> > + remote-endpoint: true
> > +
> > + required:
> > + - data-lanes
> > + - remote-endpoint
> > +
> > + additionalProperties: false
> > +
> > + additionalProperties: false
> > +
> > + port@1:
> > + type: object
> > + description: |
> > + Output / source port node, endpoint describing modules
> > + connected the CSI-2 receiver.
> > +
> > + properties:
> > +
> > + reg:
> > + const: 1
> > +
> > + endpoint:
> > + type: object
> > +
> > + properties:
> > +
> > + remote-endpoint: true
> > +
> > + required:
> > + - remote-endpoint
> > +
> > + additionalProperties: false
> > +
> > + additionalProperties: false
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - clocks
> > + - clock-names
> > + - xlnx,csi-pxl-format
> > + - ports
> > +
> > +if:
> > + not:
> > + required:
> > + - xlnx,en-csi-v2-0
> > +then:
> > + properties:
> > + xlnx,en-vcx: false
>
> As I've just commented on v12, I think we should condition the xlnx,csi-pxl-
> format property to xlnx,vfb being set. xlnx,csi-pxl-format should be removed
> from the required properties above, and the following conditions added:
>
> allOf:
> - if:
> required:
> - xlnx,vfb
> then:
> required:
> - xlnx,csi-pxl-format
> else:
> properties:
> xlnx,csi-pxl-format: false
>
> - if:
> not:
> required:
> - xlnx,en-csi-v2-0
> then:
> properties:
> xlnx,en-vcx: false
>
> The 'allOf' is needed as you can't have two 'if' constructs at the top level.
>
Thanks for sharing the explanation for this.
Can you please share where I can get this info?
> Please however let me know if my understanding is wrong and xlnx,csi-pxl-
> format is needed even when xlnx,vfb is not set. In that case please ignore this
> change (but please add the ... below).
>
Ok. I will add ... in the end.
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/gpio/gpio.h>
> > + xcsi2rxss_1: csi2rx@a0020000 {
> > + compatible = "xlnx,mipi-csi2-rx-subsystem-5.0";
> > + reg = <0x0 0xa0020000 0x0 0x10000>;
> > + interrupt-parent = <&gic>;
> > + interrupts = <0 95 4>;
> > + xlnx,csi-pxl-format = <0x2a>;
> > + xlnx,vfb;
> > + xlnx,en-active-lanes;
> > + xlnx,en-csi-v2-0;
> > + xlnx,en-vcx;
> > + clock-names = "lite_aclk", "video_aclk";
> > + clocks = <&misc_clk_0>, <&misc_clk_1>;
> > + video-reset-gpios = <&gpio 86 GPIO_ACTIVE_LOW>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + /* Sink port */
> > + reg = <0>;
> > + csiss_in: endpoint {
> > + data-lanes = <1 2 3 4>;
> > + /* MIPI CSI-2 Camera handle */
> > + remote-endpoint = <&camera_out>;
> > + };
> > + };
> > + port@1 {
> > + /* Source port */
> > + reg = <1>;
> > + csiss_out: endpoint {
> > + remote-endpoint = <&vproc_in>;
> > + };
> > + };
> > + };
> > + };
>
> YAML files usually end with
>
> ...
>
> on the last line to mark the end of file.
>
Ok I will add this to the end of the file.
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>
> --
> Regards,
>
> Laurent Pinchart
Regards
Vishal Sagar
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: High interrupt latency with low power idle mode on i.MX6
From: Russell King - ARM Linux admin @ 2020-05-27 11:53 UTC (permalink / raw)
To: Schrempf Frieder
Cc: Kate Stewart, linux-pm@vger.kernel.org, Enrico Weigelt,
Sascha Hauer, Daniel Lezcano, Rafael J. Wysocki,
linux-kernel@vger.kernel.org, Thomas Gleixner, Shawn Guo,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <bc91129c-121c-a070-53b2-1f0bb6d4500a@kontron.de>
On Wed, May 27, 2020 at 10:39:12AM +0000, Schrempf Frieder wrote:
> Hi,
>
> on our i.MX6UL/ULL boards running mainline kernels, we see an issue with
> RS485 collisions on the bus. These are caused by the resetting of the
> RTS signal being delayed after each transmission. The TXDC interrupt
> takes several milliseconds to trigger and the slave on the bus already
> starts to send a reply in the meantime.
>
> We found out that these delays only happen when the CPU is in "low power
> idle" mode (ARM power off). When we disable cpuidle state 2 or put some
> background load on the CPU everything works fine and the delays are gone.
>
> echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state2/disable
>
> It seems like also other interfaces (I2C, etc.) might be affected by
> these increased latencies, we haven't investigated this more closely,
> though.
>
> We currently apply a patch to our kernel, that disables low power idle
> mode by default, but I'm wondering if there's a way to fix this
> properly? Any ideas?
Let's examine a basic fact about power management:
The deeper PM modes that the system enters, the higher the latency to
resume operation.
So, I'm not surprised that you have higher latency when you allow the
system to enter lower power modes. Does that mean that the kernel
should not permit entering lower power modes - no, it's policy and
application dependent.
If the hardware is designed to use software to manage the RTS signal
to control the RS485 receiver, then I'm afraid that your report really
does not surprise me - throwing that at software to manage is a really
stupid idea, but it seems lots of people do this. I've held this view
since I worked on a safety critical system that used RS485 back in the
1990s (London Underground Jubilee Line Extension public address system.)
So, what we have here is several things that come together to create a
problem:
1) higher power savings produce higher latency to resume from
2) lack of hardware support for RS485 half duplex communication needing
software support
3) an application that makes use of RS485 half duplex communication
without disabling the higher latency power saving modes
The question is, who should disable those higher latency power saving
modes - the kernel, or userspace?
The kernel knows whether it needs to provide software control of the
RTS signal or not, but the kernel does not know the maximum permissible
latency (which is application specific.) So, the kernel doesn't have
all the information it needs. However, there is a QoS subsystem which
may help you.
There's also tweaks available via
/sys/devices/system/cpu/cpu*/power/pm_qos_resume_latency_us
which can be poked to configure the latency that is required, and will
prevent the deeper PM states being entered.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC 02/50] staging: vchi: Get rid of vchi_queue_user_message()
From: Nicolas Saenz Julienne @ 2020-05-27 11:53 UTC (permalink / raw)
To: bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel,
linux-kernel
Cc: devel, kernel-list, laurent.pinchart, Nicolas Saenz Julienne,
gregkh
In-Reply-To: <20200527115400.31391-1-nsaenzjulienne@suse.de>
The function has no users.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
.../vc04_services/interface/vchi/vchi.h | 6 ----
.../interface/vchiq_arm/vchiq_shim.c | 34 -------------------
2 files changed, 40 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h b/drivers/staging/vc04_services/interface/vchi/vchi.h
index 686cfc536012..62d9d3efa755 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -111,12 +111,6 @@ vchi_queue_kernel_message(struct vchi_service_handle *handle,
void *data,
unsigned int size);
-/* Routine to send a message from user memory across a service */
-extern int
-vchi_queue_user_message(struct vchi_service_handle *handle,
- void __user *data,
- unsigned int size);
-
// Routine to receive a msg from a service
// Dequeue is equivalent to hold, copy into client buffer, release
extern int32_t vchi_msg_dequeue(struct vchi_service_handle *handle,
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
index 9a040651bb9b..2c2bd7a9dc27 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
@@ -150,40 +150,6 @@ vchi_queue_kernel_message(struct vchi_service_handle *handle,
}
EXPORT_SYMBOL(vchi_queue_kernel_message);
-struct vchi_queue_user_message_context {
- void __user *data;
-};
-
-static ssize_t
-vchi_queue_user_message_callback(void *context,
- void *dest,
- size_t offset,
- size_t maxsize)
-{
- struct vchi_queue_user_message_context *copycontext = context;
-
- if (copy_from_user(dest, copycontext->data + offset, maxsize))
- return -EFAULT;
-
- return maxsize;
-}
-
-int
-vchi_queue_user_message(struct vchi_service_handle *handle,
- void __user *data,
- unsigned int size)
-{
- struct vchi_queue_user_message_context copycontext = {
- .data = data
- };
-
- return vchi_msg_queue(handle,
- vchi_queue_user_message_callback,
- ©context,
- size);
-}
-EXPORT_SYMBOL(vchi_queue_user_message);
-
/***********************************************************
* Name: vchi_bulk_queue_receive
*
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC 01/50] staging: vchi: Get rid of vchi_service_destroy()
From: Nicolas Saenz Julienne @ 2020-05-27 11:53 UTC (permalink / raw)
To: bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel,
linux-kernel
Cc: devel, kernel-list, laurent.pinchart, Nicolas Saenz Julienne,
gregkh
In-Reply-To: <20200527115400.31391-1-nsaenzjulienne@suse.de>
The function has no users.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
.../vc04_services/interface/vchi/vchi.h | 3 ---
.../interface/vchiq_arm/vchiq_shim.c | 19 -------------------
2 files changed, 22 deletions(-)
diff --git a/drivers/staging/vc04_services/interface/vchi/vchi.h b/drivers/staging/vc04_services/interface/vchi/vchi.h
index ff2b960d8cac..686cfc536012 100644
--- a/drivers/staging/vc04_services/interface/vchi/vchi.h
+++ b/drivers/staging/vc04_services/interface/vchi/vchi.h
@@ -83,9 +83,6 @@ extern uint32_t vchi_current_time(struct vchi_instance_handle *instance_handle);
/******************************************************************************
* Global service API
*****************************************************************************/
-// Routine to destroy a service
-extern int32_t vchi_service_destroy(const struct vchi_service_handle *handle);
-
// Routine to open a named service
extern int32_t vchi_service_open(struct vchi_instance_handle *instance_handle,
struct service_creation *setup,
diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
index efdd3b1c7d85..9a040651bb9b 100644
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
@@ -642,25 +642,6 @@ int32_t vchi_service_close(const struct vchi_service_handle *handle)
}
EXPORT_SYMBOL(vchi_service_close);
-int32_t vchi_service_destroy(const struct vchi_service_handle *handle)
-{
- int32_t ret = -1;
- struct shim_service *service = (struct shim_service *)handle;
-
- if (service) {
- enum vchiq_status status = vchiq_remove_service(service->handle);
-
- if (status == VCHIQ_SUCCESS) {
- service_free(service);
- service = NULL;
- }
-
- ret = vchiq_status_to_vchi(status);
- }
- return ret;
-}
-EXPORT_SYMBOL(vchi_service_destroy);
-
int32_t vchi_service_set_option(const struct vchi_service_handle *handle,
enum vchi_service_option option,
int value)
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFC 00/50] staging: vchiq: Getting rid of the vchi/vchiq split
From: Nicolas Saenz Julienne @ 2020-05-27 11:53 UTC (permalink / raw)
To: bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel
Cc: devel, kernel-list, linux-kernel, laurent.pinchart, gregkh,
Nicolas Saenz Julienne
vchi acts as a mid layer between vchiq and its kernel services, while
arguably providing little to no benefit: half of the functions exposed
are a 1:1 copy of vchiq's, and the rest provide some functionality which
can be easly integrated into vchiq without all the churn. Moreover it
has been found in the past as a blockage to further fixes in vchiq as
every change needed its vchi counterpart, if even possible.
Hence this series, which merges all vchi functionality into vchiq and
provies a simpler and more concise API to services.
I'm aware that kernel's vchi API tries to mimic its userspace
counterpart (or vice versa). Obviously this breaks the parity, but I
don't think it's a sane goal to have. There is little sense or gain from
it, and adds impossible constraints to upstreaming the driver.
Overall the series falls short of removing 1500 lines of code, which is
pretty neat on itself.
So far it has been tested trough bcm2835-camera, audio and vchiq-test. I
can't do much about vc-sm-cma for now, but the changes are done in a way
that shouldn't affect its behaviour.
Note that the series builds up on RPi/Laurent's camera support series[1]
and can't yet be merged. We'd have to coordinate here. We could either
wait for the vc_sm_cma rework (if it's not going to take months and
months to finish), or factor out all the vc-sm-cma stuff, merge that into
the downstream kernel and take the rest of the series on top of
Laurent's mmal-vchiq changes.
Regards,
Nicolas
[1] https://lwn.net/ml/linux-media/20200504092611.9798-1-laurent.pinchart@ideasonboard.com/
---
Nicolas Saenz Julienne (50):
staging: vchi: Get rid of vchi_service_destroy()
staging: vchi: Get rid of vchi_queue_user_message()
staging: vchiq: Move copy callback handling into vchiq
staging: vchi: Merge vchi_msg_queue() into vchi_queue_kernel_message()
staging: vchi: Get rid of vchi_service_set_option()
staging: vchi: Get rid of vchiq_status_to_vchi()
staging: vchi: Get rid of not implemented function declarations
staging: vchi: Get rid of C++ guards
staging: vchiq: move vchiq_release_message() into vchiq
staging: vchiq: Get rid of VCHIQ_SERVICE_OPENEND callback reason
staging: vchi: Get rid of all useless callback reasons
staging: vchi: Get rid of vchi_msg_peek()
staging: vchi: Get rid of struct vchi_instance_handle
staging: vchi: Unify struct shim_service and struct
vchi_service_handle
staging: vc04_services: bcm2835-audio: Use vchi_msg_hold()
staging: vchi: Get rid of vchi_msg_dequeue()
staging: vchi_common: Get rid of all unused definitions
staging: vc04_services: vc-sm-cma: Get rid of the multiple connections
option
staging: vchi: Get rid of unnecessary defines
staging: vc04_services: Get rid of vchi_cfg.h
staging: vchi: Get rid of flags argument in vchi_msg_hold()
staging: vchi: Use enum vchiq_bulk_mode instead of vchi's transmission
flags
staging: vchi: Use vchiq's enum vchiq_reason
staging: vchi: Get rid of effect less expression
staging: vchiq: Introduce vchiq_validate_params()
staging: vchiq: Move message queue into struct vchiq_service
staging: vchiq: Get rid of vchiq_util.h
staging: vchi: Expose struct vchi_service
staging: vchiq: Export vchiq_get_service_userdata()
staging: vchiq: Export vchiq_msg_queue_push
staging: vchi: Get rid of vchiq_shim's message callback
staging: vchiq: Don't use a typedef for vchiq_callback
staging: vchi: Use struct vchiq_service_params
staging: vchi: Get rid of struct vchi_service
staging: vchiq: Pass vchiq's message when holding a message
staging: vchi: Rework vchi_msg_hold() to match vchiq_msg_hold()
staging: vchiq: Unify fourcc definition mechanisms
staging: vchi: Get rid of struct vchiq_instance forward declaration
staging: vchi: Don't include vchiq_core.h
staging: vchiq: Get rid of unnecessary definitions in vchiq_if.h
staging: vchiq: Make vchiq_add_service() local
staging: vchiq: Move definitions only used by core into core header
staging: vchi: Get rid of vchi_bulk_queue_receive()
staging: vchi: Get rid of vchi_bulk_queue_transmit()
staging: vchi: Move vchi_queue_kernel_message() into vchiq
staging: vchiq: Get rid of vchi
staging: vchiq: Move conditional barrier definition into vchiq_core.h
staging: vchiq: Use vchiq.h as the main header file for services
staging: vchiq: Move defines into core header
staging: vchiq: Move vchiq.h into include directory
drivers/staging/vc04_services/Makefile | 4 +-
.../vc04_services/bcm2835-audio/Makefile | 2 +-
.../bcm2835-audio/bcm2835-vchiq.c | 100 ++-
.../vc04_services/bcm2835-audio/bcm2835.h | 4 +-
.../bcm2835-audio/vc_vchi_audioserv_defs.h | 5 +-
.../linux/raspberrypi/vchiq.h} | 71 +-
.../vc04_services/interface/{vchi => }/TODO | 0
.../vc04_services/interface/vchi/vchi.h | 240 ------
.../vc04_services/interface/vchi/vchi_cfg.h | 238 ------
.../interface/vchi/vchi_common.h | 138 ----
.../vc04_services/interface/vchiq_arm/vchiq.h | 21 -
.../interface/vchiq_arm/vchiq_2835_arm.c | 1 +
.../interface/vchiq_arm/vchiq_arm.c | 86 +-
.../interface/vchiq_arm/vchiq_core.c | 110 ++-
.../interface/vchiq_arm/vchiq_core.h | 53 +-
.../interface/vchiq_arm/vchiq_ioctl.h | 2 +-
.../interface/vchiq_arm/vchiq_shim.c | 751 ------------------
.../interface/vchiq_arm/vchiq_util.c | 85 --
.../interface/vchiq_arm/vchiq_util.h | 50 --
.../staging/vc04_services/vc-sm-cma/Makefile | 1 -
.../staging/vc04_services/vc-sm-cma/vc_sm.c | 10 +-
.../vc04_services/vc-sm-cma/vc_sm_cma_vchi.c | 108 ++-
.../vc04_services/vc-sm-cma/vc_sm_cma_vchi.h | 5 +-
.../vc04_services/vc-sm-cma/vc_sm_defs.h | 3 -
.../staging/vc04_services/vchiq-mmal/Makefile | 1 +
.../vc04_services/vchiq-mmal/mmal-msg.h | 1 -
.../vc04_services/vchiq-mmal/mmal-vchiq.c | 177 ++---
27 files changed, 419 insertions(+), 1848 deletions(-)
rename drivers/staging/vc04_services/{interface/vchiq_arm/vchiq_if.h => include/linux/raspberrypi/vchiq.h} (55%)
rename drivers/staging/vc04_services/interface/{vchi => }/TODO (100%)
delete mode 100644 drivers/staging/vc04_services/interface/vchi/vchi.h
delete mode 100644 drivers/staging/vc04_services/interface/vchi/vchi_cfg.h
delete mode 100644 drivers/staging/vc04_services/interface/vchi/vchi_common.h
delete mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq.h
delete mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_shim.c
delete mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.c
delete mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_util.h
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox