* [PATCHv3 RESEND 1/8] ARM: dts: stm32: set HSE_RTC clock frequency to 1 MHz on stm32f429
From: Amelie Delaunay @ 2017-01-16 13:29 UTC (permalink / raw)
To: linux-arm-kernel
This patch set HSE_RTC clock frequency to 1 MHz, as the clock supplied to
the RTC must be 1 MHz.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index e9324a3..557c1f4 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -433,6 +433,8 @@
reg = <0x40023800 0x400>;
clocks = <&clk_hse>, <&clk_i2s_ckin>;
st,syscfg = <&pwrcfg>;
+ assigned-clocks = <&rcc 1 CLK_HSE_RTC>;
+ assigned-clock-rates = <1000000>;
};
dma1: dma-controller at 40026000 {
--
1.9.1
^ permalink raw reply related
* [PATCHv3 RESEND 4/8] ARM: dts: stm32: Add RTC support for STM32F429 MCU
From: Amelie Delaunay @ 2017-01-16 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484573388-590-1-git-send-email-amelie.delaunay@st.com>
This patch adds STM32 RTC bindings for STM32F429.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 557c1f4..f05a9d9 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -125,6 +125,20 @@
status = "disabled";
};
+ rtc: rtc at 40002800 {
+ compatible = "st,stm32-rtc";
+ reg = <0x40002800 0x400>;
+ clocks = <&rcc 1 CLK_RTC>;
+ clock-names = "ck_rtc";
+ assigned-clocks = <&rcc 1 CLK_RTC>;
+ assigned-clock-parents = <&rcc 1 CLK_LSE>;
+ interrupt-parent = <&exti>;
+ interrupts = <17 1>;
+ interrupt-names = "alarm";
+ st,syscfg = <&pwrcfg>;
+ status = "disabled";
+ };
+
usart2: serial at 40004400 {
compatible = "st,stm32-usart", "st,stm32-uart";
reg = <0x40004400 0x400>;
--
1.9.1
^ permalink raw reply related
* [PATCHv3 RESEND 5/8] ARM: dts: stm32: enable RTC on stm32f429-disco
From: Amelie Delaunay @ 2017-01-16 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484573388-590-1-git-send-email-amelie.delaunay@st.com>
This patch enables RTC on stm32f429-disco with LSI as clock source because
X2 crystal for LSE is not fitted by default.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/boot/dts/stm32f429-disco.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429-disco.dts b/arch/arm/boot/dts/stm32f429-disco.dts
index 7d0415e..9222b9f 100644
--- a/arch/arm/boot/dts/stm32f429-disco.dts
+++ b/arch/arm/boot/dts/stm32f429-disco.dts
@@ -94,6 +94,12 @@
clock-frequency = <8000000>;
};
+&rtc {
+ assigned-clocks = <&rcc 1 CLK_RTC>;
+ assigned-clock-parents = <&rcc 1 CLK_LSI>;
+ status = "okay";
+};
+
&usart1 {
pinctrl-0 = <&usart1_pins_a>;
pinctrl-names = "default";
--
1.9.1
^ permalink raw reply related
* [PATCHv3 RESEND 6/8] ARM: dts: stm32: enable RTC on stm32f469-disco
From: Amelie Delaunay @ 2017-01-16 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484573388-590-1-git-send-email-amelie.delaunay@st.com>
This patch enables RTC on stm32f469-disco with default LSE clock source.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/boot/dts/stm32f469-disco.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index fda12a4..f52b9f6 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -78,6 +78,10 @@
clock-frequency = <8000000>;
};
+&rtc {
+ status = "okay";
+};
+
&usart3 {
pinctrl-0 = <&usart3_pins_a>;
pinctrl-names = "default";
--
1.9.1
^ permalink raw reply related
* [PATCHv3 RESEND 7/8] ARM: dts: stm32: enable RTC on stm32429i-eval
From: Amelie Delaunay @ 2017-01-16 13:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1484573388-590-1-git-send-email-amelie.delaunay@st.com>
This patch enables RTC on stm32429i-eval with default LSE clock source.
Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
---
arch/arm/boot/dts/stm32429i-eval.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/stm32429i-eval.dts b/arch/arm/boot/dts/stm32429i-eval.dts
index 2181220..eedb27d 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -157,6 +157,10 @@
};
};
+&rtc {
+ status = "okay";
+};
+
&usart1 {
pinctrl-0 = <&usart1_pins_a>;
pinctrl-names = "default";
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] KVM: arm64: Access CNTHCTL_EL2 bit fields correctly on VHE systems
From: Marc Zyngier @ 2017-01-16 13:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e0d1473f-0cf9-a801-585b-4385bc5b35ab@arm.com>
On 13/01/17 14:56, Suzuki K Poulose wrote:
> On 13/01/17 13:30, Marc Zyngier wrote:
>> [+ Suzuki, who wrote the whole cpus_have_const_cap thing]
>>
[...]
>> But maybe we should have have some stronger guarantees that we'll
>> always get things inlined, and that the "const" side is enforced:
>
> Agreed.
>
>>
>> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
>> index b4989df..4710469 100644
>> --- a/arch/arm64/include/asm/cpufeature.h
>> +++ b/arch/arm64/include/asm/cpufeature.h
>> @@ -105,10 +105,11 @@ static inline bool cpu_have_feature(unsigned int num)
>> }
>>
>> /* System capability check for constant caps */
>> -static inline bool cpus_have_const_cap(int num)
>> +static __always_inline bool cpus_have_const_cap(int num)
>
> I think we should have the above change and make it inline always.
>
>> {
>> - if (num >= ARM64_NCAPS)
>> - return false;
>> + BUILD_BUG_ON(!__builtin_constant_p(num));
>
> This is not needed, as the compilation would fail if num is not a constant with
> static key code.
>
>> + BUILD_BUG_ON(num >= ARM64_NCAPS);
>> +
>
> Also, I think it would be good to return false for caps > the ARM64_NCAPS, in sync
> with the non-const version.
But what's the semantic? It means we're accessing a capability that
doesn't exist, which looks like a major bug in my book. Is there any
valid use case for this?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [RFC PATCH 08/10] arm64/sve: ptrace: Wire up vector length control and reporting
From: Dave Martin @ 2017-01-16 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116122038.GG28060@E107787-LIN>
On Mon, Jan 16, 2017 at 12:20:38PM +0000, Yao Qi wrote:
> On 17-01-12 11:26:07, Dave Martin wrote:
> > This patch adds support for manipulating a task's vector length at
> > runtime via ptrace.
> >
>
> I hope kernel doesn't provide such interface to ptracer to change vector
> length.
It does, with this patch, beacuse...
> The vector length is sort of a read-only property of thread/process/
> program to debugger, unless we really have a clear requirement to modify
> vector length in debugging. I may miss something because I haven't debug
> SVE code yet.
...the vector length is no longer read-only for the task, thanks to
the new prctls().
This does add complexity, but I figured that any programmer's model
state that the thread can modify for itself should be modifiable by the
debugger, if for no other reason than the user may want to experiment to
see what happens. Without a ptrace interface, it would be necessary
to inject a prctl() call into the target, which is possible but awkward.
gdb must already re-detect the vector length on stop, since the target
could have called the prctl() in the meantime.
Access via ptrace also allows things like trapping on exec, fork or
clone and changing the vector length for the new process or thread
before it starts to run. I'm guessing here, but such a scenario seems
legitimate (?)
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/3] watchdog: imx2: Only i.MX35 and later have a WMCR register
From: Fabio Estevam @ 2017-01-16 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109095039.11979-2-u.kleine-koenig@pengutronix.de>
Hi Magnus,
On Mon, Jan 9, 2017 at 7:50 AM, Uwe Kleine-K?nig
<u.kleine-koenig@pengutronix.de> wrote:
> Commit 5fe65ce7ccbb ("watchdog: imx2_wdt: Disable power down counter on
> boot") introduced a write to the WMCR register that doesn't exist on
> i.MX21, i.MX27 and i.MX31 and so makes the SoC hang during probe.
>
> So teach the driver to differentiate between these two types. Note that
> this effectively undoes commit 5fe65ce7ccbb for machines using dt until
> their dtb is updated accordingly. This is critical iff the bootloader
> doesn't disable the power down counter and the #WDOG signal actually
> does something to the machine.
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Is it possible for you to try this series and let us know if it fixes
the mx31 watchdog issue?
Thanks
^ permalink raw reply
* [RFC PATCH 07/10] arm64/sve: Add vector length inheritance control
From: Dave Martin @ 2017-01-16 13:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116122755.GH28060@E107787-LIN>
On Mon, Jan 16, 2017 at 12:27:55PM +0000, Yao Qi wrote:
> On 17-01-12 11:26:06, Dave Martin wrote:
> > Currently the vector length is inherited across both fork() and
> > exec().
> >
> > Inheritance across fork() is desirable both for creating a copy of
> > a process (traditional fork) or creating a thread (where we want
> > all threads to share the same VL by default).
> >
> > Inheritance across exec() is less desirable, because of the ABI
> > impact of large vector lengths on the size of the signal frame --
> > when running a new binary, there is no guarantee that the new
> > binary is compatible with these ABI changes.
> >
> > This flag makes the vector length non-inherited by default.
>
> Can we make vector length inherited across fork but non-inherited
> across exec by default?
That is the behaviour: I always inherit across fork/clone, since
you are still running the same binary after those.
I could word the commit message a bit more clearly here.
Cheers
---Dave
^ permalink raw reply
* [PATCH 11/37] PCI: dwc: Split pcie-designware.c into host and core files
From: Joao Pinto @ 2017-01-16 13:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <587CAEBD.1010803@ti.com>
?s 11:30 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
> Hi Joao,
>
> On Monday 16 January 2017 03:57 PM, Joao Pinto wrote:
>>
>> Hi,
>>
>> ?s 5:21 AM de 1/16/2017, Kishon Vijay Abraham I escreveu:
>>> Hi Joao,
>>>
>>> On Friday 13 January 2017 10:19 PM, Joao Pinto wrote:
>>>> ?s 10:26 AM de 1/12/2017, Kishon Vijay Abraham I escreveu:
>>>>> Split pcie-designware.c into pcie-designware-host.c that contains
>>>>> the host specific parts of the driver and pcie-designware.c that
>>>>> contains the parts used by both host driver and endpoint driver.
>>>>>
>>>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>>>> ---
>>>>> drivers/pci/dwc/Makefile | 2 +-
>>>>> drivers/pci/dwc/pcie-designware-host.c | 619 ++++++++++++++++++++++++++++++++
>>>>> drivers/pci/dwc/pcie-designware.c | 613 +------------------------------
>>>>> drivers/pci/dwc/pcie-designware.h | 8 +
>>>>> 4 files changed, 634 insertions(+), 608 deletions(-)
>>>>> create mode 100644 drivers/pci/dwc/pcie-designware-host.c
>>>>>
>>>>> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
>>>>> index 7d27c14..3b57e55 100644
>>>>> --- a/drivers/pci/dwc/Makefile
>>>>> +++ b/drivers/pci/dwc/Makefile
>>>>> @@ -1,4 +1,4 @@
>>>>
>>>> (snip...)
>>>>
>>>>> -static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
>>>>> - int type, u64 cpu_addr, u64 pci_addr,
>>>>> - u32 size)
>>>>> +void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index, int type,
>>>>> + u64 cpu_addr, u64 pci_addr, u32 size)
>>>>> {
>>>>> u32 retries, val;
>>>>>
>>>>> @@ -186,220 +151,6 @@ static void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,
>>>>> dev_err(pci->dev, "iATU is not being enabled\n");
>>>>> }
>>>>
>>>> Kishon, iATU only makes sense in The Root Complex (host), so it should be inside
>>>> the pcie-designware-host.
>>>
>>> That is not true. Outbound ATU should be programmed to access host side buffers
>>> and inbound ATU should be programmed for the host to access EP mem space.
>>
>> Sorry, I was not clear enough. What I was trying to suggest is, since the ATU
>> programming is done by the host, wouldn't be better to include it in the
>> pcie-designware-host? It is just an architectural detail.
>
> ATU programming is required in EP mode. See "[PATCH 24/37] PCI: dwc:
> designware: Add EP mode support" in this patch series.
>
> Anything that's required by both EP mode and RC mode, I've placed in
> pcie-designware.c
Agreed!
>
> Thanks
> Kishon
>
^ permalink raw reply
* [PATCH 8/8] efi: Add EFI_SECURE_BOOT bit [ver #6]
From: Matt Fleming @ 2017-01-16 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7979.1484148564@warthog.procyon.org.uk>
On Wed, 11 Jan, at 03:29:24PM, David Howells wrote:
> Matt Fleming <matt@codeblueprint.co.uk> wrote:
>
> > Before we add more efi.flags bits I'd like this series to include the
> > patch that makes use of EFI_SECURE_BOOT. Alternatively, you move this
> > last patch to a new series.
>
> Are you willing to take the kernel lock-down patches also?
I'm happy to take them through the EFI tree provided that they've been
Reviewed/Ack-ed by the security folks.
^ permalink raw reply
* [PATCH] arm64: defconfig: disable CONFIG_DEVMEM
From: Leif Lindholm @ 2017-01-16 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170115124254.GF25883@bivouac.eciton.net>
On Sun, Jan 15, 2017 at 12:42:54PM +0000, Leif Lindholm wrote:
> On a side note, comparing the resulting configs, there is a
> semi-broken config dependency in lib/Kconfig.debug, meaning
> CONFIG_*STRICT_DEVMEM get set even if CONFIG_DEVMEM is not.
> But I'll send that out as a separate patch.
Ah - never mind, that one has already been fixed upstream for 4.10rc.
/
Leif
^ permalink raw reply
* [PATCH v3 16/24] media: Add i.MX media core driver
From: Philipp Zabel @ 2017-01-16 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a94025b4-c4dd-de51-572e-d2615a7246e4@gmail.com>
On Sat, 2017-01-14 at 14:46 -0800, Steve Longerbeam wrote:
[...]
> >> +Unprocessed Video Capture:
> >> +--------------------------
> >> +
> >> +Send frames directly from sensor to camera interface, with no
> >> +conversions:
> >> +
> >> +-> ipu_smfc -> camif
> > I'd call this capture interface, this is not just for cameras. Or maybe
> > idmac if you want to mirror hardware names?
>
> Camif is so named because it is the V4L2 user interface for video
> capture. I suppose it could be named "capif", but that doesn't role
> off the tongue quite as well.
Agreed, capif sounds weird. I find camif a bit confusing though, because
Samsung S3C has a camera interface that is actually called "CAMIF".
> >> +Note the ipu_smfc can do pixel reordering within the same colorspace.
> > That isn't a feature of the SMFC, but of the IDMAC (FCW & FCR).
>
> yes, the doc is re-worded to make that more clear.
>
> >> +For example, its sink pad can take UYVY2X8, but its source pad can
> >> +output YUYV2X8.
> > I don't think this is correct. Re-reading "37.4.3.7 Packing to memory"
> > in the CSI chapter, for 8-bit per component data, the internal format
> > between CSI, SMFC, and IDMAC is always some 32-bit RGBx/YUVx variant
> > (or "bayer/generic data"). In either case, the internal format does not
> > change along the way.
>
> these are pixels in memory buffers, not the IPU internal formats.
As long as we are talking about the CSI -> SMFC -> IDMAC path, these
should be IPU internal formats. How else would one choose between 8-bit
companded RGB, and 16-bit expanded RGB for a 10-bit per component input
signal? This is the same issue as in the next comment.
> >> + media-ctl -V "\"camif0\":0 [fmt:UYVY2X8/640x480]"
> >> + media-ctl -V "\"camif0\":1 [fmt:UYVY2X8/640x480]"
> >> + # Configure pads for OV5640 pipeline
> >> + media-ctl -V "\"ov5640_mipi 1-0040\":0 [fmt:UYVY2X8/640x480]"
> >> + media-ctl -V "\"imx-mipi-csi2\":0 [fmt:UYVY2X8/640x480]"
> >> + media-ctl -V "\"imx-mipi-csi2\":2 [fmt:UYVY2X8/640x480]"
> >> + media-ctl -V "\"ipu1_csi1\":0 [fmt:UYVY2X8/640x480]"
> >> + media-ctl -V "\"ipu1_csi1\":1 [fmt:UYVY2X8/640x480]"
> > [...]
> >> + media-ctl -V "\"camif1\":0 [fmt:UYVY2X8/640x480]"
> > I agree this looks very intuitive, but technically correct for the
> > csi1:1 and camif1:0 pads would be a 32-bit YUV format.
> > (MEDIA_BUS_FMT_YUV8_1X32_PADLO doesn't exist yet).
> >
> > I think it would be better to use the correct format
>
> I'm not sure I follow you here.
The ov5640 sends UYVY2X8 on the wire, so pads "ov5640_mipi 1-0040":0
up to "ipu1_csi1":0 are correct. But the CSI writes 32-bit YUV values
into the SMFC, so the CSI output pad and the IDMAC input pad should have
a YUV8_1X32 format.
Chapter 37.4.2.3 "FCW & FCR - Format converter write and read" in the
IDMAC chapter states that all internal submodules only work on 8-bit per
component formats with four components: YUVA or RGBA.
> > [...]
> > Is this a whole software buffer queue implementation? I thought the
> > whole point of putting the custom mem2mem framework into the capture
> > driver was to use the hardware FSU channel linking?
>
> see below.
>
> > What is the purpose of this if the sink should be triggered by the FSU?
>
> Ok, here is where I need to make an admission.
>
> The only FSU links I have attempted (and which currently have entries
> in the fsu_link_info[] table), are the enc/vf/pp --> IRT links for rotation.
Which are not described as media entity links because the rotation units
do not have separate media entities. So me arguing against handling
mem2mem chaining via media entity links doesn't concern these implicit
links.
> There does not appear to be support in the FSU for linking a write channel
> to the VDIC read channels (8, 9, 10) according to VDI_SRC_SEL field. There
> is support for the direct link from CSI (which I am using), but that's
> not an
> IDMAC channel link.
>
> There is a PRP_SRC_SEL field, with linking from IDMAC (SMFC) channels
> 0..2 (and 3? it's not clear, and not clear whether this includes channel 1).
As I read it, that is 0 and 2 only, no idea why. But since there are
only 2 CSIs, that shouldn't be a problem.
> But I think this links to channel 12, and not to channels 8,9,10 to the
> VDIC.
> Or will it? It's worth experimenting. It would have helped if FSL listed
> which
> IDMAC channels these FSU links correspond to, instead of making us guess
> at it.
I would have assumed that the FSU triggering only works on 1:1 channels
and the VDIC with its three input channels is different. But then
there's the alleged VDOA link to ch8/9/10 ro ch9, depending on
VDI_MOT_SEL.
This makes me more convinced that the CSI -> VDIC link should only
describe the direct path (real-time mode, single field).
> In any event, the docs are not clear enough to implement a real FSU
> link to the VDIC read channels, if it's even possible. And trying to get
> programming help from FSL can be difficult, and no coding examples
> for this link AFAIK.
>
> So I ended resorted to linking to VDIC channels 8,9,10 with a software
> approach, instead of attempting a hardware FSU link.
>
> The EOF interrupt handler for the SMFC channels informs the VDIC
> entity via a v4l2_subdev_ioctl() call that a buffer is available. The
> VDIC then manually kicks off its read channels to bring that buffer
> (and a previous buffer for F(n-1) field) into the VDIC.
>
> There is a small amount of extra overhead going this route compared
> to a FSU hardware link: there is the EOF irq latency (a few usec), and
> the CPU overhead for the VDIC to manually start the read channels,
> which is also a few usec at most (see prepare_vdi_in_buffers() in
> imx-vdic.c). So in total at most ~10 usec of extra overhead (CPU
> use plus irq latency) under normal system load.
That the same low overhead could be reached by linking videobuf2 queues
of different video devices, that would be a lot more flexible.
> Of course, in order to implement this software link, I had to implement
> a straightforward FIFO dma buffer ring. The sink (VDIC) allocates the ring
> at stream on, and the source requests a pointer to this ring in its own
> stream on. Passing buffers from source to sink then follows a
> straightforward
> FIFO queue/done/dequeue/queue model: sink queues buffers to src, src
> grabs queued buffers and makes them active, src signals completed
> buffers to sink, sink dequeues buffers in response, and sink queues
> buffers back when it is finished with them.
Thank you for the explanation.
[...]
> >> +static const u32 power_off_seq[] = {
> >> + IMX_MEDIA_GRP_ID_IC_PP,
> >> + IMX_MEDIA_GRP_ID_IC_PRPVF,
> >> + IMX_MEDIA_GRP_ID_IC_PRPENC,
> >> + IMX_MEDIA_GRP_ID_SMFC,
> >> + IMX_MEDIA_GRP_ID_CSI,
> >> + IMX_MEDIA_GRP_ID_VIDMUX,
> >> + IMX_MEDIA_GRP_ID_SENSOR,
> >> + IMX_MEDIA_GRP_ID_CSI2,
> >> +};
> > This seems somewhat arbitrary. Why is a power sequence needed?
>
> The CSI-2 receiver must be powered up before the sensor, that's the
> only requirement IIRC. The others have no s_power requirement. So I
> can probably change this to power up in the frontend -> backend order
> (IC_PP to sensor). And vice-versa for power off.
Yes, I think that should work (see below).
> > [...]
> >> +/*
> >> + * Turn current pipeline power on/off starting from start_entity.
> >> + * Must be called with mdev->graph_mutex held.
> >> + */
> >> +int imx_media_pipeline_set_power(struct imx_media_dev *imxmd,
> >> + struct media_entity_graph *graph,
> >> + struct media_entity *start_entity, bool on)
> >> +{
> >> + struct media_entity *entity;
> >> + struct v4l2_subdev *sd;
> >> + int i, ret = 0;
> >> + u32 id;
> >> +
> >> + for (i = 0; i < NUM_POWER_ENTITIES; i++) {
> >> + id = on ? power_on_seq[i] : power_off_seq[i];
> >> + entity = find_pipeline_entity(imxmd, graph, start_entity, id);
> >> + if (!entity)
> >> + continue;
> >> +
> >> + sd = media_entity_to_v4l2_subdev(entity);
> >> +
> >> + ret = v4l2_subdev_call(sd, core, s_power, on);
> >> + if (ret && ret != -ENOIOCTLCMD)
> >> + break;
> >> + }
> >> +
> >> + return (ret && ret != -ENOIOCTLCMD) ? ret : 0;
> >> +}
> >> +EXPORT_SYMBOL_GPL(imx_media_pipeline_set_power);
> > This should really be handled by v4l2_pipeline_pm_use.
>
> I thought about this earlier, but v4l2_pipeline_pm_use() seems to be
> doing some other stuff that bothered me, at least that's what I remember.
> I will revisit this.
I have used it with a tc358743 -> mipi-csi2 pipeline, it didn't cause
any problems. It would be better to reuse and, if necessary, fix the
existing infrastructure where available.
> >> +int imx_media_add_internal_subdevs(struct imx_media_dev *imxmd,
> >> + struct imx_media_subdev *csi[4])
> >> +{
> >> + int ret;
> >> +
> >> + /* there must be at least one CSI in first IPU */
> > Why?
>
> Well yeah, imx-media doesn't necessarily need a CSI if things
> like the VDIC or post-processor are being used by an output
> overlay pipeline, for example. I'll fix this.
I haven't even thought that far, but there could be boards with only a
parallel sensor connected to IPU2 CSI1 and IPU1 disabled for power
saving reasons.
regards
Philipp
^ permalink raw reply
* [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range
From: Andreas Färber @ 2017-01-16 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9a1dbb0b-ad3d-7898-3b43-fd8f85892985@baylibre.com>
Am 16.01.2017 um 11:26 schrieb Neil Armstrong:
> On 01/15/2017 04:44 PM, Andreas F?rber wrote:
>> Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt:
>>> it really makes a difference if we write
>>>
>>> memory at 0 {
>>> device_type = "memory";
>>> linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>>> };
>>>
>>> or
>>>
>>> memory at 0 {
>>> device_type = "memory";
>>> reg = <0x0 0x1000000 0x0 0x7f000000>;
>>> };
>>>
>>> The second version leads to failure of the Odroid C2.
>>>
>>> When I looked at /sys/firmware/fdt I saw this difference:
>>>
>>> --- fails
>>> +++ works
>>>
>>> memory at 0 {
>>> - device_type = "memory";
>>> reg = <0x0 0x0 0x0 0x78000000>;
>>> + device_type = "memory";
>>> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>>> };
>>>
>>> I found the following sentence in the NXP forum:
>>> In case you want to overwrite the memory usage passed from u-boot, you
>>> can use "linux,usable-memory".
>>> https://community.nxp.com/thread/382284
>>
>> The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot
>> instead of forcing the creation of unnecessary new .dts files onto
>> everyone due to hardcoded linux,usable-memory properties. In fact, it
>> already reserves 0x1000000, so it seems you are merely using an older
>> U-Boot.
>>
>> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39
>>
>> I would bet that the upper limit is unrelated here.
>>
>> Regards,
>> Andreas
>>
>
> Hi Andreas,
>
> I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
> a lot of u-boot version in the field, and the Odroid-C2 is part of this.
>
> Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel should work using
> any U-boot version even with the one provided by Amlogic on their openlinux distribution channel.
That is not the position of the kernel maintainers though. They
deliberately rely on timers being enabled before entering Linux, which
broke my afboot-stm32 (which I could fix) as well as s5pv210 and vf610
based platforms by F+S (which remain broken to date).
And I documented how to chainload mainline U-Boot from downstream
Amlogic U-Boot, so it is easily fixable on Meson. The only thing missing
is Carlo resubmitting his MMC patches.
A bug somewhere does not justify breaking the whole Meson-gx* .dts
design for everyone, especially not without CC'ing me as the original
creator!
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH V9 0/3] irqchip: qcom: Add IRQ combiner driver
From: Agustin Vega-Frias @ 2017-01-16 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJZ5v0h_v-iER5Fffdoczj4CAhetGYqOfJOhdO561_kNCnsEFg@mail.gmail.com>
Hi Rafael,
On 2017-01-03 16:56, Rafael J. Wysocki wrote:
> On Tue, Jan 3, 2017 at 4:19 PM, Agustin Vega-Frias
> <agustinv@codeaurora.org> wrote:
>> Hi,
>>
>> Is there any more feedback on this beyond Lorenzo's suggestion to drop
>> the conditional check on the first patch?
>> How can we move forward on this series?
>
> Essentially, I need to convince myself that patches [1-2/3] are fine
> which hasn't happened yet.
Pinging again. Do you have any questions that might help with your
review? I have some minor changes I have to make to the driver itself
(patch 3) and I'd like to submit any changes you might want along with
those.
Thanks,
Agustin
>
> Thanks,
> Rafael
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [RFC PATCH] IOMMU: SMMUv2: Support for Extended Stream ID (16 bit)
From: Aleksey Makarov @ 2017-01-16 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <63d66004-bf8c-146d-2af4-b5f035159480@arm.com>
On 01/11/2017 05:15 PM, Robin Murphy wrote:
> On 10/01/17 11:57, Aleksey Makarov wrote:
>> Enable the Extended Stream ID feature when available.
>>
>> This patch on top of series "[PATCH v7 00/19] KVM PCIe/MSI passthrough
>> on ARM/ARM64 and IOVA reserved regions" by Eric Auger allows
>> to passthrough an external PCIe network card on a ThunderX server
>> successfully.
>>
>> Without this patch that card caused a warning like
>>
>> pci 0006:90:00.0: stream ID 0x9000 out of range for SMMU (0x7fff)
>>
>> during boot.
>>
>> Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
>> ---
>> drivers/iommu/arm-smmu.c | 53 +++++++++++++++++++++++++++++++++---------------
>> 1 file changed, 37 insertions(+), 16 deletions(-)
>>
[...]
>> @@ -1761,7 +1772,12 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
>> "\t(IDR0.CTTW overridden by FW configuration)\n");
>>
>> /* Max. number of entries we have for stream matching/indexing */
>> - size = 1 << ((id >> ID0_NUMSIDB_SHIFT) & ID0_NUMSIDB_MASK);
>> + if (smmu->version == ARM_SMMU_V2 && id & ID0_EXIDS) {
>> + smmu->features |= ARM_SMMU_FEAT_EXIDS;
>> + size = (1 << 16);
>
> Unnecessary parentheses.
Thank you
>> + } else {
>> + size = 1 << ((id >> ID0_NUMSIDB_SHIFT) & ID0_NUMSIDB_MASK);
>> + }
>
> Given what the architecture says about the relationship between EXIDS
> and NUMSIDB, I suppose an even shorter version could be:
>
> if (smmu->version == ARM_SMMU_V2 && id & ID0_EXIDS)
> size *= 2;
>
> but I'm not sure that's actually any nicer to read.
I think it is not nicer: the one who reads this needs to know what is the value of NUMSIDB
in the case id & ID0_EXIDS == true; and also this makes the code depend on this, i. e.
on the correct implementation of hardware.
So I would like to leave it as is. If you are not agree, I will change it.
>> smmu->streamid_mask = size - 1;
>> if (id & ID0_SMS) {
>> u32 smr;
>> @@ -1774,20 +1790,25 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
>> return -ENODEV;
>> }
>>
>> - /*
>> - * SMR.ID bits may not be preserved if the corresponding MASK
>> - * bits are set, so check each one separately. We can reject
>> - * masters later if they try to claim IDs outside these masks.
>> - */
>> - smr = smmu->streamid_mask << SMR_ID_SHIFT;
>> - writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
>> - smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
>> - smmu->streamid_mask = smr >> SMR_ID_SHIFT;
>> -
>> - smr = smmu->streamid_mask << SMR_MASK_SHIFT;
>> - writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
>> - smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
>> - smmu->smr_mask_mask = smr >> SMR_MASK_SHIFT;
>> + if (smmu->features & ARM_SMMU_FEAT_EXIDS) {
>> + smmu->smr_mask_mask = smmu->streamid_mask;
>> + } else {
>> + /*
>> + * SMR.ID bits may not be preserved if the corresponding
>> + * MASK bits are set, so check each one separately.
>> + * We can reject masters later if they try to claim IDs
>> + * outside these masks.
>> + */
>> + smr = smmu->streamid_mask << SMR_ID_SHIFT;
>> + writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
>> + smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
>> + smmu->streamid_mask = smr >> SMR_ID_SHIFT;
>> +
>> + smr = smmu->streamid_mask << SMR_MASK_SHIFT;
>> + writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
>> + smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
>> + smmu->smr_mask_mask = smr >> SMR_MASK_SHIFT;
>> + }
>
> This hunk is quite possibly wrong. I don't see any guarantee in the
> architecture that all EXMASK/EXID bits *must* be implemented, and even
> so there's still no harm in the driver determining that experimentally.
> It looks like we need a bit of refactoring such that we move the probing
> of SMR fields to after counting and allocating the SME structures, then
> in the EXIDS case we can explicitly clear the SMEs and poke EXIDENABLE
> inbetween.
I am not quite sure I understand where you are suggesting to poke EXIDENABLE.
I am going to send v2 of the patch, I'd appreciate if you would review that please.
Thank you for review
Aleksey Makarov
^ permalink raw reply
* [PATCH v2] IOMMU: SMMUv2: Support for Extended Stream ID (16 bit)
From: Aleksey Makarov @ 2017-01-16 14:11 UTC (permalink / raw)
To: linux-arm-kernel
Enable the Extended Stream ID feature when available.
This patch on top of series "KVM PCIe/MSI passthrough on ARM/ARM64
and IOVA reserved regions" by Eric Auger [1] allows to passthrough
an external PCIe network card on a ThunderX server successfully.
Without this patch that card caused a warning like
pci 0006:90:00.0: stream ID 0x9000 out of range for SMMU (0x7fff)
during boot.
[1] https://lkml.kernel.org/r/1484127714-3263-1-git-send-email-eric.auger at redhat.com
Signed-off-by: Aleksey Makarov <aleksey.makarov@linaro.org>
---
v2:
- remove unnecessary parentheses (Robin Murphy)
- refactor testing SMR fields to after setting sCR0 as theirs width
depends on sCR0_EXIDENABLE (Robin Murphy)
v1 (rfc):
https://lkml.kernel.org/r/20170110115755.19102-1-aleksey.makarov at linaro.org
drivers/iommu/arm-smmu.c | 67 ++++++++++++++++++++++++++++++++++--------------
1 file changed, 48 insertions(+), 19 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 13d26009b8e0..c33df4083d24 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -24,6 +24,7 @@
* - v7/v8 long-descriptor format
* - Non-secure access to the SMMU
* - Context fault reporting
+ * - Extended Stream ID (16 bit)
*/
#define pr_fmt(fmt) "arm-smmu: " fmt
@@ -87,6 +88,7 @@
#define sCR0_CLIENTPD (1 << 0)
#define sCR0_GFRE (1 << 1)
#define sCR0_GFIE (1 << 2)
+#define sCR0_EXIDENABLE (1 << 3)
#define sCR0_GCFGFRE (1 << 4)
#define sCR0_GCFGFIE (1 << 5)
#define sCR0_USFCFG (1 << 10)
@@ -126,6 +128,7 @@
#define ID0_NUMIRPT_MASK 0xff
#define ID0_NUMSIDB_SHIFT 9
#define ID0_NUMSIDB_MASK 0xf
+#define ID0_EXIDS (1 << 8)
#define ID0_NUMSMRG_SHIFT 0
#define ID0_NUMSMRG_MASK 0xff
@@ -169,6 +172,7 @@
#define ARM_SMMU_GR0_S2CR(n) (0xc00 + ((n) << 2))
#define S2CR_CBNDX_SHIFT 0
#define S2CR_CBNDX_MASK 0xff
+#define S2CR_EXIDVALID (1 << 10)
#define S2CR_TYPE_SHIFT 16
#define S2CR_TYPE_MASK 0x3
enum arm_smmu_s2cr_type {
@@ -354,6 +358,7 @@ struct arm_smmu_device {
#define ARM_SMMU_FEAT_FMT_AARCH64_64K (1 << 9)
#define ARM_SMMU_FEAT_FMT_AARCH32_L (1 << 10)
#define ARM_SMMU_FEAT_FMT_AARCH32_S (1 << 11)
+#define ARM_SMMU_FEAT_EXIDS (1 << 12)
u32 features;
#define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0)
@@ -1051,7 +1056,7 @@ static void arm_smmu_write_smr(struct arm_smmu_device *smmu, int idx)
struct arm_smmu_smr *smr = smmu->smrs + idx;
u32 reg = smr->id << SMR_ID_SHIFT | smr->mask << SMR_MASK_SHIFT;
- if (smr->valid)
+ if (!(smmu->features & ARM_SMMU_FEAT_EXIDS) && smr->valid)
reg |= SMR_VALID;
writel_relaxed(reg, ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_SMR(idx));
}
@@ -1063,6 +1068,9 @@ static void arm_smmu_write_s2cr(struct arm_smmu_device *smmu, int idx)
(s2cr->cbndx & S2CR_CBNDX_MASK) << S2CR_CBNDX_SHIFT |
(s2cr->privcfg & S2CR_PRIVCFG_MASK) << S2CR_PRIVCFG_SHIFT;
+ if (smmu->features & ARM_SMMU_FEAT_EXIDS && smmu->smrs &&
+ smmu->smrs[idx].valid)
+ reg |= S2CR_EXIDVALID;
writel_relaxed(reg, ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_S2CR(idx));
}
@@ -1073,6 +1081,35 @@ static void arm_smmu_write_sme(struct arm_smmu_device *smmu, int idx)
arm_smmu_write_smr(smmu, idx);
}
+/*
+ * The width of SMR's mask field depends on sCR0_EXIDENABLE, so this function
+ * should be called after sCR0 is written.
+ */
+static void arm_smmu_test_smr_masks(struct arm_smmu_device *smmu)
+{
+ void __iomem *gr0_base = ARM_SMMU_GR0(smmu);
+ u32 smr;
+
+ if (!smmu->smrs)
+ return;
+
+ /*
+ * SMR.ID bits may not be preserved if the corresponding
+ * MASK bits are set, so check each one separately.
+ * We can reject masters later if they try to claim IDs
+ * outside these masks.
+ */
+ smr = smmu->streamid_mask << SMR_ID_SHIFT;
+ writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
+ smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
+ smmu->streamid_mask = smr >> SMR_ID_SHIFT;
+
+ smr = smmu->streamid_mask << SMR_MASK_SHIFT;
+ writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
+ smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
+ smmu->smr_mask_mask = smr >> SMR_MASK_SHIFT;
+}
+
static int arm_smmu_find_sme(struct arm_smmu_device *smmu, u16 id, u16 mask)
{
struct arm_smmu_smr *smrs = smmu->smrs;
@@ -1674,6 +1711,9 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu)
if (smmu->features & ARM_SMMU_FEAT_VMID16)
reg |= sCR0_VMID16EN;
+ if (smmu->features & ARM_SMMU_FEAT_EXIDS)
+ reg |= sCR0_EXIDENABLE;
+
/* Push the button */
__arm_smmu_tlb_sync(smmu);
writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
@@ -1761,11 +1801,14 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
"\t(IDR0.CTTW overridden by FW configuration)\n");
/* Max. number of entries we have for stream matching/indexing */
- size = 1 << ((id >> ID0_NUMSIDB_SHIFT) & ID0_NUMSIDB_MASK);
+ if (smmu->version == ARM_SMMU_V2 && id & ID0_EXIDS) {
+ smmu->features |= ARM_SMMU_FEAT_EXIDS;
+ size = 1 << 16;
+ } else {
+ size = 1 << ((id >> ID0_NUMSIDB_SHIFT) & ID0_NUMSIDB_MASK);
+ }
smmu->streamid_mask = size - 1;
if (id & ID0_SMS) {
- u32 smr;
-
smmu->features |= ARM_SMMU_FEAT_STREAM_MATCH;
size = (id >> ID0_NUMSMRG_SHIFT) & ID0_NUMSMRG_MASK;
if (size == 0) {
@@ -1774,21 +1817,6 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
return -ENODEV;
}
- /*
- * SMR.ID bits may not be preserved if the corresponding MASK
- * bits are set, so check each one separately. We can reject
- * masters later if they try to claim IDs outside these masks.
- */
- smr = smmu->streamid_mask << SMR_ID_SHIFT;
- writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
- smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
- smmu->streamid_mask = smr >> SMR_ID_SHIFT;
-
- smr = smmu->streamid_mask << SMR_MASK_SHIFT;
- writel_relaxed(smr, gr0_base + ARM_SMMU_GR0_SMR(0));
- smr = readl_relaxed(gr0_base + ARM_SMMU_GR0_SMR(0));
- smmu->smr_mask_mask = smr >> SMR_MASK_SHIFT;
-
/* Zero-initialised to mark as invalid */
smmu->smrs = devm_kcalloc(smmu->dev, size, sizeof(*smmu->smrs),
GFP_KERNEL);
@@ -2120,6 +2148,7 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
iommu_register_instance(dev->fwnode, &arm_smmu_ops);
platform_set_drvdata(pdev, smmu);
arm_smmu_device_reset(smmu);
+ arm_smmu_test_smr_masks(smmu);
/* Oh, for a proper bus abstraction */
if (!iommu_present(&platform_bus_type))
--
2.11.0
^ permalink raw reply related
* [PATCH 2/3] KVM: arm64: Access CNTHCTL_EL2 bit fields correctly on VHE systems
From: Marc Zyngier @ 2017-01-16 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <61f7dbf1-e20d-e9e4-950c-6a224619cf31@arm.com>
On 16/01/17 13:30, Marc Zyngier wrote:
> On 13/01/17 14:56, Suzuki K Poulose wrote:
>> On 13/01/17 13:30, Marc Zyngier wrote:
>>> [+ Suzuki, who wrote the whole cpus_have_const_cap thing]
>>>
>
> [...]
>
>>> But maybe we should have have some stronger guarantees that we'll
>>> always get things inlined, and that the "const" side is enforced:
>>
>> Agreed.
>>
>>>
>>> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
>>> index b4989df..4710469 100644
>>> --- a/arch/arm64/include/asm/cpufeature.h
>>> +++ b/arch/arm64/include/asm/cpufeature.h
>>> @@ -105,10 +105,11 @@ static inline bool cpu_have_feature(unsigned int num)
>>> }
>>>
>>> /* System capability check for constant caps */
>>> -static inline bool cpus_have_const_cap(int num)
>>> +static __always_inline bool cpus_have_const_cap(int num)
>>
>> I think we should have the above change and make it inline always.
>>
>>> {
>>> - if (num >= ARM64_NCAPS)
>>> - return false;
>>> + BUILD_BUG_ON(!__builtin_constant_p(num));
>>
>> This is not needed, as the compilation would fail if num is not a constant with
>> static key code.
I also just checked this, and it doesn't fail if the compiler doesn't
directly supports jump labels (we then fallback to the static key being
a standard memory access).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH V9 0/3] irqchip: qcom: Add IRQ combiner driver
From: Marc Zyngier @ 2017-01-16 14:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <266105963441d1cdddeaf40c4b78c239@codeaurora.org>
On 16/01/17 14:07, Agustin Vega-Frias wrote:
> Hi Rafael,
>
> On 2017-01-03 16:56, Rafael J. Wysocki wrote:
>> On Tue, Jan 3, 2017 at 4:19 PM, Agustin Vega-Frias
>> <agustinv@codeaurora.org> wrote:
>>> Hi,
>>>
>>> Is there any more feedback on this beyond Lorenzo's suggestion to drop
>>> the conditional check on the first patch?
>>> How can we move forward on this series?
>>
>> Essentially, I need to convince myself that patches [1-2/3] are fine
>> which hasn't happened yet.
>
> Pinging again. Do you have any questions that might help with your
> review? I have some minor changes I have to make to the driver itself
> (patch 3) and I'd like to submit any changes you might want along with
> those.
I'd like to add that these two initial patches are now a prerequisite
for Hanjun's series, so it'd be good to have an idea of where we're
going on that front.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Michael S. Tsirkin @ 2017-01-16 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116104028.GA1510@arm.com>
On Mon, Jan 16, 2017 at 10:40:28AM +0000, Will Deacon wrote:
> On Fri, Jan 13, 2017 at 08:23:35PM +0200, Michael S. Tsirkin wrote:
> > On Fri, Jan 13, 2017 at 05:21:54PM +0000, Will Deacon wrote:
> > > On Fri, Jan 13, 2017 at 06:46:32PM +0200, Michael S. Tsirkin wrote:
> > > > On Fri, Jan 13, 2017 at 09:25:22AM +0000, Will Deacon wrote:
> > > > > On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> > > > > > I'd rather people didn't use SMMU with legacy devices.
> > > > >
> > > > > I'm afraid we've been doing that for two years and the model already
> > > > > exists in a mature state, being actively used for development and
> > > > > validation by ARM and our partners. One of the big things its used for
> > > > > is to develop SMMU and GIC (our interrupt controller) code with PCI, so
> > > > > dropping the SMMU from the picture isn't an option.
> > > >
> > > > Oh so this fixes a regression? This is something I didn't realize.
> > >
> > > Yes, thanks. The regression came about because we implemented SMMU-backed
> > > DMA ops and only then was it apparent that the virtio stuff was bypassing
> > > even with translation enabled (because it wasn't using the DMA API).
> >
> > Could you point out a commit ID?
>
> There has been a fair amount of work in this area recently, but you're
> probably after something like 876945dbf649 ("arm64: Hook up IOMMU dma_ops")
> as the culprit, which is the point at which we started to swizzle DMA
> ops for devices upstream of an SMMU automatically.
>
> > > > A "Fixes:" tag can't hurt here. I then wonder
> > > > might DMA ops ever use a DMA address which isn't a physical address
> > > > from QEMU point of view? If that happens, this hack breaks
> > > > because in legacy mode QEMU still uses the GPA.
> > >
> > > If QEMU doesn't advertise an SMMU, then it will work fine with the GPA,
> > > because we won't swizzle the DMA ops for the master device. If QEMU does
> > > advertise an SMMU, then we'll allocate DMA addresses to fit within the
> > > the intersection of the SMMU aperture and device's DMA mask.
> >
> >
> > Right but doesn't just poking from qemu into phys addresses work
> > anymore? It used to ...
>
> Provided that there's no SMMU, then it will continue to work. and my
> understanding (from talking to Peter Maydell) is that qemu doesn't model
> an SMMU for ARM-based machines.
>
> Will
So how come people report failures due to presence of SMMU?
Using some other hypervisor?
--
MST
^ permalink raw reply
* [PATCH 2/3] KVM: arm64: Access CNTHCTL_EL2 bit fields correctly on VHE systems
From: Suzuki K Poulose @ 2017-01-16 14:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c82f705e-c32a-15b1-92f6-d7694f91fe0e@arm.com>
On 16/01/17 14:11, Marc Zyngier wrote:
> On 16/01/17 13:30, Marc Zyngier wrote:
>> On 13/01/17 14:56, Suzuki K Poulose wrote:
>>> On 13/01/17 13:30, Marc Zyngier wrote:
>>>> [+ Suzuki, who wrote the whole cpus_have_const_cap thing]
>>>>
>>
>> [...]
>>
>>>> But maybe we should have have some stronger guarantees that we'll
>>>> always get things inlined, and that the "const" side is enforced:
>>>
>>> Agreed.
>>>
>>>>
>>>> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
>>>> index b4989df..4710469 100644
>>>> --- a/arch/arm64/include/asm/cpufeature.h
>>>> +++ b/arch/arm64/include/asm/cpufeature.h
>>>> @@ -105,10 +105,11 @@ static inline bool cpu_have_feature(unsigned int num)
>>>> }
>>>>
>>>> /* System capability check for constant caps */
>>>> -static inline bool cpus_have_const_cap(int num)
>>>> +static __always_inline bool cpus_have_const_cap(int num)
>>>
>>> I think we should have the above change and make it inline always.
>>>
>>>> {
>>>> - if (num >= ARM64_NCAPS)
>>>> - return false;
>>>> + BUILD_BUG_ON(!__builtin_constant_p(num));
>>>
>>> This is not needed, as the compilation would fail if num is not a constant with
>>> static key code.
>
> I also just checked this, and it doesn't fail if the compiler doesn't
> directly supports jump labels (we then fallback to the static key being
> a standard memory access).
Ah, I missed that part of the story. Sorry about that. Please go ahead with the
changes. I had a similar check in my first version and was dropped later with a
similar review comment. We hadn't considered older tool chain.
Suzuki
^ permalink raw reply
* [PATCH v2 2/2] vring: Force use of DMA API for ARM-based systems
From: Will Deacon @ 2017-01-16 14:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116161639-mutt-send-email-mst@kernel.org>
On Mon, Jan 16, 2017 at 04:18:03PM +0200, Michael S. Tsirkin wrote:
> On Mon, Jan 16, 2017 at 10:40:28AM +0000, Will Deacon wrote:
> > On Fri, Jan 13, 2017 at 08:23:35PM +0200, Michael S. Tsirkin wrote:
> > > On Fri, Jan 13, 2017 at 05:21:54PM +0000, Will Deacon wrote:
> > > > On Fri, Jan 13, 2017 at 06:46:32PM +0200, Michael S. Tsirkin wrote:
> > > > > On Fri, Jan 13, 2017 at 09:25:22AM +0000, Will Deacon wrote:
> > > > > > On Fri, Jan 13, 2017 at 12:12:56AM +0200, Michael S. Tsirkin wrote:
> > > > > > > I'd rather people didn't use SMMU with legacy devices.
> > > > > >
> > > > > > I'm afraid we've been doing that for two years and the model already
> > > > > > exists in a mature state, being actively used for development and
> > > > > > validation by ARM and our partners. One of the big things its used for
> > > > > > is to develop SMMU and GIC (our interrupt controller) code with PCI, so
> > > > > > dropping the SMMU from the picture isn't an option.
> > > > >
> > > > > Oh so this fixes a regression? This is something I didn't realize.
> > > >
> > > > Yes, thanks. The regression came about because we implemented SMMU-backed
> > > > DMA ops and only then was it apparent that the virtio stuff was bypassing
> > > > even with translation enabled (because it wasn't using the DMA API).
> > >
> > > Could you point out a commit ID?
> >
> > There has been a fair amount of work in this area recently, but you're
> > probably after something like 876945dbf649 ("arm64: Hook up IOMMU dma_ops")
> > as the culprit, which is the point at which we started to swizzle DMA
> > ops for devices upstream of an SMMU automatically.
> >
> > > > > A "Fixes:" tag can't hurt here. I then wonder
> > > > > might DMA ops ever use a DMA address which isn't a physical address
> > > > > from QEMU point of view? If that happens, this hack breaks
> > > > > because in legacy mode QEMU still uses the GPA.
> > > >
> > > > If QEMU doesn't advertise an SMMU, then it will work fine with the GPA,
> > > > because we won't swizzle the DMA ops for the master device. If QEMU does
> > > > advertise an SMMU, then we'll allocate DMA addresses to fit within the
> > > > the intersection of the SMMU aperture and device's DMA mask.
> > >
> > >
> > > Right but doesn't just poking from qemu into phys addresses work
> > > anymore? It used to ...
> >
> > Provided that there's no SMMU, then it will continue to work. and my
> > understanding (from talking to Peter Maydell) is that qemu doesn't model
> > an SMMU for ARM-based machines.
> >
>
> So how come people report failures due to presence of SMMU?
> Using some other hypervisor?
The failures are reported on the ARM fastmodel (a complete system
emulation that runs on an x86 box), where an SMMU *is* present
downstream of the virtio-pci masters. There's no qemu involved there.
Will
^ permalink raw reply
* [PATCH v7 15/15] irqchip: mbigen: Add ACPI support
From: Hanjun Guo @ 2017-01-16 14:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170116113804.GB23703@red-moon>
Hi Lorenzo,
On 2017/1/16 19:38, Lorenzo Pieralisi wrote:
> On Sat, Jan 14, 2017 at 10:56:54AM +0800, Hanjun Guo wrote:
>> Hi Lorenzo,
>>
>> On 2017/1/13 18:21, Lorenzo Pieralisi wrote:
>>> On Wed, Jan 11, 2017 at 11:06:39PM +0800, Hanjun Guo wrote:
>>>> With the preparation of platform msi support and interrupt producer
>>>> in DSDT, we can add mbigen ACPI support now.
>>>>
>>>> We are using _PRS methd to indicate number of irq pins instead
>>>> of num_pins in DT to avoid _DSD usage in this case.
>>>>
>>>> For mbi-gen,
>>>> Device(MBI0) {
>>>> Name(_HID, "HISI0152")
>>>> Name(_UID, Zero)
>>>> Name(_CRS, ResourceTemplate() {
>>>> Memory32Fixed(ReadWrite, 0xa0080000, 0x10000)
>>>> })
>>>>
>>>> Name (_PRS, ResourceTemplate() {
>>>> Interrupt(ResourceProducer,...) {12,14,....}
>>> I still do not understand why you are using _PRS for this, I think
>>> the MBIgen configuration is static and if it is so the Interrupt
>>> resource should be part of the _CRS unless there is something I am
>>> missing here.
>> Sorry for not clear in the commit message. MBIgen is an interrupt producer
>> which produces irq resource to devices connecting to it, and MBIgen itself
>> don't consume wired interrupts.
> That's why you mark it as ResourceProducer, but that's not a reason to
> put it in the _PRS instead of _CRS.
If using _CRS for the interrupt resource, the irq number represented will be mapped
(i.e acpi_register_gsi()), then will conflict with the irq number of devices consuming
it (mbigen is producing the interrupts), but I agree with you that let's ask Rafael's
point of view.
>
> IIUC _PRS is there to provide a way to define the possible resource
> settings of a _configurable_ device (ie programmable) so that the actual
> resource value you would programme with a call to its _SRS is sane (ie
> the OS has a way, through the _PRS, to detect what possible resource
> settings are available for the device).
>
> I think Rafael has more insights into how the _PRS is used on x86
> systems so I would ask his point of view here before merrily merging
> this code.
OK, Rafael is traveling now, hope he will have time to take a look.
How about updating this patch set then sending a new version for review
with this patch unchanged? if Rafael have comments on this one, I will
send a single updated one for this patch (if no other changes).
>
>> Also devices connecting MBIgen may not consume all the interrupts produced
>> by MBIgen, for example, MBIgen may produce 128 interrupts but only half of
>> them are currently used, so _PRS here means "provide interrupt resources
>> may consumed by devices connecting to it".
> See above.
Thanks
Hanjun
^ permalink raw reply
* [GIT PULL] Amlogic fixes for v4.10-rc4
From: Andreas Färber @ 2017-01-16 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <m2inpi6d09.fsf@baylibre.com>
Am 13.01.2017 um 19:17 schrieb Kevin Hilman:
> ----------------------------------------------------------------
> Amlogic fixes for v4.10-rc4
> - odroid-c2: disable DVFS to avoid crashes due to broken SCPI
> - fix misc. crashes by adding known reserved memory regions
>
> ----------------------------------------------------------------
> Neil Armstrong (2):
> ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
> ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
Objection against the latter patch introducing widespread usage of
hardcoded linux,usable-memory properties - please review closely before
considering to merge.
Thanks,
Andreas
>
> arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 5 -----
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 12 ++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts | 6 +++++-
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 10 +++++++++-
> arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 9 +++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p201.dts | 9 +++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 5 -----
> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts | 6 +++++-
> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts | 6 +++++-
> arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts | 6 +++++-
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts | 6 +++++-
> arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts | 9 +++++++++
> arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dts | 9 +++++++++
> arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts | 6 +++++-
> arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 6 +++++-
> arch/arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 9 +++++++++
> arch/arm64/boot/dts/amlogic/meson-gxm-s912-q201.dts | 9 +++++++++
> 18 files changed, 111 insertions(+), 19 deletions(-)
>
> _______________________________________________
> linux-amlogic mailing list
> linux-amlogic at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-amlogic
>
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH v3 2/5] arm64: Work around Falkor erratum 1003
From: Christopher Covington @ 2017-01-16 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170111184555.GF29247@leverpostej>
Hi Mark,
On 01/11/2017 01:45 PM, Mark Rutland wrote:
> On Wed, Jan 11, 2017 at 12:40:42PM -0600, Timur Tabi wrote:
>> On 01/11/2017 12:37 PM, Mark Rutland wrote:
>>> The name, as it is, is perfectly descriptive.
>>>
>>> Let's not sacrifice legibility over a non-issue.
>>
>> I don't want to kick a dead horse or anything, but changing it to
>> QCOM_FLKR_ERRATUM_1003 would eliminate all the spacing problems
>> without sacrificing anything.
>
> The CPU is called "Falkor", not "FLKR", and we're not coming up with an
> ACPI table name...
>
> The ARM Ltd. erratum numbers are global to all parts, so we don't
> include the part name. Is the 1003 erratum number specific to Falkor?
>
> If it's global, you could use QCOM_ERRATUM_1003 instead.
E1003 is specific to Falkor, and hopefully just its first major revision.
Qualcomm Technology's first/previous generation ARMv8 custom
microarchitecture used errata numbers below 1000. I am not aware of
global coordination in the numbering, unfortunately.
> Otherwise, QCOM_FALKOR_ERRATUM_1003 is preferable.
Thanks,
Cov
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
^ 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