* [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?
From: Arnd Bergmann @ 2017-04-20 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5jLPRYi+HK=07Zndc8szEKD4mZCqaHJFnHmmoYr7tA1xPw@mail.gmail.com>
On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook <keescook@chromium.org> wrote:
> Was there a conclusion to this discussion? I didn't see anything
> definitive in the thread...
No definite answer, no. My personal view now is that we should probably
merge the patches I sent, to help those that for one reason or another
use one of those ancient toolchains, but we should not go actively looking
for more problems with those compilers.
> On Fri, Dec 16, 2016 at 3:14 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> [Fixed linux-arm-kernel mailing list address, sorry for the duplicate,
>> I'm not reposting all the ugly patches though, unless someone really
>> wants them, https://lkml.org/lkml/2016/12/16/174 has a copy]
>>
>> On Friday, December 16, 2016 11:56:21 AM CET Arnd Bergmann wrote:
>>> I had some fun doing build testing with older gcc versions, building
>>> every release from 4.0 through 7.0 and running that on my randconfig
>>> setup to see what comes out.
>>>
>>> First of all, gcc-4.9 and higher is basically warning-free everywhere,
>>> although gcc-7 introduces some interesting new warnings (I have started
>>> doing patches for those as well). gcc-4.8 is probably good, too, and
>>> gcc-4.6 and 4.7 at least don't produce build failures in general, though
>>> the level of false-positive warnings increases (we could decide to turn
>>> those off for older compilers for build test purposes).
>>>
>>> In gcc-4.5 and below, dead code elimination is not as good as later,
>>> causing a couple of link errors, and some of them have no good workaround
>>> (see patch 1). It would be nice to declare that version too old, but
>>> several older distros that are still in wide use ship with compilers
>>> earlier than 4.6:
>>>
>>> RHEL6: gcc-4.4
>
> This appears to have support until July 31, 2018. (Though it's using a
> 2.6 kernel.)
>
>>> Debian 6: gcc-4.4
>
> This went fully unsupported on Feb 29, 2016.
>
>>> Ubuntu 10.04: gcc-4.4
>
> This went fully unsupported on Apr 30, 2015.
>
>>> SLES11: gcc-4.3
>
> General support ends Mar 31 2019, fully unsupported 31 Mar 2022. (And
> like RHEL6 is using a 2.6 kernel.)
Thanks for looking these up. This means we need to consider how important
build testing on SLES11 is to us in the long run. The most important scenario
I can think of for anyone would be someone that maintains an embedded
system with an x86 CPU and uses a SLES11 setup to maintain their
own distro.
In this case you typically don't want to modify your environment, but
one might want to upgrade the target kernel, and would suffer if
we break that.
>>>
>>> I have not checked in detail which version is required for
>>> each of the above.
>>>
>>> Specifically on ARM, going further makes things rather useless especially
>>> for build testing: with gcc-4.2, we lose support for ARMv7, EABI, and
>>> effectively ARMv6 (as it relies on EABI for building reliably). Also,
>>> the number of false-positive build warnings is so high that it is useless
>>> for finding actual bugs from the warnings.
>>>
>>> See the replies to this mail for 13 patches I needed to work around
>>> issues for each of the releases before 4.6. I have also submitted
>>> some separate patches for issues that I considered actual bugs
>>> uncovered by the older compilers and that should be applied regardless.
>>>
>>> The original gcc-4.3 release was in early 2008. If we decide to still
>>> support that, we probably want the first 10 quirks in this series,
>>> while gcc-4.6 (released in 2011) requires none of them.
>
> I'd be in support of raising the minimum to gcc 4.6. (I'd actually
> prefer 4.7, just to avoid some 4.6 packaging issues, and for better
> gcc plugin support.)
>
> I'm curious what gcc 4.6 binaries are common in the wild besides
> old-stable Debian (unsupported in maybe a year from now?) and 12.04
> Ubuntu (going fully unsupported in 2 weeks). It looks like 4.6 was
> used only in Fedora 15 and 16 (both EOL).
I think we are better off defining two versions: One that we know
a lot of people care about, and we actively try to make that work
well in all configurations (e.g. 4.6, 4.7 or 4.8), fixing all warnings
we run into, and an older version that we try not to break
intentionally (e.g. 3.4, 4.1 or 4.3) but that we only fix when
someone actually runs into a problem they can't work around
by upgrading to a more modern compiler.
Arnd
^ permalink raw reply
* [PATCH] [RFC] gpu: host1x: shut up warning about DMA API misuse
From: Mikko Perttunen @ 2017-04-20 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a1Xs5XjQ+cPPUEtBE7kC6hs_6ZKKs1kHd608kaO70f6Fg@mail.gmail.com>
On 20.04.2017 13:02, Arnd Bergmann wrote:
> On Thu, Apr 20, 2017 at 11:44 AM, Mikko Perttunen <cyndis@kapsi.fi> wrote:
>> On 20.04.2017 11:25, Arnd Bergmann wrote:
>>> On Thu, Apr 20, 2017 at 9:02 AM, Mikko Perttunen <cyndis@kapsi.fi> wrote:
>>>> On 19.04.2017 21:24, Arnd Bergmann wrote:
>>>
>>> I don't think this can be a per-platform policy.
>>
>>
>> Yeah, now that we are using the ARM SMMU on T186 onwards it's more difficult
>> than when we were using the Tegra SMMU, so we'll probably have to change
>> that.
>>
>> The goal of the current code is to allocate memory from the CMA, so one
>> option would be to change it to use dma_alloc_from_contiguous. That way we
>> wouldn't get the double IOMMU mapping, which would be nice.
>
> Right, also we shouldn't define what a particular API does based on
> which platform you run on.
Indeed.
>
>> The goal of the current code is to allocate memory from the CMA, so one
>> option would be to change it to use dma_alloc_from_contiguous. That way
>> we wouldn't get the double IOMMU mapping, which would be nice.
>
> dma_alloc_from_contiguous() is intentionally not exported to drivers,
> and it would result in a page that is not mapped into your kernel
> address space.
Ah, sorry, didn't notice that while looking.
>
> This is probably not the only driver that has this issue, so maybe a
> better approach would be to fill the API gap and introduce an IOMMU
> API function that takes a domain/iova/length tuple as its argument
> and allocates coherent or WC memory that it maps into that address?
There is definitely space for some API improvement in the whole IOMMU
domain memory allocation space. I would prefer keeping the IOMMU mapping
and memory allocation separate, though, since otherwise we couldn't map
the same physical memory into multiple domains (or have some memory that
is temporarily not mapped into any.)
The issue seems to be non-trivial, so I'm fine with your RFC patch - it
solves the issue and the double domain mapping thing is not a problem
currently as we don't yet support IOMMU on T186. By the time we do
support it I hope we'll have the new API or whatever replacement in place.
>
> Arnd
>
Thanks,
Mikko
^ permalink raw reply
* [PATCH] [RFC] gpu: host1x: shut up warning about DMA API misuse
From: Arnd Bergmann @ 2017-04-20 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420094932.GM17774@n2100.armlinux.org.uk>
On Thu, Apr 20, 2017 at 11:49 AM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Thu, Apr 20, 2017 at 10:25:01AM +0200, Arnd Bergmann wrote:
>> On Thu, Apr 20, 2017 at 9:02 AM, Mikko Perttunen <cyndis@kapsi.fi> wrote:
>> > I think we have a "policy" on Tegra that the DMA API will never allocate
>> > using the IOMMU (Thierry can elaborate on this), which is why I wrote the
>> > code with that assumption. Essentially, we have made the DMA API into the
>> > API that allocates CPU-visible memory.
>>
>> I don't think this can be a per-platform policy.
>>
>> > Considering that, I'm wondering if we can just have a temporary local
>> > dma_addr_t and then cast that to phys_addr_t, combined with a good comment?
>>
>> That was my first approach, and it does address the warning, but
>> I did not send it because it still felt too wrong.
>
> Sounds to me like the warning is justified - it's saying that there's
> something not right here which could be a problem.
Absolutely.
> So I'd say, don't
> fix the warning, it's doing its job, highlighting a potential problem
> with the code.
>
> (Consider hiding the warning and then running on a platform where the
> assumptions are broken.)
The problem is that I'm probably the only one who ever sees that
warning since you don't see it in any defconfig builds that all have
the same width for dma_addr_t and phys_addr_t.
The other alternative would be to ask for the patch that introduced
the warning to get reverted before it makes it into v4.12, if we can't
come up with a proper way to do this.
Arnd
^ permalink raw reply
* [PATCH] [RFC] gpu: host1x: shut up warning about DMA API misuse
From: Arnd Bergmann @ 2017-04-20 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <46945c47-2e4e-270d-b551-b207c538e5cb@kapsi.fi>
On Thu, Apr 20, 2017 at 11:44 AM, Mikko Perttunen <cyndis@kapsi.fi> wrote:
> On 20.04.2017 11:25, Arnd Bergmann wrote:
>> On Thu, Apr 20, 2017 at 9:02 AM, Mikko Perttunen <cyndis@kapsi.fi> wrote:
>>> On 19.04.2017 21:24, Arnd Bergmann wrote:
>>
>> I don't think this can be a per-platform policy.
>
>
> Yeah, now that we are using the ARM SMMU on T186 onwards it's more difficult
> than when we were using the Tegra SMMU, so we'll probably have to change
> that.
>
> The goal of the current code is to allocate memory from the CMA, so one
> option would be to change it to use dma_alloc_from_contiguous. That way we
> wouldn't get the double IOMMU mapping, which would be nice.
Right, also we shouldn't define what a particular API does based on
which platform you run on.
> The goal of the current code is to allocate memory from the CMA, so one
> option would be to change it to use dma_alloc_from_contiguous. That way
> we wouldn't get the double IOMMU mapping, which would be nice.
dma_alloc_from_contiguous() is intentionally not exported to drivers,
and it would result in a page that is not mapped into your kernel
address space.
This is probably not the only driver that has this issue, so maybe a
better approach would be to fill the API gap and introduce an IOMMU
API function that takes a domain/iova/length tuple as its argument
and allocates coherent or WC memory that it maps into that address?
Arnd
^ permalink raw reply
* [PATCH] [RFC] gpu: host1x: shut up warning about DMA API misuse
From: Russell King - ARM Linux @ 2017-04-20 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a3JJrA_4Zur47ngWmR7VeKBopJLNZCaqOPzzmnFoV3=Ew@mail.gmail.com>
On Thu, Apr 20, 2017 at 10:25:01AM +0200, Arnd Bergmann wrote:
> On Thu, Apr 20, 2017 at 9:02 AM, Mikko Perttunen <cyndis@kapsi.fi> wrote:
> > I think we have a "policy" on Tegra that the DMA API will never allocate
> > using the IOMMU (Thierry can elaborate on this), which is why I wrote the
> > code with that assumption. Essentially, we have made the DMA API into the
> > API that allocates CPU-visible memory.
>
> I don't think this can be a per-platform policy.
>
> > Considering that, I'm wondering if we can just have a temporary local
> > dma_addr_t and then cast that to phys_addr_t, combined with a good comment?
>
> That was my first approach, and it does address the warning, but
> I did not send it because it still felt too wrong.
Sounds to me like the warning is justified - it's saying that there's
something not right here which could be a problem. So I'd say, don't
fix the warning, it's doing its job, highlighting a potential problem
with the code.
(Consider hiding the warning and then running on a platform where the
assumptions are broken.)
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] [RFC] gpu: host1x: shut up warning about DMA API misuse
From: Mikko Perttunen @ 2017-04-20 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a3JJrA_4Zur47ngWmR7VeKBopJLNZCaqOPzzmnFoV3=Ew@mail.gmail.com>
On 20.04.2017 11:25, Arnd Bergmann wrote:
> On Thu, Apr 20, 2017 at 9:02 AM, Mikko Perttunen <cyndis@kapsi.fi> wrote:
>> On 19.04.2017 21:24, Arnd Bergmann wrote:
>>>
>>> When dma_addr_t and phys_addr_t are not the same size, we get a warning
>>> from the dma_alloc_wc function:
>>>
>>> drivers/gpu/host1x/cdma.c: In function 'host1x_pushbuffer_init':
>>> drivers/gpu/host1x/cdma.c:94:48: error: passing argument 3 of
>>> 'dma_alloc_wc' from incompatible pointer type
>>> [-Werror=incompatible-pointer-types]
>>> pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
>>> ^
>>> In file included from drivers/gpu/host1x/cdma.c:22:0:
>>> include/linux/dma-mapping.h:761:37: note: expected 'dma_addr_t * {aka long
>>> long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned
>>> int *}'
>>> static noinline_if_stackbloat void *dma_alloc_wc(struct device *dev,
>>> size_t size,
>>> ^~~~~~~~~~~~
>>> drivers/gpu/host1x/cdma.c:113:48: error: passing argument 3 of
>>> 'dma_alloc_wc' from incompatible pointer type
>>> [-Werror=incompatible-pointer-types]
>>> pb->mapped = dma_alloc_wc(host1x->dev, size, &pb->phys,
>>> ^
>>> In file included from drivers/gpu/host1x/cdma.c:22:0:
>>> include/linux/dma-mapping.h:761:37: note: expected 'dma_addr_t * {aka long
>>> long unsigned int *}' but argument is of type 'phys_addr_t * {aka unsigned
>>> int *}'
>>> static noinline_if_stackbloat void *dma_alloc_wc(struct device *dev,
>>> size_t size,
>>> ^~~~~~~~~~~~
>>>
>>> The problem here is that dma_alloc_wc() returns a pointer to a dma_addr_t
>>> that may already be translated by an IOMMU, but the driver passes this
>>> into iommu_map() as a physical address. This works by accident only when
>>> the IOMMU does not get registered with the DMA API and there is a 1:1
>>> mapping between physical addresses as seen by the CPU and the device.
>>>
>>> The fundamental problem here is the lack of a generic API to do what the
>>> driver wants: allocating CPU-visible memory for use by a device through
>>> user-defined IOMMU settings. Neither the dma-mapping API nor the IOMMU
>>> API can do this by itself, and combining the two is not well-defined.
>>>
>>> This patch addresses the type mismatch by adding a third pointer into the
>>> push_buffer structure: in addition to the address as seen from the CPU
>>> and the address inside of the local IOMMU domain, the pb->alloc pointer
>>> is the token returned by dma_alloc_wc(), and this is what we later need
>>> to pass into dma_free_wc().
>>>
>>> The address we pass into iommu_map() however is the physical address
>>> computed from virt_to_phys(), assuming that the pointer we have here
>>> is part of the linear mapping (which is also questionable, e.g. when we
>>> have a non-coherent device on ARM32 this may be false). Also, when
>>> the DMA API uses the IOMMU to allocate the pointer for the default
>>> domain, we end up with two IOMMU mappings for the same physical address.
>>>
>>
>> I think we have a "policy" on Tegra that the DMA API will never allocate
>> using the IOMMU (Thierry can elaborate on this), which is why I wrote the
>> code with that assumption. Essentially, we have made the DMA API into the
>> API that allocates CPU-visible memory.
>
> I don't think this can be a per-platform policy.
Yeah, now that we are using the ARM SMMU on T186 onwards it's more
difficult than when we were using the Tegra SMMU, so we'll probably have
to change that.
The goal of the current code is to allocate memory from the CMA, so one
option would be to change it to use dma_alloc_from_contiguous. That way
we wouldn't get the double IOMMU mapping, which would be nice.
>
>> Considering that, I'm wondering if we can just have a temporary local
>> dma_addr_t and then cast that to phys_addr_t, combined with a good comment?
>
> That was my first approach, and it does address the warning, but
> I did not send it because it still felt too wrong.
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge
From: Marc Zyngier @ 2017-04-20 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2003d851-e17e-1a43-3889-ec6e79e635e3@free.fr>
On 20/04/17 09:20, Mason wrote:
> On 19/04/2017 13:19, Mason wrote:
>
>> My biggest problem is that tango_unmask() is never called.
>
> FTR, the missing incantation was:
> Explicitly calling tango_{mask/unmask/ack} from the corresponding msi_{mask/unmask/ack}
Using irq_chip_mask_parent and co, you mean?
> Marc, I have one nagging doubt, wrt splitting MSI line selection
> and MSI enable.
>
> tango_irq_domain_alloc : finds an available MSI 'j' to allocate
> tango_irq_domain_free : release MSI 'j'
> tango_unmask : enable MSI 'j'
> tango_mask : disable MSI 'j'
>
> Is the following scenario guaranteed to never happen?
>
> tango_irq_domain_alloc // alloc 0
> tango_irq_domain_free // free 0
> tango_irq_domain_alloc // alloc 0
> tango_unmask // enable 0
> tango_unmask // enable 0 = NOP
> tango_mask // disable 0
>
> In this theoretical scenario, we would be left with a non-functional
> MSI 0.
I'm not sure I get the example above, and what the various alloc/free
calls have to do with anything. If you have unbalanced
enable/disable_irq, you loose. Don't do that.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 2/2] drm: dw-hdmi: gate audio clock from the I2S enablement callbacks
From: Archit Taneja @ 2017-04-20 9:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c9258563-afcd-4088-a4f4-6a4e056f5d36@codeaurora.org>
On 04/19/2017 10:21 AM, Archit Taneja wrote:
>
>
> On 04/14/2017 02:01 PM, Romain Perier wrote:
>> Currently, the audio sampler clock is enabled from dw_hdmi_setup() at
>> step E. and is kept enabled for later use. This clock should be enabled
>> and disabled along with the actual audio stream and not always on (that
>> is bad for PM). Futhermore, as described by the datasheet, the I2S
>
> s/Futhermore/Furthermore
>
>> variant need to gate/ungate the clock when the stream is
>
> s/need/needs
>
>> enabled/disabled.
>>
>> This commit adds a parameter to hdmi_audio_enable_clk() that controls
>> when the audio sample clock must be enabled or disabled. Then, it adds
>> the call to this function from dw_hdmi_i2s_audio_enable() and
>> dw_hdmi_i2s_audio_disable().
>>
>> Signed-off-by: Romain Perier <romain.perier@collabora.com>
>> ---
>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 20 ++++++++++++++------
>> 1 file changed, 14 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 5b328c0..a6da634 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -544,6 +544,12 @@ void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate)
>> }
>> EXPORT_SYMBOL_GPL(dw_hdmi_set_sample_rate);
>>
>> +static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi, bool enable)
>> +{
>> + hdmi_modb(hdmi, enable ? 0 : HDMI_MC_CLKDIS_AUDCLK_DISABLE,
>> + HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
>> +}
>> +
>> void dw_hdmi_ahb_audio_enable(struct dw_hdmi *hdmi)
>> {
>> hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
>> @@ -557,6 +563,12 @@ void dw_hdmi_ahb_audio_disable(struct dw_hdmi *hdmi)
>> void dw_hdmi_i2s_audio_enable(struct dw_hdmi *hdmi)
>> {
>> hdmi_set_cts_n(hdmi, hdmi->audio_cts, hdmi->audio_n);
>> + hdmi_enable_audio_clk(hdmi, true);
>> +}
>> +
>> +void dw_hdmi_i2s_audio_disable(struct dw_hdmi *hdmi)
>> +{
>> + hdmi_enable_audio_clk(hdmi, false);
>> }
>
> This should be static too.
>
> If you're okay with the suggestions, I can fix these myself and push. Let
> me know if that's okay.
Took the liberty of going ahead with the fixes. Queued both patches to
drm-misc-next.
Thanks,
Archit
>
> Thanks,
> Archit
>
>>
>> void dw_hdmi_audio_enable(struct dw_hdmi *hdmi)
>> @@ -1592,11 +1604,6 @@ static void dw_hdmi_enable_video_path(struct dw_hdmi *hdmi)
>> HDMI_MC_FLOWCTRL);
>> }
>>
>> -static void hdmi_enable_audio_clk(struct dw_hdmi *hdmi)
>> -{
>> - hdmi_modb(hdmi, 0, HDMI_MC_CLKDIS_AUDCLK_DISABLE, HDMI_MC_CLKDIS);
>> -}
>> -
>> /* Workaround to clear the overflow condition */
>> static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
>> {
>> @@ -1710,7 +1717,7 @@ static int dw_hdmi_setup(struct dw_hdmi *hdmi, struct drm_display_mode *mode)
>>
>> /* HDMI Initialization Step E - Configure audio */
>> hdmi_clk_regenerator_update_pixel_clock(hdmi);
>> - hdmi_enable_audio_clk(hdmi);
>> + hdmi_enable_audio_clk(hdmi, true);
>> }
>>
>> /* not for DVI mode */
>> @@ -2438,6 +2445,7 @@ __dw_hdmi_probe(struct platform_device *pdev,
>> audio.write = hdmi_writeb;
>> audio.read = hdmi_readb;
>> hdmi->enable_audio = dw_hdmi_i2s_audio_enable;
>> + hdmi->disable_audio = dw_hdmi_i2s_audio_disable;
>>
>> pdevinfo.name = "dw-hdmi-i2s-audio";
>> pdevinfo.data = &audio;
>>
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH/RFC v2 1/2] arm64: dts: r8a7795: Add support for R-Car H3 ES2.0
From: Geert Uytterhoeven @ 2017-04-20 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1612430.SNEha5n02K@avalon>
Hi Laurent,
On Mon, Mar 27, 2017 at 10:48 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Friday 24 Mar 2017 14:37:44 Geert Uytterhoeven wrote:
>> Update r8a7795.dtsi so it corresponds to R-Car H3 ES2.0 or later:
>> - The following devices no longer exist on ES2.0, and are thus removed:
>> fcpf2, fcpvd3, fcpvi2, fdp1-2, usb3-if1, vspd3, vspi2.
>> - The DU <-> VSPD topology is different on ES2.0, hence remove the
>> "vsps" property from the DU node until the driver can handle this.
>
> I think I'll need a different compatible string between ES1.x and ES2 for the
> DU. It could make sense to move the whole DU node to *-es1.dtsi. We can decide
> about that later when I'll have a DU driver prototype ready.
Why would you need a different compatible string?
Can't you use soc_device_match() to handle ES1.x SoCs?
The different DU <-> VSPD topology is handled through the vsps property in DTS.
Are the ports different, too? That can be handled in DTS.
The main reason why I kept the DU node in r8a7795.dtsi is that the board DTS
refers to it. Sharing board DTS means there needs to be at least a
placeholder node for the DU in r8a7795.dtsi, unless you want to keep on
shuffling board overrides around.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH V4 0/7] PM / OPP: Use - instead of @ for DT entries
From: Viresh Kumar @ 2017-04-20 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1492666725.git.viresh.kumar@linaro.org>
On 20-04-17, 11:14, Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
> "reg" property.
>
> This has been sent separately as a single patch earlier, and Olof
> suggested to split it per-platform and get it merged via platform
> specific trees. Please get these applied to your trees guys and the rest
> can go via arm-soc.
This is based over 4.11-rc7 and there are no conflicts apart from
sun8i. All the other maintainers can apply their platform specific
patches from this series only.
Thanks.
--
viresh
^ permalink raw reply
* [PATCH V4 5/7] ARM: sun8i: Use - instead of @ for DT OPP entries
From: Viresh Kumar @ 2017-04-20 9:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420080202.olu2mhel6xtmnnjt@lukather>
On 20-04-17, 10:02, Maxime Ripard wrote:
> Hi,
>
> On Thu, Apr 20, 2017 at 11:14:16AM +0530, Viresh Kumar wrote:
> > Compiling the DT file with W=1, DTC warns like follows:
> >
> > Warning (unit_address_vs_reg): Node /opp_table0/opp at 1000000000 has a
> > unit name, but no reg property
> >
> > Fix this by replacing '@' with '-' as the OPP nodes will never have a
> > "reg" property.
> >
> > Reported-by: Krzysztof Kozlowski <krzk@kernel.org>
> > Reported-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > Suggested-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > Acked-by: Rob Herring <robh@kernel.org>
>
> This patch doesn't apply, please make sure to base them on linux-next
I can do that tomorrow once linux-next includes the new PM tree as the
old PM tree had my patch from V3.
--
viresh
^ permalink raw reply
* [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP
From: Ganapatrao Kulkarni @ 2017-04-20 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420084928.GC31436@leverpostej>
On Thu, Apr 20, 2017 at 2:19 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Apr 19, 2017 at 11:14:06PM +0530, Ganapatrao Kulkarni wrote:
>> commit d98ecda (arm64: perf: Count EL2 events if the kernel is running in HYP)
>> is returning error for perf syscall with mixed attribute set for exclude_kernel
>> and exclude_hv. This change is breaking some applications (observed with hhvm)
>> when ran on VHE enabled platforms.
>>
>> Adding fix to consider only exclude_kernel attribute when kernel is
>> running in HYP. Also adding sysfs file to notify the bhehaviour
>> of attribute exclude_hv.
>>
>> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
>> ---
>>
>> Changelog:
>>
>> V2:
>> - Changes as per Will Deacon's suggestion.
>>
>> V1: Initial patch
>>
>> arch/arm64/kernel/perf_event.c | 28 ++++++++++++++++++++++++----
>> include/linux/perf/arm_pmu.h | 1 +
>> 2 files changed, 25 insertions(+), 4 deletions(-)
>>
>> @@ -871,14 +890,13 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event,
>>
>> if (attr->exclude_idle)
>> return -EPERM;
>> - if (is_kernel_in_hyp_mode() &&
>> - attr->exclude_kernel != attr->exclude_hv)
>> - return -EINVAL;
>> + if (is_kernel_in_hyp_mode() && !attr->exclude_kernel)
>> + config_base |= ARMV8_PMU_INCLUDE_EL2;
>> if (attr->exclude_user)
>> config_base |= ARMV8_PMU_EXCLUDE_EL0;
>> if (!is_kernel_in_hyp_mode() && attr->exclude_kernel)
>> config_base |= ARMV8_PMU_EXCLUDE_EL1;
>> - if (!attr->exclude_hv)
>> + if (!is_kernel_in_hyp_mode() && !attr->exclude_hv)
>> config_base |= ARMV8_PMU_INCLUDE_EL2;
>
> This isn't quite what Will suggested.
>
> The idea was that userspace would read sysfs, then use that to determine
> the correct exclusion parameters [1,2]. This logic was not expected to
> change; it correctly validates whether we can provide what the user
> requests.
OK, if you are ok with sysfs part, i can send next version with that
change only?.
>
> Thanks,
> Mark.
>
> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/499224.html
> [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/499493.html
>
>>
>> /*
>> @@ -1008,6 +1026,8 @@ static int armv8_pmuv3_init(struct arm_pmu *cpu_pmu)
>> &armv8_pmuv3_events_attr_group;
>> cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_FORMATS] =
>> &armv8_pmuv3_format_attr_group;
>> + cpu_pmu->attr_groups[ARMPMU_ATTR_GROUP_ATTR] =
>> + &armv8_pmuv3_attr_group;
>> return armv8pmu_probe_pmu(cpu_pmu);
>> }
>>
>> diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
>> index 8462da2..a26ffc7 100644
>> --- a/include/linux/perf/arm_pmu.h
>> +++ b/include/linux/perf/arm_pmu.h
>> @@ -81,6 +81,7 @@ enum armpmu_attr_groups {
>> ARMPMU_ATTR_GROUP_COMMON,
>> ARMPMU_ATTR_GROUP_EVENTS,
>> ARMPMU_ATTR_GROUP_FORMATS,
>> + ARMPMU_ATTR_GROUP_ATTR,
>> ARMPMU_NR_ATTR_GROUPS
>> };
>>
>> --
>> 1.8.1.4
>>
^ permalink raw reply
* [GIT PULL] Renesas ARM Based SoC Sysc Updates for v4.12
From: Simon Horman @ 2017-04-20 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419135556.GG29219@localhost>
On Wed, Apr 19, 2017 at 06:55:56AM -0700, Olof Johansson wrote:
> Hi,
>
> On Fri, Apr 07, 2017 at 02:14:07PM -0400, Simon Horman wrote:
> > Hi Olof, Hi Kevin, Hi Arnd,
> >
> > Please consider these Renesas ARM based SoC sysc updates for v4.12.
> >
> > This pull request is based on the soc-device-match-tag2 tag of
> > Geert Uytterhoeven's renesas-drivers tree which he has already
> > sent a pull-request for.
>
> Geert's pull request wasn't cc:d to arm at kernel.org, so I had actually
> missed it when it was originally sent (since my inbox tends to get quite
> a few emails directly to it).
>
> Merged now, thanks!
Thanks, sorry for not noticing the missing CC.
^ permalink raw reply
* [PATCH v2] arm64: dts: r8a7795: salvator-x: Add current sense amplifiers
From: Simon Horman @ 2017-04-20 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420091018.GK3760@verge.net.au>
On Thu, Apr 20, 2017 at 06:10:19PM +0900, Simon Horman wrote:
> On Wed, Apr 19, 2017 at 10:37:37AM +0200, Geert Uytterhoeven wrote:
> > Add device nodes for two Maxim max961x current sense amplifiers
> > sensing the VDD_0.8V and DVFS_0.8V lines.
> >
> > Based on a patch for r8a7796-salvator-x.dts by Jacopo Mondi.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > Bindings and driver are now in staging-next.
>
> Forgive my ignorance, what is the flow of changes from staging-next
> to a release?
I now see that Jonathan Cameron says the bindings will make it into the
next release[1], so I have queued up this patch.
[1] https://www.spinics.net/lists/linux-renesas-soc/msg13179.html
^ permalink raw reply
* [PATCH v2] arm64: dts: r8a7795: salvator-x: Add current sense amplifiers
From: Simon Horman @ 2017-04-20 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492591057-10674-1-git-send-email-geert+renesas@glider.be>
On Wed, Apr 19, 2017 at 10:37:37AM +0200, Geert Uytterhoeven wrote:
> Add device nodes for two Maxim max961x current sense amplifiers
> sensing the VDD_0.8V and DVFS_0.8V lines.
>
> Based on a patch for r8a7796-salvator-x.dts by Jacopo Mondi.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> Bindings and driver are now in staging-next.
Forgive my ignorance, what is the flow of changes from staging-next
to a release?
^ permalink raw reply
* [PATCH 3/3] ARM: dts: imx7d-nitrogen7: fix rv4162 compatible
From: Gary Bisson @ 2017-04-20 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419202204.7689-3-alexandre.belloni@free-electrons.com>
Hi Alexandre,
On Wed, Apr 19, 2017 at 10:22:04PM +0200, Alexandre Belloni wrote:
> The rv4162 compatbile string is missing the vendor part, add it.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Gary Bisson <gary.bisson@boundarydevices.com>
Thanks for fixing it.
Regards,
Gary
^ permalink raw reply
* [PATCH 2/3] ARM: dts: imx6qdl-nitrogen6_som2: fix rv4162 compatible
From: Gary Bisson @ 2017-04-20 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419202204.7689-2-alexandre.belloni@free-electrons.com>
Hi Alexandre,
On Wed, Apr 19, 2017 at 10:22:03PM +0200, Alexandre Belloni wrote:
> The rv4162 vendor is microcrystal, not ST.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Gary Bisson <gary.bisson@boundarydevices.com>
Thanks for fixing it.
Regards,
Gary
^ permalink raw reply
* [PATCH 1/3] ARM: dts: imx6qdl-nitrogen6_max: fix rv4162 compatible
From: Gary Bisson @ 2017-04-20 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170419202204.7689-1-alexandre.belloni@free-electrons.com>
Hi Alexandre,
On Wed, Apr 19, 2017 at 10:22:02PM +0200, Alexandre Belloni wrote:
> The rv4162 vendor is microcrystal, not ST.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Gary Bisson <gary.bisson@boundarydevices.com>
Thanks for fixing it.
Regards,
Gary
^ permalink raw reply
* [PATCH/RFT] sata: rcar_sata: Reset SATA PHY on resume
From: Simon Horman @ 2017-04-20 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <308de569-b3a7-8909-c07c-6d39cab5b287@cogentembedded.com>
On Tue, Apr 18, 2017 at 12:20:20PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 4/18/2017 10:02 AM, Simon Horman wrote:
>
> >In the case where power is cut on suspend the SATA PHY state needs to be
> >suspended on resume.
> >
> >This is the case on the Salvator-X board with the r8a7795 or r8a7796 SoC.
> >In that environment it has been observed that SATA partitions cannot not be
> >accessed on resume.
> >
> >Based on work by Khiem Nguyen.
> >
> >Cc: Khiem Nguyen <khiem.nguyen.xt@rvc.renesas.com>
> >Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> >---
> >* Compile and boot tested only
> >---
> > drivers/ata/sata_rcar.c | 9 +--------
> > 1 file changed, 1 insertion(+), 8 deletions(-)
>
> Why the scope prefix in the subject is not just "sata_rcar: "? :-)
Thanks, I will drop that.
^ permalink raw reply
* [PATCH] arm64: dts: m3ulcb: Fix EthernetAVB PHY timing
From: Simon Horman @ 2017-04-20 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a7afb651-d103-248c-5610-2fc41a773c52@cogentembedded.com>
On Tue, Apr 18, 2017 at 12:26:25PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 4/18/2017 4:06 AM, Simon Horman wrote:
>
> >Set PHY rxc-skew-ps to 1500 and all other values to their default values.
> >
> >This is intended to to address failures in the case of 1Gbps communication
> >using the by salvator-x board with the KSZ9031RNX phy. This has been
>
> The by? :-)
>
> >reported to occur with both the r8a7795 (H3) and r8a7796 (M3-W) SoCs.
> >
> >Based in a similar patch for the r8a7796 salvator-x by Kazuya Mizuguchi.
> >
> >Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> [...]
Thanks, I have queued this up with the typo fixed.
^ permalink raw reply
* [PATCH 3/3] perf tool, arm64, thunderx2: Add implementation defined events for ThunderX2
From: Mark Rutland @ 2017-04-20 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFpQJXUfR98gWbfmiBM69wKVLM7e=ujo8LZxmUFfxJ0iTrCKsQ@mail.gmail.com>
On Wed, Apr 19, 2017 at 11:37:31PM +0530, Ganapatrao Kulkarni wrote:
> Hi Mark,
Hi,
> On Thu, Apr 6, 2017 at 3:25 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Thu, Apr 06, 2017 at 09:50:33AM +0530, Ganapatrao Kulkarni wrote:
> >> On Wed, Apr 5, 2017 at 3:35 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> >> > On Wed, Apr 05, 2017 at 02:42:39PM +0530, Ganapatrao Kulkarni wrote:
> >> >> On Tue, Apr 4, 2017 at 5:58 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> >> >> > On Tue, Apr 04, 2017 at 01:06:43PM +0530, Ganapatrao Kulkarni wrote:
> >
> >> >> >> + "CPU" :"armv8_pmuv3_0"
> >> >> >
> >> >> > Please let's not hard-code the name like this. Surely we can get rid of this?
> >> >> >
> >> >> > The kernel doesn't currently name PMUs as armv8_pmuv3_*, and as that can
> >> >> > differ across DT/ACPI and in big.LITTLE, I don't think it makes sense to
> >> >> > try to rely one particular string regardless.
> >> >>
> >> >> This string/name is fixed for a platform. having name here is essential to
> >> >> know which devices among pmu (armv8_pmuv3_0, breakpoint, software)
> >> >> devices, these jevents to be added.
> >> >> also this json file is specific to a arch/soc/board, it is not a
> >> >> generic file to be common.
> >> >
> >> > This file describe the events of a CPU PMU, and CPUs are not specific to
> >> > a platform in general. There are many systems using Cortex-A57, for
> >> > example.
> >> >
> >> > Across big.LITTLE SoCs with Cortex-A57, there's no guarantee as to
> >> > whether the Cortex-A57 cores would be named armv8_pmuv3_0, or
> >> > armv8_pmuv3_1, etc. This would depend on the boot CPU, probe order of
> >> > secondaries, etc.
>
> some of the applications(perf etc) use sysfs files of perf PMU CORE devices.
> at present the names are created as per SOC/platform like
> armv8_pmuv3, armv8_cavium_thunder, armv8_cortex_a57 etc.
>
> cpu_pmu->name = "armv8_cavium_thunder";
>
> can we please have common name similar to x86(cpu) and call them as
> cpu_0 and cpu_1?
I don't see how that helps in this case?
I'd rather that we expose some mechanism to determine whether a PMU is a
CPU PMU, other than the name. Userspace can then throw away the name if
it so wishes, and it doesn't have the potential to break existing users.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 7/8] arm64: exception: handle asynchronous SError interrupt
From: James Morse @ 2017-04-20 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e6502f82-108e-3f53-4791-515671e4d515@huawei.com>
Hi Wang Xiongfeng,
On 19/04/17 03:37, Xiongfeng Wang wrote:
> On 2017/4/18 18:51, James Morse wrote:
>> The host expects to receive physical SError Interrupts. The ARM-ARM doesn't
>> describe a way to inject these as they are generated by the CPU.
>>
>> Am I right in thinking you want this to use SError Interrupts as an APEI
>> notification? (This isn't a CPU thing so the RAS spec doesn't cover this use)
>
> Yes, using sei as an APEI notification is one part of my consideration. Another use is for ESB.
> RAS spec 6.5.3 'Example software sequences: Variant: asynchronous External Abort with ESB'
> describes the SEI recovery process when ESB is implemented.
>
> In this situation, SEI is routed to EL3 (SCR_EL3.EA = 1). When an SEI occurs in EL0 and not been taken immediately,
> and then an ESB instruction at SVC entry is executed, SEI is taken to EL3. The ESB at SVC entry is
> used for preventing the error propagating from user space to kernel space. The EL3 SEI handler collects
> the errors and fills in the APEI table, and then jump to EL2 SEI handler. EL2 SEI handler inject
> an vSEI into EL1 by setting HCR_EL2.VSE = 1, so that when returned to OS, an SEI is pending.
This step has confused me. How would this work with VHE where the host runs at
EL2 and there is nothing at Host:EL1?
>From your description I assume you have some firmware resident at EL2.
> Then ESB is executed again, and DISR_EL1.A is set by hardware (2.4.4 ESB and virtual errors), so that
> the following process can be executed.
> So we want to inject a vSEI into OS, when control is returned from EL3/2 to OS, no matter whether
> it is on host OS or guest OS.
I disagree. With Linux/KVM you can't use Virtual SError to notify the host OS.
The host OS expects to receive Physical SError, these shouldn't be taken to EL2
unless a guest is running. Notifications from firmware that use SEA or SEI
should follow the routing rules in the ARM-ARM, which means they should never
reach a guest OS.
For VHE the host runs at EL2 and sets HCR_EL2.AMO. Any firmware notification
should come from EL3 to the host at EL2. The host may choose to notify the
guest, but this should always go via Qemu.
For non-VHE systems the host runs at EL1 and KVM lives at EL2 to do the world
switch. When KVM is running a guest it sets HCR_EL2.AMO, when it has switched
back to the host it clears it.
Notifications from EL3 that pretend to be SError should route SError to EL2 or
EL1 depending on HCR_EL2.AMO.
When KVM gets a Synchronous External Abort or an SError while a guest is running
it will switch back to the host and tell the handle_exit() code. Again the host
may choose to notify the guest, but this should always go via Qemu.
The ARM-ARM pseudo code for the routing rules is in
AArch64.TakePhysicalSErrorException(). Firmware injecting fake SError should
behave exactly like this.
Newly appeared in the ARM-ARM is HCR_EL2.TEA, which takes Synchronous External
Aborts to EL2 (if SCR_EL3 hasn't claimed them). We should set/clear this bit
like we do HCR_EL2.AMO if the CPU has the RAS extensions.
>> You cant use SError to cover all the possible RAS exceptions. We already have
>> this problem using SEI if PSTATE.A was set and the exception was an imprecise
>> abort from EL2. We can't return to the interrupted context and we can't deliver
>> an SError to EL2 either.
>
> SEI came from EL2 and PSTATE.A is set. Is it the situation where VHE is enabled and CPU is running
> in kernel space. If SEI occurs in kernel space, can we just panic or shutdown.
firmware-panic? We can do a little better than that:
If the IESB bit is set in the ESR we can behave as if this were an ESB and have
firmware write an appropriate ESR to DISR_EL1 if PSTATE.A is set and the
exception came from EL2.
Linux should have an ESB in its __switch_to(), I've re-worked the daif masking
in entry.S so that PSTATE.A will always be unmasked here.
Other than these two cases, yes, this CPU really is wrecked. Firmware can power
it off via PSCI, and could notify another CPU about what happened. UEFI's table
250 'Processor Generic Error Section' has a 'Processor ID' field, with a note
that on ARM this is the MPIDR_EL1. Table 260 'ARM Processor Error Section' has
something similar.
Thanks,
James
^ permalink raw reply
* [PATCH 0/3] Add R8A7743/SK-RZG1M PFC support
From: Simon Horman @ 2017-04-20 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414210941.143838720@cogentembedded.com>
On Sat, Apr 15, 2017 at 12:09:41AM +0300, Sergei Shtylyov wrote:
> Hello.
>
> Here's the set of 3 patches against Simon Horman's 'renesas.git' repo,
> 'renesas-devel-20170410-v4.11-rc6' tag. We're adding the R8A7743 PFC node and
> then describe the pins for SCIF0 and Ether devices described eralier. These
> patches depend on the R8A7743 PFC suport in order to work properly.
>
> [1/3] ARM: dts: r8a7743: add PFC support
> [2/3] ARM: dts: sk-rzg1m: add SCIF0 pins
> [3/3] ARM: dts: sk-rzg1m: add Ether pins
These look good to me. Please repost me or ping me once the prerequisites
have been accepted. Likewise for the similar patchset for the R8A7745/SK-RZG1E.
^ permalink raw reply
* [PATCH] [media] atmel-isc: Set the default DMA memory burst size
From: Songjun Wu @ 2017-04-20 8:51 UTC (permalink / raw)
To: linux-arm-kernel
Sometimes 'DMA single access' is not enough to transfer
a frame of image, '8-beat burst access' is set as the
default DMA memory burst size.
Signed-off-by: Songjun Wu <songjun.wu@microchip.com>
---
drivers/media/platform/atmel/atmel-isc.c | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
index c4b2115559a5..78d966233f80 100644
--- a/drivers/media/platform/atmel/atmel-isc.c
+++ b/drivers/media/platform/atmel/atmel-isc.c
@@ -239,13 +239,11 @@ static struct isc_format isc_formats[] = {
{ V4L2_PIX_FMT_YUV420, 0x0, 12,
ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_YYCC,
- ISC_DCFG_IMODE_YC420P | ISC_DCFG_YMBSIZE_BEATS8 |
- ISC_DCFG_CMBSIZE_BEATS8, ISC_DCTRL_DVIEW_PLANAR, 0x7fb,
+ ISC_DCFG_IMODE_YC420P, ISC_DCTRL_DVIEW_PLANAR, 0x7fb,
false, false },
{ V4L2_PIX_FMT_YUV422P, 0x0, 16,
ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_YYCC,
- ISC_DCFG_IMODE_YC422P | ISC_DCFG_YMBSIZE_BEATS8 |
- ISC_DCFG_CMBSIZE_BEATS8, ISC_DCTRL_DVIEW_PLANAR, 0x3fb,
+ ISC_DCFG_IMODE_YC422P, ISC_DCTRL_DVIEW_PLANAR, 0x3fb,
false, false },
{ V4L2_PIX_FMT_RGB565, MEDIA_BUS_FMT_RGB565_2X8_LE, 16,
ISC_PFE_CFG0_BPS_EIGHT, ISC_BAY_CFG_BGBG, ISC_RLP_CFG_MODE_RGB565,
@@ -700,8 +698,10 @@ static void isc_set_histogram(struct isc_device *isc)
}
static inline void isc_get_param(const struct isc_format *fmt,
- u32 *rlp_mode, u32 *dcfg_imode)
+ u32 *rlp_mode, u32 *dcfg)
{
+ *dcfg = ISC_DCFG_YMBSIZE_BEATS8;
+
switch (fmt->fourcc) {
case V4L2_PIX_FMT_SBGGR10:
case V4L2_PIX_FMT_SGBRG10:
@@ -712,11 +712,11 @@ static inline void isc_get_param(const struct isc_format *fmt,
case V4L2_PIX_FMT_SGRBG12:
case V4L2_PIX_FMT_SRGGB12:
*rlp_mode = fmt->reg_rlp_mode;
- *dcfg_imode = fmt->reg_dcfg_imode;
+ *dcfg |= fmt->reg_dcfg_imode;
break;
default:
*rlp_mode = ISC_RLP_CFG_MODE_DAT8;
- *dcfg_imode = ISC_DCFG_IMODE_PACKED8;
+ *dcfg |= ISC_DCFG_IMODE_PACKED8;
break;
}
}
@@ -726,18 +726,19 @@ static int isc_configure(struct isc_device *isc)
struct regmap *regmap = isc->regmap;
const struct isc_format *current_fmt = isc->current_fmt;
struct isc_subdev_entity *subdev = isc->current_subdev;
- u32 pfe_cfg0, rlp_mode, dcfg_imode, mask, pipeline;
+ u32 pfe_cfg0, rlp_mode, dcfg, mask, pipeline;
if (sensor_is_preferred(current_fmt)) {
pfe_cfg0 = current_fmt->reg_bps;
pipeline = 0x0;
- isc_get_param(current_fmt, &rlp_mode, &dcfg_imode);
+ isc_get_param(current_fmt, &rlp_mode, &dcfg);
isc->ctrls.hist_stat = HIST_INIT;
} else {
pfe_cfg0 = isc->raw_fmt->reg_bps;
pipeline = current_fmt->pipeline;
rlp_mode = current_fmt->reg_rlp_mode;
- dcfg_imode = current_fmt->reg_dcfg_imode;
+ dcfg = current_fmt->reg_dcfg_imode | ISC_DCFG_YMBSIZE_BEATS8 |
+ ISC_DCFG_CMBSIZE_BEATS8;
}
pfe_cfg0 |= subdev->pfe_cfg0 | ISC_PFE_CFG0_MODE_PROGRESSIVE;
@@ -750,7 +751,7 @@ static int isc_configure(struct isc_device *isc)
regmap_update_bits(regmap, ISC_RLP_CFG, ISC_RLP_CFG_MODE_MASK,
rlp_mode);
- regmap_update_bits(regmap, ISC_DCFG, ISC_DCFG_IMODE_MASK, dcfg_imode);
+ regmap_write(regmap, ISC_DCFG, dcfg);
/* Set the pipeline */
isc_set_pipeline(isc, pipeline);
--
2.11.0
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: r8a7743: add PFC support
From: Simon Horman @ 2017-04-20 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414211505.733692280@cogentembedded.com>
On Sat, Apr 15, 2017 at 12:09:42AM +0300, Sergei Shtylyov wrote:
> Define the generic R8A7743 part of the PFC device node.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> arch/arm/boot/dts/r8a7743.dtsi | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
> ===================================================================
> --- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
> +++ renesas/arch/arm/boot/dts/r8a7743.dtsi
> @@ -1,7 +1,7 @@
> /*
> * Device Tree Source for the r8a7743 SoC
> *
> - * Copyright (C) 2016 Cogent Embedded Inc.
> + * Copyright (C) 2016-2017 Cogent Embedded Inc.
> *
> * This file is licensed under the terms of the GNU General Public License
> * version 2. This program is licensed "as is" without any warranty of any
> @@ -123,6 +123,11 @@
> #power-domain-cells = <1>;
> };
>
> + pfc: pin-controller at e6060000 {
> + compatible = "renesas,pfc-r8a7743";
> + reg = <0 0xe6060000 0 0x250>;
> + };
> +
I am curious to know why pin-controller was chosen rather than pfc which
is dominant in the DT for Renesas SoCs. And as a follow-up question, do
you think it would be worth creating patches to make this uniform
across the DT for Renesas SoCs.
> dmac0: dma-controller at e6700000 {
> compatible = "renesas,dmac-r8a7743",
> "renesas,rcar-dmac";
>
^ 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