* Applied "ASoC: sun4i-codec: Revise comments for register definition macros" to the asoc tree
From: Mark Brown @ 2016-11-03 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103075556.29018-4-wens@csie.org>
The patch
ASoC: sun4i-codec: Revise comments for register definition macros
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 bd720ecf4ec6923207b4059ff4b4a43ee25ac891 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Thu, 3 Nov 2016 15:55:45 +0800
Subject: [PATCH] ASoC: sun4i-codec: Revise comments for register definition
macros
This revises existing comments in the register definition macros
section, and adds a few more, so that readers can clearly identify
the types of control registers.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 7b78f4045d38..969d86b4cd44 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -38,7 +38,7 @@
#include <sound/initval.h>
#include <sound/dmaengine_pcm.h>
-/* Codec DAC register offsets and bit fields */
+/* Codec DAC digital controls and FIFO registers */
#define SUN4I_CODEC_DAC_DPC (0x00)
#define SUN4I_CODEC_DAC_DPC_EN_DA (31)
#define SUN4I_CODEC_DAC_DPC_DVOL (12)
@@ -55,6 +55,8 @@
#define SUN4I_CODEC_DAC_FIFOC_FIFO_FLUSH (0)
#define SUN4I_CODEC_DAC_FIFOS (0x08)
#define SUN4I_CODEC_DAC_TXDATA (0x0c)
+
+/* Codec DAC side analog signal controls */
#define SUN4I_CODEC_DAC_ACTL (0x10)
#define SUN4I_CODEC_DAC_ACTL_DACAENR (31)
#define SUN4I_CODEC_DAC_ACTL_DACAENL (30)
@@ -69,7 +71,7 @@
#define SUN4I_CODEC_DAC_TUNE (0x14)
#define SUN4I_CODEC_DAC_DEBUG (0x18)
-/* Codec ADC register offsets and bit fields */
+/* Codec ADC digital controls and FIFO registers */
#define SUN4I_CODEC_ADC_FIFOC (0x1c)
#define SUN4I_CODEC_ADC_FIFOC_ADC_FS (29)
#define SUN4I_CODEC_ADC_FIFOC_EN_AD (28)
@@ -81,6 +83,8 @@
#define SUN4I_CODEC_ADC_FIFOC_FIFO_FLUSH (0)
#define SUN4I_CODEC_ADC_FIFOS (0x20)
#define SUN4I_CODEC_ADC_RXDATA (0x24)
+
+/* Codec ADC side analog signal controls */
#define SUN4I_CODEC_ADC_ACTL (0x28)
#define SUN4I_CODEC_ADC_ACTL_ADC_R_EN (31)
#define SUN4I_CODEC_ADC_ACTL_ADC_L_EN (30)
@@ -93,10 +97,14 @@
#define SUN4I_CODEC_ADC_ACTL_DDE (3)
#define SUN4I_CODEC_ADC_DEBUG (0x2c)
-/* Other various ADC registers */
+/* FIFO counters */
#define SUN4I_CODEC_DAC_TXCNT (0x30)
#define SUN4I_CODEC_ADC_RXCNT (0x34)
+
+/* Calibration register (sun7i only) */
#define SUN7I_CODEC_AC_DAC_CAL (0x38)
+
+/* Microphone controls (sun7i only) */
#define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
struct sun4i_codec {
--
2.10.1
^ permalink raw reply related
* [PATCH] iommu/arm-smmu: Check that iommu_fwspecs are ours
From: Joerg Roedel @ 2016-11-03 20:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b3680f58498efd0914c5d7887737a7ef9b733982.1478107892.git.robin.murphy@arm.com>
On Wed, Nov 02, 2016 at 05:31:32PM +0000, Robin Murphy wrote:
> We seem to have forgotten to check that iommu_fwspecs actually belong to
> us before we go ahead and dereference their private data. Oops.
>
> Fixes: 021bb8420d44 ("iommu/arm-smmu: Wire up generic configuration support")
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/iommu/arm-smmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)a
Applied to iommu/fixes, thanks.
^ permalink raw reply
* [PATCHv2] PCI: QDF2432 32 bit config space accessors
From: Bjorn Helgaas @ 2016-11-03 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aa8bc916-9363-2de7-2997-4ce470562b2c@codeaurora.org>
On Thu, Nov 03, 2016 at 12:58:10PM -0400, Sinan Kaya wrote:
>
> On 11/3/2016 10:00 AM, Bjorn Helgaas wrote:
> > On Wed, Nov 02, 2016 at 12:36:16PM -0400, Sinan Kaya wrote:
> >> Hi Bjorn,
> >>
> >> On 11/2/2016 12:08 PM, Bjorn Helgaas wrote:
> >>> On Tue, Nov 01, 2016 at 07:06:31AM -0600, cov at codeaurora.org wrote:
> >>>> Hi Bjorn,
> >>>>
> >>>> On 2016-10-31 15:48, Bjorn Helgaas wrote:
> >>>>> On Wed, Sep 21, 2016 at 06:38:05PM -0400, Christopher Covington wrote:
> >>>>>> The Qualcomm Technologies QDF2432 SoC does not support accesses
> >>>>>> smaller
> >>>>>> than 32 bits to the PCI configuration space. Register the appropriate
> >>>>>> quirk.
> >>>>>>
> >>>>>> Signed-off-by: Christopher Covington <cov@codeaurora.org>
> >>>>>
> >>>>> Hi Christopher,
> >>>>>
> >>>>> Can you rebase this against v4.9-rc1? It no longer applies to my tree.
> >>>>
> >>>> I apologize for not being clearer. This patch depends on:
> >>>>
> >>>> PCI/ACPI: Extend pci_mcfg_lookup() responsibilities
> >>>> PCI/ACPI: Check platform-specific ECAM quirks
> >>>>
> >>>> These patches from Tomasz Nowicki were previously in your pci/ecam-v6
> >>>> branch, but that seems to have come and gone. How would you like to
> >>>> proceed?
> >>>
> >>> Oh yes, that's right, I forgot that connection. I'm afraid I kind of
> >>> dropped the ball on that thread, so I went back and read through it
> >>> again.
> >>>
> >>> I *think* the current state is:
> >>>
> >>> - I'm OK with the first two patches that add the quirk
> >>> infrastructure.
> >>>
> >>> - My issue with the last three patches that add ThunderX quirks is
> >>> that there's no generic description of the ECAM address space.
> >>>
> >>> So if I understand correctly, your Qualcomm patch depends only on the
> >>> first two patches.
> >>>
> >>> Then the question is how the Qualcomm ECAM address space is described.
> >>> Your quirk overrides the default pci_generic_ecam_ops with the
> >>> &pci_32b_ops, but it doesn't touch the address space part, so I assume
> >>> the bus ranges and corresponding address space in your MCFG is
> >>> correct. So far, so good.
> >>
> >> Qualcomm ECAM space includes both the root port and the endpoint address
> >> space with a single contiguous 256 MB address space described in MCFG table.
> >> There is no need to describe additional resources like PNP0C02.
> >
> > This is the crucial point I have failed to communicate clearly: the
> > PNP0C02 resource is *always* required, even if the MCFG is correct.
> >
>
> Interesting...
>
> It looks like there is a lot of lessons learnt here from history.
>
> I think this requirement is only true if your system DDR space and PCIe
> space overlaps in the memory map. I understand that Intel systems allow
> sharing of these two memory ranges. An OS could potentially reclaim this
> address range.
>
> If there is no overlap and PCI is not enabled, there can't be any SW entity
> to reclaim this space.
No, this isn't really anything to do with DDR/PCIe overlaps. This is
just a fundamental part of the ACPI model: the firmware should
communicate all address space usage to the OS either via ACPI or via
standard self-describing mechanisms like PCI BARs.
You can argue that this isn't "necessary", but that's an assumption
based on your knowledge of this particular system, and we don't want
the OS to have to make that assumption. For example, ACPI allows the
hot-addition of new ACPI devices, and we may have to assign address
space for them, and we don't want to collide with existing devices.
Bjorn
^ permalink raw reply
* [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries
From: Stuart Yoder @ 2016-11-03 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478219244-7815-1-git-send-email-nipun.gupta@nxp.com>
> -----Original Message-----
> From: Nipun Gupta [mailto:nipun.gupta at nxp.com]
> Sent: Thursday, November 03, 2016 7:27 PM
> To: robin.murphy at arm.com; will.deacon at arm.com; linux-arm-kernel at lists.infradead.org; iommu at lists.linux-
> foundation.org
> Cc: Stuart Yoder <stuart.yoder@nxp.com>; Nipun Gupta <nipun.gupta@nxp.com>
> Subject: [PATCH] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries
When you respin a patch, put the version number in the patch subject:
[PATCH v2] iommu: arm-smmu: Set SMTNMB_TLBEN in ACR to enable caching of bypass entries
Stuart
^ permalink raw reply
* [PATCHv2] ARM: OMAP3: Fix formatting of features printed
From: Sebastian Reichel @ 2016-11-03 21:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103173439.20657-1-tony@atomide.com>
Hi,
On Thu, Nov 03, 2016 at 10:34:39AM -0700, Tony Lindgren wrote:
> With the printk cleanups merged into v4.9-rc1, we now get the omap
> revision printed on multiple lines. Let's fix that and also remove the
> extra empty space at the end of the features. And let's update things
> to use scnprintf as suggested by Ivaylo Dimitrov
> <ivo.g.dimitrov.75@gmail.com>.
>
> Reported-by: Adam Ford <aford173@gmail.com>
> Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/mach-omap2/id.c | 16 +++++++++++-----
> 1 file changed, 11 insertions(+), 5 deletions(-)
Reviewed-By: Sebastian Reichel <sre@kernel.org>
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161103/cb911b5c/attachment.sig>
^ permalink raw reply
* [PATCH 0/5] drm/sun4i: Handle TV overscan
From: Sean Paul @ 2016-11-03 21:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103090106.dq2bn4z7m2hzhi53@lukather>
On Thu, Nov 3, 2016 at 3:01 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi Russell,
>
> On Mon, Oct 31, 2016 at 08:42:34AM +0000, Russell King - ARM Linux wrote:
>> On Tue, Oct 18, 2016 at 12:03:49PM +0200, Maxime Ripard wrote:
>> > The first one is that this overscanning should be reported by the
>> > connector I guess? but this is really TV specific, so we need one way
>> > to let the user tell how the image is displayed on its side, and we
>> > cannot really autodetect it, and this needs to be done at runtime so
>> > that we can present some shiny interface to let it select which
>> > overscan ratio works for him/her.
>>
>> See xbmc... they go through a nice shiny setup which includes adjusting
>> the visible area. From what I remember, it has pointers on each corner
>> which you can adjust to be just visible on the screen, so xbmc knows
>> how much overscan there is, and xbmc itself reduces down to the user
>> set size.
>
> Yes. And that is an XBMC only solution, that doesn't work with the
> fbdev emulation and is probably doing an additional composition to
> scale down and center their frames through OpenGL.
>
> We might not have a GPU in the system, and we might not even have an
> entire graphic stack on top either, so I don't think fixing at the
> user-space level is a good option (especially since we already have an
> overscan property in DRM).
>
Hi Maxime,
I took a quick look at the first 2 patches in the series and they look
good at first glance. I have them in my queue to review more
carefully.
Can you explain why you can't fix this by specifying a new mode with
big porches (as Russell suggested)?
Sean
>> > The second one is that we still need to expose the reduced modes to
>> > userspace, and not only the displayed size, so that the applications
>> > know what they must draw on. But I guess this could be adjusted by the
>> > core too.
>> >
>> > In order to work consistently, I think all planes should be adjusted
>> > that way, so that relative coordinates are from the primary plane
>> > origin, and not the display origin. But that could be adjusted too by
>> > the core I guess.
>>
>> I'm not sure about that - we want the graphics to be visible, but that
>> may not be appropriate for an video overlay frame. It's quite common
>> for (eg) broadcast video to contain dead pixels or other artifacts on
>> the right hand side, and the broadcast video expects overscan to be
>> present.
>>
>> I know this because I have run my TV with overscan disabled, even for
>> broadcast TV.
>
> I know, but on this particular hardware, composite really is just
> another video output. There's not even a TV receiver in it, so I don't
> think we have to worry about it.
>
>> > The fourth one being the major one. Every time I raised the issue on
>> > IRC, the answer basically was "we don't care about analog", so I'm a
>> > bit pessimistic about whether dealing with this in the core would be
>> > accepted, hence why I chose to deal with this at the driver level.
>>
>> Yea, that's quite sad, "analog" has become a dirty word, but really
>> this has nothing to do with "analog" at all - there are LCD TVs (and
>> some monitors) out there which take HDMI signals but refuse to
>> disable overscan no matter what you do to them if you provide them
>> with a "broadcast" mode - so the analog excuse is very poor.
>
> I'd agree with you, but I was also told to not turn that into a
> generic code and deal with that in my driver.
>
> Do you have any suggestions?
>
> Thanks,
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [RFC PATCH 00/10] ARM: dts: exynos: Fix invalid GIC interrupt flags
From: Krzysztof Kozlowski @ 2016-11-03 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474054971-16831-1-git-send-email-krzk@kernel.org>
On Fri, Sep 16, 2016 at 09:42:41PM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> Marek (internally), Geert and Alban reported errors like:
> genirq: Setting trigger mode 0 for irq 16 failed (gic_set_type+0x0/0x68)
> The patchset fixes this issue.
>
> Tested on:
> 1. Exynos4412: Odroid U3,
> 2. Exynos5410: Odroid XU,
> 3. Exynos5422: Odroid XU3.
>
> Other platforms not tested so testing would be highly appreciated.
Applied entire patchset for v4.10. Let it boil for some time in
linux-next.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v10 03/11] remoteproc: Update Kconfig setup to 'depends on REMOTEPROC'
From: Bjorn Andersson @ 2016-11-03 21:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475931154-1021-4-git-send-email-peter.griffin@linaro.org>
On Sat 08 Oct 05:52 PDT 2016, Peter Griffin wrote:
> Make REMOTEPROC core a selectable kconfig option, and update
> remoteproc client drivers to 'depends on' the core. This avoids
> some nasty Kconfig recursive dependency issues. Also when using
> menuconfig client drivers will be hidden until the core has been
> enabled.
>
> Documentation/kbuild/kconfig-language.txt:
>
> Note:
> select should be used with care. select will force
> a symbol to a value without visiting the dependencies.
> By abusing select you are able to select a symbol FOO even
> if FOO depends on BAR that is not set.
> In general use select only for non-visible symbols
> (no prompts anywhere) and for symbols with no dependencies.
> That will limit the usefulness but on the other hand avoid
> the illegal configurations all over.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Sorry, I missed this patch in the set - but spotted it in linux-next.
I still don't like the change, but remoteproc has dependencies so I
guess I have to pick it until we fix that.
It's however not okay to take this patch through the DMA tree, as it
effectively stops me from introducing any changes in the rproc tree.
Further more, it's not based on v4.9, so it currently introduces another
Kconfig dependency problem - that I can't fix in my tree without
conflicting with Vinod's.
So, Vinod, can you please drop this patch from your tree? I'll pick it
up for now.
Regards,
Bjorn
> ---
> drivers/remoteproc/Kconfig | 21 ++++++++++++---------
> 1 file changed, 12 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index a7bedc6..decdcbe 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -1,20 +1,21 @@
> menu "Remoteproc drivers"
>
> -# REMOTEPROC gets selected by whoever wants it
> config REMOTEPROC
> - tristate
> + tristate "Support for Remote Processor subsystem"
> depends on HAS_DMA
> select CRC32
> select FW_LOADER
> select VIRTIO
> select VIRTUALIZATION
>
> +if REMOTEPROC
> +
> config OMAP_REMOTEPROC
> tristate "OMAP remoteproc support"
> depends on HAS_DMA
> depends on ARCH_OMAP4 || SOC_OMAP5
> depends on OMAP_IOMMU
> - select REMOTEPROC
> + depends on REMOTEPROC
> select MAILBOX
> select OMAP2PLUS_MBOX
> select RPMSG
> @@ -34,7 +35,7 @@ config OMAP_REMOTEPROC
> config STE_MODEM_RPROC
> tristate "STE-Modem remoteproc support"
> depends on HAS_DMA
> - select REMOTEPROC
> + depends on REMOTEPROC
> default n
> help
> Say y or m here to support STE-Modem shared memory driver.
> @@ -44,7 +45,7 @@ config STE_MODEM_RPROC
> config WKUP_M3_RPROC
> tristate "AMx3xx Wakeup M3 remoteproc support"
> depends on SOC_AM33XX || SOC_AM43XX
> - select REMOTEPROC
> + depends on REMOTEPROC
> help
> Say y here to support Wakeup M3 remote processor on TI AM33xx
> and AM43xx family of SoCs.
> @@ -57,8 +58,8 @@ config WKUP_M3_RPROC
> config DA8XX_REMOTEPROC
> tristate "DA8xx/OMAP-L13x remoteproc support"
> depends on ARCH_DAVINCI_DA8XX
> + depends on REMOTEPROC
> select CMA if MMU
> - select REMOTEPROC
> select RPMSG
> help
> Say y here to support DA8xx/OMAP-L13x remote processors via the
> @@ -84,9 +85,9 @@ config QCOM_Q6V5_PIL
> tristate "Qualcomm Hexagon V5 Peripherial Image Loader"
> depends on OF && ARCH_QCOM
> depends on QCOM_SMEM
> + depends on REMOTEPROC
> select MFD_SYSCON
> select QCOM_MDT_LOADER
> - select REMOTEPROC
> help
> Say y here to support the Qualcomm Peripherial Image Loader for the
> Hexagon V5 based remote processors.
> @@ -94,7 +95,7 @@ config QCOM_Q6V5_PIL
> config ST_REMOTEPROC
> tristate "ST remoteproc support"
> depends on ARCH_STI
> - select REMOTEPROC
> + depends on REMOTEPROC
> help
> Say y here to support ST's adjunct processors via the remote
> processor framework.
> @@ -102,6 +103,8 @@ config ST_REMOTEPROC
>
> config ST_SLIM_REMOTEPROC
> tristate
> - select REMOTEPROC
> + depends on REMOTEPROC
> +
> +endif # REMOTEPROC
>
> endmenu
> --
> 1.9.1
>
^ permalink raw reply
* [RFC] fpga mgr: Introduce FPGA capabilities
From: Moritz Fischer @ 2016-11-03 21:27 UTC (permalink / raw)
To: linux-arm-kernel
Add FPGA capabilities as a way to express the capabilities
of a given FPGA manager.
Removes code duplication by comparing the low-level driver's
capabilities at the framework level rather than having each driver
check for supported operations in the write_init() callback.
This allows for extending with additional capabilities, similar
to the the dmaengine framework's implementation.
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Cc: Alan Tull <atull@opensource.altera.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
Cc: linux-kernel at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
Hi all,
this is another RFC (this one is against mainline) implementing
fpga capabilities to centralize the checks for different operations.
If we agree this is the way forward, I'll rebase it on top of Alan's
series once that went in (and add potential drivers we added by then.
Cheers,
Moritz
PS: I'm not sure if the checkpatch warning is a false positive ...
---
drivers/fpga/fpga-mgr.c | 14 +++++++++++++
drivers/fpga/socfpga.c | 10 +++++-----
drivers/fpga/zynq-fpga.c | 7 ++++++-
include/linux/fpga/fpga-mgr.h | 46 ++++++++++++++++++++++++++++++++++++++++++-
4 files changed, 70 insertions(+), 7 deletions(-)
diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
index 953dc91..21c508a 100644
--- a/drivers/fpga/fpga-mgr.c
+++ b/drivers/fpga/fpga-mgr.c
@@ -49,6 +49,18 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, const char *buf,
struct device *dev = &mgr->dev;
int ret;
+ if (flags & FPGA_MGR_PARTIAL_RECONFIG &&
+ !fpga_mgr_has_cap(FPGA_MGR_CAP_PARTIAL_RECONF, mgr->caps)) {
+ dev_err(dev, "Partial reconfiguration not supported\n");
+ return -ENOTSUPP;
+ }
+
+ if (flags & FPGA_MGR_FULL_RECONFIG &&
+ !fpga_mgr_has_cap(FPGA_MGR_CAP_FULL_RECONF, mgr->caps)) {
+ dev_err(dev, "Full reconfiguration not supported\n");
+ return -ENOTSUPP;
+ }
+
/*
* Call the low level driver's write_init function. This will do the
* device-specific things to get the FPGA into the state where it is
@@ -245,12 +257,14 @@ EXPORT_SYMBOL_GPL(fpga_mgr_put);
* @dev: fpga manager device from pdev
* @name: fpga manager name
* @mops: pointer to structure of fpga manager ops
+ * @caps: fpga manager capabilites
* @priv: fpga manager private data
*
* Return: 0 on success, negative error code otherwise.
*/
int fpga_mgr_register(struct device *dev, const char *name,
const struct fpga_manager_ops *mops,
+ fpga_mgr_cap_mask_t caps,
void *priv)
{
struct fpga_manager *mgr;
diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c
index 27d2ff2..fd9760c 100644
--- a/drivers/fpga/socfpga.c
+++ b/drivers/fpga/socfpga.c
@@ -413,10 +413,6 @@ static int socfpga_fpga_ops_configure_init(struct fpga_manager *mgr, u32 flags,
struct socfpga_fpga_priv *priv = mgr->priv;
int ret;
- if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
- dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
- return -EINVAL;
- }
/* Steps 1 - 5: Reset the FPGA */
ret = socfpga_fpga_reset(mgr);
if (ret)
@@ -555,6 +551,7 @@ static int socfpga_fpga_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct socfpga_fpga_priv *priv;
struct resource *res;
+ fpga_mgr_cap_mask_t caps;
int ret;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -580,8 +577,11 @@ static int socfpga_fpga_probe(struct platform_device *pdev)
if (ret)
return ret;
+ fpga_mgr_cap_zero(&caps);
+ fpga_mgr_cap_set(FPGA_MGR_CAP_FULL_RECONF, caps);
+
return fpga_mgr_register(dev, "Altera SOCFPGA FPGA Manager",
- &socfpga_fpga_ops, priv);
+ &socfpga_fpga_ops, caps, priv);
}
static int socfpga_fpga_remove(struct platform_device *pdev)
diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c
index c2fb412..1d37ff0 100644
--- a/drivers/fpga/zynq-fpga.c
+++ b/drivers/fpga/zynq-fpga.c
@@ -410,6 +410,7 @@ static int zynq_fpga_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct zynq_fpga_priv *priv;
struct resource *res;
+ fpga_mgr_cap_mask_t caps;
int err;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -461,9 +462,13 @@ static int zynq_fpga_probe(struct platform_device *pdev)
zynq_fpga_write(priv, UNLOCK_OFFSET, UNLOCK_MASK);
clk_disable(priv->clk);
+ fpga_mgr_cap_zero(&caps);
+ fpga_mgr_cap_set(FPGA_MGR_CAP_FULL_RECONF, caps);
+ fpga_mgr_cap_set(FPGA_MGR_CAP_PARTIAL_RECONF, caps);
+
err = fpga_mgr_register(dev, "Xilinx Zynq FPGA Manager",
- &zynq_fpga_ops, priv);
+ &zynq_fpga_ops, caps, priv);
if (err) {
dev_err(dev, "unable to register FPGA manager");
clk_unprepare(priv->clk);
diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
index 0940bf4..a0bf750 100644
--- a/include/linux/fpga/fpga-mgr.h
+++ b/include/linux/fpga/fpga-mgr.h
@@ -67,6 +67,47 @@ enum fpga_mgr_states {
* FPGA_MGR_PARTIAL_RECONFIG: do partial reconfiguration if supported
*/
#define FPGA_MGR_PARTIAL_RECONFIG BIT(0)
+#define FPGA_MGR_FULL_RECONFIG BIT(1)
+
+enum fpga_manager_capability {
+ FPGA_MGR_CAP_PARTIAL_RECONF,
+ FPGA_MGR_CAP_FULL_RECONF,
+
+/* last capability type for creation of the capabilities mask */
+ FPGA_MGR_CAP_END,
+};
+
+typedef struct { DECLARE_BITMAP(bits, FPGA_MGR_CAP_END); } fpga_mgr_cap_mask_t;
+
+#define fpga_mgr_has_cap(cap, mask) __fpga_mgr_has_cap((cap), &(mask))
+static inline int __fpga_mgr_has_cap(enum fpga_manager_capability cap,
+ fpga_mgr_cap_mask_t *mask)
+{
+ return test_bit(cap, mask->bits);
+}
+
+#define fpga_mgr_cap_zero(mask) __fpga_mgr_cap_zero(mask)
+static inline void __fpga_mgr_cap_zero(fpga_mgr_cap_mask_t *mask)
+{
+ bitmap_zero(mask->bits, FPGA_MGR_CAP_END);
+}
+
+#define fpga_mgr_cap_clear(cap, mask) __fpga_mgr_cap_clear((cap), &(mask))
+static inline void __fpga_mgr_cap_clear(enum fpga_manager_capability cap,
+ fpga_mgr_cap_mask_t *mask)
+
+{
+ clear_bit(cap, mask->bits);
+}
+
+#define fpga_mgr_cap_set(cap, mask) __fpga_mgr_cap_set((cap), &(mask))
+static inline void __fpga_mgr_cap_set(enum fpga_manager_capability cap,
+ fpga_mgr_cap_mask_t *mask)
+
+{
+ set_bit(cap, mask->bits);
+}
+
/**
* struct fpga_manager_ops - ops for low level fpga manager drivers
@@ -105,6 +146,7 @@ struct fpga_manager {
enum fpga_mgr_states state;
const struct fpga_manager_ops *mops;
void *priv;
+ fpga_mgr_cap_mask_t caps;
};
#define to_fpga_manager(d) container_of(d, struct fpga_manager, dev)
@@ -120,7 +162,9 @@ struct fpga_manager *of_fpga_mgr_get(struct device_node *node);
void fpga_mgr_put(struct fpga_manager *mgr);
int fpga_mgr_register(struct device *dev, const char *name,
- const struct fpga_manager_ops *mops, void *priv);
+ const struct fpga_manager_ops *mops,
+ fpga_mgr_cap_mask_t caps,
+ void *priv);
void fpga_mgr_unregister(struct device *dev);
--
2.10.0
^ permalink raw reply related
* [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Bjorn Andersson @ 2016-11-03 21:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476783556-2501-2-git-send-email-peter.griffin@linaro.org>
On Tue 18 Oct 02:39 PDT 2016, Peter Griffin wrote:
> slim core is used as a basis for many IPs in the STi
> chipsets such as fdma and demux. To avoid duplicating
> the elf loading code in each device driver a slim
> rproc driver has been created.
>
> This driver is designed to be used by other device drivers
> such as fdma, or demux whose IP is based around a slim core.
> The device driver can call slim_rproc_alloc() to allocate
> a slim rproc and slim_rproc_put() when finished.
>
> This driver takes care of ioremapping the slim
> registers (dmem, imem, slimcore, peripherals), whose offsets
> and sizes can change between IP's. It also obtains and enables
> any clocks used by the device. This approach avoids having
> a double mapping of the registers as slim_rproc does not register
> its own platform device. It also maps well to device tree
> abstraction as it allows us to have one dt node for the whole
> device.
>
> All of the generic rproc elf loading code can be reused, and
> we provide start() stop() hooks to start and stop the slim
> core once the firmware has been loaded. This has been tested
> successfully with fdma driver.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
> drivers/remoteproc/Kconfig | 7 +-
> drivers/remoteproc/Makefile | 1 +
> drivers/remoteproc/st_slim_rproc.c | 364 +++++++++++++++++++++++++++++++
> include/linux/remoteproc/st_slim_rproc.h | 58 +++++
> 4 files changed, 428 insertions(+), 2 deletions(-)
> create mode 100644 drivers/remoteproc/st_slim_rproc.c
> create mode 100644 include/linux/remoteproc/st_slim_rproc.h
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index f396bfe..9270c8e 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -58,7 +58,6 @@ config DA8XX_REMOTEPROC
> tristate "DA8xx/OMAP-L13x remoteproc support"
> depends on ARCH_DAVINCI_DA8XX
> select CMA if MMU
> - select REMOTEPROC
No, this is an unrelated change to this patch.
> select RPMSG_VIRTIO
> help
> Say y here to support DA8xx/OMAP-L13x remote processors via the
> @@ -99,10 +98,10 @@ config QCOM_WCNSS_PIL
> tristate "Qualcomm WCNSS Peripheral Image Loader"
> depends on OF && ARCH_QCOM
> depends on QCOM_SMEM
> + depends on REMOTEPROC
> select QCOM_MDT_LOADER
> select QCOM_SCM
> select QCOM_WCNSS_IRIS
> - select REMOTEPROC
Dito.
As you now make changes to the entire remoteproc Kconfig file, rather
than simply add a Kconfig symbol we can't bring this in via Vinod's tree
without providing Linus with a messy merge conflict.
So the remoteproc parts now has to go through my tree.
> help
> Say y here to support the Peripheral Image Loader for the Qualcomm
> Wireless Connectivity Subsystem.
> @@ -116,4 +115,8 @@ config ST_REMOTEPROC
> processor framework.
> This can be either built-in or a loadable module.
>
> +config ST_SLIM_REMOTEPROC
> + tristate
> + select REMOTEPROC
> +
> endmenu
[..]
> diff --git a/drivers/remoteproc/st_slim_rproc.c b/drivers/remoteproc/st_slim_rproc.c
[..]
> +struct st_slim_rproc *st_slim_rproc_alloc(struct platform_device *pdev,
> + char *fw_name)
> +{
[..]
> + rproc = rproc_alloc(dev, np->name, &slim_rproc_ops,
> + fw_name, sizeof(*slim_rproc));
[..]
> + rproc_put(rproc);
As of v4.9 you need to rproc_free() rather than rproc_put() to undo
rproc_alloc().
Regards,
Bjorn
^ permalink raw reply
* [RFC 0/8] KVM PCIe/MSI passthrough on ARM/ARM64 (Alt II)
From: Eric Auger @ 2016-11-03 21:39 UTC (permalink / raw)
To: linux-arm-kernel
Following Will & Robin's suggestions, this series attempts to propose
an alternative to [1] where the host would arbitrarily decide the
location of the IOVA MSI window and would be able to report to the
userspace the list of reserved IOVA regions that cannot be used
along with VFIO_IOMMU_MAP_DMA. This would allow the userspace to react
in case of conflict.
Userspace can retrieve all the reserved regions through the VFIO_IOMMU_GET_INFO
IOCTL by querying the new RESV_IOVA_RANGE chained capability. Each reserved
IOVA range is put in a separate capability.
At IOMMU level, the reserved regions are stored in an iommu_domain list
which is populated on each device attachment. An IOMMU add_reserved_regions
callback specializes the registration of the reserved regions.
On x86, the [FEE0_0000h - FEF0_000h] MSI window is registered (NOT tested).
On ARM, the PCI host bridge windows (ACS check to be added?) + the MSI IOVA
reserved regions are populated by the arm-smmu driver. Currently the MSI
IOVA region is arbitrarily located at 0x8000000 and 1MB sized. An IOVA domain
is created in add_reserved_regions callback. Then MSIs are transparently
mapped using this IOVA domain.
This series currently does not address some features addressed in [1]:
- MSI IOVA size requirement computation
- IRQ safety assessment
This RFC was just tested on ARM Overdrive with QEMU and is sent to help
potential discussions at LPC. Additionnal development + testing is needed.
2 tentative fixes may be submitted separately:
- vfio: fix vfio_info_cap_add/shift
- iommu/iova: fix __alloc_and_insert_iova_range
Best Regards
Eric
[1] [PATCH v14 00/16] KVM PCIe/MSI passthrough on ARM/ARM64
https://lkml.org/lkml/2016/10/12/347
Git: complete series available at
https://github.com/eauger/linux/tree/v4.9-rc3-reserved-rfc
Eric Auger (7):
vfio: fix vfio_info_cap_add/shift
iommu/iova: fix __alloc_and_insert_iova_range
iommu: Add a list of iommu_reserved_region in iommu_domain
vfio/type1: Introduce RESV_IOVA_RANGE capability
iommu: Handle the list of reserved regions
iommu/vt-d: Implement add_reserved_regions callback
iommu/arm-smmu: implement add_reserved_regions callback
Robin Murphy (1):
iommu/dma: Allow MSI-only cookies
drivers/iommu/arm-smmu.c | 63 +++++++++++++++++++++++++++++++++++++++++
drivers/iommu/dma-iommu.c | 39 +++++++++++++++++++++++++
drivers/iommu/intel-iommu.c | 48 ++++++++++++++++++++++---------
drivers/iommu/iommu.c | 25 ++++++++++++++++
drivers/iommu/iova.c | 2 +-
drivers/vfio/vfio.c | 5 ++--
drivers/vfio/vfio_iommu_type1.c | 63 ++++++++++++++++++++++++++++++++++++++++-
include/linux/dma-iommu.h | 9 ++++++
include/linux/iommu.h | 23 +++++++++++++++
include/uapi/linux/vfio.h | 16 ++++++++++-
10 files changed, 275 insertions(+), 18 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCHv6] support for AD5820 camera auto-focus coil
From: Sakari Ailus @ 2016-11-03 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103102727.GA10084@amd>
On Thu, Nov 03, 2016 at 11:27:27AM +0100, Pavel Machek wrote:
> Hi!
>
> > > > > > Yeah. I just compiled it but haven't tested it. I presume it'll work. :-)
> > > > >
> > > > > I'm testing it on n900. I guess simpler hardware with ad5820 would be better for the
> > > > > test...
> > > > >
> > > > > What hardware do you have?
> > > >
> > > > N900. What else could it be? :-) :-)
> > >
> > > Heh. Basically anything is easier to develop for than n900 :-(.
> >
> > Is it?
> >
> > I actually find the old Nokia devices very practical. It's easy to boot your
> > own kernel and things just work... until musb broke a bit recently. It
> > requires reconnecting the usb cable again to function.
> >
> > I have to admit I mostly use an N9.
>
> Well, if you compare that to development on PC, I prefer PC.
>
> Even arm development boards are usually easier, as they don't need too
> complex userspace, and do have working serial ports.
>
> But I do have a serial adapter for N900 now (thanks, sre), so my main
> problem now is that N900 takes a lot of time to boot into usable
> state.
Yeah... I just upgraded my Debian installation (armel over NFS) a few major
numbers and I find it a lot slower than it used to do. I presume that's
mostly because of systemd...
--
Sakari Ailus
e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
^ permalink raw reply
* [PATCH 1/3] ARM: dts: rename MSM8660/APQ8060 pmicintc to pm8058
From: Bjorn Andersson @ 2016-11-03 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478164390-21613-1-git-send-email-linus.walleij@linaro.org>
On Thu 03 Nov 02:13 PDT 2016, Linus Walleij wrote:
> The name "pmicintc" is ambiguous: there is a second power
> management IC named PM8901 on these systems, and it is also
> an interrupt controller. To make things clear, just name the
> node alias "pm8058", this in unambigous and has all information
> we need.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> ---
> arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 2 +-
> arch/arm/boot/dts/qcom-msm8660-surf.dts | 2 +-
> arch/arm/boot/dts/qcom-msm8660.dtsi | 12 ++++++------
> 3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
> index 4b8872cc8bf9..4a532ddab53a 100644
> --- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
> +++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
> @@ -412,7 +412,7 @@
> * The second interrupt is the PME interrupt
> * for network wakeup, connected to the TLMM.
> */
> - interrupts-extended = <&pmicintc 198 IRQ_TYPE_EDGE_FALLING>,
> + interrupts-extended = <&pm8058 198 IRQ_TYPE_EDGE_FALLING>,
> <&tlmm 29 IRQ_TYPE_EDGE_RISING>;
> reset-gpios = <&tlmm 30 GPIO_ACTIVE_LOW>;
> vdd33a-supply = <&dragon_veth>;
> diff --git a/arch/arm/boot/dts/qcom-msm8660-surf.dts b/arch/arm/boot/dts/qcom-msm8660-surf.dts
> index 23de764558ab..1adc04978a47 100644
> --- a/arch/arm/boot/dts/qcom-msm8660-surf.dts
> +++ b/arch/arm/boot/dts/qcom-msm8660-surf.dts
> @@ -48,7 +48,7 @@
> };
> };
>
> -&pmicintc {
> +&pm8058 {
> keypad at 148 {
> linux,keymap = <
> MATRIX_KEY(0, 0, KEY_FN_F1)
> diff --git a/arch/arm/boot/dts/qcom-msm8660.dtsi b/arch/arm/boot/dts/qcom-msm8660.dtsi
> index 4d828f810746..91c9a62ae725 100644
> --- a/arch/arm/boot/dts/qcom-msm8660.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8660.dtsi
> @@ -163,7 +163,7 @@
> reg = <0x500000 0x1000>;
> qcom,controller-type = "pmic-arbiter";
>
> - pmicintc: pmic at 0 {
> + pm8058: pmic at 0 {
> compatible = "qcom,pm8058";
> interrupt-parent = <&tlmm>;
> interrupts = <88 8>;
> @@ -176,7 +176,7 @@
> compatible = "qcom,pm8058-gpio",
> "qcom,ssbi-gpio";
> reg = <0x150>;
> - interrupt-parent = <&pmicintc>;
> + interrupt-parent = <&pm8058>;
> interrupts = <192 IRQ_TYPE_NONE>,
> <193 IRQ_TYPE_NONE>,
> <194 IRQ_TYPE_NONE>,
> @@ -232,7 +232,7 @@
> reg = <0x50>;
> gpio-controller;
> #gpio-cells = <2>;
> - interrupt-parent = <&pmicintc>;
> + interrupt-parent = <&pm8058>;
> interrupts =
> <128 IRQ_TYPE_NONE>,
> <129 IRQ_TYPE_NONE>,
> @@ -251,7 +251,7 @@
> pwrkey at 1c {
> compatible = "qcom,pm8058-pwrkey";
> reg = <0x1c>;
> - interrupt-parent = <&pmicintc>;
> + interrupt-parent = <&pm8058>;
> interrupts = <50 1>, <51 1>;
> debounce = <15625>;
> pull-up;
> @@ -260,7 +260,7 @@
> keypad at 148 {
> compatible = "qcom,pm8058-keypad";
> reg = <0x148>;
> - interrupt-parent = <&pmicintc>;
> + interrupt-parent = <&pm8058>;
> interrupts = <74 1>, <75 1>;
> debounce = <15>;
> scan-delay = <32>;
> @@ -270,7 +270,7 @@
> rtc at 1e8 {
> compatible = "qcom,pm8058-rtc";
> reg = <0x1e8>;
> - interrupt-parent = <&pmicintc>;
> + interrupt-parent = <&pm8058>;
> interrupts = <39 1>;
> allow-set-time;
> };
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH 2/3] ARM: dts: reference PM8058 as IRQ parent
From: Bjorn Andersson @ 2016-11-03 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478164390-21613-2-git-send-email-linus.walleij@linaro.org>
On Thu 03 Nov 02:13 PDT 2016, Linus Walleij wrote:
> Some nodes are referencing the pm8058_gpio as IRQ parent, but
> the HW IRQ offset they are supplying is actually that for the
> parent to that controller: the PM8058 itself. Since that is the
> proper parent, reference it directly.
>
> We can switch this to the pm8058_gpio and the proper offset
> once we have fixed the SSBI GPIO driver to properly deal with
> the hierarchical IRQ domain and get proper local offset
> translation.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> ---
> arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
> index 4a532ddab53a..ea660ffa03ea 100644
> --- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
> +++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
> @@ -369,8 +369,8 @@
> ak8975 at 0c {
> compatible = "asahi-kasei,ak8975";
> reg = <0x0c>;
> - /* GPIO33 has interrupt 224 on the PM8058 */
> - interrupt-parent = <&pm8058_gpio>;
> + /* FIXME: GPIO33 has interrupt 224 on the PM8058 */
> + interrupt-parent = <&pm8058>;
> interrupts = <224 IRQ_TYPE_EDGE_RISING>;
> pinctrl-names = "default";
> pinctrl-0 = <&dragon_ak8975_gpios>;
> @@ -380,8 +380,8 @@
> bmp085 at 77 {
> compatible = "bosch,bmp085";
> reg = <0x77>;
> - /* GPIO16 has interrupt 207 on the PM8058 */
> - interrupt-parent = <&pm8058_gpio>;
> + /* FIXME: GPIO16 has interrupt 207 on the PM8058 */
> + interrupt-parent = <&pm8058>;
> interrupts = <207 IRQ_TYPE_EDGE_RISING>;
> reset-gpios = <&tlmm 86 GPIO_ACTIVE_LOW>;
> pinctrl-names = "default";
> --
> 2.7.4
>
^ permalink raw reply
* [RFC PATCH 1/3] ARM64: meson: Add Amlogic Meson GX PM Suspend
From: Sudeep Holla @ 2016-11-03 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478183365-23708-2-git-send-email-narmstrong@baylibre.com>
On Thu, Nov 03, 2016 at 03:29:23PM +0100, Neil Armstrong wrote:
> The Amlogic Meson GX SoCs uses a non-standard argument to the
> PSCI CPU_SUSPEND call to enter system suspend.
>
> Implement such call within platform_suspend_ops.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> drivers/firmware/meson/Kconfig | 6 +++
> drivers/firmware/meson/Makefile | 1 +
> drivers/firmware/meson/meson_gx_pm.c | 86 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 93 insertions(+)
> create mode 100644 drivers/firmware/meson/meson_gx_pm.c
>
> diff --git a/drivers/firmware/meson/Kconfig b/drivers/firmware/meson/Kconfig
> index 170d7e8..5b3fea3 100644
> --- a/drivers/firmware/meson/Kconfig
> +++ b/drivers/firmware/meson/Kconfig
> @@ -7,3 +7,9 @@ config MESON_SM
> depends on ARM64_4K_PAGES
> help
> Say y here to enable the Amlogic secure monitor driver
> +
> +config MESON_GX_PM
> + bool
> + default ARCH_MESON if ARM64
> + help
> + Say y here to enable the Amlogic GX SoC Power Management
> diff --git a/drivers/firmware/meson/Makefile b/drivers/firmware/meson/Makefile
> index 9ab3884..b6e285d 100644
> --- a/drivers/firmware/meson/Makefile
> +++ b/drivers/firmware/meson/Makefile
> @@ -1 +1,2 @@
> obj-$(CONFIG_MESON_SM) += meson_sm.o
> +obj-$(CONFIG_MESON_GX_PM) += meson_gx_pm.o
> diff --git a/drivers/firmware/meson/meson_gx_pm.c b/drivers/firmware/meson/meson_gx_pm.c
> new file mode 100644
> index 0000000..c104c2e
> --- /dev/null
> +++ b/drivers/firmware/meson/meson_gx_pm.c
> @@ -0,0 +1,86 @@
> +/*
> + * Amlogic Meson GX Power Management
> + *
> + * Copyright (c) 2016 Baylibre, SAS.
> + * Author: Neil Armstrong <narmstrong@baylibre.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of version 2 of the GNU General Public License as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/suspend.h>
> +#include <linux/arm-smccc.h>
> +
> +#include <uapi/linux/psci.h>
> +
> +#include <asm/suspend.h>
> +
> +/*
> + * The Amlogic GX SoCs uses a special argument value to the
> + * PSCI CPU_SUSPEND method to enter SUSPEND_MEM.
> + */
> +
> +#define MESON_SUSPEND_PARAM 0x0010000
> +#define PSCI_FN_NATIVE(version, name) PSCI_##version##_FN64_##name
> +
> +static int meson_gx_suspend_finish(unsigned long arg)
> +{
> + struct arm_smccc_res res;
> +
> + arm_smccc_smc(PSCI_FN_NATIVE(0_2, CPU_SUSPEND), arg,
> + virt_to_phys(cpu_resume), 0, 0, 0, 0, 0, &res);
> +
> + return res.a0;
> +}
> +
> +static int meson_gx_suspend_enter(suspend_state_t state)
> +{
> + switch (state) {
> + case PM_SUSPEND_MEM:
> + return cpu_suspend(MESON_SUSPEND_PARAM,
> + meson_gx_suspend_finish);
Short response to this patch: NAK
To be constructive, since this system lacks PSCI system suspend, it just
can't support. Alternatively, this can be normal cpuidle state and you
can use suspend to idle to achieve the same and you need not hack/work
around using platform specific driver.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] PM / Domains: Fix for domain idle state
From: Lina Iyer @ 2016-11-03 21:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi Rafael,
This follows the discussions we had at LPC. The decision to use a different
compatible (different from that of the CPU's idle state) resulted in a new idle
state node definition that is specific to PM domains. The patch describes this
new binding.
You have already pulled in my earlier changes for domain idle states into your
linux-next. This patch is intended to be applied on top of that and fixes the
domain idle state and maps it to the new definition.
Thanks,
Lina
Lina Iyer (1):
PM / Domains: Fix compatible for domain idle state
.../bindings/power/domain-idle-state.txt | 33 ++++++++++++++++++++++
.../devicetree/bindings/power/power_domain.txt | 8 +++---
drivers/base/power/domain.c | 2 +-
3 files changed, 38 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt
--
2.7.4
^ permalink raw reply
* [PATCH] PM / Domains: Fix compatible for domain idle state
From: Lina Iyer @ 2016-11-03 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478210075-92045-1-git-send-email-lina.iyer@linaro.org>
Re-using idle state definition provided by arm,idle-state for domain
idle states creates a lot of confusion and limits further evolution of
the domain idle definition. To keep things clear and simple, define a
idle states for domain using a new compatible "domain-idle-state".
Fix existing PM domains code to look for the newly defined compatible.
Cc: <devicetree@vger.kernel.org>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
---
.../bindings/power/domain-idle-state.txt | 33 ++++++++++++++++++++++
.../devicetree/bindings/power/power_domain.txt | 8 +++---
drivers/base/power/domain.c | 2 +-
3 files changed, 38 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt
diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.txt b/Documentation/devicetree/bindings/power/domain-idle-state.txt
new file mode 100644
index 0000000..eefc7ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/domain-idle-state.txt
@@ -0,0 +1,33 @@
+PM Domain Idle State Node:
+
+A domain idle state node represents the state parameters that will be used to
+select the state when there are no active components in the domain.
+
+The state node has the following parameters -
+
+- compatible:
+ Usage: Required
+ Value type: <string>
+ Definition: Must be "domain-idle-state".
+
+- entry-latency-us
+ Usage: Required
+ Value type: <prop-encoded-array>
+ Definition: u32 value representing worst case latency in
+ microseconds required to enter the idle state.
+ The exit-latency-us duration may be guaranteed
+ only after entry-latency-us has passed.
+
+- exit-latency-us
+ Usage: Required
+ Value type: <prop-encoded-array>
+ Definition: u32 value representing worst case latency
+ in microseconds required to exit the idle state.
+
+- min-residency-us
+ Usage: Required
+ Value type: <prop-encoded-array>
+ Definition: u32 value representing minimum residency duration
+ in microseconds after which the idle state will yield
+ power benefits after overcoming the overhead in entering
+i the idle state.
diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
index e165036..723e1ad 100644
--- a/Documentation/devicetree/bindings/power/power_domain.txt
+++ b/Documentation/devicetree/bindings/power/power_domain.txt
@@ -31,7 +31,7 @@ Optional properties:
- domain-idle-states : A phandle of an idle-state that shall be soaked into a
generic domain power state. The idle state definitions are
- compatible with arm,idle-state specified in [1].
+ compatible with domain-idle-state specified in [1].
The domain-idle-state property reflects the idle state of this PM domain and
not the idle states of the devices or sub-domains in the PM domain. Devices
and sub-domains have their own idle-states independent of the parent
@@ -85,7 +85,7 @@ Example 3:
};
DOMAIN_RET: state at 0 {
- compatible = "arm,idle-state";
+ compatible = "domain-idle-state";
reg = <0x0>;
entry-latency-us = <1000>;
exit-latency-us = <2000>;
@@ -93,7 +93,7 @@ Example 3:
};
DOMAIN_PWR_DN: state at 1 {
- compatible = "arm,idle-state";
+ compatible = "domain-idle-state";
reg = <0x1>;
entry-latency-us = <5000>;
exit-latency-us = <8000>;
@@ -118,4 +118,4 @@ The node above defines a typical PM domain consumer device, which is located
inside a PM domain with index 0 of a power controller represented by a node
with the label "power".
-[1]. Documentation/devicetree/bindings/arm/idle-states.txt
+[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index 661737c..f0bc672 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -2048,7 +2048,7 @@ int genpd_dev_pm_attach(struct device *dev)
EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
static const struct of_device_id idle_state_match[] = {
- { .compatible = "arm,idle-state", },
+ { .compatible = "domain-idle-state", },
{ }
};
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: Add gyro and accel to APQ8060 Dragonboard
From: Bjorn Andersson @ 2016-11-03 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478164390-21613-3-git-send-email-linus.walleij@linaro.org>
On Thu 03 Nov 02:13 PDT 2016, Linus Walleij wrote:
> This adds the MPU-3050 gyroscope and the KXSD9 accelerometer to
> the Qualcomm APQ8060 Dragonboard. The KXSD9 is mounted beyond the
> MPU-3050 and appear as a subdevice beyond it. We set up the
> required GPIO and interrupt lines to make the devices work.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
I still would have preferred you using interrupts-extended when you're
specifying both parent and irq specifier anyways, but I'm ok with this.
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
> ---
> ChangeLog v2->v3:
> - Move the interrupt to the pm8058 alias to reflect the two patches
> properly specifying the PMIC as interrupt parent.
> ChangeLog v1->v2:
> - Use the new I2C mux gate bindings from Peter Rosin (merged to
> the I2C subsystem)
> ---
> arch/arm/boot/dts/qcom-apq8060-dragonboard.dts | 53 ++++++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
> index ea660ffa03ea..c1b99c9cb318 100644
> --- a/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
> +++ b/arch/arm/boot/dts/qcom-apq8060-dragonboard.dts
> @@ -220,6 +220,14 @@
> function = "ebi2";
> };
> };
> +
> + /* Interrupt line for the KXSD9 accelerometer */
> + dragon_kxsd9_gpios: kxsd9 {
> + irq {
> + pins = "gpio57"; /* IRQ line */
> + bias-pull-up;
> + };
> + };
> };
>
> qcom,ssbi at 500000 {
> @@ -272,6 +280,15 @@
> power-source = <PM8058_GPIO_S3>;
> };
> };
> + dragon_mpu3050_gpios: mpu3050-gpios {
> + pinconf {
> + pins = "gpio17";
> + function = "normal";
> + input-enable;
> + bias-disable;
> + power-source = <PM8058_GPIO_S3>;
> + };
> + };
> dragon_sdcc3_gpios: sdcc3-gpios {
> pinconf {
> pins = "gpio22";
> @@ -389,6 +406,42 @@
> vddd-supply = <&pm8058_lvs0>; // 1.8V
> vdda-supply = <&pm8058_l14>; // 2.85V
> };
> + mpu3050 at 68 {
> + compatible = "invensense,mpu3050";
> + reg = <0x68>;
> + /*
> + * GPIO17 has interrupt 208 on the
> + * PM8058, it is pulled high by a 10k
> + * resistor to VLOGIC so needs to be
> + * active low/falling edge.
> + */
> + interrupt-parent = <&pm8058>;
> + interrupts = <208 IRQ_TYPE_EDGE_FALLING>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&dragon_mpu3050_gpios>;
> + vlogic-supply = <&pm8058_lvs0>; // 1.8V
> + vdd-supply = <&pm8058_l14>; // 2.85V
> +
> + /*
> + * The MPU-3050 acts as a hub for the
> + * accelerometer.
> + */
> + i2c-gate {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + kxsd9 at 18 {
> + compatible = "kionix,kxsd9";
> + reg = <0x18>;
> + interrupt-parent = <&tlmm>;
> + interrupts = <57 IRQ_TYPE_EDGE_FALLING>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&dragon_kxsd9_gpios>;
> + iovdd-supply = <&pm8058_lvs0>; // 1.8V
> + vdd-supply = <&pm8058_l14>; // 2.85V
> + };
> + };
> + };
> };
> };
>
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Sricharan @ 2016-11-03 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <421e2b14-0231-d376-02a0-097423120b3d@arm.com>
Hi Robin,
>>>> [ 39.901592] iommu: Removing device 0000:08:00.0 from group 0
>>
>>Yikes, on second look, that definitely shouldn't be happening.
>>Everything below is probably the resulting fallout.
>
>[ 40.206703] vfio-pci 0000:08:00.0: Failed to setup iommu ops
>
>I think the above print which says "failed to setup iommu_ops"
>because the call ops->add_device failed in of_pci_iommu_configure
>is the reason for the failure, in my case i simply do not get this even with
>your scripts. ops->add_device succeeds in the rebind as well. So still
>checking what could be happening in your case.
I was looking at your code base from [1].The ops->add_device
callback from of_pci_iommu_configure on the rebind is the
one which is causing the failure. But not able to spot out
from code which point is causing the failure. It would be very helpful
if i can know which is the return value from the add_device callback
or point inside add_device callback which fails in your setup.
[1] git://linux-arm.org/linux-rm iommu/misc
>
>
>Regards,
> Sricharan
>
^ permalink raw reply
* [PATCH v3] arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
From: Marc Zyngier @ 2016-11-03 22:27 UTC (permalink / raw)
To: linux-arm-kernel
Architecturally, TLBs are private to the (physical) CPU they're
associated with. But when multiple vcpus from the same VM are
being multiplexed on the same CPU, the TLBs are not private
to the vcpus (and are actually shared across the VMID).
Let's consider the following scenario:
- vcpu-0 maps PA to VA
- vcpu-1 maps PA' to VA
If run on the same physical CPU, vcpu-1 can hit TLB entries generated
by vcpu-0 accesses, and access the wrong physical page.
The solution to this is to keep a per-VM map of which vcpu ran last
on each given physical CPU, and invalidate local TLBs when switching
to a different vcpu from the same VM.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
- From v2:
* Fixed the horrible sched_in vs load bug
* Now performing immediate invalidation instead of defering it
* Squashed a buglet in the kern_hyp_va macro
* Dropped Mark's RB since the code has substantially changed
* Only lightly tested on 32bit (I'm travelling)
arch/arm/include/asm/kvm_asm.h | 1 +
arch/arm/include/asm/kvm_host.h | 3 +++
arch/arm/include/asm/kvm_hyp.h | 1 +
arch/arm/kvm/arm.c | 27 ++++++++++++++++++++++++++-
arch/arm/kvm/hyp/tlb.c | 15 +++++++++++++++
arch/arm64/include/asm/kvm_asm.h | 1 +
arch/arm64/include/asm/kvm_host.h | 3 +++
arch/arm64/include/asm/kvm_mmu.h | 2 +-
arch/arm64/kvm/hyp/tlb.c | 15 +++++++++++++++
9 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index d7ea6bcb29bf..8ef05381984b 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -66,6 +66,7 @@ extern char __kvm_hyp_vector[];
extern void __kvm_flush_vm_context(void);
extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
+extern void __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu);
extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 2d19e02d03fd..d5423ab15ed5 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -57,6 +57,9 @@ struct kvm_arch {
/* VTTBR value associated with below pgd and vmid */
u64 vttbr;
+ /* The last vcpu id that ran on each physical CPU */
+ int __percpu *last_vcpu_ran;
+
/* Timer */
struct arch_timer_kvm timer;
diff --git a/arch/arm/include/asm/kvm_hyp.h b/arch/arm/include/asm/kvm_hyp.h
index 343135ede5fa..58508900c4bb 100644
--- a/arch/arm/include/asm/kvm_hyp.h
+++ b/arch/arm/include/asm/kvm_hyp.h
@@ -71,6 +71,7 @@
#define ICIALLUIS __ACCESS_CP15(c7, 0, c1, 0)
#define ATS1CPR __ACCESS_CP15(c7, 0, c8, 0)
#define TLBIALLIS __ACCESS_CP15(c8, 0, c3, 0)
+#define TLBIALL __ACCESS_CP15(c8, 0, c7, 0)
#define TLBIALLNSNHIS __ACCESS_CP15(c8, 4, c3, 4)
#define PRRR __ACCESS_CP15(c10, 0, c2, 0)
#define NMRR __ACCESS_CP15(c10, 0, c2, 1)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 08bb84f2ad58..19b5f5c1c0ff 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -114,11 +114,18 @@ void kvm_arch_check_processor_compat(void *rtn)
*/
int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
{
- int ret = 0;
+ int ret, cpu;
if (type)
return -EINVAL;
+ kvm->arch.last_vcpu_ran = alloc_percpu(typeof(*kvm->arch.last_vcpu_ran));
+ if (!kvm->arch.last_vcpu_ran)
+ return -ENOMEM;
+
+ for_each_possible_cpu(cpu)
+ *per_cpu_ptr(kvm->arch.last_vcpu_ran, cpu) = -1;
+
ret = kvm_alloc_stage2_pgd(kvm);
if (ret)
goto out_fail_alloc;
@@ -141,6 +148,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
out_free_stage2_pgd:
kvm_free_stage2_pgd(kvm);
out_fail_alloc:
+ free_percpu(kvm->arch.last_vcpu_ran);
+ kvm->arch.last_vcpu_ran = NULL;
return ret;
}
@@ -168,6 +177,9 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
{
int i;
+ free_percpu(kvm->arch.last_vcpu_ran);
+ kvm->arch.last_vcpu_ran = NULL;
+
for (i = 0; i < KVM_MAX_VCPUS; ++i) {
if (kvm->vcpus[i]) {
kvm_arch_vcpu_free(kvm->vcpus[i]);
@@ -312,6 +324,19 @@ int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
{
+ int *last_ran;
+
+ last_ran = this_cpu_ptr(vcpu->kvm->arch.last_vcpu_ran);
+
+ /*
+ * We might get preempted before the vCPU actually runs, but
+ * over-invalidation doesn't affect correctness.
+ */
+ if (*last_ran != vcpu->vcpu_id) {
+ kvm_call_hyp(__kvm_tlb_flush_local_vmid, vcpu);
+ *last_ran = vcpu->vcpu_id;
+ }
+
vcpu->cpu = cpu;
vcpu->arch.host_cpu_context = this_cpu_ptr(kvm_host_cpu_state);
diff --git a/arch/arm/kvm/hyp/tlb.c b/arch/arm/kvm/hyp/tlb.c
index 729652854f90..6d810af2d9fd 100644
--- a/arch/arm/kvm/hyp/tlb.c
+++ b/arch/arm/kvm/hyp/tlb.c
@@ -55,6 +55,21 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
__kvm_tlb_flush_vmid(kvm);
}
+void __hyp_text __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu)
+{
+ struct kvm *kvm = kern_hyp_va(kern_hyp_va(vcpu)->kvm);
+
+ /* Switch to requested VMID */
+ write_sysreg(kvm->arch.vttbr, VTTBR);
+ isb();
+
+ write_sysreg(0, TLBIALL);
+ dsb(nsh);
+ isb();
+
+ write_sysreg(0, VTTBR);
+}
+
void __hyp_text __kvm_flush_vm_context(void)
{
write_sysreg(0, TLBIALLNSNHIS);
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index 18f746551bf6..ec3553eb9349 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -54,6 +54,7 @@ extern char __kvm_hyp_vector[];
extern void __kvm_flush_vm_context(void);
extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa);
extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
+extern void __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu);
extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index bd94e6766759..e5050388e062 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -62,6 +62,9 @@ struct kvm_arch {
/* VTTBR value associated with above pgd and vmid */
u64 vttbr;
+ /* The last vcpu id that ran on each physical CPU */
+ int __percpu *last_vcpu_ran;
+
/* The maximum number of vCPUs depends on the used GIC model */
int max_vcpus;
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index a79b969c26fc..6f72fe8b0e3e 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -128,7 +128,7 @@ static inline unsigned long __kern_hyp_va(unsigned long v)
return v;
}
-#define kern_hyp_va(v) (typeof(v))(__kern_hyp_va((unsigned long)(v)))
+#define kern_hyp_va(v) ((typeof(v))(__kern_hyp_va((unsigned long)(v))))
/*
* We currently only support a 40bit IPA.
diff --git a/arch/arm64/kvm/hyp/tlb.c b/arch/arm64/kvm/hyp/tlb.c
index 9cc0ea784ae6..88e2f2b938f0 100644
--- a/arch/arm64/kvm/hyp/tlb.c
+++ b/arch/arm64/kvm/hyp/tlb.c
@@ -64,6 +64,21 @@ void __hyp_text __kvm_tlb_flush_vmid(struct kvm *kvm)
write_sysreg(0, vttbr_el2);
}
+void __hyp_text __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu)
+{
+ struct kvm *kvm = kern_hyp_va(kern_hyp_va(vcpu)->kvm);
+
+ /* Switch to requested VMID */
+ write_sysreg(kvm->arch.vttbr, vttbr_el2);
+ isb();
+
+ asm volatile("tlbi vmalle1" : : );
+ dsb(nsh);
+ isb();
+
+ write_sysreg(0, vttbr_el2);
+}
+
void __hyp_text __kvm_flush_vm_context(void)
{
dsb(ishst);
--
2.10.1
^ permalink raw reply related
* [PATCH 0/2] ARM64: meson-gxbb: SCPI Fixup
From: Kevin Hilman @ 2016-11-03 22:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478164284-24958-1-git-send-email-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> This patchset updates the GXBB dtsi and the ARM64 defconfig in order
> to make SCPI work following the Legacy SCPI rework from Sudeep Hola at [1].
>
> The rework introduced a generic "arm,legacy-scpi" compatible string.
> The second patch enables the necessary Platform MHU in defconfig.
I folded PATCH 1/2 into the original, and (re)pushed both the amlogic
v4.10/dt64 branch.
Kevin
> [1] http://lkml.kernel.org/r/1478148731-11712-1-git-send-email-sudeep.holla at arm.com
>
> Neil Armstrong (2):
> ARM64: dts: meson-gxbb: Add generic legacy scpi compatible
> ARM64: configs: Add Platform MHU in defconfig
>
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 2 +-
> arch/arm64/configs/defconfig | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
^ permalink raw reply
* [PATCH] ARM: cache-uniphier: include <linux/errno.h> instead of <linux/types.h>
From: Masahiro Yamada @ 2016-11-03 22:57 UTC (permalink / raw)
To: linux-arm-kernel
Nothing in this header file depends on <linux/types.h>.
Rather, <linux/errno.h> should be included for -ENODEV.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/arm/include/asm/hardware/cache-uniphier.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/hardware/cache-uniphier.h b/arch/arm/include/asm/hardware/cache-uniphier.h
index eaa60da..0ef42ae 100644
--- a/arch/arm/include/asm/hardware/cache-uniphier.h
+++ b/arch/arm/include/asm/hardware/cache-uniphier.h
@@ -16,7 +16,7 @@
#ifndef __CACHE_UNIPHIER_H
#define __CACHE_UNIPHIER_H
-#include <linux/types.h>
+#include <linux/errno.h>
#ifdef CONFIG_CACHE_UNIPHIER
int uniphier_cache_init(void);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/6] pinctrl-aspeed-g5: Never set SCU90[6]
From: Joel Stanley @ 2016-11-03 22:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478097481-14895-2-git-send-email-andrew@aj.id.au>
On Thu, Nov 3, 2016 at 1:07 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> If a pin depending on bit 6 in SCU90 is requested for GPIO, the export
> will succeed but changes to the GPIO's value will not be accepted by the
> hardware. This is because the pinmux driver has misconfigured the SCU by
> writing 1 to the reserved bit.
>
> The description of SCU90[6] from the datasheet is 'Reserved, must keep
> at value ?0?'. The fix is to switch pinmux from the bit-flipping macro
> to explicitly configuring the .enable and .disable values to zero.
>
> The patch has been tested on an AST2500 EVB.
>
> Fixes: 56e57cb6c07f (pinctrl: Add pinctrl-aspeed-g5 driver)
> Reported-by: Uma Yadlapati <yadlapat@us.ibm.com>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
And tested-by.
> This patch should be applied for 4.9.
In the future I think we should send fixes separately from the rest of
the series, so it's clear to Linus where we expect patches to end up.
Perhaps Linus can share his preference with us?
Cheers,
Joel
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> index c8c72e8259d3..87b46390b695 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> @@ -26,7 +26,7 @@
>
> #define ASPEED_G5_NR_PINS 228
>
> -#define COND1 SIG_DESC_BIT(SCU90, 6, 0)
> +#define COND1 { SCU90, BIT(6), 0, 0 }
> #define COND2 { SCU94, GENMASK(1, 0), 0, 0 }
>
> #define B14 0
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v2 3/6] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LPCHC)
From: Joel Stanley @ 2016-11-03 23:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478097481-14895-4-git-send-email-andrew@aj.id.au>
On Thu, Nov 3, 2016 at 1:07 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> The Aspeed LPC Host Controller is presented as a syscon device to
> arbitrate access by LPC and pinmux drivers. LPC pinmux configuration on
> fifth generation SoCs depends on bits in both the System Control Unit
> and the LPC Host Controller.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
> new file mode 100644
> index 000000000000..792651488c3d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
> @@ -0,0 +1,17 @@
> +* Device tree bindings for the Aspeed LPC Host Controller (LPCHC)
I had to check the data sheet for that acronym. They call the
registers LHC. I somewhat prefer that name, but if you're happy with
it as-is then that's fine.
I assume this is not an issue on the g4/ast2400?
> +
> +The LPCHC registers configure LPC behaviour between the BMC and the host
> +system. The LPCHC also participates in pinmux requests on g5 SoCs and is
> +therefore considered a syscon device.
> +
> +Required properties:
> +- compatible: "aspeed,ast2500-lpchc", "syscon"
> +- reg: contains offset/length value of the LPCHC memory
> + region.
> +
> +Example:
> +
> +lpchc: lpchc at 1e7890a0 {
> + compatible = "aspeed,ast2500-lpchc", "syscon";
> + reg = <0x1e7890a0 0xc4>;
Where's the 0xc4 come from? I can see 9 registers, which would mean
the length should be 0x24?
Cheers,
Joel
^ permalink raw reply
* [PATCH v2 4/6] pinctrl: aspeed: Read and write bits in LPCHC and GFX controllers
From: Joel Stanley @ 2016-11-03 23:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478097481-14895-5-git-send-email-andrew@aj.id.au>
On Thu, Nov 3, 2016 at 1:07 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> The System Control Unit IP block in the Aspeed SoCs is typically where
> the pinmux configuration is found, but not always. A number of pins
> depend on state in one of LPC Host Control (LPCHC) or SoC Display
> Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
> means to adjust these as necessary.
>
> We use syscon to cast a regmap over the GFX and LPCHCR blocks, which is
> used as an arbitration layer between the relevant driver and the pinctrl
> subsystem. The regmaps are then exposed to the SoC-specific pinctrl
> drivers by phandles in the devicetree, and are selected during a mux
> request by querying a new 'ip' member in struct aspeed_sig_desc.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
I like this a lot more than the first go. Good work.
Some minor comments below.
> ---
> Since v1:
>
> The change is now proactive: instead of reporting that we need to flip bits in
> controllers we can't access, the patch provides access via regmaps for the
> relevant controllers. The implementation also splits out the IP block ID into
> its own variable rather than packing the value into the upper bits of the reg
> member of struct aspeed_sig_desc. This drives some churn in the diff, but I've
> tried to minimise it.
>
> .../devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 50 +++++++++++++---
> drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 18 +++---
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 39 ++++++++++---
> drivers/pinctrl/aspeed/pinctrl-aspeed.c | 66 +++++++++++++---------
> drivers/pinctrl/aspeed/pinctrl-aspeed.h | 32 ++++++++---
> 5 files changed, 144 insertions(+), 61 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> index 2ad18c4ea55c..115b0cce6c1c 100644
> --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt
> @@ -4,12 +4,19 @@ Aspeed Pin Controllers
> The Aspeed SoCs vary in functionality inside a generation but have a common mux
> device register layout.
>
> -Required properties:
> -- compatible : Should be any one of the following:
> - "aspeed,ast2400-pinctrl"
> - "aspeed,g4-pinctrl"
> - "aspeed,ast2500-pinctrl"
> - "aspeed,g5-pinctrl"
> +Required properties for g4:
> +- compatible : Should be any one of the following:
> + "aspeed,ast2400-pinctrl"
> + "aspeed,g4-pinctrl"
> +
> +Required properties for g5:
> +- compatible : Should be any one of the following:
> + "aspeed,ast2500-pinctrl"
> + "aspeed,g5-pinctrl"
> +
> +- aspeed,external-nodes: A cell of phandles to external controller nodes:
> + 0: compatible with "aspeed,ast2500-gfx", "syscon"
> + 1: compatible with "aspeed,ast2500-lpchc", "syscon"
>
> The pin controller node should be a child of a syscon node with the required
> property:
> @@ -47,7 +54,7 @@ RGMII1 RGMII2 RMII1 RMII2 SD1 SPI1 SPI1DEBUG SPI1PASSTHRU TIMER4 TIMER5 TIMER6
> TIMER7 TIMER8 VGABIOSROM
>
>
> -Examples:
> +g4 Example:
>
> syscon: scu at 1e6e2000 {
> compatible = "syscon", "simple-mfd";
> @@ -63,5 +70,34 @@ syscon: scu at 1e6e2000 {
> };
> };
>
> +g5 Example:
> +
> +apb {
> + gfx: display at 1e6e6000 {
> + compatible = "aspeed,ast2500-gfx", "syscon";
> + reg = <0x1e6e6000 0x1000>;
> + };
> +
> + lpchc: lpchc at 1e7890a0 {
> + compatible = "aspeed,ast2500-lpchc", "syscon";
> + reg = <0x1e7890a0 0xc4>;
> + };
> +
> + syscon: scu at 1e6e2000 {
> + compatible = "syscon", "simple-mfd";
> + reg = <0x1e6e2000 0x1a8>;
> +
> + pinctrl: pinctrl {
> + compatible = "aspeed,g5-pinctrl";
> + aspeed,external-nodes = <&gfx, &lpchc>;
> +
> + pinctrl_i2c3_default: i2c3_default {
> + function = "I2C3";
> + groups = "I2C3";
> + };
> + };
> + };
> +};
> +
> Please refer to pinctrl-bindings.txt in this directory for details of the
> common pinctrl bindings used by client devices.
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
> index a21b071ff290..558bd102416c 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
> @@ -292,7 +292,7 @@ SSSF_PIN_DECL(U18, GPIOG7, FLWP, SIG_DESC_SET(SCU84, 7));
> #define UART6_DESC SIG_DESC_SET(SCU90, 7)
> #define ROM16_DESC SIG_DESC_SET(SCU90, 6)
> #define FLASH_WIDE SIG_DESC_SET(HW_STRAP1, 4)
> -#define BOOT_SRC_NOR { HW_STRAP1, GENMASK(1, 0), 0, 0 }
> +#define BOOT_SRC_NOR { ASPEED_IP_SCU, HW_STRAP1, GENMASK(1, 0), 0, 0 }
>
> #define A8 56
> SIG_EXPR_DECL(ROMD8, ROM16, ROM16_DESC);
> @@ -418,9 +418,9 @@ FUNC_GROUP_DECL(I2C8, G5, F3);
> #define U1 88
> SSSF_PIN_DECL(U1, GPIOL0, NCTS1, SIG_DESC_SET(SCU84, 16));
>
> -#define VPI18_DESC { SCU90, GENMASK(5, 4), 1, 0 }
> -#define VPI24_DESC { SCU90, GENMASK(5, 4), 2, 0 }
> -#define VPI30_DESC { SCU90, GENMASK(5, 4), 3, 0 }
> +#define VPI18_DESC { ASPEED_IP_SCU, SCU90, GENMASK(5, 4), 1, 0 }
> +#define VPI24_DESC { ASPEED_IP_SCU, SCU90, GENMASK(5, 4), 2, 0 }
> +#define VPI30_DESC { ASPEED_IP_SCU, SCU90, GENMASK(5, 4), 3, 0 }
>
> #define T5 89
> #define T5_DESC SIG_DESC_SET(SCU84, 17)
> @@ -641,11 +641,11 @@ SSSF_PIN_DECL(Y22, GPIOR2, ROMCS3, SIG_DESC_SET(SCU88, 26));
> #define U19 139
> SSSF_PIN_DECL(U19, GPIOR3, ROMCS4, SIG_DESC_SET(SCU88, 27));
>
> -#define VPOOFF0_DESC { SCU94, GENMASK(1, 0), 0, 0 }
> -#define VPO12_DESC { SCU94, GENMASK(1, 0), 1, 0 }
> -#define VPO24_DESC { SCU94, GENMASK(1, 0), 2, 0 }
> -#define VPOOFF1_DESC { SCU94, GENMASK(1, 0), 3, 0 }
> -#define VPO_OFF_12 { SCU94, 0x2, 0, 0 }
> +#define VPOOFF0_DESC { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 0, 0 }
> +#define VPO12_DESC { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 1, 0 }
> +#define VPO24_DESC { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 2, 0 }
> +#define VPOOFF1_DESC { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 3, 0 }
> +#define VPO_OFF_12 { ASPEED_IP_SCU, SCU94, 0x2, 0, 0 }
> #define VPO_24_OFF SIG_DESC_SET(SCU94, 1)
>
> #define V21 140
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> index 87b46390b695..99c4fa9bf861 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c
> @@ -10,6 +10,7 @@
> #include <linux/init.h>
> #include <linux/io.h>
> #include <linux/kernel.h>
> +#include <linux/mfd/syscon.h>
> #include <linux/mutex.h>
> #include <linux/of.h>
> #include <linux/platform_device.h>
> @@ -26,8 +27,8 @@
>
> #define ASPEED_G5_NR_PINS 228
>
> -#define COND1 { SCU90, BIT(6), 0, 0 }
> -#define COND2 { SCU94, GENMASK(1, 0), 0, 0 }
> +#define COND1 { ASPEED_IP_SCU, SCU90, BIT(6), 0, 0 }
> +#define COND2 { ASPEED_IP_SCU, SCU94, GENMASK(1, 0), 0, 0 }
>
> #define B14 0
> SSSF_PIN_DECL(B14, GPIOA0, MAC1LINK, SIG_DESC_SET(SCU80, 0));
> @@ -186,9 +187,12 @@ MS_PIN_DECL(C20, GPIOE1, NDCD3, GPIE0OUT);
>
> FUNC_GROUP_DECL(GPIE0, B20, C20);
>
> -#define SPI1_DESC { HW_STRAP1, GENMASK(13, 12), 1, 0 }
> -#define SPI1DEBUG_DESC { HW_STRAP1, GENMASK(13, 12), 2, 0 }
> -#define SPI1PASSTHRU_DESC { HW_STRAP1, GENMASK(13, 12), 3, 0 }
> +#define SPI1_DESC \
> + { ASPEED_IP_SCU, HW_STRAP1, GENMASK(13, 12), 1, 0 }
> +#define SPI1DEBUG_DESC \
> + { ASPEED_IP_SCU, HW_STRAP1, GENMASK(13, 12), 2, 0 }
> +#define SPI1PASSTHRU_DESC \
> + { ASPEED_IP_SCU, HW_STRAP1, GENMASK(13, 12), 3, 0 }
>
> #define C18 64
> SIG_EXPR_DECL(SYSCS, SPI1DEBUG, COND1, SPI1DEBUG_DESC);
> @@ -325,10 +329,11 @@ SS_PIN_DECL(R1, GPIOK7, SDA8);
>
> FUNC_GROUP_DECL(I2C8, P2, R1);
>
> -#define VPIOFF0_DESC { SCU90, GENMASK(5, 4), 0, 0 }
> -#define VPIOFF1_DESC { SCU90, GENMASK(5, 4), 1, 0 }
> -#define VPI24_DESC { SCU90, GENMASK(5, 4), 2, 0 }
> -#define VPIRSVD_DESC { SCU90, GENMASK(5, 4), 3, 0 }
> +#define VPIOFF0_DESC { ASPEED_IP_SCU, SCU90, GENMASK(5, 4), 0, 0 }
> +#define VPIOFF1_DESC { ASPEED_IP_SCU, SCU90, GENMASK(5, 4), 1, 0 }
> +#define VPI24_DESC { ASPEED_IP_SCU, SCU90, GENMASK(5, 4), 2, 0 }
> +#define VPIRSVD_DESC { ASPEED_IP_SCU, SCU90, GENMASK(5, 4), 3, 0 }
> +
>
> #define V2 104
> #define V2_DESC SIG_DESC_SET(SCU88, 0)
> @@ -848,10 +853,26 @@ static struct pinctrl_desc aspeed_g5_pinctrl_desc = {
> static int aspeed_g5_pinctrl_probe(struct platform_device *pdev)
> {
> int i;
> + struct regmap **map;
> + struct device_node *node;
>
> for (i = 0; i < ARRAY_SIZE(aspeed_g5_pins); i++)
> aspeed_g5_pins[i].number = i;
>
> + map = &aspeed_g5_pinctrl_data.maps[ASPEED_IP_GFX];
> + node = of_parse_phandle(pdev->dev.of_node, "aspeed,external-nodes", 0);
> + *map = syscon_node_to_regmap(node);
I think you can use syscon_regmap_lookup_by_phandle to replace both of
these lines.
> + of_node_put(node);
> + if (IS_ERR(*map))
> + return PTR_ERR(*map);
Do we want to fail, or warn and continue?
The sequence is a bit messy. How about:
struct regmap *map;
map = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
"aspeed,external-nodes");
if (IS_ERR(map))
return PTR_ERR(map);
aspeed_g5_pinctrl_data.maps[ASPEED_IP_GFX] = map;
> +
> + map = &aspeed_g5_pinctrl_data.maps[ASPEED_IP_LPCHC];
> + node = of_parse_phandle(pdev->dev.of_node, "aspeed,external-nodes", 1);
> + *map = syscon_node_to_regmap(node);
> + of_node_put(node);
> + if (IS_ERR(*map))
> + return PTR_ERR(*map);
> +
Same comments as above.
> return aspeed_pinctrl_probe(pdev, &aspeed_g5_pinctrl_desc,
> &aspeed_g5_pinctrl_data);
> }
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> index 49aeba912531..23586aac7a5a 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> @@ -14,6 +14,12 @@
> #include "../core.h"
> #include "pinctrl-aspeed.h"
>
> +static const char *const aspeed_pinmux_ips[] = {
> + [ASPEED_IP_SCU] = "SCU",
> + [ASPEED_IP_GFX] = "GFX",
> + [ASPEED_IP_LPCHC] = "LHCR",
We've got both LPCHC and LHCR here. As I said when commenting on the
regmap bindings, I like LHC(R) better.
> +};
> +
> int aspeed_pinctrl_get_groups_count(struct pinctrl_dev *pctldev)
> {
> struct aspeed_pinctrl_data *pdata = pinctrl_dev_get_drvdata(pctldev);
> @@ -78,7 +84,8 @@ int aspeed_pinmux_get_fn_groups(struct pinctrl_dev *pctldev,
> static inline void aspeed_sig_desc_print_val(
> const struct aspeed_sig_desc *desc, bool enable, u32 rv)
What's a rv? Perhaps "reg" or "value"?
> {
> - pr_debug("SCU%x[0x%08x]=0x%x, got 0x%x from 0x%08x\n", desc->reg,
> + pr_debug("Want %s%X[0x%08X]=0x%X, got 0x%X from 0x%08X\n",
> + aspeed_pinmux_ips[desc->ip], desc->reg,
> desc->mask, enable ? desc->enable : desc->disable,
> (rv & desc->mask) >> __ffs(desc->mask), rv);
> }
> @@ -88,7 +95,7 @@ static inline void aspeed_sig_desc_print_val(
> *
> * @desc: The signal descriptor of interest
> * @enabled: True to query the enabled state, false to query disabled state
> - * @regmap: The SCU regmap instance
> + * @regmap: The IP block's regmap instance
> *
> * @return True if the descriptor's bitfield is configured to the state
> * selected by @enabled, false otherwise
> @@ -119,7 +126,7 @@ static bool aspeed_sig_desc_eval(const struct aspeed_sig_desc *desc,
> *
> * @expr: An expression controlling the signal for a mux function on a pin
> * @enabled: True to query the enabled state, false to query disabled state
> - * @regmap: The SCU regmap instance
> + * @maps: The list of regmap instances
> *
> * @return True if the expression composed by @enabled evaluates true, false
> * otherwise
> @@ -136,15 +143,16 @@ static bool aspeed_sig_desc_eval(const struct aspeed_sig_desc *desc,
> * either condition as required.
> */
> static bool aspeed_sig_expr_eval(const struct aspeed_sig_expr *expr,
> - bool enabled, struct regmap *map)
> + bool enabled, struct regmap * const *maps)
> {
> int i;
>
> for (i = 0; i < expr->ndescs; i++) {
> const struct aspeed_sig_desc *desc = &expr->descs[i];
>
> - if (!aspeed_sig_desc_eval(desc, enabled, map))
> + if (!aspeed_sig_desc_eval(desc, enabled, maps[desc->ip]))
> return false;
> +
> }
>
> return true;
> @@ -158,12 +166,12 @@ static bool aspeed_sig_expr_eval(const struct aspeed_sig_expr *expr,
> * configured
> * @enable: true to enable an function's signal through a pin's signal
> * expression, false to disable the function's signal
> - * @map: The SCU's regmap instance for pinmux register access.
> + * @maps: The list of regmap instances for pinmux register access.
> *
> * @return true if the expression is configured as requested, false otherwise
> */
> static bool aspeed_sig_expr_set(const struct aspeed_sig_expr *expr,
> - bool enable, struct regmap *map)
> + bool enable, struct regmap * const *maps)
> {
> int i;
>
> @@ -171,6 +179,7 @@ static bool aspeed_sig_expr_set(const struct aspeed_sig_expr *expr,
> bool ret;
> const struct aspeed_sig_desc *desc = &expr->descs[i];
> u32 pattern = enable ? desc->enable : desc->disable;
> + u32 val = (pattern << __ffs(desc->mask));
>
> /*
> * Strap registers are configured in hardware or by early-boot
> @@ -179,48 +188,49 @@ static bool aspeed_sig_expr_set(const struct aspeed_sig_expr *expr,
> * deconfigured and is the reason we re-evaluate after writing
> * all descriptor bits.
> */
> - if (desc->reg == HW_STRAP1 || desc->reg == HW_STRAP2)
> + if ((desc->reg == HW_STRAP1 || desc->reg == HW_STRAP2) &&
> + desc->ip == ASPEED_IP_SCU)
> continue;
>
> - ret = regmap_update_bits(map, desc->reg, desc->mask,
> - pattern << __ffs(desc->mask)) == 0;
> + ret = regmap_update_bits(maps[desc->ip], desc->reg,
> + desc->mask, val) == 0;
>
> if (!ret)
> return ret;
> }
>
> - return aspeed_sig_expr_eval(expr, enable, map);
> + return aspeed_sig_expr_eval(expr, enable, maps);
> }
>
> static bool aspeed_sig_expr_enable(const struct aspeed_sig_expr *expr,
> - struct regmap *map)
> + struct regmap * const *maps)
> {
> - if (aspeed_sig_expr_eval(expr, true, map))
> + if (aspeed_sig_expr_eval(expr, true, maps))
> return true;
>
> - return aspeed_sig_expr_set(expr, true, map);
> + return aspeed_sig_expr_set(expr, true, maps);
> }
>
> static bool aspeed_sig_expr_disable(const struct aspeed_sig_expr *expr,
> - struct regmap *map)
> + struct regmap * const *maps)
> {
> - if (!aspeed_sig_expr_eval(expr, true, map))
> + if (!aspeed_sig_expr_eval(expr, true, maps))
> return true;
>
> - return aspeed_sig_expr_set(expr, false, map);
> + return aspeed_sig_expr_set(expr, false, maps);
> }
>
> /**
> * Disable a signal on a pin by disabling all provided signal expressions.
> *
> * @exprs: The list of signal expressions (from a priority level on a pin)
> - * @map: The SCU's regmap instance for pinmux register access.
> + * @maps: The list of regmap instances for pinmux register access.
> *
> * @return true if all expressions in the list are successfully disabled, false
> * otherwise
> */
> static bool aspeed_disable_sig(const struct aspeed_sig_expr **exprs,
> - struct regmap *map)
> + struct regmap * const *maps)
> {
> bool disabled = true;
>
> @@ -230,7 +240,7 @@ static bool aspeed_disable_sig(const struct aspeed_sig_expr **exprs,
> while (*exprs) {
> bool ret;
>
> - ret = aspeed_sig_expr_disable(*exprs, map);
> + ret = aspeed_sig_expr_disable(*exprs, maps);
> disabled = disabled && ret;
>
> exprs++;
> @@ -343,6 +353,8 @@ int aspeed_pinmux_set_mux(struct pinctrl_dev *pctldev, unsigned int function,
> const struct aspeed_sig_expr **funcs;
> const struct aspeed_sig_expr ***prios;
>
> + pr_debug("Muxing pin %d for %s\n", pin, pfunc->name);
> +
> if (!pdesc)
> return -EINVAL;
>
> @@ -358,7 +370,7 @@ int aspeed_pinmux_set_mux(struct pinctrl_dev *pctldev, unsigned int function,
> if (expr)
> break;
>
> - if (!aspeed_disable_sig(funcs, pdata->map))
> + if (!aspeed_disable_sig(funcs, pdata->maps))
> return -EPERM;
>
> prios++;
> @@ -377,7 +389,7 @@ int aspeed_pinmux_set_mux(struct pinctrl_dev *pctldev, unsigned int function,
> return -ENXIO;
> }
>
> - if (!aspeed_sig_expr_enable(expr, pdata->map))
> + if (!aspeed_sig_expr_enable(expr, pdata->maps))
> return -EPERM;
> }
>
> @@ -432,7 +444,7 @@ int aspeed_gpio_request_enable(struct pinctrl_dev *pctldev,
> if (aspeed_gpio_in_exprs(funcs))
> break;
>
> - if (!aspeed_disable_sig(funcs, pdata->map))
> + if (!aspeed_disable_sig(funcs, pdata->maps))
> return -EPERM;
>
> prios++;
> @@ -462,7 +474,7 @@ int aspeed_gpio_request_enable(struct pinctrl_dev *pctldev,
> * If GPIO is not the lowest priority signal type, assume there is only
> * one expression defined to enable the GPIO function
> */
> - if (!aspeed_sig_expr_enable(expr, pdata->map))
> + if (!aspeed_sig_expr_enable(expr, pdata->maps))
> return -EPERM;
>
> return 0;
> @@ -481,10 +493,10 @@ int aspeed_pinctrl_probe(struct platform_device *pdev,
> return -ENODEV;
> }
>
> - pdata->map = syscon_node_to_regmap(parent->of_node);
> - if (IS_ERR(pdata->map)) {
> + pdata->maps[ASPEED_IP_SCU] = syscon_node_to_regmap(parent->of_node);
> + if (IS_ERR(pdata->maps[ASPEED_IP_SCU])) {
> dev_err(&pdev->dev, "No regmap for syscon pincontroller parent\n");
> - return PTR_ERR(pdata->map);
> + return PTR_ERR(pdata->maps[ASPEED_IP_SCU]);
> }
>
> pctl = pinctrl_register(pdesc, &pdev->dev, pdata);
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.h b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> index 3e72ef8c54bf..727728b86c07 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.h
> @@ -232,6 +232,11 @@
> * group.
> */
>
> +#define ASPEED_IP_SCU 0
> +#define ASPEED_IP_GFX 1
> +#define ASPEED_IP_LPCHC 2
> +#define ASPEED_NR_PINMUX_IPS 3
> +
> /*
> * The "Multi-function Pins Mapping and Control" table in the SoC datasheet
> * references registers by the device/offset mnemonic. The register macros
> @@ -261,7 +266,9 @@
> * A signal descriptor, which describes the register, bits and the
> * enable/disable values that should be compared or written.
> *
> - * @reg: The register offset from base in bytes
> + * @ip: The IP block identifier, used as an index into the regmap array in
> + * struct aspeed_pinctrl_data
> + * @reg: The register offset with respect to the base address of the IP block
> * @mask: The mask to apply to the register. The lowest set bit of the mask is
> * used to derive the shift value.
> * @enable: The value that enables the function. Value should be in the LSBs,
> @@ -270,6 +277,7 @@
> * LSBs, not at the position of the mask.
> */
> struct aspeed_sig_desc {
> + unsigned int ip;
> unsigned int reg;
> u32 mask;
> u32 enable;
> @@ -313,24 +321,30 @@ struct aspeed_pin_desc {
>
> /* Macro hell */
>
> +#define SIG_DESC_IP_BIT(ip, reg, idx, val) \
> + { ip, reg, BIT_MASK(idx), val, (((val) + 1) & 1) }
> +
> /**
> - * Short-hand macro for describing a configuration enabled by the state of one
> - * bit. The disable value is derived.
> + * Short-hand macro for describing an SCU descriptor enabled by the state of
> + * one bit. The disable value is derived.
> *
> * @reg: The signal's associated register, offset from base
> * @idx: The signal's bit index in the register
> * @val: The value (0 or 1) that enables the function
> */
> #define SIG_DESC_BIT(reg, idx, val) \
> - { reg, BIT_MASK(idx), val, (((val) + 1) & 1) }
> + SIG_DESC_IP_BIT(ASPEED_IP_SCU, reg, idx, val)
> +
> +#define SIG_DESC_IP_SET(ip, reg, idx) SIG_DESC_IP_BIT(ip, reg, idx, 1)
>
> /**
> - * A further short-hand macro describing a configuration enabled with a set bit.
> + * A further short-hand macro expanding to an SCU descriptor enabled by a set
> + * bit.
> *
> - * @reg: The configuration's associated register, offset from base
> - * @idx: The configuration's bit index in the register
> + * @reg: The register, offset from base
> + * @idx: The bit index in the register
> */
> -#define SIG_DESC_SET(reg, idx) SIG_DESC_BIT(reg, idx, 1)
> +#define SIG_DESC_SET(reg, idx) SIG_DESC_IP_BIT(ASPEED_IP_SCU, reg, idx, 1)
>
> #define SIG_DESC_LIST_SYM(sig, func) sig_descs_ ## sig ## _ ## func
> #define SIG_DESC_LIST_DECL(sig, func, ...) \
> @@ -500,7 +514,7 @@ struct aspeed_pin_desc {
> MS_PIN_DECL_(pin, SIG_EXPR_LIST_PTR(gpio))
>
> struct aspeed_pinctrl_data {
> - struct regmap *map;
> + struct regmap *maps[ASPEED_NR_PINMUX_IPS];
>
> const struct pinctrl_pin_desc *pins;
> const unsigned int npins;
> --
> 2.7.4
>
^ 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