* [PATCH v5 01/10] dt-bindings: add powercontroller
From: Frank Wunderlich @ 2019-08-12 12:15 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Allison Randal,
David S. Miller, devicetree, Eddie Huang, Greg Kroah-Hartman,
Jonathan Cameron, Kate Stewart, Lee Jones, linux-arm-kernel,
linux-kernel, linux-mediatek, linux-pm, linux-rtc, Mark Rutland,
Matthias Brugger, Mauro Carvalho Chehab, Nicolas Ferre,
Richard Fontana, Rob Herring, Sean Wang, Sebastian Reichel,
Thomas Gleixner, Tianping . Fang
Cc: Josef Friedl, Frank Wunderlich
In-Reply-To: <20190812121511.4169-1-frank-w@public-files.de>
From: Josef Friedl <josef.friedl@speed.at>
add mt6323-rtc and mt6323-pwrc to mt6397 mfd DT bindings
an example is shown in mt6323-poweroff.txt
Suggested-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: Josef Friedl <josef.friedl@speed.at>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
---
changes since v4: use relative path
changes since v3: none
changes since v2: separated rtc-mt6397.txt to part 2
---
.../devicetree/bindings/mfd/mt6397.txt | 20 +++++++++++++------
.../bindings/power/reset/mt6323-poweroff.txt | 20 +++++++++++++++++++
2 files changed, 34 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt
index 0ebd08af777d..063f5fe1cace 100644
--- a/Documentation/devicetree/bindings/mfd/mt6397.txt
+++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
@@ -8,11 +8,12 @@ MT6397/MT6323 is a multifunction device with the following sub modules:
- Clock
- LED
- Keys
+- Power controller
It is interfaced to host controller using SPI interface by a proprietary hardware
called PMIC wrapper or pwrap. MT6397/MT6323 MFD is a child device of pwrap.
See the following for pwarp node definitions:
-Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
+../../bindings/soc/mediatek/pwrap.txt
This document describes the binding for MFD device and its sub module.
@@ -22,14 +23,16 @@ compatible: "mediatek,mt6397" or "mediatek,mt6323"
Optional subnodes:
- rtc
- Required properties:
+ Required properties: Should be one of follows
+ - compatible: "mediatek,mt6323-rtc"
- compatible: "mediatek,mt6397-rtc"
+ For details, see ../../bindings/rtc/rtc-mt6397.txt
- regulators
Required properties:
- compatible: "mediatek,mt6397-regulator"
- see Documentation/devicetree/bindings/regulator/mt6397-regulator.txt
+ see ../../bindings/regulator/mt6397-regulator.txt
- compatible: "mediatek,mt6323-regulator"
- see Documentation/devicetree/bindings/regulator/mt6323-regulator.txt
+ see ../../bindings/regulator/mt6323-regulator.txt
- codec
Required properties:
- compatible: "mediatek,mt6397-codec"
@@ -39,12 +42,17 @@ Optional subnodes:
- led
Required properties:
- compatible: "mediatek,mt6323-led"
- see Documentation/devicetree/bindings/leds/leds-mt6323.txt
+ see ../../bindings/leds/leds-mt6323.txt
- keys
Required properties:
- compatible: "mediatek,mt6397-keys" or "mediatek,mt6323-keys"
- see Documentation/devicetree/bindings/input/mtk-pmic-keys.txt
+ see ../../bindings/input/mtk-pmic-keys.txt
+
+- power-controller
+ Required properties:
+ - compatible: "mediatek,mt6323-pwrc"
+ For details, see ../../bindings/power/reset/mt6323-poweroff.txt
Example:
pwrap: pwrap@1000f000 {
diff --git a/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt b/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
new file mode 100644
index 000000000000..933f0c48e887
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
@@ -0,0 +1,20 @@
+Device Tree Bindings for Power Controller on MediaTek PMIC
+
+The power controller which could be found on PMIC is responsible for externally
+powering off or on the remote MediaTek SoC through the circuit BBPU.
+
+Required properties:
+- compatible: Should be one of follows
+ "mediatek,mt6323-pwrc": for MT6323 PMIC
+
+Example:
+
+ pmic {
+ compatible = "mediatek,mt6323";
+
+ ...
+
+ power-controller {
+ compatible = "mediatek,mt6323-pwrc";
+ };
+ }
--
2.17.1
_______________________________________________
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 v5 00/10] implement poweroff for mt6323 / bpi-r2
From: Frank Wunderlich @ 2019-08-12 12:15 UTC (permalink / raw)
To: Alessandro Zummo, Alexandre Belloni, Allison Randal,
David S. Miller, devicetree, Eddie Huang, Greg Kroah-Hartman,
Jonathan Cameron, Kate Stewart, Lee Jones, linux-arm-kernel,
linux-kernel, linux-mediatek, linux-pm, linux-rtc, Mark Rutland,
Matthias Brugger, Mauro Carvalho Chehab, Nicolas Ferre,
Richard Fontana, Rob Herring, Sean Wang, Sebastian Reichel,
Thomas Gleixner, Tianping . Fang
Cc: Frank Wunderlich
mainline-driver does not support mt6323
this series makes some cleanup to mt6397-rtc-driver, adds mt6323 and
implement power-controller on it.
tested on bananapi-r2
Original Patch from Josef Friedl
changes since v4:
- relative path in part 1+2
- drop change of copyright-year in part 5
changes since v3:
- moved SOB in 2/10 and 9/10
- moved part 5 to 6 to be near driver-change
- changehistory of patches below ---
changes since v2:
- Splitted some parts and rebased on 5.3-rc2:
v2.1 dt-bindings: add powercontroller – try to make better subject
v2.2 separate rtc-mt6397.txt (suggested by Alexandre Belloni)
add missing commit-message (suggested by Matthias Brugger)
v2.3 fix alloc after IRQ (suggested by Alexandre Belloni)
new compatible (splitting suggested by Alexandre Belloni)
needed due to different rtc-base/size see #7
v2.4 simplifications (Define-res-macros)
add mt6323 rtc+pwrc
v2.5 add poweroff-driver (no change)
v2.6 MAINTAINERS (no change)
v2.7 DTS-Changes (no change)
Josef Friedl (10):
dt-bindings: add powercontroller
dt-bindings: add missing mt6397 rtc
rtc: mt6397: move some common definitions into rtc.h
rtc: mt6397: improvements of rtc driver
mfd: mt6323: some improvements of mt6397-core
rtc: mt6397: add compatible for mt6323
mfd: mt6323: add mt6323 rtc+pwrc
power: reset: add driver for mt6323 poweroff
MAINTAINERS: add Mediatek shutdown drivers
arm: dts: mt6323: add keys, power-controller, rtc and codec
.../devicetree/bindings/mfd/mt6397.txt | 20 +++-
.../bindings/power/reset/mt6323-poweroff.txt | 20 ++++
.../devicetree/bindings/rtc/rtc-mt6397.txt | 29 +++++
MAINTAINERS | 7 ++
arch/arm/boot/dts/mt6323.dtsi | 27 +++++
drivers/mfd/mt6397-core.c | 38 +++++--
drivers/power/reset/Kconfig | 10 ++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/mt6323-poweroff.c | 97 ++++++++++++++++
drivers/rtc/rtc-mt6397.c | 107 ++++--------------
include/linux/mfd/mt6397/core.h | 2 +
include/linux/mfd/mt6397/rtc.h | 71 ++++++++++++
12 files changed, 327 insertions(+), 102 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/reset/mt6323-poweroff.txt
create mode 100644 Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
create mode 100644 drivers/power/reset/mt6323-poweroff.c
create mode 100644 include/linux/mfd/mt6397/rtc.h
--
2.17.1
_______________________________________________
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 0/7] media: cedrus: Improvements/cleanup
From: Hans Verkuil @ 2019-08-12 12:12 UTC (permalink / raw)
To: Jernej Skrabec, paul.kocialkowski, maxime.ripard
Cc: devel, gregkh, linux-kernel, wens, mchehab, linux-arm-kernel,
linux-media
In-Reply-To: <20190530211516.1891-1-jernej.skrabec@siol.net>
On 5/30/19 11:15 PM, Jernej Skrabec wrote:
> Here is first batch of random Cedrus improvements/cleanups. Only patch 2
> has a change which raises a question about H264 controls.
>
> Changes were tested on H3 SoC using modified ffmpeg and Kodi.
>
> Please take a look.
This has been sitting in patchwork for quite some time. I've updated the
status of the various patches and most needed extra work.
It seems that patches 4/7 and 5/7 are OK. Maxime, can you please confirm
that these two are still valid? They apply cleanly on the latest master
at least, but since they are a bit old I prefer to have confirmation that
it's OK to merge them.
Regards,
Hans
>
> Best regards,
> Jernej
>
> Jernej Skrabec (7):
> media: cedrus: Disable engine after each slice decoding
> media: cedrus: Fix H264 default reference index count
> media: cedrus: Fix decoding for some H264 videos
> media: cedrus: Remove dst_bufs from context
> media: cedrus: Don't set chroma size for scale & rotation
> media: cedrus: Add infra for extra buffers connected to capture
> buffers
> media: cedrus: Improve H264 memory efficiency
>
> drivers/staging/media/sunxi/cedrus/cedrus.h | 12 +-
> .../staging/media/sunxi/cedrus/cedrus_h264.c | 115 ++++++++----------
> .../staging/media/sunxi/cedrus/cedrus_hw.c | 4 +-
> .../staging/media/sunxi/cedrus/cedrus_video.c | 25 ++--
> 4 files changed, 68 insertions(+), 88 deletions(-)
>
_______________________________________________
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 0/7] Allwinner H6 SPDIF support
From: Clément Péron @ 2019-08-12 12:10 UTC (permalink / raw)
To: Mark Brown
Cc: Mark Rutland, devicetree, Linux-ALSA, Maxime Ripard, linux-kernel,
linux-sunxi, Takashi Iwai, Liam Girdwood, Chen-Yu Tsai,
Rob Herring, Jagan Teki, Jaroslav Kysela, linux-arm-kernel
In-Reply-To: <20190812110103.GD4592@sirena.co.uk>
Hi Mark,
On Mon, 12 Aug 2019 at 13:01, Mark Brown <broonie@kernel.org> wrote:
>
> On Sat, Aug 10, 2019 at 10:45:23AM +0200, Clément Péron wrote:
>
> > Hi,
>
> Please don't top post, reply in line with needed context. This allows
> readers to readily follow the flow of conversation and understand what
> you are talking about and also helps ensure that everything in the
> discussion is being addressed.
>
> > Sorry, I just discovered that the ASoC patches have been merged into
> > the broonie and linus tree in 5.3.
>
> > I'm still quite new in the sending of patches to the Kernel but
> > souldn't be a ack or a mail sent to warn the sender when the series
> > are accepted?
>
> Not every maintainer will send those, I do but you might find they've
> gone into your spam folder if you're using gmail.
Thank you very much for the answer,
Regards,
Clément
_______________________________________________
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 2/2] drivers/perf: Add CCPI2 PMU support in ThunderX2 UNCORE driver.
From: Mark Rutland @ 2019-08-12 12:01 UTC (permalink / raw)
To: Ganapatrao Kulkarni
Cc: corbet@lwn.net, Jan Glauber, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Robert Richter, gklkml16@gmail.com,
Jayachandran Chandrasekharan Nair, will@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1563873380-2003-3-git-send-email-gkulkarni@marvell.com>
On Tue, Jul 23, 2019 at 09:16:28AM +0000, Ganapatrao Kulkarni wrote:
> CCPI2 is a low-latency high-bandwidth serial interface for connecting
> ThunderX2 processors. This patch adds support to capture CCPI2 perf events.
It would be worth pointing out in the commit message how the CCPI2
counters differ from the others. I realise you have that in the body of
patch 1, but it's critical information when reviewing this patch...
>
> Signed-off-by: Ganapatrao Kulkarni <gkulkarni@marvell.com>
> ---
> drivers/perf/thunderx2_pmu.c | 248 ++++++++++++++++++++++++++++++-----
> 1 file changed, 214 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c
> index 43d76c85da56..a4e1273eafa3 100644
> --- a/drivers/perf/thunderx2_pmu.c
> +++ b/drivers/perf/thunderx2_pmu.c
> @@ -17,22 +17,31 @@
> */
>
> #define TX2_PMU_MAX_COUNTERS 4
Shouldn't this be 8 now?
[...]
> /*
> - * pmu on each socket has 2 uncore devices(dmc and l3c),
> - * each device has 4 counters.
> + * pmu on each socket has 3 uncore devices(dmc, l3ci and ccpi2),
> + * dmc and l3c has 4 counters and ccpi2 8.
> */
How about:
/*
* Each socket has 3 uncore device associated with a PMU. The DMC and
* L3C have 4 32-bit counters, and the CCPI2 has 8 64-bit counters.
*/
> struct tx2_uncore_pmu {
> struct hlist_node hpnode;
> @@ -69,12 +86,14 @@ struct tx2_uncore_pmu {
> int node;
> int cpu;
> u32 max_counters;
> + u32 counters_mask;
> u32 prorate_factor;
> u32 max_events;
> + u32 events_mask;
> u64 hrtimer_interval;
> void __iomem *base;
> DECLARE_BITMAP(active_counters, TX2_PMU_MAX_COUNTERS);
This bitmap isn't big enough for the 4 new counters.
> - struct perf_event *events[TX2_PMU_MAX_COUNTERS];
> + struct perf_event **events;
As above, can't we bump TX2_PMU_MAX_COUNTERS to 8 rather than making
this a dynamic allocation?
[...]
> static inline u32 reg_readl(unsigned long addr)
> {
> return readl((void __iomem *)addr);
> }
>
> +static inline u32 reg_readq(unsigned long addr)
> +{
> + return readq((void __iomem *)addr);
> +}
Presumably reg_readq() should return a u64.
[...]
> +static void uncore_start_event_ccpi2(struct perf_event *event, int flags)
> +{
> + u32 emask;
> + struct hw_perf_event *hwc = &event->hw;
> + struct tx2_uncore_pmu *tx2_pmu;
> +
> + tx2_pmu = pmu_to_tx2_pmu(event->pmu);
> + emask = tx2_pmu->events_mask;
> +
> + /* Bit [09:00] to set event id, set level and type to 1 */
> + reg_writel((3 << 10) |
Do you mean that bits [11:10] are level and type?
What exactly are 'level' and 'type'?
Can we give those bits mnemonics?
> + GET_EVENTID(event, emask), hwc->config_base);
> + /* reset[4], enable[0] and start[1] counters */
Rather than using magic numbers everywhere, please give these mnemonics,
e.g.
#define CCPI2_PERF_CTL_ENABLE BIT(0)
#define CCPI2_PERF_CTL_START BIT(1)
#define CCPI2_PERF_CTL_RESET BIT(4)
> + reg_writel(0x13, hwc->event_base + CCPI2_PERF_CTL);
... and then you can OR them in here:
ctl = CCPI2_PERF_CTL_ENABLE |
CCPI2_PERF_CTL_START |
CCPI2_PERF_CTL_RESET;
reg_writel(ctl, hwc->event_base + CCPI2_PERF_CTL);
[...]
> @@ -456,8 +603,9 @@ static void tx2_uncore_event_start(struct perf_event *event, int flags)
> tx2_pmu->start_event(event, flags);
> perf_event_update_userpage(event);
>
> - /* Start timer for first event */
> - if (bitmap_weight(tx2_pmu->active_counters,
> + /* Start timer for first non ccpi2 event */
> + if (tx2_pmu->type != PMU_TYPE_CCPI2 &&
> + bitmap_weight(tx2_pmu->active_counters,
> tx2_pmu->max_counters) == 1) {
> hrtimer_start(&tx2_pmu->hrtimer,
> ns_to_ktime(tx2_pmu->hrtimer_interval),
This would be easier to read as two statements:
/* No hrtimer needed with 64-bit counters */
if (tx2_pmu->type == PMU_TYPE_CCPI2)
return;
/* Start timer for first event */
if (bitmap_weight(tx2_pmu->active_counters,
tx2_pmu->max_counters) != 1) {
...
}
> @@ -495,7 +643,8 @@ static int tx2_uncore_event_add(struct perf_event *event, int flags)
> if (hwc->idx < 0)
> return -EAGAIN;
>
> - tx2_pmu->events[hwc->idx] = event;
> + if (tx2_pmu->events)
> + tx2_pmu->events[hwc->idx] = event;
So this is NULL for CCPI2?
I guess we don't strictly need the if we don't have a hrtimer to update
event counts, but this makes the code more complicated than it needs to
be.
[...]
> @@ -580,8 +732,12 @@ static int tx2_uncore_pmu_add_dev(struct tx2_uncore_pmu *tx2_pmu)
> cpu_online_mask);
>
> tx2_pmu->cpu = cpu;
> - hrtimer_init(&tx2_pmu->hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> - tx2_pmu->hrtimer.function = tx2_hrtimer_callback;
> + /* CCPI2 counters are 64 bit counters, no overflow */
> + if (tx2_pmu->type != PMU_TYPE_CCPI2) {
> + hrtimer_init(&tx2_pmu->hrtimer,
> + CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + tx2_pmu->hrtimer.function = tx2_hrtimer_callback;
> + }
Hmmm... this means that tx2_pmu->hrtimer.function is NULL for the CCPI2
PMU. I think it would be best to check that when (re)programming the
counters rather than the PMU type. For example, in
tx2_uncore_event_start() we could have:
if (!tx2_pmu->hrtimer.function)
return;
if (bitmap_weight(tx2_pmu->active_counters,
tx2_pmu->max_counters) != 1) {
...
}
Thanks,
Mark.
_______________________________________________
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 1/2] ACPI/PPTT: Add support for ACPI 6.3 thread flag
From: Will Deacon @ 2019-08-12 11:59 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: lorenzo.pieralisi@arm.com, rric@kernel.org,
catalin.marinas@arm.com, rjw@rjwysocki.net, Jeremy Linton,
linux-acpi@vger.kernel.org, Robert Richter, sudeep.holla@arm.com,
linux-arm-kernel@lists.infradead.org, lenb@kernel.org
In-Reply-To: <CAJZ5v0imn0X=M38LJcwe76gfLafWGU+MgyGd=NuKAeDtNZ+1DQ@mail.gmail.com>
On Mon, Aug 12, 2019 at 11:06:07AM +0200, Rafael J. Wysocki wrote:
> On Fri, Aug 9, 2019 at 12:25 AM Robert Richter <rrichter@marvell.com> wrote:
> >
> > On 08.08.19 15:40:06, Jeremy Linton wrote:
> > > ACPI 6.3 adds a flag to the CPU node to indicate whether
> > > the given PE is a thread. Add a function to return that
> > > information for a given linux logical CPU.
> > >
> > > Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> > > Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
> > > ---
> > > drivers/acpi/pptt.c | 53 +++++++++++++++++++++++++++++++++++++++++++-
> > > include/linux/acpi.h | 5 +++++
> > > 2 files changed, 57 insertions(+), 1 deletion(-)
> >
> > Reviewed-by: Robert Richter <rrichter@marvell.com>
>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> and please push it through ARM64 along with the second patch.
Thanks. I'll push these into -next shortly.
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 3/6] usb: add a HCD_DMA flag instead of guestimating DMA capabilities
From: Christoph Hellwig @ 2019-08-12 11:57 UTC (permalink / raw)
To: Greg Kroah-Hartman, Maxime Chevallier
Cc: linux-arch, Gavin Li, Pengutronix Kernel Team, Mathias Nyman,
Geoff Levand, Olav Kongas, Sascha Hauer, linux-usb, Michal Simek,
linux-kernel, Tony Prisk, iommu, Alan Stern, NXP Linux Team,
Fabio Estevam, Minas Harutyunyan, Shawn Guo, linuxppc-dev,
Bin Liu, linux-arm-kernel, Laurentiu Tudor
In-Reply-To: <20190811080520.21712-4-hch@lst.de>
> diff --git a/drivers/usb/host/ehci-ppc-of.c b/drivers/usb/host/ehci-ppc-of.c
> index 576f7d79ad4e..9d17e0695e35 100644
> --- a/drivers/usb/host/ehci-ppc-of.c
> +++ b/drivers/usb/host/ehci-ppc-of.c
> @@ -31,7 +31,7 @@ static const struct hc_driver ehci_ppc_of_hc_driver = {
> * generic hardware linkage
> */
> .irq = ehci_irq,
> - .flags = HCD_MEMORY | HCD_USB2 | HCD_BH,
> + .flags = HCD_MEMORY | HC_DMA | HCD_USB2 | HCD_BH,
FYI, the kbuild bot found a little typo here, so even for the unlikely
case that the series is otherwise perfect I'll have to resend it at
least once.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Re: Re: [PATCH v3 01/10] dt-bindings: add powercontroller
From: Lee Jones @ 2019-08-12 11:51 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Kate Stewart, Mark Rutland, Alexandre Belloni, linux-kernel,
Richard Fontana, Mauro Carvalho Chehab, linux-rtc, Allison Randal,
devicetree, linux-pm, Sean Wang, Tianping . Fang, Rob Herring,
linux-mediatek, Jonathan Cameron, Matthias Brugger,
Thomas Gleixner, Eddie Huang, linux-arm-kernel, Alessandro Zummo,
Josef Friedl, Greg Kroah-Hartman, Sebastian Reichel,
David S. Miller
In-Reply-To: <trinity-738d59ed-ecac-4025-a729-0888eaea1f95-1565609875829@3c-app-gmx-bs80>
On Mon, 12 Aug 2019, Frank Wunderlich wrote:
> > Gesendet: Montag, 12. August 2019 um 13:25 Uhr
> > Von: "Lee Jones" <lee.jones@linaro.org>
> > It was an example (hence the "E.g.").
> >
> > You will need to adapt it depending on where the file ends up.
>
> i saw the e.g., but i wanted to know relative to which directory ;) your example mentions that it should contain the dt-bindings-folder and i think it should be relative to current file...
>
> have applied your suggestions to my tree
>
> https://github.com/frank-w/BPI-R2-4.14/commits/5.3-poweroff
>
> please take a short look if i don't miss anything
Just resubmit them. Doing off-list reviews is a slippery slope.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Aw: Re: Re: [PATCH v3 01/10] dt-bindings: add powercontroller
From: Frank Wunderlich @ 2019-08-12 11:37 UTC (permalink / raw)
To: Lee Jones
Cc: Kate Stewart, Mark Rutland, Alexandre Belloni, linux-kernel,
Richard Fontana, Mauro Carvalho Chehab, linux-rtc, Allison Randal,
devicetree, linux-pm, Sean Wang, Tianping . Fang, Rob Herring,
linux-mediatek, Jonathan Cameron, Matthias Brugger,
Thomas Gleixner, Eddie Huang, linux-arm-kernel, Alessandro Zummo,
Josef Friedl, Greg Kroah-Hartman, Sebastian Reichel,
David S. Miller
In-Reply-To: <20190812112507.GR26727@dell>
> Gesendet: Montag, 12. August 2019 um 13:25 Uhr
> Von: "Lee Jones" <lee.jones@linaro.org>
> It was an example (hence the "E.g.").
>
> You will need to adapt it depending on where the file ends up.
i saw the e.g., but i wanted to know relative to which directory ;) your example mentions that it should contain the dt-bindings-folder and i think it should be relative to current file...
have applied your suggestions to my tree
https://github.com/frank-w/BPI-R2-4.14/commits/5.3-poweroff
please take a short look if i don't miss anything
regards Frank
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit property in EP driver.
From: Lorenzo Pieralisi @ 2019-08-12 11:35 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland@arm.com, Roy Zang, arnd@arndb.de,
devicetree@vger.kernel.org, gregkh@linuxfoundation.org,
kstewart@linuxfoundation.org, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Leo Li,
M.h. Lian, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, pombredanne@nexb.com,
bhelgaas@google.com, kishon@ti.com, shawnguo@kernel.org,
shawn.lin@rock-chips.com, Mingkai Hu
In-Reply-To: <AM5PR04MB329929A0B046F6BEB94B0120F5D30@AM5PR04MB3299.eurprd04.prod.outlook.com>
On Mon, Aug 12, 2019 at 10:39:00AM +0000, Xiaowei Bao wrote:
>
>
> > -----Original Message-----
> > From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Sent: 2019年8月12日 18:12
> > To: Xiaowei Bao <xiaowei.bao@nxp.com>; kishon@ti.com
> > Cc: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> > shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; arnd@arndb.de;
> > gregkh@linuxfoundation.org; M.h. Lian <minghuan.lian@nxp.com>; Mingkai
> > Hu <mingkai.hu@nxp.com>; Roy Zang <roy.zang@nxp.com>;
> > kstewart@linuxfoundation.org; pombredanne@nexb.com;
> > shawn.lin@rock-chips.com; linux-pci@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> > Subject: [EXT] Re: [PATCHv3 1/2] PCI: layerscape: Add the bar_fixed_64bit
> > property in EP driver.
> >
> > Caution: EXT Email
> >
> > First off:
> >
> > Trim the CC list, you CC'ed maintainers (and mailing lists) for no reasons
> > whatsover.
> [Xiaowei Bao]Hi Lorenzo, I am not clear why the mail list is the CC, I use the command "git send-email --to", I will try to send the patch again, do I need to modify the version is v4 when I send this patch again?
Yes you do.
Wrap lines to max 80 characters. There is no need to add [Xiaowei Bao].
1) Read, email etiquette
https://kernelnewbies.org/PatchCulture
2) get_maintainer.pl -f drivers/pci/controller/dwc/pci-layerscape.c
Compare the output to the people in CC, trim it accordingly.
3) The NXP maintainers in the MAINTAINERS file have not given a single
comment for this patchset. Either they show up or I will remove them
from the MAINTAINERS list.
4) Before submitting patches, talk to someone at NXP who can help you
format them in preparation for posting, I do not have time to write
guidelines for everyone posting on linux-pci, sorry, the information
is out there if you care to read it.
Thanks,
Lorenzo
> >
> > Then, read this:
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> > rnel.org%2Flinux-pci%2F20171026223701.GA25649%40bhelgaas-glaptop.roa
> > m.corp.google.com%2F&data=02%7C01%7Cxiaowei.bao%40nxp.com%7
> > C1c586178e23c423a0e8808d71f0d8f6f%7C686ea1d3bc2b4c6fa92cd99c5c30
> > 1635%7C0%7C0%7C637012015426788575&sdata=3bx1bDFIzik8FnD0wl
> > duAUv7wtLdD1J3hQ3xNH2xmFY%3D&reserved=0
> >
> > and make your patches compliant please.
> >
> > On Fri, Jun 28, 2019 at 09:38:25AM +0800, Xiaowei Bao wrote:
> > > The PCIe controller of layerscape just have 4 BARs, BAR0 and BAR1 is
> > > 32bit, BAR3 and BAR4 is 64bit, this is determined by hardware, so set
> > > the bar_fixed_64bit with 0x14.
> > >
> > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > ---
> > > v2:
> > > - Replace value 0x14 with a macro.
> > > v3:
> > > - No change.
> > >
> > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 1 +
> > > 1 files changed, 1 insertions(+), 0 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > index be61d96..227c33b 100644
> > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > @@ -44,6 +44,7 @@ static int ls_pcie_establish_link(struct dw_pcie *pci)
> > > .linkup_notifier = false,
> > > .msi_capable = true,
> > > .msix_capable = false,
> > > + .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> >
> > I would appreciate Kishon's ACK on this.
> >
> > Lorenzo
> >
> > > };
> > >
> > > static const struct pci_epc_features*
> > > --
> > > 1.7.1
> > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] gpio: pl061: Fix the issue failed to register the ACPI interruption
From: Wei Xu @ 2019-08-12 11:28 UTC (permalink / raw)
To: linux-gpio, linux-kernel, linux-arm-kernel@lists.infradead.org,
linus.walleij
Cc: Salil Mehta, jinying, Tangkunshan, huangdaode, John Garry,
Linuxarm, xuwei5, Shameerali Kolothum Thodi, Jonathan Cameron,
Liguozhu (Kenneth), Zhangyi ac, Shiju Jose
Invoke acpi_gpiochip_request_interrupts after the acpi data has been
attached to the pl061 acpi node to register interruption.
Otherwise it will be failed to register interruption for the ACPI case.
Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked
after gpiochip_add_irqchip but at that time the acpi data has not been
attached yet.
Tested with below steps on QEMU v4.1.0-rc3 and Linux kernel v5.3-rc4,
and found pl061 interruption is missed in the /proc/interrupts:
1.
qemu-system-aarch64 \
-machine virt,gic-version=3 -cpu cortex-a57 \
-m 1G,maxmem=4G,slots=4 \
-kernel Image -initrd rootfs.cpio.gz \
-net none -nographic \
-bios QEMU_EFI.fd \
-append "console=ttyAMA0 acpi=force earlycon=pl011,0x9000000"
2. cat /proc/interrupts in the guest console:
estuary:/$ cat /proc/interrupts
CPU0
2: 3228 GICv3 27 Level arch_timer
4: 15 GICv3 33 Level uart-pl011
42: 0 GICv3 23 Level arm-pmu
IPI0: 0 Rescheduling interrupts
IPI1: 0 Function call interrupts
IPI2: 0 CPU stop interrupts
IPI3: 0 CPU stop (for crash dump) interrupts
IPI4: 0 Timer broadcast interrupts
IPI5: 0 IRQ work interrupts
IPI6: 0 CPU wake-up interrupts
Err: 0
Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
---
drivers/gpio/gpio-pl061.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 722ce5c..e1a434e 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -8,6 +8,7 @@
*
* Data sheet: ARM DDI 0190B, September 2000
*/
+#include <linux/acpi.h>
#include <linux/spinlock.h>
#include <linux/errno.h>
#include <linux/init.h>
@@ -24,6 +25,9 @@
#include <linux/pinctrl/consumer.h>
#include <linux/pm.h>
+#include "gpiolib.h"
+#include "gpiolib-acpi.h"
+
#define GPIODIR 0x400
#define GPIOIS 0x404
#define GPIOIBE 0x408
@@ -345,6 +349,9 @@ static int pl061_probe(struct amba_device *adev,
const struct amba_id *id)
if (ret)
return ret;
+ if (has_acpi_companion(dev))
+ acpi_gpiochip_request_interrupts(&pl061->gc);
+
amba_set_drvdata(adev, pl061);
dev_info(dev, "PL061 GPIO chip registered\n");
--
2.8.1
.
_______________________________________________
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: Re: [PATCH v3 06/10] mfd: mt6323: some improvements of mt6397-core
From: Lee Jones @ 2019-08-12 11:27 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Kate Stewart, Mark Rutland, Alexandre Belloni, Richard Fontana,
Mauro Carvalho Chehab, linux-rtc, Allison Randal, devicetree,
linux-pm, Sean Wang, Tianping . Fang, Rob Herring, linux-mediatek,
Jonathan Cameron, Matthias Brugger, Thomas Gleixner, Eddie Huang,
linux-arm-kernel, Alessandro Zummo, Josef Friedl,
Greg Kroah-Hartman, linux-kernel, Sebastian Reichel,
David S. Miller
In-Reply-To: <trinity-0fa641df-f7bb-4627-a9ab-aac3cabc90ba-1565609115974@3c-app-gmx-bs80>
On Mon, 12 Aug 2019, Frank Wunderlich wrote:
> > Gesendet: Montag, 12. August 2019 um 12:22 Uhr
> > Von: "Lee Jones" <lee.jones@linaro.org>
>
> > > - * Copyright (c) 2014 MediaTek Inc.
> > > + * Copyright (c) 2014-2018 MediaTek Inc.
> >
> > This is out of date. Please update it.
>
> maybe i should drop change of this line completely (else it needs to be adjusted every year)
It only needs changing when the Copyright is changed.
If you want to update it to 2014-2019, that's fine.
Or leaving it untouched, is also fine.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 1/3] media: stm32-dcmi: improve sensor subdev naming
From: Hugues Fruchet @ 2019-08-12 11:26 UTC (permalink / raw)
To: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, Hugues Fruchet, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <1565609206-27101-1-git-send-email-hugues.fruchet@st.com>
Rename "subdev" entity struct field to "source"
to prepare for several subdev support.
Move asd field on top of entity struct.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
drivers/media/platform/stm32/stm32-dcmi.c | 46 +++++++++++++++----------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index b9dad0a..b462f71 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -100,10 +100,10 @@ enum state {
#define OVERRUN_ERROR_THRESHOLD 3
struct dcmi_graph_entity {
- struct device_node *node;
-
struct v4l2_async_subdev asd;
- struct v4l2_subdev *subdev;
+
+ struct device_node *remote_node;
+ struct v4l2_subdev *source;
};
struct dcmi_format {
@@ -595,7 +595,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
}
/* Enable stream on the sub device */
- ret = v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 1);
+ ret = v4l2_subdev_call(dcmi->entity.source, video, s_stream, 1);
if (ret && ret != -ENOIOCTLCMD) {
dev_err(dcmi->dev, "%s: Failed to start streaming, subdev streamon error",
__func__);
@@ -685,7 +685,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
return 0;
err_subdev_streamoff:
- v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 0);
+ v4l2_subdev_call(dcmi->entity.source, video, s_stream, 0);
err_pm_put:
pm_runtime_put(dcmi->dev);
@@ -713,7 +713,7 @@ static void dcmi_stop_streaming(struct vb2_queue *vq)
int ret;
/* Disable stream on the sub device */
- ret = v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 0);
+ ret = v4l2_subdev_call(dcmi->entity.source, video, s_stream, 0);
if (ret && ret != -ENOIOCTLCMD)
dev_err(dcmi->dev, "%s: Failed to stop streaming, subdev streamoff error (%d)\n",
__func__, ret);
@@ -857,7 +857,7 @@ static int dcmi_try_fmt(struct stm32_dcmi *dcmi, struct v4l2_format *f,
}
v4l2_fill_mbus_format(&format.format, pix, sd_fmt->mbus_code);
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, set_fmt,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, set_fmt,
&pad_cfg, &format);
if (ret < 0)
return ret;
@@ -934,7 +934,7 @@ static int dcmi_set_fmt(struct stm32_dcmi *dcmi, struct v4l2_format *f)
mf->width = sd_framesize.width;
mf->height = sd_framesize.height;
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad,
set_fmt, NULL, &format);
if (ret < 0)
return ret;
@@ -991,7 +991,7 @@ static int dcmi_get_sensor_format(struct stm32_dcmi *dcmi,
};
int ret;
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, get_fmt, NULL, &fmt);
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, get_fmt, NULL, &fmt);
if (ret)
return ret;
@@ -1020,7 +1020,7 @@ static int dcmi_set_sensor_format(struct stm32_dcmi *dcmi,
}
v4l2_fill_mbus_format(&format.format, pix, sd_fmt->mbus_code);
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, set_fmt,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, set_fmt,
&pad_cfg, &format);
if (ret < 0)
return ret;
@@ -1043,7 +1043,7 @@ static int dcmi_get_sensor_bounds(struct stm32_dcmi *dcmi,
/*
* Get sensor bounds first
*/
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, get_selection,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, get_selection,
NULL, &bounds);
if (!ret)
*r = bounds.r;
@@ -1224,7 +1224,7 @@ static int dcmi_enum_framesizes(struct file *file, void *fh,
fse.code = sd_fmt->mbus_code;
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad, enum_frame_size,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad, enum_frame_size,
NULL, &fse);
if (ret)
return ret;
@@ -1241,7 +1241,7 @@ static int dcmi_g_parm(struct file *file, void *priv,
{
struct stm32_dcmi *dcmi = video_drvdata(file);
- return v4l2_g_parm_cap(video_devdata(file), dcmi->entity.subdev, p);
+ return v4l2_g_parm_cap(video_devdata(file), dcmi->entity.source, p);
}
static int dcmi_s_parm(struct file *file, void *priv,
@@ -1249,7 +1249,7 @@ static int dcmi_s_parm(struct file *file, void *priv,
{
struct stm32_dcmi *dcmi = video_drvdata(file);
- return v4l2_s_parm_cap(video_devdata(file), dcmi->entity.subdev, p);
+ return v4l2_s_parm_cap(video_devdata(file), dcmi->entity.source, p);
}
static int dcmi_enum_frameintervals(struct file *file, void *fh,
@@ -1271,7 +1271,7 @@ static int dcmi_enum_frameintervals(struct file *file, void *fh,
fie.code = sd_fmt->mbus_code;
- ret = v4l2_subdev_call(dcmi->entity.subdev, pad,
+ ret = v4l2_subdev_call(dcmi->entity.source, pad,
enum_frame_interval, NULL, &fie);
if (ret)
return ret;
@@ -1291,7 +1291,7 @@ MODULE_DEVICE_TABLE(of, stm32_dcmi_of_match);
static int dcmi_open(struct file *file)
{
struct stm32_dcmi *dcmi = video_drvdata(file);
- struct v4l2_subdev *sd = dcmi->entity.subdev;
+ struct v4l2_subdev *sd = dcmi->entity.source;
int ret;
if (mutex_lock_interruptible(&dcmi->lock))
@@ -1322,7 +1322,7 @@ static int dcmi_open(struct file *file)
static int dcmi_release(struct file *file)
{
struct stm32_dcmi *dcmi = video_drvdata(file);
- struct v4l2_subdev *sd = dcmi->entity.subdev;
+ struct v4l2_subdev *sd = dcmi->entity.source;
bool fh_singular;
int ret;
@@ -1433,7 +1433,7 @@ static int dcmi_formats_init(struct stm32_dcmi *dcmi)
{
const struct dcmi_format *sd_fmts[ARRAY_SIZE(dcmi_formats)];
unsigned int num_fmts = 0, i, j;
- struct v4l2_subdev *subdev = dcmi->entity.subdev;
+ struct v4l2_subdev *subdev = dcmi->entity.source;
struct v4l2_subdev_mbus_code_enum mbus_code = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
@@ -1479,7 +1479,7 @@ static int dcmi_formats_init(struct stm32_dcmi *dcmi)
static int dcmi_framesizes_init(struct stm32_dcmi *dcmi)
{
unsigned int num_fsize = 0;
- struct v4l2_subdev *subdev = dcmi->entity.subdev;
+ struct v4l2_subdev *subdev = dcmi->entity.source;
struct v4l2_subdev_frame_size_enum fse = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
.code = dcmi->sd_format->mbus_code,
@@ -1526,7 +1526,7 @@ static int dcmi_graph_notify_complete(struct v4l2_async_notifier *notifier)
struct stm32_dcmi *dcmi = notifier_to_dcmi(notifier);
int ret;
- dcmi->vdev->ctrl_handler = dcmi->entity.subdev->ctrl_handler;
+ dcmi->vdev->ctrl_handler = dcmi->entity.source->ctrl_handler;
ret = dcmi_formats_init(dcmi);
if (ret) {
dev_err(dcmi->dev, "No supported mediabus format found\n");
@@ -1582,7 +1582,7 @@ static int dcmi_graph_notify_bound(struct v4l2_async_notifier *notifier,
dev_dbg(dcmi->dev, "Subdev %s bound\n", subdev->name);
- dcmi->entity.subdev = subdev;
+ dcmi->entity.source = subdev;
return 0;
}
@@ -1608,7 +1608,7 @@ static int dcmi_graph_parse(struct stm32_dcmi *dcmi, struct device_node *node)
return -EINVAL;
/* Remote node to connect */
- dcmi->entity.node = remote;
+ dcmi->entity.remote_node = remote;
dcmi->entity.asd.match_type = V4L2_ASYNC_MATCH_FWNODE;
dcmi->entity.asd.match.fwnode = of_fwnode_handle(remote);
return 0;
@@ -1631,7 +1631,7 @@ static int dcmi_graph_init(struct stm32_dcmi *dcmi)
&dcmi->entity.asd);
if (ret) {
dev_err(dcmi->dev, "Failed to add subdev notifier\n");
- of_node_put(dcmi->entity.node);
+ of_node_put(dcmi->entity.remote_node);
return ret;
}
--
2.7.4
_______________________________________________
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 v5 2/3] media: stm32-dcmi: add media controller support
From: Hugues Fruchet @ 2019-08-12 11:26 UTC (permalink / raw)
To: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, Hugues Fruchet, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <1565609206-27101-1-git-send-email-hugues.fruchet@st.com>
Add media controller support to dcmi in order
to walk within remote subdevices pipeline.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
drivers/media/platform/Kconfig | 2 +-
drivers/media/platform/stm32/stm32-dcmi.c | 52 ++++++++++++++++++++++++-------
2 files changed, 41 insertions(+), 13 deletions(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 8a19654..de7e21f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -121,7 +121,7 @@ config VIDEO_S3C_CAMIF
config VIDEO_STM32_DCMI
tristate "STM32 Digital Camera Memory Interface (DCMI) support"
- depends on VIDEO_V4L2 && OF
+ depends on VIDEO_V4L2 && OF && MEDIA_CONTROLLER
depends on ARCH_STM32 || COMPILE_TEST
select VIDEOBUF2_DMA_CONTIG
select V4L2_FWNODE
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index b462f71..6f37617 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -169,6 +169,9 @@ struct stm32_dcmi {
/* Ensure DMA operations atomicity */
struct mutex dma_lock;
+
+ struct media_device mdev;
+ struct media_pad vid_cap_pad;
};
static inline struct stm32_dcmi *notifier_to_dcmi(struct v4l2_async_notifier *n)
@@ -1551,14 +1554,6 @@ static int dcmi_graph_notify_complete(struct v4l2_async_notifier *notifier)
return ret;
}
- ret = video_register_device(dcmi->vdev, VFL_TYPE_GRABBER, -1);
- if (ret) {
- dev_err(dcmi->dev, "Failed to register video device\n");
- return ret;
- }
-
- dev_dbg(dcmi->dev, "Device registered as %s\n",
- video_device_node_name(dcmi->vdev));
return 0;
}
@@ -1751,10 +1746,19 @@ static int dcmi_probe(struct platform_device *pdev)
q = &dcmi->queue;
+ dcmi->v4l2_dev.mdev = &dcmi->mdev;
+
+ /* Initialize media device */
+ strscpy(dcmi->mdev.model, DRV_NAME, sizeof(dcmi->mdev.model));
+ snprintf(dcmi->mdev.bus_info, sizeof(dcmi->mdev.bus_info),
+ "platform:%s", DRV_NAME);
+ dcmi->mdev.dev = &pdev->dev;
+ media_device_init(&dcmi->mdev);
+
/* Initialize the top-level structure */
ret = v4l2_device_register(&pdev->dev, &dcmi->v4l2_dev);
if (ret)
- goto err_dma_release;
+ goto err_media_device_cleanup;
dcmi->vdev = video_device_alloc();
if (!dcmi->vdev) {
@@ -1774,6 +1778,25 @@ static int dcmi_probe(struct platform_device *pdev)
V4L2_CAP_READWRITE;
video_set_drvdata(dcmi->vdev, dcmi);
+ /* Media entity pads */
+ dcmi->vid_cap_pad.flags = MEDIA_PAD_FL_SINK;
+ ret = media_entity_pads_init(&dcmi->vdev->entity,
+ 1, &dcmi->vid_cap_pad);
+ if (ret) {
+ dev_err(dcmi->dev, "Failed to init media entity pad\n");
+ goto err_device_release;
+ }
+ dcmi->vdev->entity.flags |= MEDIA_ENT_FL_DEFAULT;
+
+ ret = video_register_device(dcmi->vdev, VFL_TYPE_GRABBER, -1);
+ if (ret) {
+ dev_err(dcmi->dev, "Failed to register video device\n");
+ goto err_media_entity_cleanup;
+ }
+
+ dev_dbg(dcmi->dev, "Device registered as %s\n",
+ video_device_node_name(dcmi->vdev));
+
/* Buffer queue */
q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
q->io_modes = VB2_MMAP | VB2_READ | VB2_DMABUF;
@@ -1789,12 +1812,12 @@ static int dcmi_probe(struct platform_device *pdev)
ret = vb2_queue_init(q);
if (ret < 0) {
dev_err(&pdev->dev, "Failed to initialize vb2 queue\n");
- goto err_device_release;
+ goto err_media_entity_cleanup;
}
ret = dcmi_graph_init(dcmi);
if (ret < 0)
- goto err_device_release;
+ goto err_media_entity_cleanup;
/* Reset device */
ret = reset_control_assert(dcmi->rstc);
@@ -1821,11 +1844,14 @@ static int dcmi_probe(struct platform_device *pdev)
err_cleanup:
v4l2_async_notifier_cleanup(&dcmi->notifier);
+err_media_entity_cleanup:
+ media_entity_cleanup(&dcmi->vdev->entity);
err_device_release:
video_device_release(dcmi->vdev);
err_device_unregister:
v4l2_device_unregister(&dcmi->v4l2_dev);
-err_dma_release:
+err_media_device_cleanup:
+ media_device_cleanup(&dcmi->mdev);
dma_release_channel(dcmi->dma_chan);
return ret;
@@ -1839,7 +1865,9 @@ static int dcmi_remove(struct platform_device *pdev)
v4l2_async_notifier_unregister(&dcmi->notifier);
v4l2_async_notifier_cleanup(&dcmi->notifier);
+ media_entity_cleanup(&dcmi->vdev->entity);
v4l2_device_unregister(&dcmi->v4l2_dev);
+ media_device_cleanup(&dcmi->mdev);
dma_release_channel(dcmi->dma_chan);
--
2.7.4
_______________________________________________
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 v5 3/3] media: stm32-dcmi: add support of several sub-devices
From: Hugues Fruchet @ 2019-08-12 11:26 UTC (permalink / raw)
To: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, Hugues Fruchet, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <1565609206-27101-1-git-send-email-hugues.fruchet@st.com>
Add support of several sub-devices within pipeline instead
of a single one.
This allows to support a CSI-2 camera sensor connected
through a CSI-2 to parallel bridge.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hugues Fruchet <hugues.fruchet@st.com>
---
drivers/media/platform/stm32/stm32-dcmi.c | 195 +++++++++++++++++++++++++++---
1 file changed, 177 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index 6f37617..7c21805 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -172,6 +172,7 @@ struct stm32_dcmi {
struct media_device mdev;
struct media_pad vid_cap_pad;
+ struct media_pipeline pipeline;
};
static inline struct stm32_dcmi *notifier_to_dcmi(struct v4l2_async_notifier *n)
@@ -583,6 +584,131 @@ static void dcmi_buf_queue(struct vb2_buffer *vb)
spin_unlock_irq(&dcmi->irqlock);
}
+static struct media_entity *dcmi_find_source(struct stm32_dcmi *dcmi)
+{
+ struct media_entity *entity = &dcmi->vdev->entity;
+ struct media_pad *pad;
+
+ /* Walk searching for entity having no sink */
+ while (1) {
+ pad = &entity->pads[0];
+ if (!(pad->flags & MEDIA_PAD_FL_SINK))
+ break;
+
+ pad = media_entity_remote_pad(pad);
+ if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
+ break;
+
+ entity = pad->entity;
+ }
+
+ return entity;
+}
+
+static int dcmi_pipeline_s_fmt(struct stm32_dcmi *dcmi,
+ struct v4l2_subdev_pad_config *pad_cfg,
+ struct v4l2_subdev_format *format)
+{
+ struct media_entity *entity = &dcmi->entity.source->entity;
+ struct v4l2_subdev *subdev;
+ struct media_pad *sink_pad = NULL;
+ struct media_pad *src_pad = NULL;
+ struct media_pad *pad = NULL;
+ struct v4l2_subdev_format fmt = *format;
+ bool found = false;
+ int ret;
+
+ /*
+ * Starting from sensor subdevice, walk within
+ * pipeline and set format on each subdevice
+ */
+ while (1) {
+ unsigned int i;
+
+ /* Search if current entity has a source pad */
+ for (i = 0; i < entity->num_pads; i++) {
+ pad = &entity->pads[i];
+ if (pad->flags & MEDIA_PAD_FL_SOURCE) {
+ src_pad = pad;
+ found = true;
+ break;
+ }
+ }
+ if (!found)
+ break;
+
+ subdev = media_entity_to_v4l2_subdev(entity);
+
+ /* Propagate format on sink pad if any, otherwise source pad */
+ if (sink_pad)
+ pad = sink_pad;
+
+ dev_dbg(dcmi->dev, "%s[%d] pad format set to 0x%x %ux%u\n",
+ subdev->name, pad->index, format->format.code,
+ format->format.width, format->format.height);
+
+ fmt.pad = pad->index;
+ ret = v4l2_subdev_call(subdev, pad, set_fmt, pad_cfg, &fmt);
+ if (ret < 0)
+ return ret;
+
+ /* Walk to next entity */
+ sink_pad = media_entity_remote_pad(src_pad);
+ if (!sink_pad || !is_media_entity_v4l2_subdev(sink_pad->entity))
+ break;
+
+ entity = sink_pad->entity;
+ }
+ *format = fmt;
+
+ return 0;
+}
+
+static int dcmi_pipeline_s_stream(struct stm32_dcmi *dcmi, int state)
+{
+ struct media_entity *entity = &dcmi->vdev->entity;
+ struct v4l2_subdev *subdev;
+ struct media_pad *pad;
+ int ret;
+
+ /* Start/stop all entities within pipeline */
+ while (1) {
+ pad = &entity->pads[0];
+ if (!(pad->flags & MEDIA_PAD_FL_SINK))
+ break;
+
+ pad = media_entity_remote_pad(pad);
+ if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
+ break;
+
+ entity = pad->entity;
+ subdev = media_entity_to_v4l2_subdev(entity);
+
+ ret = v4l2_subdev_call(subdev, video, s_stream, state);
+ if (ret < 0 && ret != -ENOIOCTLCMD) {
+ dev_err(dcmi->dev, "%s: %s failed to %s streaming (%d)\n",
+ __func__, subdev->name,
+ state ? "start" : "stop", ret);
+ return ret;
+ }
+
+ dev_dbg(dcmi->dev, "%s is %s\n",
+ subdev->name, state ? "started" : "stopped");
+ }
+
+ return 0;
+}
+
+static int dcmi_pipeline_start(struct stm32_dcmi *dcmi)
+{
+ return dcmi_pipeline_s_stream(dcmi, 1);
+}
+
+static void dcmi_pipeline_stop(struct stm32_dcmi *dcmi)
+{
+ dcmi_pipeline_s_stream(dcmi, 0);
+}
+
static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct stm32_dcmi *dcmi = vb2_get_drv_priv(vq);
@@ -597,14 +723,17 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
goto err_release_buffers;
}
- /* Enable stream on the sub device */
- ret = v4l2_subdev_call(dcmi->entity.source, video, s_stream, 1);
- if (ret && ret != -ENOIOCTLCMD) {
- dev_err(dcmi->dev, "%s: Failed to start streaming, subdev streamon error",
- __func__);
+ ret = media_pipeline_start(&dcmi->vdev->entity, &dcmi->pipeline);
+ if (ret < 0) {
+ dev_err(dcmi->dev, "%s: Failed to start streaming, media pipeline start error (%d)\n",
+ __func__, ret);
goto err_pm_put;
}
+ ret = dcmi_pipeline_start(dcmi);
+ if (ret)
+ goto err_media_pipeline_stop;
+
spin_lock_irq(&dcmi->irqlock);
/* Set bus width */
@@ -676,7 +805,7 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
if (ret) {
dev_err(dcmi->dev, "%s: Start streaming failed, cannot start capture\n",
__func__);
- goto err_subdev_streamoff;
+ goto err_pipeline_stop;
}
/* Enable interruptions */
@@ -687,8 +816,11 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
return 0;
-err_subdev_streamoff:
- v4l2_subdev_call(dcmi->entity.source, video, s_stream, 0);
+err_pipeline_stop:
+ dcmi_pipeline_stop(dcmi);
+
+err_media_pipeline_stop:
+ media_pipeline_stop(&dcmi->vdev->entity);
err_pm_put:
pm_runtime_put(dcmi->dev);
@@ -713,13 +845,10 @@ static void dcmi_stop_streaming(struct vb2_queue *vq)
{
struct stm32_dcmi *dcmi = vb2_get_drv_priv(vq);
struct dcmi_buf *buf, *node;
- int ret;
- /* Disable stream on the sub device */
- ret = v4l2_subdev_call(dcmi->entity.source, video, s_stream, 0);
- if (ret && ret != -ENOIOCTLCMD)
- dev_err(dcmi->dev, "%s: Failed to stop streaming, subdev streamoff error (%d)\n",
- __func__, ret);
+ dcmi_pipeline_stop(dcmi);
+
+ media_pipeline_stop(&dcmi->vdev->entity);
spin_lock_irq(&dcmi->irqlock);
@@ -937,8 +1066,7 @@ static int dcmi_set_fmt(struct stm32_dcmi *dcmi, struct v4l2_format *f)
mf->width = sd_framesize.width;
mf->height = sd_framesize.height;
- ret = v4l2_subdev_call(dcmi->entity.source, pad,
- set_fmt, NULL, &format);
+ ret = dcmi_pipeline_s_fmt(dcmi, NULL, &format);
if (ret < 0)
return ret;
@@ -1529,7 +1657,20 @@ static int dcmi_graph_notify_complete(struct v4l2_async_notifier *notifier)
struct stm32_dcmi *dcmi = notifier_to_dcmi(notifier);
int ret;
+ /*
+ * Now that the graph is complete,
+ * we search for the source subdevice
+ * in order to expose it through V4L2 interface
+ */
+ dcmi->entity.source =
+ media_entity_to_v4l2_subdev(dcmi_find_source(dcmi));
+ if (!dcmi->entity.source) {
+ dev_err(dcmi->dev, "Source subdevice not found\n");
+ return -ENODEV;
+ }
+
dcmi->vdev->ctrl_handler = dcmi->entity.source->ctrl_handler;
+
ret = dcmi_formats_init(dcmi);
if (ret) {
dev_err(dcmi->dev, "No supported mediabus format found\n");
@@ -1574,12 +1715,30 @@ static int dcmi_graph_notify_bound(struct v4l2_async_notifier *notifier,
struct v4l2_async_subdev *asd)
{
struct stm32_dcmi *dcmi = notifier_to_dcmi(notifier);
+ unsigned int ret;
+ int src_pad;
dev_dbg(dcmi->dev, "Subdev %s bound\n", subdev->name);
- dcmi->entity.source = subdev;
+ /*
+ * Link this sub-device to DCMI, it could be
+ * a parallel camera sensor or a bridge
+ */
+ src_pad = media_entity_get_fwnode_pad(&subdev->entity,
+ subdev->fwnode,
+ MEDIA_PAD_FL_SOURCE);
+
+ ret = media_create_pad_link(&subdev->entity, src_pad,
+ &dcmi->vdev->entity, 0,
+ MEDIA_LNK_FL_IMMUTABLE |
+ MEDIA_LNK_FL_ENABLED);
+ if (ret)
+ dev_err(dcmi->dev, "Failed to create media pad link with subdev %s\n",
+ subdev->name);
+ else
+ dev_dbg(dcmi->dev, "DCMI is now linked to %s\n", subdev->name);
- return 0;
+ return ret;
}
static const struct v4l2_async_notifier_operations dcmi_graph_notify_ops = {
--
2.7.4
_______________________________________________
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 v5 0/3] DCMI bridge support
From: Hugues Fruchet @ 2019-08-12 11:26 UTC (permalink / raw)
To: Alexandre Torgue, Mauro Carvalho Chehab, Hans Verkuil,
Sakari Ailus
Cc: Mickael GUENE, linux-kernel, Philippe CORNU, Yannick Fertre,
Benjamin Gaignard, Hugues Fruchet, linux-stm32, linux-arm-kernel,
linux-media
This patch serie allows to connect non-parallel camera sensor to
DCMI thanks to a bridge connected in between such as STMIPID02 [1].
Media controller support is introduced first, then support of
several sub-devices within pipeline with dynamic linking
between them.
In order to keep backward compatibility with applications
relying on V4L2 interface only, format set on video node
is propagated to all sub-devices connected to camera interface.
[1] https://www.spinics.net/lists/devicetree/msg278002.html
===========
= history =
===========
version 5:
- Remove remaining Change-Id
- Add Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
version 4:
- Also drop subdev nodes registry as suggested by Hans:
https://www.spinics.net/lists/arm-kernel/msg743375.html
version 3:
- Drop media device registry to not expose media controller
interface to userspace as per Laurent' suggestion:
https://www.spinics.net/lists/linux-media/msg153417.html
- Prefer "source" instead of "sensor" and keep it in
dcmi_graph_entity struct, move asd as first member
of struct as per Sakari' suggestion:
https://www.spinics.net/lists/linux-media/msg153119.html
- Drop dcmi_graph_deinit() as per Sakari' suggestion:
https://www.spinics.net/lists/linux-media/msg153417.html
version 2:
- Fix bus_info not consistent between media and V4L:
https://www.spinics.net/lists/arm-kernel/msg717676.html
- Propagation of format set on video node to the sub-devices
chain connected on camera interface
version 1:
- Initial submission
Hugues Fruchet (3):
media: stm32-dcmi: improve sensor subdev naming
media: stm32-dcmi: add media controller support
media: stm32-dcmi: add support of several sub-devices
drivers/media/platform/Kconfig | 2 +-
drivers/media/platform/stm32/stm32-dcmi.c | 283 +++++++++++++++++++++++++-----
2 files changed, 236 insertions(+), 49 deletions(-)
--
2.7.4
_______________________________________________
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] arm64: dts: allwinner: Enable DDC regulator for Beelink GS1
From: Maxime Ripard @ 2019-08-12 11:26 UTC (permalink / raw)
To: Clément Péron
Cc: devicetree, Chen-Yu Tsai, linux-kernel, linux-sunxi, Rob Herring,
linux-arm-kernel
In-Reply-To: <20190812102355.22586-1-peron.clem@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 431 bytes --]
On Mon, Aug 12, 2019 at 12:23:55PM +0200, Clément Péron wrote:
> Beelink GS1 has a DDC I2C bus voltage shifter. This is actually missing
> and video is limited to 1024x768 due to missing EDID information.
>
> Add the DDC regulator in the device-tree.
>
> Signed-off-by: Clément Péron <peron.clem@gmail.com>
Applied, thanks
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 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
* Aw: Re: [PATCH v3 06/10] mfd: mt6323: some improvements of mt6397-core
From: Frank Wunderlich @ 2019-08-12 11:25 UTC (permalink / raw)
To: Lee Jones
Cc: Kate Stewart, Mark Rutland, Alexandre Belloni, Richard Fontana,
Mauro Carvalho Chehab, linux-rtc, Allison Randal, devicetree,
linux-pm, Sean Wang, Tianping . Fang, Rob Herring, linux-mediatek,
Jonathan Cameron, Matthias Brugger, Thomas Gleixner, Eddie Huang,
linux-arm-kernel, Alessandro Zummo, Josef Friedl,
Greg Kroah-Hartman, linux-kernel, Sebastian Reichel,
David S. Miller
In-Reply-To: <20190812102209.GI26727@dell>
> Gesendet: Montag, 12. August 2019 um 12:22 Uhr
> Von: "Lee Jones" <lee.jones@linaro.org>
> > - * Copyright (c) 2014 MediaTek Inc.
> > + * Copyright (c) 2014-2018 MediaTek Inc.
>
> This is out of date. Please update it.
maybe i should drop change of this line completely (else it needs to be adjusted every year)
regards Frank
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Re: [PATCH v3 01/10] dt-bindings: add powercontroller
From: Lee Jones @ 2019-08-12 11:25 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Kate Stewart, Mark Rutland, Alexandre Belloni, linux-kernel,
Richard Fontana, Mauro Carvalho Chehab, linux-rtc, Allison Randal,
devicetree, linux-pm, Sean Wang, Tianping . Fang, Rob Herring,
linux-mediatek, Jonathan Cameron, Matthias Brugger,
Thomas Gleixner, Eddie Huang, linux-arm-kernel, Alessandro Zummo,
Josef Friedl, Greg Kroah-Hartman, Sebastian Reichel,
David S. Miller
In-Reply-To: <trinity-a6c06411-16d3-40ab-a4fb-3494131c8ed6-1565608221532@3c-app-gmx-bs80>
On Mon, 12 Aug 2019, Frank Wunderlich wrote:
> > Gesendet: Montag, 12. August 2019 um 12:20 Uhr
> > Von: "Lee Jones" <lee.jones@linaro.org>
>
> > > --- a/Documentation/devicetree/bindings/mfd/mt6397.txt
> ...
> > > + For details, see Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
> >
> > Please use relative paths.
> >
> > E.g: ../bindings/rtc/rtc-mt6397.txt
>
> Hi,
>
> as we are in Documentation/devicetree/bindings/mfd/ it should be
> ../../bindings/..., right? or ../rtc/rtc-mt6397.txt ?
It was an example (hence the "E.g.").
You will need to adapt it depending on where the file ends up.
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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 03/11] clocksource: sun4i: Add missing compatibles
From: Maxime Ripard @ 2019-08-12 11:24 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Mark Rutland, devicetree, Chen-Yu Tsai, Rob Herring, tglx,
Frank Rowand, linux-arm-kernel
In-Reply-To: <42ee55ee-258c-7588-fea3-db3c661a0156@linaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 760 bytes --]
On Mon, Aug 12, 2019 at 11:21:50AM +0200, Daniel Lezcano wrote:
> On 12/08/2019 11:16, Maxime Ripard wrote:
> > Hi,
> >
> > On Mon, Aug 12, 2019 at 10:59:51AM +0200, Daniel Lezcano wrote:
> >> On 22/07/2019 10:12, Maxime Ripard wrote:
> >>> Newer Allwinner SoCs have different number of interrupts, let's add
> >>> different compatibles for all of them to deal with this properly.
> >>>
> >>> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> >>
> >> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> >
> > Thanks!
> >
> > Can you merge this through your tree (along with the bindings)? I'll
> > merge the DT patches
>
> patches 1-4 then ?
Yep, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 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 v6 0/2] Allwinner H6 SPDIF support
From: Maxime Ripard @ 2019-08-12 11:23 UTC (permalink / raw)
To: Clément Péron
Cc: devicetree, linux-sunxi, Rob Herring, linux-kernel,
linux-arm-kernel
In-Reply-To: <20190812105115.26676-1-peron.clem@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 589 bytes --]
On Mon, Aug 12, 2019 at 12:51:13PM +0200, Clément Péron wrote:
> Allwinner H6 SoC has a SPDIF controller called One Wire Audio (OWA) which
> is different from the previous H3 generation and not compatible.
>
> Difference are an increase of fifo sizes, some memory mapping are different
> and there is now the possibility to output the master clock on a pin.
>
> Actually all these features are unused and only a bit for flushing the TX
> fifo is required.
Applied both, thanks
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 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
* Aw: Re: [PATCH v3 01/10] dt-bindings: add powercontroller
From: Frank Wunderlich @ 2019-08-12 11:10 UTC (permalink / raw)
To: Lee Jones
Cc: Kate Stewart, Mark Rutland, Alexandre Belloni, linux-kernel,
Richard Fontana, Mauro Carvalho Chehab, linux-rtc, Allison Randal,
devicetree, linux-pm, Sean Wang, Tianping . Fang, Rob Herring,
linux-mediatek, Jonathan Cameron, Matthias Brugger,
Thomas Gleixner, Eddie Huang, linux-arm-kernel, Alessandro Zummo,
Josef Friedl, Greg Kroah-Hartman, Sebastian Reichel,
David S. Miller
In-Reply-To: <20190812102035.GH26727@dell>
> Gesendet: Montag, 12. August 2019 um 12:20 Uhr
> Von: "Lee Jones" <lee.jones@linaro.org>
> > --- a/Documentation/devicetree/bindings/mfd/mt6397.txt
...
> > + For details, see Documentation/devicetree/bindings/rtc/rtc-mt6397.txt
>
> Please use relative paths.
>
> E.g: ../bindings/rtc/rtc-mt6397.txt
Hi,
as we are in Documentation/devicetree/bindings/mfd/ it should be ../../bindings/..., right? or ../rtc/rtc-mt6397.txt ?
regards Frank
_______________________________________________
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 0/5] can: xilinx_can: Bug fixes
From: Michal Simek @ 2019-08-12 11:05 UTC (permalink / raw)
To: Marc Kleine-Budde, Michal Simek, Appana Durga Kedareswara rao, wg,
davem
Cc: netdev, linux-kernel, linux-arm-kernel, linux-can
In-Reply-To: <6b36bbcb-06e3-63aa-8861-c07c8840e25e@pengutronix.de>
On 12. 08. 19 12:59, Marc Kleine-Budde wrote:
> On 8/12/19 12:57 PM, Michal Simek wrote:
>> On 12. 08. 19 12:47, Marc Kleine-Budde wrote:
>>> On 8/12/19 12:18 PM, Michal Simek wrote:
>>>> On 12. 08. 19 11:10, Marc Kleine-Budde wrote:
>>>>> On 8/12/19 11:05 AM, Marc Kleine-Budde wrote:
>>>>>> On 8/12/19 9:28 AM, Appana Durga Kedareswara rao wrote:
>>>>>>> This patch series fixes below issues
>>>>>>> --> Bugs in the driver w.r.to CANFD 2.0 IP support
>>>>>>> --> Defer the probe if clock is not found
>>>>>>>
>>>>>>> Appana Durga Kedareswara rao (3):
>>>>>>> can: xilinx_can: Fix FSR register handling in the rx path
>>>>>>> can: xilinx_can: Fix the data updation logic for CANFD FD frames
>>>>>>> can: xilinx_can: Fix FSR register FL and RI mask values for canfd 2.0
>>>>>>>
>>>>>>> Srinivas Neeli (1):
>>>>>>> can: xilinx_can: Fix the data phase btr1 calculation
>>>>>>>
>>>>>>> Venkatesh Yadav Abbarapu (1):
>>>>>>> can: xilinx_can: defer the probe if clock is not found
>>>>>>
>>>>>> Please add your S-o-b to patches 4+5.
>>>>>>
>>>>>> As these all are bugfixes please add a reference to the commit it fixes:
>>>>>>
>>>>>> Fixes: commitish ("description")
>>>>>
>>>>> Add this to your ~/.gitconfig:
>>>>>
>>>>> [alias]
>>>>> lfixes = log --pretty=fixes
>>>>> [pretty]
>>>>> fixes = Fixes: %h (\"%s\")
>>>>
>>>> This is understandable and I have this in my .gitconfig for quite a long
>>>> time. And this is just log
>>>>
>>>>> and then use $(git lfixes $commitish).
>>>>
>>>> But what do you mean by this? Are you able to add this to commit message
>>>> just with sha1?
>>>
>>> First identify the commit that this patch fixes then go to the command
>>> line and enter
>>>
>>> git lfixes $committish
>>>
>>> and git will print out the line that you can copy directly to the commit
>>> message.
>>
>> ok. I thought you have any nice way to directly add it to commit message
>> without c&p.
>
> You can insert the output from a console command in vim by adding a "!"
> in front of it in the command mode.
ok.
M
_______________________________________________
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 0/7] Allwinner H6 SPDIF support
From: Mark Brown @ 2019-08-12 11:01 UTC (permalink / raw)
To: Clément Péron
Cc: Mark Rutland, devicetree, Linux-ALSA, Maxime Ripard, linux-kernel,
linux-sunxi, Takashi Iwai, Liam Girdwood, Chen-Yu Tsai,
Rob Herring, Jagan Teki, Jaroslav Kysela, linux-arm-kernel
In-Reply-To: <CAJiuCceYDnyxRLLLLy6Dn6DLTZ+NmSaUnoX1Vmzvgiy0XvF_Fw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 712 bytes --]
On Sat, Aug 10, 2019 at 10:45:23AM +0200, Clément Péron wrote:
> Hi,
Please don't top post, reply in line with needed context. This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.
> Sorry, I just discovered that the ASoC patches have been merged into
> the broonie and linus tree in 5.3.
> I'm still quite new in the sending of patches to the Kernel but
> souldn't be a ack or a mail sent to warn the sender when the series
> are accepted?
Not every maintainer will send those, I do but you might find they've
gone into your spam folder if you're using gmail.
[-- 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
* Re: [PATCH v4 03/10] mfd: mt6397: modify suspend/resume behavior
From: Lee Jones @ 2019-08-12 11:00 UTC (permalink / raw)
To: Hsin-Hsiung Wang
Cc: Mark Rutland, Alessandro Zummo, Alexandre Belloni, srv_heupstream,
devicetree, Sean Wang, Liam Girdwood, Rob Herring, linux-kernel,
Richard Fontana, Mark Brown, linux-mediatek, Allison Randal,
linux-rtc, Matthias Brugger, Thomas Gleixner, Eddie Huang,
Kate Stewart, linux-arm-kernel
In-Reply-To: <1564982518-32163-4-git-send-email-hsin-hsiung.wang@mediatek.com>
On Mon, 05 Aug 2019, Hsin-Hsiung Wang wrote:
> Some pmics don't need backup interrupt settings, so we change to use
> pm notifier for the pmics which are necessary to store settings.
>
> Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
> ---
> drivers/mfd/mt6397-core.c | 89 +++++++++++++++++------------------------
> drivers/mfd/mt6397-irq.c | 33 +++++++++++++++
> include/linux/mfd/mt6397/core.h | 3 ++
> 3 files changed, 73 insertions(+), 52 deletions(-)
For my own reference:
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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