* [PATCH v3 3/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: atull @ 2016-11-30 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6989b2ee-9caf-81b3-2328-9d4e287794cb@gmail.com>
On Wed, 30 Nov 2016, Joshua Clayton wrote:
Hi Joshua,
> Hi Alan,
>
> On 11/30/2016 09:45 AM, atull wrote:
> > On Wed, 30 Nov 2016, Joshua Clayton wrote:
> >
> > Hi Clayton,
> >
> > I just have a few minor one line changes below. Only one
> > is operational, I should have caught that earlier.
> >
> Thanks for the speedy review.
> >> +};
> >> +MODULE_DEVICE_TABLE(of, of_ef_match);
> >> +
> >> +static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
> >> +{
> >> + return mgr->state;
> >> +}
> > This function gets called once to initialize mgr->state in
> > fpga_mgr_register(). So it should at least return the state the FPGA
> > is at then. If it is unknown, it can just return
> > FPGA_MGR_STATE_UNKNOWN.
> >
> I guess I didn't understand the purpose of this function.
> The driver has access to the status pin at this phase, so I can return
> FPGA_MGR_STATE_UNKNOWN or FPGA_MGR_STATE_RESET depending
> on the state of that pin.
>
> >> +
> >> +static int cyclonespi_write_init(struct fpga_manager *mgr, u32 flags,
> >> + const char *buf, size_t count)
> > Minor, but please fix the indentation of 'const' to match that of
> > 'struct' above. checkpatch.pl is probably issuing warnings
> > about that.
> I double checked. The indentation is correct here. It only has
> The appearance of being off by one due to the diff format.
Yes, I understand.
> >> +{
> >> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> >> + int i;
> >> +
> >> + if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
> >> + dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
> >> + return -EINVAL;
> >> + }
> >> +
> >> + gpiod_set_value(conf->config, 0);
> >> + usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
> >> + if (gpiod_get_value(conf->status) == 1) {
> >> + dev_err(&mgr->dev, "Status pin should be low.\n");
> >> + return -EIO;
> >> + }
> >> +
> >> + gpiod_set_value(conf->config, 1);
> >> + for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
> >> + usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
> >> + if (gpiod_get_value(conf->status))
> >> + return 0;
> >> + }
> >> +
> >> + dev_err(&mgr->dev, "Status pin not ready.\n");
> >> + return -EIO;
> >> +}
> >> +
> >> +static void rev_buf(void *buf, size_t len)
> >> +{
> >> + u32 *fw32 = (u32 *)buf;
> >> + const u32 *fw_end = (u32 *)(buf + len);
> >> +
> >> + /* set buffer to lsb first */
> >> + while (fw32 < fw_end) {
> >> + *fw32 = bitrev8x4(*fw32);
> >> + fw32++;
> >> + }
> >> +}
> >> +
> >> +static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
> >> + size_t count)
> > Please fix alignment here also.
> Same as above. Indentation is OK.
>
>
> I'll get a v4 turned around soon.
No rush since the other two patches need acks from
their respective maintainers and this won't be able
to go in without them. But with that one change
it looks good to me.
Alan
> Thanks,
> Joshua
>
^ permalink raw reply
* Unable to use perf in VM
From: Wei Huang @ 2016-11-30 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a81f82da-322a-a52b-de0e-316b7ce5f463@arm.com>
On 11/30/2016 07:37 AM, Marc Zyngier wrote:
> On 30/11/16 11:48, Marc Zyngier wrote:
>> + Shannon
>>
>> On 29/11/16 22:04, Itaru Kitayama wrote:
>>> Hi,
>>>
>>> In a VM (virsh controlled, KVM acceleration enabled) on a recent
>>> kvmarm kernel host, I find I am unable to use perf to obtain
>>> performance statistics for a complex task like kernel build.
>>> (I've verified this is seen with a Fedora 25 VM and host combination
>>> as well)
>>> APM folks CC'ed think this might be caused by a bug in the core PMU
>>> framework code, thus I'd like to have experts opinion on this issue.
>>>
>>> [root at localhost linux]# perf stat -B make
>>> CHK include/config/kernel.release
>>> [ 119.617684] git[1144]: undefined instruction: pc=fffffc000808ff30
>>> [ 119.623040] Code: 51000442 92401042 d51b9ca2 d5033fdf (d53b9d40)
>>> [ 119.627607] Internal error: undefined instruction: 0 [#1] SMP
>>
>> [...]
>>
>> In a VM running mainline hosted on an AMD Seattle box:
>>
>> Performance counter stats for 'make':
>>
>> 1526089.499304 task-clock:u (msec) # 0.932 CPUs utilized
>> 0 context-switches:u # 0.000 K/sec
>> 0 cpu-migrations:u # 0.000 K/sec
>> 29527793 page-faults:u # 0.019 M/sec
>> 2913174122673 cycles:u # 1.909 GHz
>> 2365040892322 instructions:u # 0.81 insn per cycle
>> <not supported> branches:u
>> 32049215378 branch-misses:u # 0.00% of all branches
>>
>> 1637.531444837 seconds time elapsed
>>
>> Running the same host kernel on a Mustang system, the guest explodes
>> in the way you reported. The failing instruction always seems to be
>> an access to pmxevcntr_el0 (I've seen both reads and writes).
>>
>> Funnily enough, it dies if you try any HW event other than cycles
>> ("perf stat -e cycles ls" works, and "perf stat -e instructions ls"
>> explodes). Which would tend to indicate that we're screwing up
>> the counter selection, but I have no proof of that (specially that
>> the Seattle guest is working just as expected).
>
> It turns out that we *don't* inject an undef. It seems to be generated
> locally at EL1.
>
> Still digging.
Just FYI: I saw it on Mustang before. My initial thought was HW related,
but without proof. I am interested to see your findings...
>
> M.
>
^ permalink raw reply
* [linux-sunxi] Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Jernej Škrabec @ 2016-11-30 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130220324.3Kg4VPEw@smtp1m.mail.yandex.net>
Dne ?etrtek, 01. december 2016 ob 03:03:14 CET je Icenowy Zheng napisal(a):
> 2016?12?1? 02:49? Jernej Skrabec <jernej.skrabec@gmail.com>???
>
> > Hi Jean-Fran?ois,
> >
> > Dne sreda, 30. november 2016 10.35.08 UTC+1 je oseba Jean-Fran?ois Moine
napisala:
> >> On Tue, 29 Nov 2016 22:59:32 +0100
> >>
> >> Maxime Ripard <maxime...@free-electrons.com> wrote:
> >> > > > I'm still not sure which pipeline should I use.
> >> > > >
> >> > > > And, it seems that HDMI Slow Clock is not needed?
> >> > > >
> >> > > > (seems that it's only for EDID, but simplefb won't use EDID)
> >> > >
> >> > > So, I don't see how this may work.
> >> > > How can the u-boot know the resolutions of the HDMI display device?
> >> > >
> >> > > In other words: I have a new H3 board with the last u-boot and
> >> > > kernel.
> >> > > I plug my (rather old or brand new) HDMI display device.
> >> > > After powering on the system, I hope to get something on the screen.
> >> > > How?
> >> >
> >> > If it works like the driver for the first display engine in U-Boot, it
> >> > will use the preferred mode reported by the EDID, and will fallback to
> >> > 1024x768 if it cannot access it.
> >>
> >> Icenowy wrote: "simplefb won't use EDID"
> >>
> >> Then, if it is like in the kernel, the 1024x768 mode is VGA. It does
> >> not work with HDMI (different timings).
> >
> > U-Boot driver now accept any timings recommended by EDID. So far it
> > was tested with at least following resolutions:
> > - 1920x1080 @ 60 Hz
> > - 1280x1024 @ 60 Hz
> > - 1280x800 @ 60 Hz (slight clock difference)
> > - 800x480 (not sure about frame rate)
> > - 3840x2160 @ 30 Hz (4K)
>
> I tested on 1024x600 (If my memory is right, it's @ 60Hz)
>
> > and nobody complained so far. I'm pretty sure 1024x768 would work.
> >
> >> > Maybe it would be worth exchanging on the EDID code that has been done
> >> > for the u-boot driver too, so that it can be fixed in your driver.
> >>
> >> The u-boot got my code, and, up to now, I could not fix the random or
> >> permanent failures of EDID reading in some boards.
> >
> > I only have one OPi2, but as I said, EDID always worked for me. The only
> > code left from you is for DE2. HDMI stuff is basically copied from Rockhip
> > driver (including EDID reading), TCON code is now reverted to the same as
> > it is in sunxi_display.c. I think it is worth to take a look at EDID code
> > and compare it.
>
> So is the TCON of DE 2.0 identical to the original TCON?
>
> If so, we should reuse sun4i-tcon ...
>
Well, TCON is splitted in two parts (two base addresses), one for HDMI and one
for TV. However, register offsets are same as before, so I guess driver
reusage make sense. I think that there are few additional registers, but they
can be ignored for simplefb.
> >
> >
> >> --
> >> Ken ar c'henta? | ** Breizh ha Linux atav! **
> >> Jef | http://moinejf.free.fr/
> >
> > Best regards,
> > Jernej ?krabec
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "linux-sunxi" group. To unsubscribe from this group and stop receiving
> > emails from it, send an email to
> > linux-sunxi+unsubscribe at googlegroups.com. For more options, visit
> > https://groups.google.com/d/optout.
Best regards,
Jernej ?krabec
^ permalink raw reply
* [PATCH net-next] net: thunderx: Fix transmit queue timeout issue
From: David Miller @ 2016-11-30 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480419620-32500-1-git-send-email-sunil.kovvuri@gmail.com>
From: sunil.kovvuri@gmail.com
Date: Tue, 29 Nov 2016 17:10:20 +0530
> + /* Check again, incase another cpu freed descriptors */
> + if (atomic_read(&sq->free_cnt) > MIN_SQ_DESC_PER_PKT_XMIT) {
> + netif_tx_start_queue(txq);
You have to use netif_tx_wake_queue() any time you restart a queue after bringing
the device up.
^ permalink raw reply
* [PATCH v3 3/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: Joshua Clayton @ 2016-11-30 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1611301122470.2617@atull-730U3E-740U3E>
Hi Alan,
On 11/30/2016 09:45 AM, atull wrote:
> On Wed, 30 Nov 2016, Joshua Clayton wrote:
>
> Hi Clayton,
>
> I just have a few minor one line changes below. Only one
> is operational, I should have caught that earlier.
>
Thanks for the speedy review.
>> +};
>> +MODULE_DEVICE_TABLE(of, of_ef_match);
>> +
>> +static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
>> +{
>> + return mgr->state;
>> +}
> This function gets called once to initialize mgr->state in
> fpga_mgr_register(). So it should at least return the state the FPGA
> is at then. If it is unknown, it can just return
> FPGA_MGR_STATE_UNKNOWN.
>
I guess I didn't understand the purpose of this function.
The driver has access to the status pin at this phase, so I can return
FPGA_MGR_STATE_UNKNOWN or FPGA_MGR_STATE_RESET depending
on the state of that pin.
>> +
>> +static int cyclonespi_write_init(struct fpga_manager *mgr, u32 flags,
>> + const char *buf, size_t count)
> Minor, but please fix the indentation of 'const' to match that of
> 'struct' above. checkpatch.pl is probably issuing warnings
> about that.
I double checked. The indentation is correct here. It only has
The appearance of being off by one due to the diff format.
>> +{
>> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
>> + int i;
>> +
>> + if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
>> + dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
>> + return -EINVAL;
>> + }
>> +
>> + gpiod_set_value(conf->config, 0);
>> + usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
>> + if (gpiod_get_value(conf->status) == 1) {
>> + dev_err(&mgr->dev, "Status pin should be low.\n");
>> + return -EIO;
>> + }
>> +
>> + gpiod_set_value(conf->config, 1);
>> + for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
>> + usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
>> + if (gpiod_get_value(conf->status))
>> + return 0;
>> + }
>> +
>> + dev_err(&mgr->dev, "Status pin not ready.\n");
>> + return -EIO;
>> +}
>> +
>> +static void rev_buf(void *buf, size_t len)
>> +{
>> + u32 *fw32 = (u32 *)buf;
>> + const u32 *fw_end = (u32 *)(buf + len);
>> +
>> + /* set buffer to lsb first */
>> + while (fw32 < fw_end) {
>> + *fw32 = bitrev8x4(*fw32);
>> + fw32++;
>> + }
>> +}
>> +
>> +static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
>> + size_t count)
> Please fix alignment here also.
Same as above. Indentation is OK.
I'll get a v4 turned around soon.
Thanks,
Joshua
^ permalink raw reply
* [PATCH v4 net-next 3/7] net: mvneta: Use cacheable memory to store the rx buffer virtual address
From: David Miller @ 2016-11-30 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bb2f1a61e9b912905f8390f7a06c36f9f1e7ab66.1480431285.git-series.gregory.clement@free-electrons.com>
From: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date: Tue, 29 Nov 2016 15:55:21 +0100
> + /* Virtual address of the RX buffer */
> + void **buf_virt_addr;
> +
> /* Virtual address of the RX DMA descriptors array */
> struct mvneta_rx_desc *descs;
>
...
> + data = (unsigned char *)rxq->buf_virt_addr[index];
This cast is unnecessary, please remove it.
^ permalink raw reply
* [PATCH net-next v4 0/4] Fix OdroidC2 Gigabit Tx link issue
From: Florian Fainelli @ 2016-11-30 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480499246.17538.208.camel@baylibre.com>
On 11/30/2016 01:47 AM, Jerome Brunet wrote:
>> If we start supporting generic "enable", "disable" type of properties
>> with values that map directly to register definitions of the HW, we
>> leave too much room for these properties to be utilized to implement
>> a
>> specific policy, and this is not acceptable.
>
> Florian,
>
> I agree that DT should not be used to setup a policy, but to describe
> what the HW is.
>
> I tried to implement it the way you suggested, using phy fixup, too see
> what it looks like.
> There is 2 places in the code that seems (remotely) linked to the
> issue:
> - meson8b_dwmac driver : if the mac, regardless of the board/platform,
> could not tolerate to have EEE activated, it would make sense to have
> the fixup here. It can provide a C callback for such case.
> - realtek phy driver: philosophy is kind of the same
>
> To be clear, it is doable and it works that way, but I don't think
> embedding this directly in the code is the right way to do it. It seems
> we are hiding an information specific about the board inside a generic
> driver.
So there are a few things about that:
- if we were not on ARM64, there would be possibly a remote chance of
having some concept of a board file which would be where such a PHY
fixup, or fixup of any kind would reside
- having the PHY fixup in the PHY driver gated by both an exact match on
the PHY OUI *and* the specific affected board makes it reasonably easy
to locate it
>
> We have several amlogic's design with the same MAC, sometimes with the
> same PHY, which have no problem with EEE at all. The issue is really
> about the board design.
OK, not a problem then: of_machine_is_compatible() should help you here?
>
> What I propose is not an enable/disable configuration switch, but to
> clearly state that a particular mode of operation is broken. Like the
> "max-speed" property, it setup a restriction. IMO, this is a
> description of what the HW is and is capable of, and as such it should
> be part of the DT.
Sure, there is a fine line between describing what's broken, and being
able to use that to actually configure non-broken hardware the way you want.
>
> Yes the property directly map to a register, but it does let you
> directly manipulate it (you can't pass the value you want to write in
> the register). Having it this way just makes the code simple on both
> ends (user and driver).
That's exactly the part that is giving me the creeps, any property that
directly maps to a register value has a chance of a) leading to hard to
debug problem if mis-configured, and b) being used as a policy as
opposed to purely describing what is going on with the HW.
>
> Yes people could start abusing this to setup policy. In the end, it is
> our responsibility, as community, to make sure APIs are used in a
> proper way, and not let it be used that way.
>
> I'm open to suggestion on how improve the solution, maybe something
> which could bring more confidence that property won't be misused.
Once the binding lands in the kernel, there is absolutely zero guarantee
nor visibility in how people end-up using in e.g: DT aware bootloader,
and I am one of these people. Since there is a binding, there is
consumer code in the kernel that needs to behave properly with respect
to how the binding is defined. This is the same problem as with any kind
of ABI, and a diverse range of consumers.
--
Florian
^ permalink raw reply
* [PATCH v2] arm64: mm: Fix memmap to be initialized for the entire section
From: Robert Richter @ 2016-11-30 18:21 UTC (permalink / raw)
To: linux-arm-kernel
On ThunderX systems with certain memory configurations we see the
following BUG_ON():
kernel BUG at mm/page_alloc.c:1848!
This happens for some configs with 64k page size enabled. The BUG_ON()
checks if start and end page of a memmap range belongs to the same
zone.
The BUG_ON() check fails if a memory zone contains NOMAP regions. In
this case the node information of those pages is not initialized. This
causes an inconsistency of the page links with wrong zone and node
information for that pages. NOMAP pages from node 1 still point to the
mem zone from node 0 and have the wrong nid assigned.
The reason for the mis-configuration is a change in pfn_valid() which
reports pages marked NOMAP as invalid:
68709f45385a arm64: only consider memblocks with NOMAP cleared for linear mapping
This causes pages marked as nomap being no long reassigned to the new
zone in memmap_init_zone() by calling __init_single_pfn().
Fixing this by restoring the old behavior of pfn_valid() to use
memblock_is_memory(). Also changing users of pfn_valid() in arm64 code
to use memblock_is_map_memory() where necessary. This only affects
code in ioremap.c. The code in mmu.c still can use the new version of
pfn_valid().
As a consequence, pfn_valid() can not be used to check if a physical
page is RAM. It just checks if there is an underlying memmap with a
valid struct page. Moreover, for performance reasons the whole memmap
(with pageblock_nr_pages number of pages) has valid pfns (SPARSEMEM
config). The memory range is extended to fit the alignment of the
memmap. Thus, pfn_valid() may return true for pfns that do not map to
physical memory. Those pages are simply not reported to the mm, they
are not marked reserved nor added to the list of free pages. Other
functions such a page_is_ram() or memblock_is_map_ memory() must be
used to check for memory and if the page can be mapped with the linear
mapping.
Since NOMAP mem ranges may need to be mapped with different mem
attributes (e.g. read-only or non-caching) we can not use linear
mapping here. The use of memblock_is_memory() in pfn_valid() may not
break this behaviour. Since commit:
e7cd190385d1 arm64: mark reserved memblock regions explicitly in iomem
NOMAP mem resources are no longer marked as system RAM (IORESOURCE_
SYSTEM_RAM). Now page_is_ram() and region_intersects() (see
memremap()) do not detect NOMAP mem as system ram and NOMAP mem is not
added to the linear mapping as system RAM is.
v2:
* Added Ack
* updated description to reflect the discussion
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
arch/arm64/mm/init.c | 2 +-
arch/arm64/mm/ioremap.c | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 212c4d1e2f26..166911f4a2e6 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -147,7 +147,7 @@ static void __init zone_sizes_init(unsigned long min, unsigned long max)
#ifdef CONFIG_HAVE_ARCH_PFN_VALID
int pfn_valid(unsigned long pfn)
{
- return memblock_is_map_memory(pfn << PAGE_SHIFT);
+ return memblock_is_memory(pfn << PAGE_SHIFT);
}
EXPORT_SYMBOL(pfn_valid);
#endif
diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
index 01e88c8bcab0..c17c220b0c48 100644
--- a/arch/arm64/mm/ioremap.c
+++ b/arch/arm64/mm/ioremap.c
@@ -21,6 +21,7 @@
*/
#include <linux/export.h>
+#include <linux/memblock.h>
#include <linux/mm.h>
#include <linux/vmalloc.h>
#include <linux/io.h>
@@ -55,7 +56,7 @@ static void __iomem *__ioremap_caller(phys_addr_t phys_addr, size_t size,
/*
* Don't allow RAM to be mapped.
*/
- if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
+ if (WARN_ON(memblock_is_map_memory(phys_addr)))
return NULL;
area = get_vm_area_caller(size, VM_IOREMAP, caller);
@@ -96,7 +97,7 @@ EXPORT_SYMBOL(__iounmap);
void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
{
/* For normal memory we already have a cacheable mapping. */
- if (pfn_valid(__phys_to_pfn(phys_addr)))
+ if (memblock_is_map_memory(phys_addr))
return (void __iomem *)__phys_to_virt(phys_addr);
return __ioremap_caller(phys_addr, size, __pgprot(PROT_NORMAL),
--
2.1.4
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add support for A23 codec" to the asoc tree
From: Mark Brown @ 2016-11-30 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-5-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for A23 codec
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From dac5f86bc9e60eae87a28512f025362d1e2574e3 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Fri, 25 Nov 2016 20:34:36 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for A23 codec
The codec in the A23 is similar to the one found on the A31. One key
difference is the analog path controls are routed through the PRCM
block. This is supported by the sun8i-codec-analog driver, and tied
into this codec driver with the audio card's aux_dev.
In addition, the A23 does not have LINEOUT, and it does not support
headset jack detection or buttons.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/sound/sun4i-codec.txt | 11 ++-
sound/soc/sunxi/sun4i-codec.c | 108 +++++++++++++++++++++
2 files changed, 117 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index d91a95377f49..f7a548b604fc 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -5,6 +5,7 @@ Required properties:
- "allwinner,sun4i-a10-codec"
- "allwinner,sun6i-a31-codec"
- "allwinner,sun7i-a20-codec"
+ - "allwinner,sun8i-a23-codec"
- reg: must contain the registers location and length
- interrupts: must contain the codec interrupt
- dmas: DMA channels for tx and rx dma. See the DMA client binding,
@@ -21,6 +22,7 @@ Optional properties:
Required properties for the following compatibles:
- "allwinner,sun6i-a31-codec"
+ - "allwinner,sun8i-a23-codec"
- resets: phandle to the reset control for this device
- allwinner,audio-routing: A list of the connections between audio components.
Each entry is a pair of strings, the first being the
@@ -31,10 +33,10 @@ Required properties for the following compatibles:
"HP"
"HPCOM"
"LINEIN"
- "LINEOUT"
+ "LINEOUT" (not on sun8i-a23)
"MIC1"
"MIC2"
- "MIC3"
+ "MIC3" (sun6i-a31 only)
Microphone biases from the SoC:
"HBIAS"
@@ -48,6 +50,11 @@ Required properties for the following compatibles:
"Mic"
"Speaker"
+Required properties for the following compatibles:
+ - "allwinner,sun8i-a23-codec"
+- allwinner,codec-analog-controls: A phandle to the codec analog controls
+ block in the PRCM.
+
Example:
codec: codec at 01c22c00 {
#sound-dai-cells = <0>;
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 092fdcf6de95..ada5fa055950 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -213,6 +213,10 @@
/* TODO sun6i DAP (Digital Audio Processing) bits */
+/* FIFO counters moved on A23 */
+#define SUN8I_A23_CODEC_DAC_TXCNT (0x1c)
+#define SUN8I_A23_CODEC_ADC_RXCNT (0x20)
+
struct sun4i_codec {
struct device *dev;
struct regmap *regmap;
@@ -1067,6 +1071,32 @@ static struct snd_soc_codec_driver sun6i_codec_codec = {
},
};
+/* sun8i A23 codec */
+static const struct snd_kcontrol_new sun8i_a23_codec_codec_controls[] = {
+ SOC_SINGLE_TLV("DAC Playback Volume", SUN4I_CODEC_DAC_DPC,
+ SUN4I_CODEC_DAC_DPC_DVOL, 0x3f, 1,
+ sun6i_codec_dvol_scale),
+};
+
+static const struct snd_soc_dapm_widget sun8i_a23_codec_codec_widgets[] = {
+ /* Digital parts of the ADCs */
+ SND_SOC_DAPM_SUPPLY("ADC Enable", SUN6I_CODEC_ADC_FIFOC,
+ SUN6I_CODEC_ADC_FIFOC_EN_AD, 0, NULL, 0),
+ /* Digital parts of the DACs */
+ SND_SOC_DAPM_SUPPLY("DAC Enable", SUN4I_CODEC_DAC_DPC,
+ SUN4I_CODEC_DAC_DPC_EN_DA, 0, NULL, 0),
+
+};
+
+static struct snd_soc_codec_driver sun8i_a23_codec_codec = {
+ .component_driver = {
+ .controls = sun8i_a23_codec_codec_controls,
+ .num_controls = ARRAY_SIZE(sun8i_a23_codec_codec_controls),
+ .dapm_widgets = sun8i_a23_codec_codec_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(sun8i_a23_codec_codec_widgets),
+ },
+};
+
static const struct snd_soc_component_driver sun4i_codec_component = {
.name = "sun4i-codec",
};
@@ -1206,6 +1236,63 @@ static struct snd_soc_card *sun6i_codec_create_card(struct device *dev)
return card;
};
+/* Connect digital side enables to analog side widgets */
+static const struct snd_soc_dapm_route sun8i_codec_card_routes[] = {
+ /* ADC Routes */
+ { "Left ADC", NULL, "ADC Enable" },
+ { "Right ADC", NULL, "ADC Enable" },
+ { "Codec Capture", NULL, "Left ADC" },
+ { "Codec Capture", NULL, "Right ADC" },
+
+ /* DAC Routes */
+ { "Left DAC", NULL, "DAC Enable" },
+ { "Right DAC", NULL, "DAC Enable" },
+ { "Left DAC", NULL, "Codec Playback" },
+ { "Right DAC", NULL, "Codec Playback" },
+};
+
+static struct snd_soc_aux_dev aux_dev = {
+ .name = "Codec Analog Controls",
+};
+
+static struct snd_soc_card *sun8i_a23_codec_create_card(struct device *dev)
+{
+ struct snd_soc_card *card;
+ int ret;
+
+ card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL);
+ if (!card)
+ return ERR_PTR(-ENOMEM);
+
+ aux_dev.codec_of_node = of_parse_phandle(dev->of_node,
+ "allwinner,codec-analog-controls",
+ 0);
+ if (!aux_dev.codec_of_node) {
+ dev_err(dev, "Can't find analog controls for codec.\n");
+ return ERR_PTR(-EINVAL);
+ };
+
+ card->dai_link = sun4i_codec_create_link(dev, &card->num_links);
+ if (!card->dai_link)
+ return ERR_PTR(-ENOMEM);
+
+ card->dev = dev;
+ card->name = "A23 Audio Codec";
+ card->dapm_widgets = sun6i_codec_card_dapm_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
+ card->dapm_routes = sun8i_codec_card_routes;
+ card->num_dapm_routes = ARRAY_SIZE(sun8i_codec_card_routes);
+ card->aux_dev = &aux_dev;
+ card->num_aux_devs = 1;
+ card->fully_routed = true;
+
+ ret = snd_soc_of_parse_audio_routing(card, "allwinner,audio-routing");
+ if (ret)
+ dev_warn(dev, "failed to parse audio-routing: %d\n", ret);
+
+ return card;
+};
+
static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
@@ -1227,6 +1314,13 @@ static const struct regmap_config sun7i_codec_regmap_config = {
.max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
};
+static const struct regmap_config sun8i_a23_codec_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = SUN8I_A23_CODEC_ADC_RXCNT,
+};
+
struct sun4i_codec_quirks {
const struct regmap_config *regmap_config;
const struct snd_soc_codec_driver *codec;
@@ -1265,6 +1359,16 @@ static const struct sun4i_codec_quirks sun7i_codec_quirks = {
.reg_adc_rxdata = SUN4I_CODEC_ADC_RXDATA,
};
+static const struct sun4i_codec_quirks sun8i_a23_codec_quirks = {
+ .regmap_config = &sun8i_a23_codec_regmap_config,
+ .codec = &sun8i_a23_codec_codec,
+ .create_card = sun8i_a23_codec_create_card,
+ .reg_adc_fifoc = REG_FIELD(SUN6I_CODEC_ADC_FIFOC, 0, 31),
+ .reg_dac_txdata = SUN4I_CODEC_DAC_TXDATA,
+ .reg_adc_rxdata = SUN6I_CODEC_ADC_RXDATA,
+ .has_reset = true,
+};
+
static const struct of_device_id sun4i_codec_of_match[] = {
{
.compatible = "allwinner,sun4i-a10-codec",
@@ -1278,6 +1382,10 @@ static const struct of_device_id sun4i_codec_of_match[] = {
.compatible = "allwinner,sun7i-a20-codec",
.data = &sun7i_codec_quirks,
},
+ {
+ .compatible = "allwinner,sun8i-a23-codec",
+ .data = &sun8i_a23_codec_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun4i_codec_of_match);
--
2.10.2
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add support for H3 codec" to the asoc tree
From: Mark Brown @ 2016-11-30 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-9-wens@csie.org>
The patch
ASoC: sun4i-codec: Add support for H3 codec
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 4a15b24a65f13778f7616ad0a65be78d8ec0b45a Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Fri, 25 Nov 2016 20:34:40 +0800
Subject: [PATCH] ASoC: sun4i-codec: Add support for H3 codec
The codec on the H3 is similar to the one found on the A31. One key
difference is the analog path controls are routed through the PRCM
block. This is supported by the sun8i-codec-analog driver, and tied
into this codec driver with the audio card's aux_dev.
In addition, the H3 has no HP (headphone) and HBIAS support, and no
MIC3 input. The FIFO related registers are slightly rearranged.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/sound/sun4i-codec.txt | 3 +
sound/soc/sunxi/sun4i-codec.c | 71 ++++++++++++++++++++++
2 files changed, 74 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
index f7a548b604fc..3033bd8aab0f 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt
@@ -6,6 +6,7 @@ Required properties:
- "allwinner,sun6i-a31-codec"
- "allwinner,sun7i-a20-codec"
- "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-codec"
- reg: must contain the registers location and length
- interrupts: must contain the codec interrupt
- dmas: DMA channels for tx and rx dma. See the DMA client binding,
@@ -23,6 +24,7 @@ Optional properties:
Required properties for the following compatibles:
- "allwinner,sun6i-a31-codec"
- "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-codec"
- resets: phandle to the reset control for this device
- allwinner,audio-routing: A list of the connections between audio components.
Each entry is a pair of strings, the first being the
@@ -52,6 +54,7 @@ Required properties for the following compatibles:
Required properties for the following compatibles:
- "allwinner,sun8i-a23-codec"
+ - "allwinner,sun8i-h3-codec"
- allwinner,codec-analog-controls: A phandle to the codec analog controls
block in the PRCM.
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index ada5fa055950..848af01692a0 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -217,6 +217,13 @@
#define SUN8I_A23_CODEC_DAC_TXCNT (0x1c)
#define SUN8I_A23_CODEC_ADC_RXCNT (0x20)
+/* TX FIFO moved on H3 */
+#define SUN8I_H3_CODEC_DAC_TXDATA (0x20)
+#define SUN8I_H3_CODEC_DAC_DBG (0x48)
+#define SUN8I_H3_CODEC_ADC_DBG (0x4c)
+
+/* TODO H3 DAP (Digital Audio Processing) bits */
+
struct sun4i_codec {
struct device *dev;
struct regmap *regmap;
@@ -1293,6 +1300,44 @@ static struct snd_soc_card *sun8i_a23_codec_create_card(struct device *dev)
return card;
};
+static struct snd_soc_card *sun8i_h3_codec_create_card(struct device *dev)
+{
+ struct snd_soc_card *card;
+ int ret;
+
+ card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL);
+ if (!card)
+ return ERR_PTR(-ENOMEM);
+
+ aux_dev.codec_of_node = of_parse_phandle(dev->of_node,
+ "allwinner,codec-analog-controls",
+ 0);
+ if (!aux_dev.codec_of_node) {
+ dev_err(dev, "Can't find analog controls for codec.\n");
+ return ERR_PTR(-EINVAL);
+ };
+
+ card->dai_link = sun4i_codec_create_link(dev, &card->num_links);
+ if (!card->dai_link)
+ return ERR_PTR(-ENOMEM);
+
+ card->dev = dev;
+ card->name = "H3 Audio Codec";
+ card->dapm_widgets = sun6i_codec_card_dapm_widgets;
+ card->num_dapm_widgets = ARRAY_SIZE(sun6i_codec_card_dapm_widgets);
+ card->dapm_routes = sun8i_codec_card_routes;
+ card->num_dapm_routes = ARRAY_SIZE(sun8i_codec_card_routes);
+ card->aux_dev = &aux_dev;
+ card->num_aux_devs = 1;
+ card->fully_routed = true;
+
+ ret = snd_soc_of_parse_audio_routing(card, "allwinner,audio-routing");
+ if (ret)
+ dev_warn(dev, "failed to parse audio-routing: %d\n", ret);
+
+ return card;
+};
+
static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
@@ -1321,6 +1366,13 @@ static const struct regmap_config sun8i_a23_codec_regmap_config = {
.max_register = SUN8I_A23_CODEC_ADC_RXCNT,
};
+static const struct regmap_config sun8i_h3_codec_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = SUN8I_H3_CODEC_ADC_DBG,
+};
+
struct sun4i_codec_quirks {
const struct regmap_config *regmap_config;
const struct snd_soc_codec_driver *codec;
@@ -1369,6 +1421,21 @@ static const struct sun4i_codec_quirks sun8i_a23_codec_quirks = {
.has_reset = true,
};
+static const struct sun4i_codec_quirks sun8i_h3_codec_quirks = {
+ .regmap_config = &sun8i_h3_codec_regmap_config,
+ /*
+ * TODO Share the codec structure with A23 for now.
+ * This should be split out when adding digital audio
+ * processing support for the H3.
+ */
+ .codec = &sun8i_a23_codec_codec,
+ .create_card = sun8i_h3_codec_create_card,
+ .reg_adc_fifoc = REG_FIELD(SUN6I_CODEC_ADC_FIFOC, 0, 31),
+ .reg_dac_txdata = SUN8I_H3_CODEC_DAC_TXDATA,
+ .reg_adc_rxdata = SUN6I_CODEC_ADC_RXDATA,
+ .has_reset = true,
+};
+
static const struct of_device_id sun4i_codec_of_match[] = {
{
.compatible = "allwinner,sun4i-a10-codec",
@@ -1386,6 +1453,10 @@ static const struct of_device_id sun4i_codec_of_match[] = {
.compatible = "allwinner,sun8i-a23-codec",
.data = &sun8i_a23_codec_quirks,
},
+ {
+ .compatible = "allwinner,sun8i-h3-codec",
+ .data = &sun8i_h3_codec_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun4i_codec_of_match);
--
2.10.2
^ permalink raw reply related
* [PATCH v3 0/3] Altera Cyclone Passive Serial SPI FPGA Manager
From: atull @ 2016-11-30 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1480467185.git.stillcompiling@gmail.com>
On Wed, 30 Nov 2016, Joshua Clayton wrote:
Hi Joshua,
The DT bindings will need Rob Herring's ack. The bitrev.h
changes will need Russell King's ack.
I've made some comments on patch 3/3 but it looks good to me
besides that.
Once we have those other acks, please submit your v4 including fixes
for my comments and whatever else comes up. I'm hoping it will be
minor and with that done, v4 can go in.
When you send in v4, please also cc our new mailing list that Moritz
made: linux-fpga at vger.kernel.org
Alan
> This series adds an FPGA manager for Altera cyclone FPGAs
> that can program them using an spi port and a couple of gpios, using
> Alteras passive serial protocol.
>
> Changes from v2:
>
> - Merged patch 3 and 4 as suggested in review by Moritz Fischer
> - Changed FPGA_MIN_DELAY from 250 to 50 ms is the time advertized by
> Altera. This now works, as we don't assume it is done
>
> Changes from v1:
> - Changed the name from cyclone-spi-fpga-mgr to cyclone-ps-spi-fpga-mgr
> This name change was requested by Alan Tull, to be specific about which
> programming method is being employed on the fpga.
> - Changed the name of the reset-gpio to config-gpio to closer match the
> way the pins are described in the Altera manual
> - Moved MODULE_LICENCE, _AUTHOR, and _DESCRIPTION to the bottom
>
> - Added a bitrev8x4() function to the bitrev headers and implemented ARM
> const, runtime, and ARM specific faster versions (This may end up
> needing to be a standalone patch)
>
> - Moved the bitswapping into cyclonespi_write(), as requested.
> This falls short of my desired generic lsb first spi support, but is a step
> in that direction.
>
> - Fixed whitespace problems introduced during refactoring
>
> - Replaced magic number for initial delay with a descriptive macro
> - Poll the fpga to see when it is ready rather than a fixed 1 ms sleep
>
> Joshua Clayton (3):
> lib: add bitrev8x4()
> doc: dt: add cyclone-spi binding document
> fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
>
> .../bindings/fpga/cyclone-ps-spi-fpga-mgr.txt | 23 +++
> arch/arm/include/asm/bitrev.h | 5 +
> drivers/fpga/Kconfig | 7 +
> drivers/fpga/Makefile | 1 +
> drivers/fpga/cyclone-ps-spi.c | 176 +++++++++++++++++++++
> include/linux/bitrev.h | 26 +++
> 6 files changed, 238 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
> create mode 100644 drivers/fpga/cyclone-ps-spi.c
>
> --
> 2.9.3
>
>
^ permalink raw reply
* [GIT PULL] ARM: keystone: add TI SCI protocol support for v4.10
From: Tero Kristo @ 2016-11-30 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9563335.412haHXOPG@wuerfel>
On 30/11/16 18:43, Arnd Bergmann wrote:
> On Monday, November 28, 2016 6:42:41 PM CET Tero Kristo wrote:
>> Gentle ping on this, is anybody going to pull this one?
>>
>> -Tero
>>
>> On 27/10/16 12:30, Tero Kristo wrote:
>>> Hi Arnd, Olof, Kevin,
>>>
>>> This pull introduces the TI SCI protocol support for keystone family of
>>> devices, targeted for v4.10 merge window. We discussed with Santosh
>>> (keystone maintainer) that it would probably be better that I'll be
>>> sending the pull requests for this directly, avoiding one extra step of
>>> merges.
>>
>
> Sorry for the delay. I just saw this pull request in the backlog
> and had to take a closer look first. I probably would have commented
> on a few details in a proper review, but overall this seems harmless
> enough, so I've merged it into next/drivers in the end.
>
> There was no branch description in
> https://github.com/t-kristo/linux-pm.git for-4.10-ti-sci-base
> and I ended up taking something from the wiki. This is now the
> commit I ended up with:
Thanks Arnd, that looks good to me.
I'll figure out how to add branch description next time when I am going
to be sending a pull-request directly to you guys.
-Tero
>
> commit ba9cb7b9ffa4a4056158bc8570f1a851e4a6a8ae
> Merge: e7541f9 912cffb
> Author: Arnd Bergmann <arnd@arndb.de>
> Date: Wed Nov 30 17:13:13 2016 +0100
>
> Merge branch 'for-4.10-ti-sci-base' of https://github.com/t-kristo/linux-pm into next/drivers
>
> Merge "ARM: keystone: add TI SCI protocol support for v4.10" from
> Tero Kristo:
>
> [description taken from http://processors.wiki.ti.com/index.php/TISCI
>
> Texas Instruments' Keystone generation System on Chips (SoC) starting
> with 66AK2G02, now include a dedicated SoC System Control entity called
> PMMC(Power Management Micro Controller) in line with ARM architecture
> recommendations. The function of this module is to integrate all system
> operations in a centralized location. Communication with the SoC System
> Control entity from various processing units like ARM/DSP occurs over
> Message Manager hardware block.
>
> ...
>
> Texas Instruments' System Control Interface defines the communication
> protocol between various processing entities to the System Control Entity
> on TI SoCs. This is a set of message formats and sequence of operations
> required to communicate and get system services processed from System
> Control entity in the SoC.]
>
> * 'for-4.10-ti-sci-base' of https://github.com/t-kristo/linux-pm:
> firmware: ti_sci: Add support for reboot core service
> firmware: ti_sci: Add support for Clock control
> firmware: ti_sci: Add support for Device control
> firmware: Add basic support for TI System Control Interface (TI-SCI) protocol
> Documentation: Add support for TI System Control Interface (TI-SCI) protocol
>
> Arnd
>
^ permalink raw reply
* [PATCH v3 3/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: atull @ 2016-11-30 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e193572d7746e6f6b8666da7ac0f54031fed5214.1480467185.git.stillcompiling@gmail.com>
On Wed, 30 Nov 2016, Joshua Clayton wrote:
Hi Clayton,
I just have a few minor one line changes below. Only one
is operational, I should have caught that earlier.
> cyclone-ps-spi loads FPGA firmware over spi, using the "passive serial"
> interface on Altera Cyclone FPGAS.
>
> This is one of the simpler ways to set up an FPGA at runtime.
> The signal interface is close to unidirectional spi with lsb first.
>
> Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
> ---
> drivers/fpga/Kconfig | 7 ++
> drivers/fpga/Makefile | 1 +
> drivers/fpga/cyclone-ps-spi.c | 176 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 184 insertions(+)
> create mode 100644 drivers/fpga/cyclone-ps-spi.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index cd84934..2462707 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -13,6 +13,13 @@ config FPGA
>
> if FPGA
>
> +config FPGA_MGR_CYCLONE_PS_SPI
> + tristate "Altera Cyclone FPGA Passive Serial over SPI"
> + depends on SPI
> + help
> + FPGA manager driver support for Altera Cyclone using the
> + passive serial interface over SPI
> +
> config FPGA_MGR_SOCFPGA
> tristate "Altera SOCFPGA FPGA Manager"
> depends on ARCH_SOCFPGA
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 8d83fc6..8f93930 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -6,5 +6,6 @@
> obj-$(CONFIG_FPGA) += fpga-mgr.o
>
> # FPGA Manager Drivers
> +obj-$(CONFIG_FPGA_MGR_CYCLONE_PS_SPI) += cyclone-ps-spi.o
> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> diff --git a/drivers/fpga/cyclone-ps-spi.c b/drivers/fpga/cyclone-ps-spi.c
> new file mode 100644
> index 0000000..57a520d
> --- /dev/null
> +++ b/drivers/fpga/cyclone-ps-spi.c
> @@ -0,0 +1,176 @@
> +/**
> + * Copyright (c) 2015 United Western Technologies, Corporation
> + *
> + * Joshua Clayton <stillcompiling@gmail.com>
> + *
> + * Manage Altera fpga firmware that is loaded over spi.
> + * Firmware must be in binary "rbf" format.
> + * Works on Cyclone V. Should work on cyclone series.
> + * May work on other Altera fpgas.
> + *
> + */
> +
> +#include <linux/bitrev.h>
> +#include <linux/delay.h>
> +#include <linux/fpga/fpga-mgr.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of_gpio.h>
> +#include <linux/spi/spi.h>
> +#include <linux/sizes.h>
> +
> +#define FPGA_RESET_TIME 50 /* time in usecs to trigger FPGA config */
> +#define FPGA_MIN_DELAY 50 /* min usecs to wait for config status */
> +#define FPGA_MAX_DELAY 1000 /* max usecs to wait for config status */
> +
> +struct cyclonespi_conf {
> + struct gpio_desc *config;
> + struct gpio_desc *status;
> + struct spi_device *spi;
> +};
> +
> +static const struct of_device_id of_ef_match[] = {
> + { .compatible = "altr,cyclone-ps-spi-fpga-mgr", },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, of_ef_match);
> +
> +static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
> +{
> + return mgr->state;
> +}
This function gets called once to initialize mgr->state in
fpga_mgr_register(). So it should at least return the state the FPGA
is at then. If it is unknown, it can just return
FPGA_MGR_STATE_UNKNOWN.
> +
> +static int cyclonespi_write_init(struct fpga_manager *mgr, u32 flags,
> + const char *buf, size_t count)
Minor, but please fix the indentation of 'const' to match that of
'struct' above. checkpatch.pl is probably issuing warnings
about that.
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> + int i;
> +
> + if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
> + dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
> + return -EINVAL;
> + }
> +
> + gpiod_set_value(conf->config, 0);
> + usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
> + if (gpiod_get_value(conf->status) == 1) {
> + dev_err(&mgr->dev, "Status pin should be low.\n");
> + return -EIO;
> + }
> +
> + gpiod_set_value(conf->config, 1);
> + for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
> + usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
> + if (gpiod_get_value(conf->status))
> + return 0;
> + }
> +
> + dev_err(&mgr->dev, "Status pin not ready.\n");
> + return -EIO;
> +}
> +
> +static void rev_buf(void *buf, size_t len)
> +{
> + u32 *fw32 = (u32 *)buf;
> + const u32 *fw_end = (u32 *)(buf + len);
> +
> + /* set buffer to lsb first */
> + while (fw32 < fw_end) {
> + *fw32 = bitrev8x4(*fw32);
> + fw32++;
> + }
> +}
> +
> +static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
> + size_t count)
Please fix alignment here also.
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> + const char *fw_data = buf;
> + const char *fw_data_end = fw_data + count;
> +
> + while (fw_data < fw_data_end) {
> + int ret;
> + size_t stride = min(fw_data_end - fw_data, SZ_4K);
> +
> + rev_buf((void *)fw_data, stride);
> + ret = spi_write(conf->spi, fw_data, stride);
> + if (ret) {
> + dev_err(&mgr->dev, "spi error in firmware write: %d\n",
> + ret);
> + return ret;
> + }
> + fw_data += stride;
> + }
> +
> + return 0;
> +}
> +
> +static int cyclonespi_write_complete(struct fpga_manager *mgr, u32 flags)
> +{
> + struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
> +
> + if (gpiod_get_value(conf->status) == 0) {
> + dev_err(&mgr->dev, "Error during configuration.\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static const struct fpga_manager_ops cyclonespi_ops = {
> + .state = cyclonespi_state,
> + .write_init = cyclonespi_write_init,
> + .write = cyclonespi_write,
> + .write_complete = cyclonespi_write_complete,
> +};
> +
> +static int cyclonespi_probe(struct spi_device *spi)
> +{
> + struct cyclonespi_conf *conf = devm_kzalloc(&spi->dev, sizeof(*conf),
> + GFP_KERNEL);
> +
> + if (!conf)
> + return -ENOMEM;
> +
> + conf->spi = spi;
> + conf->config = devm_gpiod_get(&spi->dev, "config", GPIOD_OUT_LOW);
> + if (IS_ERR(conf->config)) {
> + dev_err(&spi->dev, "Failed to get config gpio: %ld\n",
> + PTR_ERR(conf->config));
> + return PTR_ERR(conf->config);
> + }
> +
> + conf->status = devm_gpiod_get(&spi->dev, "status", GPIOD_IN);
> + if (IS_ERR(conf->status)) {
> + dev_err(&spi->dev, "Failed to get status gpio: %ld\n",
> + PTR_ERR(conf->status));
> + return PTR_ERR(conf->status);
> + }
> +
> + return fpga_mgr_register(&spi->dev,
> + "Altera Cyclone PS SPI FPGA Manager",
> + &cyclonespi_ops, conf);
> +}
> +
> +static int cyclonespi_remove(struct spi_device *spi)
> +{
> + fpga_mgr_unregister(&spi->dev);
> +
> + return 0;
> +}
> +
> +static struct spi_driver cyclonespi_driver = {
> + .driver = {
> + .name = "cyclone-ps-spi",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(of_ef_match),
> + },
> + .probe = cyclonespi_probe,
> + .remove = cyclonespi_remove,
> +};
> +
> +module_spi_driver(cyclonespi_driver)
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Joshua Clayton <stillcompiling@gmail.com>");
> +MODULE_DESCRIPTION("Module to load Altera FPGA firmware over spi");
> --
> 2.9.3
>
>
Thanks,
Alan
^ permalink raw reply
* [PATCH 2/2] ARM: dts: at91: sama5d4 Xplained: enable UART1 node with DMA
From: Nicolas Ferre @ 2016-11-30 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130173630.11944-1-nicolas.ferre@atmel.com>
Enable UART1 and use DMA configuration with it.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/at91-sama5d4_xplained.dts | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d4_xplained.dts b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
index ed7fce297738..91cf69e26aa1 100644
--- a/arch/arm/boot/dts/at91-sama5d4_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d4_xplained.dts
@@ -69,6 +69,12 @@
ahb {
apb {
+ uart0: serial at f8004000 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
+ status = "okay";
+ };
+
spi0: spi at f8010000 {
cs-gpios = <&pioC 3 0>, <0>, <0>, <0>;
status = "okay";
--
2.9.0
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: at91: sama5d4: change DMA allocation for secure peripherals
From: Nicolas Ferre @ 2016-11-30 17:36 UTC (permalink / raw)
To: linux-arm-kernel
Some peripherals are "Programmable Secure" but left as "Secure" by default.
If tried to be connected to Non-Secure DMA controller, the possibility to
leak secure data is prevented so using these peripherals with DMA1 is not
possible with this default configuration (MATRIX_SPSELR registers setup by
bootloader).
Move them to DMA0 which is an "Always-Secure" DMA controller.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/sama5d4.dtsi | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 4f60c1b7b137..d3889c9d25a9 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -854,10 +854,10 @@
compatible = "atmel,at91sam9260-usart";
reg = <0xf8004000 0x100>;
interrupts = <27 IRQ_TYPE_LEVEL_HIGH 5>;
- dmas = <&dma1
+ dmas = <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(22))>,
- <&dma1
+ <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(23))>;
dma-names = "tx", "rx";
@@ -938,10 +938,10 @@
compatible = "atmel,sama5d4-i2c";
reg = <0xf8018000 0x4000>;
interrupts = <33 IRQ_TYPE_LEVEL_HIGH 6>;
- dmas = <&dma1
+ dmas = <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(4))>,
- <&dma1
+ <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(5))>;
dma-names = "tx", "rx";
@@ -1055,10 +1055,10 @@
compatible = "atmel,at91sam9260-usart";
reg = <0xfc004000 0x100>;
interrupts = <28 IRQ_TYPE_LEVEL_HIGH 5>;
- dmas = <&dma1
+ dmas = <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(24))>,
- <&dma1
+ <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(25))>;
dma-names = "tx", "rx";
@@ -1167,10 +1167,10 @@
compatible = "atmel,at91rm9200-spi";
reg = <0xfc01c000 0x100>;
interrupts = <39 IRQ_TYPE_LEVEL_HIGH 3>;
- dmas = <&dma1
+ dmas = <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(14))>,
- <&dma1
+ <&dma0
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)
| AT91_XDMAC_DT_PERID(15))>;
dma-names = "tx", "rx";
--
2.9.0
^ permalink raw reply related
* [linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Icenowy Zheng @ 2016-11-30 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130114415.2280151e2965280733a629e5@free.fr>
30.11.2016, 18:44, "Jean-Francois Moine" <moinejf@free.fr>:
> On Wed, 30 Nov 2016 11:52:25 +0200
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>
>> ?Hi Jean-Fran?ois,
>>
>> ?On Wednesday 30 Nov 2016 10:27:57 Jean-Francois Moine wrote:
>> ?> On Wed, 30 Nov 2016 10:20:21 +0200 Laurent Pinchart wrote:
>> ?> >> Well, I don't see what this connector can be.
>> ?> >> May you give me a DT example?
>> ?> >
>> ?> > Sure.
>> ?> >
>> ?> > arch/arm/boot/dts/r8a7791-koelsch.dts
>> ?> >
>> ?> > /* HDMI encoder */
>
> ????????[snip]
>> ?> > /* HDMI connector */
>> ?> >
>> ?> > hdmi-out {
>> ?> > compatible = "hdmi-connector";
>> ?> > type = "a";
>> ?> >
>> ?> > port {
>> ?> > hdmi_con: endpoint {
>> ?> > remote-endpoint = <&adv7511_out>;
>> ?> > };
>> ?> > };
>> ?> > };
>
> ????????[snip]
>> ?> - what does the software do with the connector type?
>>
>> ?That's up to the software to decide, the DT bindings should describe the
>> ?hardware in the most accurate and usable way for the OS as possible. One of my
>> ?longer term goals is to add connector drivers to handle DDC and HPD when
>> ?they're not handled by the encoder (they are in the above example).
>>
>> ?If the DDC was connected to a general-purpose I2C bus of the SoC, and the HPD
>> ?to a GPIO, we would have
>>
>> ?????????hdmi-out {
>> ?????????????????compatible = "hdmi-connector";
>> ?????????????????type = "a";
>> ?????????????????/* I2C bus and GPIO references are made up for the example */
>> ?????????????????ddc-i2c-bus = <&i2c4>;
>> ?????????????????hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>
>>
>> ?????????????????port {
>> ?????????????????????????hdmi_con: endpoint {
>> ?????????????????????????????????remote-endpoint = <&adv7511_out>;
>> ?????????????????????????};
>> ?????????????????};
>> ?????????};
>>
>> ?and both HPD and EDID reading should be handled by the connector driver.
>
> ????????[snip]
>
> Hi Laurent,
>
> OK. I understand. This connector complexity should be added in all DTs,
> and the same code would be used.
>
> Actually, for component binding, I use drm_of_component_probe():
>
> - from the DRM master, loop on the "ports" phandle array and bind the
> ??CRTCs,
>
> - for each CRTC, loop on the first remote port level and bind the
> ??encoders/connectors
>
> Now, this should be:
>
> - from the DRM master, loop on the first remote ports level and bind
> ??the CRTCs,
>
> - for each CRTC, loop on the second remote port level and bind the
> ??encoders (and bridges?),
>
> - for each encoder, loop on the third remote port level and bind the
> ??connectors.
>
> Then, it would be nice to have a generic function for doing this job.
>
> Otherwise, from your description:
>
>> ?????????hdmi-out {
>> ?????????????????compatible = "hdmi-connector";
>> ?????????????????type = "a";
>> ?????????????????/* I2C bus and GPIO references are made up for the example */
>> ?????????????????ddc-i2c-bus = <&i2c4>;
>> ?????????????????hpd-gpios = <&gpio4 7 GPIO_ACTIVE_HIGH>
>
> the "hdmi-connector" is a big piece of software. It must handle a lot
> of more and more exotic connectors.
> So, I hope that you have written a "simple-hdmi-connector" which does
> nothing but setting the connector type.
> Where is it?
I suddenly thought about something...
If a DVI connector instead of a HDMI connector is soldered, how should such a
device tree be written?
How about solder a HDMI-to-VGA bridge on the board? (Maybe there should be
"dumb-hdmi-dvi-bridge" and "dumb-hdmi-vga-bridge" drivers?)
>
> --
> Ken ar c'henta? | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Icenowy Zheng @ 2016-11-30 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130102757.9eec1f7f3377d0f4787e3829@free.fr>
30.11.2016, 17:28, "Jean-Francois Moine" <moinejf@free.fr>:
> On Wed, 30 Nov 2016 10:20:21 +0200
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>
>> ?> Well, I don't see what this connector can be.
>> ?> May you give me a DT example?
>>
>> ?Sure.
>>
>> ?arch/arm/boot/dts/r8a7791-koelsch.dts
>>
>> ?????????/* HDMI encoder */
>>
>> ?????????hdmi at 39 {
>> ?????????????????compatible = "adi,adv7511w";
>> ?????????????????reg = <0x39>;
>> ?????????????????interrupt-parent = <&gpio3>;
>> ?????????????????interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
>>
>> ?????????????????adi,input-depth = <8>;
>> ?????????????????adi,input-colorspace = "rgb";
>> ?????????????????adi,input-clock = "1x";
>> ?????????????????adi,input-style = <1>;
>> ?????????????????adi,input-justification = "evenly";
>>
>> ?????????????????ports {
>> ?????????????????????????#address-cells = <1>;
>> ?????????????????????????#size-cells = <0>;
>>
>> ?????????????????????????port at 0 {
>> ?????????????????????????????????reg = <0>;
>> ?????????????????????????????????adv7511_in: endpoint {
>> ?????????????????????????????????????????remote-endpoint = <&du_out_rgb>;
>> ?????????????????????????????????};
>> ?????????????????????????};
>>
>> ?????????????????????????port at 1 {
>> ?????????????????????????????????reg = <1>;
>> ?????????????????????????????????adv7511_out: endpoint {
>> ?????????????????????????????????????????remote-endpoint = <&hdmi_con>;
>> ?????????????????????????????????};
>> ?????????????????????????};
>> ?????????????????};
>> ?????????};
>>
>> ?????????/* HDMI connector */
>>
>> ?????????hdmi-out {
>> ?????????????????compatible = "hdmi-connector";
>> ?????????????????type = "a";
>>
>> ?????????????????port {
>> ?????????????????????????hdmi_con: endpoint {
>> ?????????????????????????????????remote-endpoint = <&adv7511_out>;
>> ?????????????????????????};
>> ?????????????????};
>> ?????????};
>
> Hi Laurent,
>
> Sorry for I don't see the interest:
> - it is obvious that the HDMI connector is a 'hdmi-connector'!
Yes, it means the wire between the HDMI pins on the SoC and the connector ;-)
> - the physical connector type may be changed on any board by a soldering
> ??iron or a connector to connector cable.
I can always alter the devices on a board ;-)
But I should also alter the dt after altering the board.
> - what does the software do with the connector type?
> - why not to put the connector information in the HDMI device?
>
> And, if I follow you, the graph of ports could also be used to describe
> the way the various parts of the SoCs are powered, to describe the pin
> connections, to describe the USB connectors, to describe the board
> internal hubs and bridges...
>
> --
> Ken ar c'henta? | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCHv4 05/10] arm64: Use __pa_symbol for kernel symbols
From: Catalin Marinas @ 2016-11-30 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480445729-27130-6-git-send-email-labbott@redhat.com>
On Tue, Nov 29, 2016 at 10:55:24AM -0800, Laura Abbott wrote:
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -205,6 +205,8 @@ static inline void *phys_to_virt(phys_addr_t x)
> #define __va(x) ((void *)__phys_to_virt((phys_addr_t)(x)))
> #define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT)
> #define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x)))
> +#define sym_to_pfn(x) __phys_to_pfn(__pa_symbol(x))
> +#define lm_alias(x) __va(__pa_symbol(x))
[...]
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -76,6 +76,10 @@ extern int mmap_rnd_compat_bits __read_mostly;
> #define page_to_virt(x) __va(PFN_PHYS(page_to_pfn(x)))
> #endif
>
> +#ifndef lm_alias
> +#define lm_alias(x) __va(__pa_symbol(x))
> +#endif
You can drop the arm64-specific lm_alias macro as it's the same as the
generic one you introduced in the same patch.
--
Catalin
^ permalink raw reply
* [PATCH] soc: ti: qmss: fix the case when !SMP
From: Santosh Shilimkar @ 2016-11-30 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0a2d9284-d1e3-c848-42a4-66b06babba80@ti.com>
On 11/30/2016 9:10 AM, Grygorii Strashko wrote:
>
> Hi Santosh,
>
> On 11/30/2016 11:01 AM, Santosh Shilimkar wrote:
>> Hi Grygorii,
>>
>> On 11/30/2016 3:37 AM, Arnd Bergmann wrote:
>>> On Tuesday, November 29, 2016 4:15:08 PM CET Grygorii Strashko wrote:
>>>> range->num_irqs++;
>>>>
>>>> - if (oirq.args_count == 3)
>>>> + if (IS_ENABLED(SMP) && oirq.args_count == 3)
>>>> range->irqs[i].cpu_map =
>>>> (oirq.args[2] & 0x0000ff00) >> 8;
>>>>
>>>
>>> I think you mean CONFIG_SMP, not SMP. With the change above, the
>>> code will never be executed.
>>>
>> Is that the full patch ? Can you post updated patch wit above fixed
>> and copy me. I will pick it up.
>>
>
> I've sent v2.
>
> For some reason you e-email is not working - delivery failure
> ssantosh at kernel.org
>
Weird. I was getting all the emails. Thanks for bouncing the thread.
I will check.
^ permalink raw reply
* [PATCH v2] soc: ti: qmss: fix the case when !SMP
From: Santosh Shilimkar @ 2016-11-30 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d26f37e6-657f-ff42-2d9d-343fa47c2e5d@ti.com>
Hi Anrd,
Can you apply this to your non critical fixes queue ?
On 11/30/2016 9:09 AM, Grygorii Strashko wrote:
> + Santosh Shilimkar <santosh.shilimkar@oracle.com>
>
> On 11/30/2016 10:53 AM, Grygorii Strashko wrote:
>> The irq_set_affinity_hint() will always fail when !SMP and
>> Networking will fail on Keystone 2 devices in this case.
>> Hence, fix by ignoring IRQ affinity settings when !SMP.
>>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> ---
Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
>> drivers/soc/ti/knav_qmss_queue.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/soc/ti/knav_qmss_queue.c
>> b/drivers/soc/ti/knav_qmss_queue.c
>> index b73e353..eacad57 100644
>> --- a/drivers/soc/ti/knav_qmss_queue.c
>> +++ b/drivers/soc/ti/knav_qmss_queue.c
>> @@ -1228,7 +1228,7 @@ static int knav_setup_queue_range(struct
>> knav_device *kdev,
>>
>> range->num_irqs++;
>>
>> - if (oirq.args_count == 3)
>> + if (IS_ENABLED(CONFIG_SMP) && oirq.args_count == 3)
>> range->irqs[i].cpu_map =
>> (oirq.args[2] & 0x0000ff00) >> 8;
>> }
>>
>
^ permalink raw reply
* [PATCH] soc: ti: qmss: fix the case when !SMP
From: Grygorii Strashko @ 2016-11-30 17:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2531f769-dd28-dfbd-0ed7-b209ef6ae98d@oracle.com>
Hi Santosh,
On 11/30/2016 11:01 AM, Santosh Shilimkar wrote:
> Hi Grygorii,
>
> On 11/30/2016 3:37 AM, Arnd Bergmann wrote:
>> On Tuesday, November 29, 2016 4:15:08 PM CET Grygorii Strashko wrote:
>>> range->num_irqs++;
>>>
>>> - if (oirq.args_count == 3)
>>> + if (IS_ENABLED(SMP) && oirq.args_count == 3)
>>> range->irqs[i].cpu_map =
>>> (oirq.args[2] & 0x0000ff00) >> 8;
>>>
>>
>> I think you mean CONFIG_SMP, not SMP. With the change above, the
>> code will never be executed.
>>
> Is that the full patch ? Can you post updated patch wit above fixed
> and copy me. I will pick it up.
>
I've sent v2.
For some reason you e-email is not working - delivery failure
ssantosh at kernel.org
--
regards,
-grygorii
^ permalink raw reply
* [PATCH v2] soc: ti: qmss: fix the case when !SMP
From: Grygorii Strashko @ 2016-11-30 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130165351.1154-1-grygorii.strashko@ti.com>
+ Santosh Shilimkar <santosh.shilimkar@oracle.com>
On 11/30/2016 10:53 AM, Grygorii Strashko wrote:
> The irq_set_affinity_hint() will always fail when !SMP and
> Networking will fail on Keystone 2 devices in this case.
> Hence, fix by ignoring IRQ affinity settings when !SMP.
>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
> drivers/soc/ti/knav_qmss_queue.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
> index b73e353..eacad57 100644
> --- a/drivers/soc/ti/knav_qmss_queue.c
> +++ b/drivers/soc/ti/knav_qmss_queue.c
> @@ -1228,7 +1228,7 @@ static int knav_setup_queue_range(struct knav_device *kdev,
>
> range->num_irqs++;
>
> - if (oirq.args_count == 3)
> + if (IS_ENABLED(CONFIG_SMP) && oirq.args_count == 3)
> range->irqs[i].cpu_map =
> (oirq.args[2] & 0x0000ff00) >> 8;
> }
>
--
regards,
-grygorii
^ permalink raw reply
* question about irq_enter()/irq_exit() calling policy
From: Grygorii Strashko @ 2016-11-30 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130102134.GB14217@n2100.armlinux.org.uk>
Hi Russell,
On 11/30/2016 04:21 AM, Russell King - ARM Linux wrote:
> On Tue, Nov 29, 2016 at 05:47:12PM -0600, Grygorii Strashko wrote:
>> 2) Should these function be called for each processed irq?
>>
>>
>> HW IRQ:
>> switch (IRQ mode)
>> ...
>> while (irq = get_pending_irq()) {
>> ...
>> irq_enter()
>> handle(irq) - execute hw_irq_hadler
>> irq_exit()
>> }
>> ...
>> switch
>
> We tend to do (2) as a general rule, which isn't much different from what
> other architectures do - even if they have a method to directly enter
> through vectors (eg, x86) the effect of two pending interrupts is that one
> will run after each other, and there will be an intervening exit -> entry.
>
> In the case of ARM CPUs, if the interrupt signal is active, you vector
> back to the interrupt handler as soon as you exit back to the parent
> context without executing any parent context instructions.
>
> So, we have the choice of going through all the IRQ entry code, processing
> one interrupt, and returning only to then re-vector back through the IRQ
> entry code, or we can process all the pending IRQs that we can see at that
> time.
>
> The former method wastes all the CPU cycles getting from the parent context
> to the IRQ context for each and every interrupt.
>
Thanks a lot for your detailed explanation.
When I've asked this question my intention was to understand possibility of calling
irq_enter()/irq_exit() only once for the case (2), like:
HW IRQ:
switch (IRQ mode)
...
irq_enter()
while (irq = get_pending_irq()) {
...
handle(irq) - execute hw_irq_hadler
}
irq_exit()
...
switch
--
regards,
-grygorii
^ permalink raw reply
* [PATCH v3 2/5] i2c: Add STM32F4 I2C driver
From: M'boumba Cedric Madianga @ 2016-11-30 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130162353.GC1441@katana>
Hi,
2016-11-30 17:23 GMT+01:00 Wolfram Sang <wsa-dev@sang-engineering.com>:
> Hi,
>
>> I was too busy in another project but now I am ready to complete the
>> upstream of the STM32F4 I2C driver.
>
> Nice.
>
>> >> +static void stm32f4_i2c_set_periph_clk_freq(struct stm32f4_i2c_dev *i2c_dev)
>> >> +{
>> >> + u32 clk_rate, cr2, freq;
>> >> +
>> >> + cr2 = readl_relaxed(i2c_dev->base + STM32F4_I2C_CR2);
>> >> + cr2 &= ~STM32F4_I2C_CR2_FREQ_MASK;
>> >> +
>> >> + clk_rate = clk_get_rate(i2c_dev->clk);
>> >> + freq = clk_rate / MHZ_TO_HZ;
>> >> +
>> >> + if (freq > STM32F4_I2C_MAX_FREQ)
>> >> + freq = STM32F4_I2C_MAX_FREQ;
>> >> + if (freq < STM32F4_I2C_MIN_FREQ)
>> >> + freq = STM32F4_I2C_MIN_FREQ;
>> >
>> > clamp() to enforce the range?
>> Sorry but what do you mean by "clamp()" ?
>
> The kernel has a clamp() function which would fit this purpose, I think.
Ok I got it. I will fix it in the V4.
Thanks
>
> Regards,
>
> Wolfram
>
^ permalink raw reply
* [PATCH] soc: ti: qmss: fix the case when !SMP
From: Santosh Shilimkar @ 2016-11-30 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5501170.dgvo5UdPBX@wuerfel>
Hi Grygorii,
On 11/30/2016 3:37 AM, Arnd Bergmann wrote:
> On Tuesday, November 29, 2016 4:15:08 PM CET Grygorii Strashko wrote:
>> range->num_irqs++;
>>
>> - if (oirq.args_count == 3)
>> + if (IS_ENABLED(SMP) && oirq.args_count == 3)
>> range->irqs[i].cpu_map =
>> (oirq.args[2] & 0x0000ff00) >> 8;
>>
>
> I think you mean CONFIG_SMP, not SMP. With the change above, the
> code will never be executed.
>
Is that the full patch ? Can you post updated patch wit above fixed
and copy me. I will pick it up.
Regards,
Santosh
^ 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