* [RFC] fpga: Pull checks for supported operations into framework
From: Moritz Fischer @ 2016-10-31 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477851123-17686-1-git-send-email-moritz.fischer@ettus.com>
Found a couple of issues, will resubmit after cleaning up. Feel free to add
general feedback on the idea anyways in the meantime. Sorry for double post.
On Sun, Oct 30, 2016 at 11:12 AM, Moritz Fischer
<moritz.fischer@ettus.com> wrote:
> Most of the drivers only support a subset of {PARTIAL, FULL}
> reconfiguration.
> Pull duplicate checks in each driver into the framework.
>
> 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,
>
> with the new drivers (ice40, altera-ps-spi) being submitted I've noticed
> we're duplicating this check over and over again,
> so I figured we might as well pull it into the framework.
>
> I'm not sure if there are gonna be other 'flags' we need to support
> in the short term (we talked about byte-swapping ...)
>
> Note: This patch goes on top of greg's char-misc-testing that already
> contains Alan's latest changes to support the A10 and won't apply
> to master.
>
> Cheers,
>
> Moritz
>
> ---
> drivers/fpga/fpga-mgr.c | 12 ++++++++++++
> drivers/fpga/socfpga-a10.c | 4 +++-
> drivers/fpga/socfpga.c | 3 ++-
> drivers/fpga/zynq-fpga.c | 3 ++-
> include/linux/fpga/fpga-mgr.h | 9 +++++++--
> 5 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
> index c58b4c4..85f17d8 100644
> --- a/drivers/fpga/fpga-mgr.c
> +++ b/drivers/fpga/fpga-mgr.c
> @@ -49,6 +49,11 @@ int fpga_mgr_buf_load(struct fpga_manager *mgr, struct fpga_image_info *info,
> struct device *dev = &mgr->dev;
> int ret;
>
> + if (!(mgr->supported_flags & info->flags)) {
> + dev_err(dev, "Unsupported flags passed\n");
> + return -ENOTSUPP;
> + }
That condition is obviously garbage ...
> +
> /*
> * 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
> @@ -252,6 +257,7 @@ EXPORT_SYMBOL_GPL(fpga_mgr_put);
> */
> int fpga_mgr_register(struct device *dev, const char *name,
> const struct fpga_manager_ops *mops,
> + u32 supported_flags,
> void *priv)
> {
> struct fpga_manager *mgr;
> @@ -268,6 +274,11 @@ int fpga_mgr_register(struct device *dev, const char *name,
> return -EINVAL;
> }
>
> + if (!supported_flags) {
> + dev_err(dev, "Attempt to register with no supported flags\n");
> + return -EINVAL;
> + }
> +
> mgr = kzalloc(sizeof(*mgr), GFP_KERNEL);
> if (!mgr)
> return -ENOMEM;
> @@ -282,6 +293,7 @@ int fpga_mgr_register(struct device *dev, const char *name,
>
> mgr->name = name;
> mgr->mops = mops;
> + mgr->supported_flags = supported_flags;
> mgr->priv = priv;
>
> /*
> diff --git a/drivers/fpga/socfpga-a10.c b/drivers/fpga/socfpga-a10.c
> index ccd9fb2..e7c82ff 100644
> --- a/drivers/fpga/socfpga-a10.c
> +++ b/drivers/fpga/socfpga-a10.c
> @@ -519,7 +519,9 @@ static int socfpga_a10_fpga_probe(struct platform_device *pdev)
> }
>
> return fpga_mgr_register(dev, "SoCFPGA Arria10 FPGA Manager",
> - &socfpga_a10_fpga_mgr_ops, priv);
> + &socfpga_a10_fpga_mgr_ops,
> + FPGA_MGR_PARTIAL_RECONFIG,
> + priv);
> }
>
> static int socfpga_a10_fpga_remove(struct platform_device *pdev)
> diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c
> index b6672e6..3285b7d 100644
> --- a/drivers/fpga/socfpga.c
> +++ b/drivers/fpga/socfpga.c
> @@ -582,7 +582,8 @@ static int socfpga_fpga_probe(struct platform_device *pdev)
> return ret;
>
> return fpga_mgr_register(dev, "Altera SOCFPGA FPGA Manager",
> - &socfpga_fpga_ops, priv);
> + &socfpga_fpga_ops, FPGA_MGR_FULL_RECONFIG,
> + 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 249682e..1dabd25 100644
> --- a/drivers/fpga/zynq-fpga.c
> +++ b/drivers/fpga/zynq-fpga.c
> @@ -413,6 +413,7 @@ static int zynq_fpga_probe(struct platform_device *pdev)
> struct zynq_fpga_priv *priv;
> struct resource *res;
> int err;
> + u32 flags = FPGA_MGR_FULL_RECONFIG | FPGA_MGR_PARTIAL_RECONFIG;
>
> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> if (!priv)
> @@ -465,7 +466,7 @@ static int zynq_fpga_probe(struct platform_device *pdev)
> clk_disable(priv->clk);
>
> err = fpga_mgr_register(dev, "Xilinx Zynq FPGA Manager",
> - &zynq_fpga_ops, priv);
> + &zynq_fpga_ops, flags, 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 040b86d..4f4bcf2 100644
> --- a/include/linux/fpga/fpga-mgr.h
> +++ b/include/linux/fpga/fpga-mgr.h
> @@ -64,9 +64,12 @@ enum fpga_mgr_states {
>
> /*
> * FPGA Manager flags
> + * FPGA_MGR_FULL_RECONFIG: do full reconfiguration if supported
> * FPGA_MGR_PARTIAL_RECONFIG: do partial reconfiguration if supported
> */
> -#define FPGA_MGR_PARTIAL_RECONFIG BIT(0)
> +#define FPGA_MGR_FULL_RECONFIG BIT(0)
> +#define FPGA_MGR_PARTIAL_RECONFIG BIT(1)
> +#define FPGA_MGR_EXTERNAL_CONFIG BIT(2)
On second thought the FULL_RECONFIG is the same as !PARTIAL_RECONFIG,
so useless ..
>
> /**
> * struct fpga_image_info - information specific to a FPGA image
> @@ -119,6 +122,7 @@ struct fpga_manager {
> enum fpga_mgr_states state;
> const struct fpga_manager_ops *mops;
> void *priv;
> + u32 supported_flags;
> };
>
> #define to_fpga_manager(d) container_of(d, struct fpga_manager, dev)
> @@ -135,7 +139,8 @@ 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, u32 supported_flags,
> + void *priv);
>
> void fpga_mgr_unregister(struct device *dev);
>
> --
> 2.4.11
>
Cheers,
Moritz
^ permalink raw reply
* [PATCHv2 1/4] dt-bindings: mfd: Add Altera Arria10 SR Monitor
From: Thor Thayer @ 2016-10-31 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031053604.3rjbuk7maabzbwq7@rob-hp-laptop>
Hi Rob,
On 10/31/2016 12:36 AM, Rob Herring wrote:
> On Thu, Oct 27, 2016 at 03:00:23PM -0500, tthayer at opensource.altera.com wrote:
>> From: Thor Thayer <tthayer@opensource.altera.com>
>>
>> Add the Arria10 DevKit System Resource Chip register and state
>> monitoring module to the MFD.
>>
>> Signed-off-by: Thor Thayer <tthayer@opensource.altera.com>
>> ---
>> Note: This needs to be applied to the bindings document that
>> was Acked & Applied but didn't reach the for-next branch.
>> See https://patchwork.ozlabs.org/patch/629397/
>> ---
>> v2 Change compatible string -mon to -monitor for clarity
>> ---
>> Documentation/devicetree/bindings/mfd/altera-a10sr.txt | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>> index ea151f2..c47be28 100644
>> --- a/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>> +++ b/Documentation/devicetree/bindings/mfd/altera-a10sr.txt
>> @@ -18,6 +18,7 @@ The A10SR consists of these sub-devices:
>> Device Description
>> ------ ----------
>> a10sr_gpio GPIO Controller
>
> This should be just "gpio" BTW.
I reason I preprend a10sr_ is to distinguish this GPIO from the other
GPIOs when binding to our LEDs (see below). I think the LEDs need a
unique node name (unless I'm not understanding something).
A less important reason I use a10sr_gpio on the node name is that I can
cat the /sys/class/gpio/gpioxxx/label and see that it is associated with
the a10sr instead of one of our other general GPIOs. Is there a better
way to distinguish these?
>
>> +a10sr_monitor Register and State Monitoring
>
> s/_/-/ or maybe just "monitor". Not really a generic node name to use
> for this.
>
The reason I use _ for the node name is that the DTC fails if I
reference a node name with "-" but works OK for "_". For instance, I get
an error if the LEDs reference "a10sr-gpio" but "a10sr_gpio" compiles ok.
Thanks for reviewing!
Thor
> Rob
>
^ permalink raw reply
* [PATCH] arm64: mm: fix __page_to_voff definition
From: Catalin Marinas @ 2016-10-31 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161030143858.vhmnibvvwf5qjvqj@localhost>
On Sun, Oct 30, 2016 at 02:38:58PM +0000, Catalin Marinas wrote:
> On Fri, Oct 21, 2016 at 02:28:46PM +0530, Neeraj Upadhyay wrote:
> > Fix parameter name for __page_to_voff, to match its definition.
> > At present, we don't see any issue, as page_to_virt's caller
> > declares 'page'.
> >
> > Fixes: 9f2875912dac ("arm64: mm: restrict virt_to_page() to the linear mapping")
> > Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
>
> I'll queue this patch for 4.10. Thanks.
I didn't realise that Will sent it already for 4.9-rc3, so I dropped it
from the 4.10 queue.
--
Catalin
^ permalink raw reply
* [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Russell King - ARM Linux @ 2016-10-31 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1913139.FJW82OAuEF@amdc3058>
On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Wednesday, July 13, 2016 04:37:31 PM Arnd Bergmann wrote:
> > On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > >
> > > On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
> > > > On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
> > > > > This patch disables deprecated IDE subsystem in assabet_defconfig
> > > > > (no IDE host drivers are selected in this config so there is no
> > > > > valid reason to enable IDE subsystem itself).
> > > > >
> > > > > Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> > > > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > > >
> > > > I think the series makes a lot of sense. I have checked your assertions
> > > > in the changelogs and found no flaws in your logic, so I think we should
> > > > take them all through arm-soc unless there are other concerns.
> > >
> > > Thank you.
> > >
> > > Should I resend everything or just patches that were not reposted yet
> > > (the ones that were marked as RFT initially and got no feedback)?
> >
> > I'd be fine with just getting a pull request with all the patches that
> > had no negative feedback and that were not already applied (if any).
>
> Here it is (sorry for taking so long).
I've just been digging in the dmesg logs from when I was using the
Assabet+Neponset as my firewall, and it was having to use the IDE
ide-cs driver rather than the pata pcmcia driver.
I don't recall whether the pata pcmcia driver was a problem or not,
as the PCMCIA interface can't cope with _any_ 32-bit accesses. I
think PATA tries to use the "highest" possible access size by
default...
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Applied "ASoC: sun4i-codec: return error code instead of NULL when create_card fails" to the asoc tree
From: Mark Brown @ 2016-10-31 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031064209.12241-1-wens@csie.org>
The patch
ASoC: sun4i-codec: return error code instead of NULL when create_card fails
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 85915b63ad8b796848f431b66c9ba5e356e722e5 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens@csie.org>
Date: Mon, 31 Oct 2016 14:42:09 +0800
Subject: [PATCH] ASoC: sun4i-codec: return error code instead of NULL when
create_card fails
When sun4i_codec_create_card fails, we do not assign a proper error
code to the return value. The return value would be 0 from the previous
function call, or we would have bailed out sooner. This would confuse
the driver core into thinking the device probe succeeded, when in fact
it didn't, leaving various devres based resources lingering.
Make the create_card function pass back a meaningful error code, and
assign it to the return value.
Fixes: 45fb6b6f2aa3 ("ASoC: sunxi: add support for the on-chip codec on
early Allwinner SoCs")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index e047ec06d538..a60707761abf 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -765,11 +765,11 @@ static struct snd_soc_card *sun4i_codec_create_card(struct device *dev)
card = devm_kzalloc(dev, sizeof(*card), GFP_KERNEL);
if (!card)
- return NULL;
+ return ERR_PTR(-ENOMEM);
card->dai_link = sun4i_codec_create_link(dev, &card->num_links);
if (!card->dai_link)
- return NULL;
+ return ERR_PTR(-ENOMEM);
card->dev = dev;
card->name = "sun4i-codec";
@@ -876,7 +876,8 @@ static int sun4i_codec_probe(struct platform_device *pdev)
}
card = sun4i_codec_create_card(&pdev->dev);
- if (!card) {
+ if (IS_ERR(card)) {
+ ret = PTR_ERR(card);
dev_err(&pdev->dev, "Failed to create our card\n");
goto err_unregister_codec;
}
--
2.10.1
^ permalink raw reply related
* MAINTAINERS entry for ARM/CLKDEV SUPPORT
From: Russell King - ARM Linux @ 2016-10-31 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <663e5d47-c2b5-c76f-01b4-0fb9a792acf6@codeaurora.org>
On Wed, Oct 26, 2016 at 02:31:31PM -0700, Stephen Boyd wrote:
> On 10/26/2016 12:19 PM, Dan Carpenter wrote:
> > On Mon, Oct 10, 2016 at 03:18:19PM +0100, Russell King - ARM Linux wrote:
> >> On Mon, Oct 10, 2016 at 05:08:10PM +0300, Dan Carpenter wrote:
> >>> Hello Stephen Boyd,
> >> Okay, that's really not nice.
> >>
> >> This is _not_ a question for Stephen. Stephen does _not_ co-maintain
> >> clkdev or the clk API, but co-maintains CCF. I've no idea why you are
> >> addressing this to Stephen when this is clearly a question for me to
> >> answer.
> >>
> > Sorry, I didn't mean to offend. He's the one who deleted the clkdev.h
> > file though so I thought he might know if it should still be listed or
> > if it was gone for good.
> >
>
> Yes, the arm version isn't coming back. We should delete
> arch/arm/include/asm/clkdev.h from the maintainers file and perhaps
> replace it with the asm-generic one.
I disagree. See my reply to the original mail for the reasons.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2 1/8] drm/bridge: rgb-to-vga: Support an enable GPIO
From: Russell King - ARM Linux @ 2016-10-31 15:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026221724.55yufeql6s5nd5gq@lukather>
On Thu, Oct 27, 2016 at 12:17:24AM +0200, Maxime Ripard wrote:
> Hi Rob,
>
> On Wed, Oct 26, 2016 at 05:13:46PM -0500, Rob Herring wrote:
> > On Thu, Oct 20, 2016 at 11:43:37AM +0800, Chen-Yu Tsai wrote:
> > > Some rgb-to-vga bridges have an enable GPIO, either directly tied to
> > > an enable pin on the bridge IC, or indirectly controlling a power
> > > switch.
> > >
> > > Add support for it.
> > >
> > > Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> > > ---
> > > .../bindings/display/bridge/dumb-vga-dac.txt | 2 ++
> > > drivers/gpu/drm/bridge/dumb-vga-dac.c | 28 ++++++++++++++++++++++
> > > 2 files changed, 30 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> > > index 003bc246a270..d3484822bf77 100644
> > > --- a/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> > > +++ b/Documentation/devicetree/bindings/display/bridge/dumb-vga-dac.txt
> > > @@ -16,6 +16,8 @@ graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> > > - Video port 0 for RGB input
> > > - Video port 1 for VGA output
> > >
> > > +Optional properties:
> > > +- enable-gpios: GPIO pin to enable or disable the bridge
> >
> > This should also define the active state.
> >
> > > +static void dumb_vga_enable(struct drm_bridge *bridge)
> > > +{
> > > + struct dumb_vga *vga = drm_bridge_to_dumb_vga(bridge);
> > > +
> > > + if (vga->enable_gpio)
> > > + gpiod_set_value_cansleep(vga->enable_gpio, 1);
> >
> > So the driver should allow either active high or low.
>
> You mean like having a enable-active-high property? Isn't that
> redundant with the GPIO flags?
Correct - the gpiod APIs remove the need for drivers to know the
polarity of the signal, handling it inside the GPIO subsystem
instead, controlled either from the gpiod lookup tables in legacy
board files, or the DT specification for the GPIO.
So, in drivers, gpiod_set_value*(, 1) means "set gpio to active
level" and gpiod_set_value*(, 0) means "set gpio to inactive level".
Far nicer than all the bugs we've had with the legacy GPIO interfaces
with random different drivers implementing random different ways to
invert the signal, with all the pain that brings with it when a
platform comes along with a different inversion state.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* SMR masking and PCI
From: Diana Madalina Craciun @ 2016-10-31 15:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c39b785a-0f18-fc0a-ce08-7ebe3cfaf8c5@arm.com>
Hi Robin,
On 10/28/2016 07:16 PM, Robin Murphy wrote:
> Hi Stuart,
>
> On 27/10/16 18:10, Stuart Yoder wrote:
>> Hi Robin,
>>
>> A question about how the SMR masking defined in the arm,smmu binding
>> relates to the PCI iommu-map.
>>
>> The #iommu-cells property defines the number of cells an "IOMMU specifier"
>> takes and 2 is specified to be:
>>
>> SMMUs with stream matching support and complex masters
>> may use a value of 2, where the second cell represents
>> an SMR mask to combine with the ID in the first cell.
>>
>> An iommu-map entry is defined as:
>>
>> (rid-base,iommu,iommu-base,length)
>>
>> What seems to be currently missing in the iommu-map support is
>> the possibility the case where #iommu-cells=<2>.
> Indeed. The bindings have so far rather implicitly assumed the case of
> #{msi,iommu}-cells = 1, and the code has followed suit.
>
>> In this case iommu-base which is an IOMMU specifier should
>> occupy 2 cells. For example on an ls2085a we would want:
>>
>> iommu-map = <0x0 0x6 0x7 0x3ff 0x1
>> 0x100 0x6 0x8 0x3ff 0x1>;
>>
>> ...to mask our stream IDs to 10 bits.
>>
>> This should work in theory and comply with the bindings, no?
> In theory, but now consider:
>
> iommu-map = <0x0 0x6 0x7 0x3ff 0x2>;
>
> faced with ID 1. The input base is 0, the output base is the 2-cell
> value 0x7000003ff, so the final ID value should be 0x700000400, right?
>
>> of_pci_map_rid() seems to have a hardcoded assumption that
>> each field in the map is 4 bytes.
> It does. I guess we should explicitly check that #{msi,iommu}-cells = 1
> on the target node, and maybe clarify in the binding that that cell
> should represent a plain linear ID value (although that's pretty obvious
> from context IMO).
>
>> (Also, I guess that msi-map is not affected by this since it
>> is not related to the IOMMU...but we do have common code
>> handling both maps.)
> I'd say it's definitely affected, since #msi-cells can equally be more
> than 1, and encodes an equally opaque value.
>
> It seems pretty reasonable to me that we could extend the binding to
> accommodate #cells > 1 iff length == 1. Mark?
>
> That said, is there a concrete need for this, i.e. do you actually have
> one device with a single requester ID, which maps to multiple output IDs
> (which differ only in the upper bits) in a non-predictable manner?
>
Actually in the example presented by Stuart, the SMR mask should be
0x7C00 (as 0 means that the bit is relevant for matching). So, we have
the stream ID 7, but the SMMU 500 is appending the TBU bits which makes
the stream ID look like 0x1407 (TBU 5). In our platform the relationship
device-TBU is not exposed and documented. The SMMU-500 ref manual
describes this case:
"If the Stream ID presented to each TBU is already unique, and the TBU
ID addition is not required, then you must ensure that the TBU ID field
is masked in the SMR."
This is the reason that we need the SMR mask, to mask the TBU bits in
the SMR.
Thank you,
Diana
^ permalink raw reply
* [PATCH v2 0/3] arm64: Support systems without FP/ASIMD
From: Suzuki K Poulose @ 2016-10-31 16:03 UTC (permalink / raw)
To: linux-arm-kernel
This series adds supports to the kernel and KVM hyp to handle
systems without FP/ASIMD properly. At the moment the kernel
doesn't check if the FP unit is available before accessing
the registers (e.g during context switch). Also for KVM,
we trap the FP/ASIMD accesses and handle it by injecting an
undefined instruction into the VM on systems without FP.
Tested on a FVP_Base-AEM-v8A model by disabling VFP on at
least one CPU ( -C clusterX.cpuY.vfp-present=0 ).
Applies on aarch64 : for-next/core
Suzuki K Poulose (3):
arm64: crypto/aes-ce-ccm: Cleanup hwcap check
arm64: Add hypervisor safe helper for checking constant capabilities
arm64: Support systems without FP/ASIMD
arch/arm64/crypto/aes-ce-ccm-glue.c | 5 ++---
arch/arm64/include/asm/cpufeature.h | 24 ++++++++++++++++++++----
arch/arm64/include/asm/neon.h | 3 ++-
arch/arm64/kernel/cpufeature.c | 15 +++++++++++++++
arch/arm64/kernel/fpsimd.c | 14 ++++++++++++++
arch/arm64/kvm/handle_exit.c | 11 +++++++++++
arch/arm64/kvm/hyp/hyp-entry.S | 9 ++++++++-
arch/arm64/kvm/hyp/switch.c | 5 ++++-
8 files changed, 76 insertions(+), 10 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/3] arm64: crypto/aes-ce-ccm: Cleanup hwcap check
From: Suzuki K Poulose @ 2016-10-31 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477929825-5907-1-git-send-email-suzuki.poulose@arm.com>
Use the module_cpu_feature_match to make sure the system has
HWCAP_AES to use the module.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/crypto/aes-ce-ccm-glue.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/crypto/aes-ce-ccm-glue.c b/arch/arm64/crypto/aes-ce-ccm-glue.c
index f4bf2f2..fa82eaa 100644
--- a/arch/arm64/crypto/aes-ce-ccm-glue.c
+++ b/arch/arm64/crypto/aes-ce-ccm-glue.c
@@ -14,6 +14,7 @@
#include <crypto/algapi.h>
#include <crypto/scatterwalk.h>
#include <crypto/internal/aead.h>
+#include <linux/cpufeature.h>
#include <linux/module.h>
#include "aes-ce-setkey.h"
@@ -296,8 +297,6 @@ static struct aead_alg ccm_aes_alg = {
static int __init aes_mod_init(void)
{
- if (!(elf_hwcap & HWCAP_AES))
- return -ENODEV;
return crypto_register_aead(&ccm_aes_alg);
}
@@ -306,7 +305,7 @@ static void __exit aes_mod_exit(void)
crypto_unregister_aead(&ccm_aes_alg);
}
-module_init(aes_mod_init);
+module_cpu_feature_match(AES, aes_mod_init);
module_exit(aes_mod_exit);
MODULE_DESCRIPTION("Synchronous AES in CCM mode using ARMv8 Crypto Extensions");
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] arm64: Add hypervisor safe helper for checking constant capabilities
From: Suzuki K Poulose @ 2016-10-31 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477929825-5907-1-git-send-email-suzuki.poulose@arm.com>
The hypervisor may not have full access to the kernel data structures
and hence cannot safely use cpus_have_cap() helper for checking the
system capability. Add a safe helper for hypervisors to check a constant
system capability, which *doesn't* fall back to checking the bitmap
maintained by the kernel.
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
arch/arm64/include/asm/cpufeature.h | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 758d74f..ae5e994 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -9,8 +9,6 @@
#ifndef __ASM_CPUFEATURE_H
#define __ASM_CPUFEATURE_H
-#include <linux/jump_label.h>
-
#include <asm/hwcap.h>
#include <asm/sysreg.h>
@@ -45,6 +43,8 @@
#ifndef __ASSEMBLY__
+#include <linux/bug.h>
+#include <linux/jump_label.h>
#include <linux/kernel.h>
/* CPU feature register tracking */
@@ -122,6 +122,16 @@ static inline bool cpu_have_feature(unsigned int num)
return elf_hwcap & (1UL << num);
}
+/* System capability check for constant caps */
+static inline bool cpus_have_const_cap(int num)
+{
+ if (__builtin_constant_p(num))
+ return static_branch_unlikely(&cpu_hwcap_keys[num]);
+ BUILD_BUG();
+ /* unreachable */
+ return false;
+}
+
static inline bool cpus_have_cap(unsigned int num)
{
if (num >= ARM64_NCAPS)
@@ -218,7 +228,7 @@ static inline bool cpu_supports_mixed_endian_el0(void)
static inline bool system_supports_32bit_el0(void)
{
- return cpus_have_cap(ARM64_HAS_32BIT_EL0);
+ return cpus_have_const_cap(ARM64_HAS_32BIT_EL0);
}
static inline bool system_supports_mixed_endian_el0(void)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] arm64: Support systems without FP/ASIMD
From: Suzuki K Poulose @ 2016-10-31 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477929825-5907-1-git-send-email-suzuki.poulose@arm.com>
The arm64 kernel assumes that FP/ASIMD units are always present
and accesses the FP/ASIMD specific registers unconditionally. This
could cause problems when they are absent. This patch adds the
support for kernel handling systems without FP/ASIMD by skipping the
register access within the kernel. For kvm, we trap the accesses
to FP/ASIMD and inject an undefined instruction exception to the VM.
The callers of the exported kernel_neon_begin_parital() should
make sure that the FP/ASIMD is supported.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
Changes since V1:
- Dropped explicit FP/ASIMD check from Crypto modules.
---
arch/arm64/include/asm/cpufeature.h | 8 +++++++-
arch/arm64/include/asm/neon.h | 3 ++-
arch/arm64/kernel/cpufeature.c | 15 +++++++++++++++
arch/arm64/kernel/fpsimd.c | 14 ++++++++++++++
arch/arm64/kvm/handle_exit.c | 11 +++++++++++
arch/arm64/kvm/hyp/hyp-entry.S | 9 ++++++++-
arch/arm64/kvm/hyp/switch.c | 5 ++++-
7 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index ae5e994..63d739c 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -38,8 +38,9 @@
#define ARM64_HAS_32BIT_EL0 13
#define ARM64_HYP_OFFSET_LOW 14
#define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
+#define ARM64_HAS_NO_FPSIMD 16
-#define ARM64_NCAPS 16
+#define ARM64_NCAPS 17
#ifndef __ASSEMBLY__
@@ -236,6 +237,11 @@ static inline bool system_supports_mixed_endian_el0(void)
return id_aa64mmfr0_mixed_endian_el0(read_system_reg(SYS_ID_AA64MMFR0_EL1));
}
+static inline bool system_supports_fpsimd(void)
+{
+ return !cpus_have_const_cap(ARM64_HAS_NO_FPSIMD);
+}
+
#endif /* __ASSEMBLY__ */
#endif
diff --git a/arch/arm64/include/asm/neon.h b/arch/arm64/include/asm/neon.h
index 13ce4cc..ad4cdc9 100644
--- a/arch/arm64/include/asm/neon.h
+++ b/arch/arm64/include/asm/neon.h
@@ -9,8 +9,9 @@
*/
#include <linux/types.h>
+#include <asm/fpsimd.h>
-#define cpu_has_neon() (1)
+#define cpu_has_neon() system_supports_fpsimd()
#define kernel_neon_begin() kernel_neon_begin_partial(32)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d577f26..8f22544 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -744,6 +744,14 @@ static bool hyp_offset_low(const struct arm64_cpu_capabilities *entry,
return idmap_addr > GENMASK(VA_BITS - 2, 0) && !is_kernel_in_hyp_mode();
}
+static bool has_no_fpsimd(const struct arm64_cpu_capabilities *entry, int __unused)
+{
+ u64 pfr0 = read_system_reg(SYS_ID_AA64PFR0_EL1);
+
+ return cpuid_feature_extract_signed_field(pfr0,
+ ID_AA64PFR0_FP_SHIFT) < 0;
+}
+
static const struct arm64_cpu_capabilities arm64_features[] = {
{
.desc = "GIC system register CPU interface",
@@ -827,6 +835,13 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
.def_scope = SCOPE_SYSTEM,
.matches = hyp_offset_low,
},
+ {
+ /* FP/SIMD is not implemented */
+ .capability = ARM64_HAS_NO_FPSIMD,
+ .def_scope = SCOPE_SYSTEM,
+ .min_field_value = 0,
+ .matches = has_no_fpsimd,
+ },
{},
};
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 975b274..80da5aa 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -127,6 +127,8 @@ void do_fpsimd_exc(unsigned int esr, struct pt_regs *regs)
void fpsimd_thread_switch(struct task_struct *next)
{
+ if (!system_supports_fpsimd())
+ return;
/*
* Save the current FPSIMD state to memory, but only if whatever is in
* the registers is in fact the most recent userland FPSIMD state of
@@ -157,6 +159,8 @@ void fpsimd_thread_switch(struct task_struct *next)
void fpsimd_flush_thread(void)
{
+ if (!system_supports_fpsimd())
+ return;
memset(¤t->thread.fpsimd_state, 0, sizeof(struct fpsimd_state));
fpsimd_flush_task_state(current);
set_thread_flag(TIF_FOREIGN_FPSTATE);
@@ -168,6 +172,8 @@ void fpsimd_flush_thread(void)
*/
void fpsimd_preserve_current_state(void)
{
+ if (!system_supports_fpsimd())
+ return;
preempt_disable();
if (!test_thread_flag(TIF_FOREIGN_FPSTATE))
fpsimd_save_state(¤t->thread.fpsimd_state);
@@ -181,6 +187,8 @@ void fpsimd_preserve_current_state(void)
*/
void fpsimd_restore_current_state(void)
{
+ if (!system_supports_fpsimd())
+ return;
preempt_disable();
if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
struct fpsimd_state *st = ¤t->thread.fpsimd_state;
@@ -199,6 +207,8 @@ void fpsimd_restore_current_state(void)
*/
void fpsimd_update_current_state(struct fpsimd_state *state)
{
+ if (!system_supports_fpsimd())
+ return;
preempt_disable();
fpsimd_load_state(state);
if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {
@@ -228,6 +238,8 @@ static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
*/
void kernel_neon_begin_partial(u32 num_regs)
{
+ if (WARN_ON(!system_supports_fpsimd()))
+ return;
if (in_interrupt()) {
struct fpsimd_partial_state *s = this_cpu_ptr(
in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
@@ -252,6 +264,8 @@ EXPORT_SYMBOL(kernel_neon_begin_partial);
void kernel_neon_end(void)
{
+ if (!system_supports_fpsimd())
+ return;
if (in_interrupt()) {
struct fpsimd_partial_state *s = this_cpu_ptr(
in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index fa96fe2..39e055a 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -57,6 +57,16 @@ static int handle_smc(struct kvm_vcpu *vcpu, struct kvm_run *run)
return 1;
}
+/*
+ * Guest access to FP/ASIMD registers are routed to this handler only
+ * when the system doesn't support FP/ASIMD.
+ */
+static int handle_no_fpsimd(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+ kvm_inject_undefined(vcpu);
+ return 1;
+}
+
/**
* kvm_handle_wfx - handle a wait-for-interrupts or wait-for-event
* instruction executed by a guest
@@ -144,6 +154,7 @@ static exit_handle_fn arm_exit_handlers[] = {
[ESR_ELx_EC_BREAKPT_LOW]= kvm_handle_guest_debug,
[ESR_ELx_EC_BKPT32] = kvm_handle_guest_debug,
[ESR_ELx_EC_BRK64] = kvm_handle_guest_debug,
+ [ESR_ELx_EC_FP_ASIMD] = handle_no_fpsimd,
};
static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu)
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
index f6d9694..16167d7 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -117,9 +117,16 @@ el1_trap:
* x2: ESR_EC
*/
- /* Guest accessed VFP/SIMD registers, save host, restore Guest */
+ /*
+ * We trap the first access to the FP/SIMD to save the host context
+ * and restore the guest context lazily.
+ * If FP/SIMD is not implemented, handle the trap and inject an
+ * undefined instruction exception to the guest.
+ */
+alternative_if_not ARM64_HAS_NO_FPSIMD
cmp x2, #ESR_ELx_EC_FP_ASIMD
b.eq __fpsimd_guest_restore
+alternative_else_nop_endif
mrs x0, tpidr_el2
mov x1, #ARM_EXCEPTION_TRAP
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index ae7855f..f2d0c4f 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -18,6 +18,7 @@
#include <linux/types.h>
#include <asm/kvm_asm.h>
#include <asm/kvm_hyp.h>
+#include <asm/fpsimd.h>
static bool __hyp_text __fpsimd_enabled_nvhe(void)
{
@@ -73,9 +74,11 @@ static void __hyp_text __activate_traps(struct kvm_vcpu *vcpu)
* traps are only taken to EL2 if the operation would not otherwise
* trap to EL1. Therefore, always make sure that for 32-bit guests,
* we set FPEXC.EN to prevent traps to EL1, when setting the TFP bit.
+ * If FP/ASIMD is not implemented, FPEXC is UNDEFINED and any access to
+ * it will cause an exception.
*/
val = vcpu->arch.hcr_el2;
- if (!(val & HCR_RW)) {
+ if (!(val & HCR_RW) && system_supports_fpsimd()) {
write_sysreg(1 << 30, fpexc32_el2);
isb();
}
--
2.7.4
^ permalink raw reply related
* [PATCH v5 1/2] drm: tilcdc: implement palette loading for rev1
From: Jyri Sarha @ 2016-10-31 16:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477923567-1610-2-git-send-email-bgolaszewski@baylibre.com>
On 10/31/16 16:19, Bartosz Golaszewski wrote:
> Revision 1 of the IP doesn't work if we don't load the palette (even
> if it's not used, which is the case for the RGB565 format).
>
> Add a function called from tilcdc_crtc_enable() which performs all
> required actions if we're dealing with a rev1 chip.
>
There is only one thing I do not like about this patch. The palette
loading is done so late that the frame buffer address are already placed
into DMA base and ceiling registers, and we need to read them from the
registers and restore them back after the palette loading.
Could you try if the palette loading function works without trouble when
called from tilcdc_pm_resume() before drm_atomic_helper_resume() call?
If it does it would be cleaner in the sense that you could get rid off
the old dma address restore code. You could reinit the completion always
there right before the palette loading.
If you can not get the above suggestion to work, then I can take this
patch.
BR,
Jyri
ps. There is one nit pick comment bellow.
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 88 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 87 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index db2f538..937697d 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -21,11 +21,15 @@
> #include <drm/drm_flip_work.h>
> #include <drm/drm_plane_helper.h>
> #include <linux/workqueue.h>
> +#include <linux/completion.h>
> +#include <linux/dma-mapping.h>
>
> #include "tilcdc_drv.h"
> #include "tilcdc_regs.h"
>
> -#define TILCDC_VBLANK_SAFETY_THRESHOLD_US 1000
> +#define TILCDC_VBLANK_SAFETY_THRESHOLD_US 1000
> +#define TILCDC_REV1_PALETTE_SIZE 32
> +#define TILCDC_REV1_PALETTE_FIRST_ENTRY 0x4000
>
> struct tilcdc_crtc {
> struct drm_crtc base;
> @@ -53,6 +57,10 @@ struct tilcdc_crtc {
>
> int sync_lost_count;
> bool frame_intact;
> +
> + dma_addr_t palette_dma_handle;
> + void *palette_base;
> + struct completion palette_loaded;
> };
> #define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)
>
> @@ -98,6 +106,55 @@ static void set_scanout(struct drm_crtc *crtc, struct drm_framebuffer *fb)
> tilcdc_crtc->curr_fb = fb;
> }
>
> +/*
> + * The driver currently only supports the RGB565 format for revision 1. For
> + * 16 bits-per-pixel the palette block is bypassed, but the first 32 bytes of
> + * the framebuffer are still considered palette. The first 16-bit entry must
> + * be 0x4000 while all other entries must be zeroed.
> + */
> +static void tilcdc_crtc_load_palette(struct drm_crtc *crtc)
> +{
> + u32 dma_fb_base, dma_fb_ceiling, raster_ctl;
> + struct tilcdc_crtc *tilcdc_crtc;
> + struct drm_device *dev;
> + u16 *first_entry;
> +
> + dev = crtc->dev;
> + tilcdc_crtc = to_tilcdc_crtc(crtc);
> + first_entry = tilcdc_crtc->palette_base;
> +
> + *first_entry = TILCDC_REV1_PALETTE_FIRST_ENTRY;
> +
> + dma_fb_base = tilcdc_read(dev, LCDC_DMA_FB_BASE_ADDR_0_REG);
> + dma_fb_ceiling = tilcdc_read(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG);
> + raster_ctl = tilcdc_read(dev, LCDC_RASTER_CTRL_REG);
> +
> + /* Tell the LCDC where the palette is located. */
> + tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG,
> + tilcdc_crtc->palette_dma_handle);
> + tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG,
> + (u32)tilcdc_crtc->palette_dma_handle
Just a nit pick, but I would put the plus sign to the end of the line
above instead of the beginning of the line bellow. However,
check_patch.pl does not complain about this so I guess I can accept it too.
> + + TILCDC_REV1_PALETTE_SIZE - 1);
> +
> + /* Load it. */
> + tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
> + LCDC_PALETTE_LOAD_MODE(DATA_ONLY));
> + tilcdc_set(dev, LCDC_RASTER_CTRL_REG,
> + LCDC_PALETTE_LOAD_MODE(PALETTE_ONLY));
> +
> + /* Enable the LCDC and wait for palette to be loaded. */
> + tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_V1_PL_INT_ENA);
> + tilcdc_set(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
> +
> + wait_for_completion(&tilcdc_crtc->palette_loaded);
> +
> + /* Restore the registers. */
> + tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
> + tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG, dma_fb_base);
> + tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG, dma_fb_ceiling);
> + tilcdc_write(dev, LCDC_RASTER_CTRL_REG, raster_ctl);
> +}
> +
> static void tilcdc_crtc_enable_irqs(struct drm_device *dev)
> {
> struct tilcdc_drm_private *priv = dev->dev_private;
> @@ -152,6 +209,7 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
> {
> struct drm_device *dev = crtc->dev;
> struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
> + struct tilcdc_drm_private *priv = dev->dev_private;
>
> WARN_ON(!drm_modeset_is_locked(&crtc->mutex));
>
> @@ -162,6 +220,9 @@ static void tilcdc_crtc_enable(struct drm_crtc *crtc)
>
> reset(crtc);
>
> + if (priv->rev == 1 && !completion_done(&tilcdc_crtc->palette_loaded))
> + tilcdc_crtc_load_palette(crtc);
> +
> tilcdc_crtc_enable_irqs(dev);
>
> tilcdc_clear(dev, LCDC_DMA_CTRL_REG, LCDC_DUAL_FRAME_BUFFER_ENABLE);
> @@ -200,6 +261,13 @@ void tilcdc_crtc_disable(struct drm_crtc *crtc)
> __func__);
> }
>
> + /*
> + * LCDC will not retain the palette when reset. Make sure it gets
> + * reloaded on tilcdc_crtc_enable().
> + */
> + if (priv->rev == 1)
> + reinit_completion(&tilcdc_crtc->palette_loaded);
> +
> drm_crtc_vblank_off(crtc);
>
> tilcdc_crtc_disable_irqs(dev);
> @@ -802,6 +870,14 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
> dev_err_ratelimited(dev->dev, "%s(0x%08x): FIFO underfow",
> __func__, stat);
>
> + if (priv->rev == 1) {
> + if (stat & LCDC_PL_LOAD_DONE) {
> + complete(&tilcdc_crtc->palette_loaded);
> + tilcdc_clear(dev,
> + LCDC_RASTER_CTRL_REG, LCDC_V1_PL_INT_ENA);
> + }
> + }
> +
> /* For revision 2 only */
> if (priv->rev == 2) {
> if (stat & LCDC_FRAME_DONE) {
> @@ -843,6 +919,16 @@ struct drm_crtc *tilcdc_crtc_create(struct drm_device *dev)
> return NULL;
> }
>
> + if (priv->rev == 1) {
> + init_completion(&tilcdc_crtc->palette_loaded);
> + tilcdc_crtc->palette_base = dmam_alloc_coherent(dev->dev,
> + TILCDC_REV1_PALETTE_SIZE,
> + &tilcdc_crtc->palette_dma_handle,
> + GFP_KERNEL | __GFP_ZERO);
> + if (!tilcdc_crtc->palette_base)
> + return ERR_PTR(-ENOMEM);
> + }
> +
> crtc = &tilcdc_crtc->base;
>
> ret = tilcdc_plane_init(dev, &tilcdc_crtc->primary);
>
^ permalink raw reply
* [PATCH 1/5] ARM: wire up HWCAP2 feature bits to the CPU modalias
From: Russell King - ARM Linux @ 2016-10-31 16:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_y7e=sJT+7FNj846NczgpNOdVx53SDC7dupmN-3ztNwA@mail.gmail.com>
On Sat, Oct 29, 2016 at 11:08:36AM +0100, Ard Biesheuvel wrote:
> On 18 October 2016 at 11:52, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > Wire up the generic support for exposing CPU feature bits via the
> > modalias in /sys/device/system/cpu. This allows udev to automatically
> > load modules for things like crypto algorithms that are implemented
> > using optional instructions.
> >
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > ---
> > arch/arm/Kconfig | 1 +
> > arch/arm/include/asm/cpufeature.h | 32 ++++++++++++++++++++
> > 2 files changed, 33 insertions(+)
> >
>
> Russell,
>
> do you have any concerns regarding this patch? If not, I will drop it
> into the patch system.
It's still something I need to look at... I've been offline last week,
and sort-of offline the previous week, so I'm catching up.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 2/2] MAINTAINERS: add ARM and arm64 EFI specific files to EFI subsystem
From: Russell King - ARM Linux @ 2016-10-31 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9B7X3CDVZrxZQFVsn3U2CT0A2Z3Owj7BQuFXPjk5Ln4Q@mail.gmail.com>
On Sat, Oct 29, 2016 at 11:09:55AM +0100, Ard Biesheuvel wrote:
> On 21 September 2016 at 16:35, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > Since I will be co-maintaining the EFI subsystem, it makes sense to
> > mention the ARM and arm64 EFI bits in the EFI section in MAINTAINERS
> > so that Matt, the list and I get cc'ed on proposed changes.
> >
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Russell King <rmk+kernel@armlinux.org.uk>
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > ---
> > MAINTAINERS | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
>
> Russell,
>
> do you have an objections to this change?
Looks fine, thanks.
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [Bug] ARM: mxs: STI: console can't wake up from freeze
From: Russell King - ARM Linux @ 2016-10-31 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1709157673.85170.1cb53b4d-2805-48ea-aef1-dd282306d108.open-xchange@email.1und1.de>
On Sat, Oct 29, 2016 at 01:44:14PM +0200, Stefan Wahren wrote:
> unfortunately not:
>
> Setting: no_console_suspend not in cmdline, Debug UART wakeup source enabled
>
> echo mem > /sys/power/state
>
> Result: Able to wakeup via Debug UART
> Expected result: Able to wakeup via Debug UART
>
> ---
>
> Setting: no_console_suspend not in cmdline, Debug UART wakeup source enabled
>
> echo freeze > /sys/power/state
>
> Result: Unable to wakeup via Debug UART (no hung task warning)
> Expected result: Able to wakeup via Debug UART
Okay - I know that certain actions are bypassed when no_console_suspend
is set, which has detrimental effects on some ARM platforms, so it was
worth testing - iirc, working no_console_suspend is reliant on the boot
loader re-setting up the serial port after its lost state.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: spear: Fix error handling
From: Russell King - ARM Linux @ 2016-10-31 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161029135839.6388-1-christophe.jaillet@wanadoo.fr>
For the spear or arm-soc guys to deal with...
On Sat, Oct 29, 2016 at 03:58:39PM +0200, Christophe JAILLET wrote:
> 'clk_get_sys()' returns an error pointer in case of error, not NULL. So
> test it with IS_ERR.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> arch/arm/mach-spear/time.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-spear/time.c b/arch/arm/mach-spear/time.c
> index 9ccffc1d0f28..4878ba90026d 100644
> --- a/arch/arm/mach-spear/time.c
> +++ b/arch/arm/mach-spear/time.c
> @@ -233,7 +233,7 @@ void __init spear_setup_of_timer(void)
> }
>
> gpt_clk = clk_get_sys("gpt0", NULL);
> - if (!gpt_clk) {
> + if (IS_ERR(gpt_clk)) {
> pr_err("%s:couldn't get clk for gpt\n", __func__);
> goto err_iomap;
> }
> --
> 2.9.3
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: mm: add ARM_L1_CACHE_SHIFT_7 for UniPhier outer cache
From: Russell King - ARM Linux @ 2016-10-31 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNAQfZ86_V6ZC5nnCB7Y4EvOPtFBUDM+Kfm9UNyE9h6MA4Q@mail.gmail.com>
On Sun, Oct 30, 2016 at 12:31:04AM +0900, Masahiro Yamada wrote:
> Hi.
>
> If there is no objection to this patch,
> I will put it into Russell's patch tracker.
I don't think I have any objection, it's following the same pattern
that we have for 64-byte cache lines, and this is about the only way
to deal with it.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: zx: Fix error handling
From: Russell King - ARM Linux @ 2016-10-31 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161030081010.14735-1-christophe.jaillet@wanadoo.fr>
Same as the other fix...
On Sun, Oct 30, 2016 at 09:10:10AM +0100, Christophe JAILLET wrote:
> 'devm_ioremap_resource()' returns an error pointer in case of error, not
> NULL. So test it with IS_ERR.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> 'return -EIO;' could also be turned into 'return PTR_ERR(pcubase);' in
> order to propagate the error value.
> ---
> arch/arm/mach-zx/zx296702-pm-domain.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-zx/zx296702-pm-domain.c b/arch/arm/mach-zx/zx296702-pm-domain.c
> index e08574d4e2ca..79dcf2549267 100644
> --- a/arch/arm/mach-zx/zx296702-pm-domain.c
> +++ b/arch/arm/mach-zx/zx296702-pm-domain.c
> @@ -169,7 +169,7 @@ static int zx296702_pd_probe(struct platform_device *pdev)
> }
>
> pcubase = devm_ioremap_resource(&pdev->dev, res);
> - if (!pcubase) {
> + if (IS_ERR(pcubase)) {
> dev_err(&pdev->dev, "ioremap fail.\n");
> return -EIO;
> }
> --
> 2.9.3
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] fpga zynq: Check the bitstream for validity
From: Jason Gunthorpe @ 2016-10-31 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161029000926.GA30169@live.com>
On Fri, Oct 28, 2016 at 05:09:26PM -0700, Moritz Fischer wrote:
> It's not a single command but rather a sequence of steps we take to
> create an image that works (using write_cfgmem instead of write_binfile)
Ah, and it relies on newer Vivado features too.. Never had a use for
write_cfgmem before, and wouldn't have thought it did this.
I always do these transform externally and we tack our own header onto
the bitfile as well..
> > So, the question still remains, should the driver require the header
> > be stripped (eg the sync word is the first 4 bytes), or should it
> > search the first bit for an aligned sync word?
>
> So currently we don't require it to be stripped, changing it so it does
> require stripping would break people's setups that already use the
> current implementation.
Considering there is a way to produce an acceptable bitfile via
write_cfgmem I think we should stick with that and allow the header to
be present, otherwise all users need yet another tool.
I'll send another patch when I get back from the plumbers conference.
> > Either requirement is acceptable to the hardware. My patch does the
> > former, I suspect you need the later?
>
> For my usecases I could deal with either way, looking at backwards
> compat the latter one would be preferential I supose ...
Well, there are no in-kernel users, and no uapi, so it isn't such a
big deal. I'm actually surprised this got merged without users ..
Jason
^ permalink raw reply
* [PATCH] ARM: zynq: Reserve correct amount of non-DMA RAM
From: Kyle Roeschley @ 2016-10-31 16:26 UTC (permalink / raw)
To: linux-arm-kernel
On Zynq, we haven't been reserving the correct amount of DMA-incapable
RAM to keep DMA away from it (per the Zynq TRM Section 4.1, it should be
the first 512k). In older kernels, this was masked by the
memblock_reserve call in arm_memblock_init(). Now, reserve the correct
amount excplicitly rather than relying on swapper_pg_dir, which is an
address and not a size anyway.
Fixes: 46f5b96 ("ARM: zynq: Reserve not DMAable space in front of the
kernel")
Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com>
---
Found when migrating from 4.1 to 4.6.
arch/arm/mach-zynq/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
index 6cefdb8..75885bc 100644
--- a/arch/arm/mach-zynq/common.c
+++ b/arch/arm/mach-zynq/common.c
@@ -59,7 +59,7 @@ void __iomem *zynq_scu_base;
static void __init zynq_memory_init(void)
{
if (!__pa(PAGE_OFFSET))
- memblock_reserve(__pa(PAGE_OFFSET), __pa(swapper_pg_dir));
+ memblock_reserve(__pa(PAGE_OFFSET), 0x80000);
}
static struct platform_device zynq_cpuidle_device = {
--
2.9.3
^ permalink raw reply related
* [PATCH] [ARM] Fix stack alignment when processing backtraces
From: Jason Gunthorpe @ 2016-10-31 16:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161031085126.GT1041@n2100.armlinux.org.uk>
On Mon, Oct 31, 2016 at 08:51:26AM +0000, Russell King - ARM Linux wrote:
> > -.Ldumpstm: stmfd sp!, {instr, reg, stack, r7, lr}
> > + /* Must maintain 8 byte stack alignment */
> > +.Ldumpstm: stmfd sp!, {r3, instr, reg, stack, r7, lr}
> > mov stack, r0
> > mov instr, r1
> > mov reg, #10
> > @@ -140,7 +141,7 @@ ENDPROC(c_backtrace)
> > teq r7, #0
> > adrne r0, .Lcr
> > blne printk
> > - ldmfd sp!, {instr, reg, stack, r7, pc}
> > + ldmfd sp!, {r3, instr, reg, stack, r7, pc}
>
> I'd prefer r8 to get used rather than r3, as it makes it look like
> r3 is somehow required to be preserved when that's not the case.
> Makes the code slightly more difficult to understand.
Sure, I will change that and send it to your tracker.
Thanks,
Jason
^ permalink raw reply
* [PATCH] pinctrl: meson: Add GXL pinctrl definitions
From: Neil Armstrong @ 2016-10-31 16:32 UTC (permalink / raw)
To: linux-arm-kernel
Add support for the Amlogic Meson GXL SoC, this is a partially complete
definition only based on the Amlogic Vendor tree.
This definition differs a lot from the GXBB and needs a separate entry.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
.../devicetree/bindings/pinctrl/meson,pinctrl.txt | 2 +
drivers/pinctrl/meson/Makefile | 3 +-
drivers/pinctrl/meson/pinctrl-meson-gxl.c | 589 +++++++++++++++++++++
drivers/pinctrl/meson/pinctrl-meson.c | 8 +
drivers/pinctrl/meson/pinctrl-meson.h | 2 +
include/dt-bindings/gpio/meson-gxl-gpio.h | 131 +++++
6 files changed, 734 insertions(+), 1 deletion(-)
create mode 100644 drivers/pinctrl/meson/pinctrl-meson-gxl.c
create mode 100644 include/dt-bindings/gpio/meson-gxl-gpio.h
Original RFC patchset at : [1]
[1] http://lkml.kernel.org/r/1477060838-14164-1-git-send-email-narmstrong at baylibre.com
diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
index fe7fe0b..2392557 100644
--- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt
@@ -7,6 +7,8 @@ Required properties for the root node:
"amlogic,meson8b-aobus-pinctrl"
"amlogic,meson-gxbb-periphs-pinctrl"
"amlogic,meson-gxbb-aobus-pinctrl"
+ "amlogic,meson-gxl-periphs-pinctrl"
+ "amlogic,meson-gxl-aobus-pinctrl"
- reg: address and size of registers controlling irq functionality
=== GPIO sub-nodes ===
diff --git a/drivers/pinctrl/meson/Makefile b/drivers/pinctrl/meson/Makefile
index 24434f1..27c5b51 100644
--- a/drivers/pinctrl/meson/Makefile
+++ b/drivers/pinctrl/meson/Makefile
@@ -1,2 +1,3 @@
-obj-y += pinctrl-meson8.o pinctrl-meson8b.o pinctrl-meson-gxbb.o
+obj-y += pinctrl-meson8.o pinctrl-meson8b.o
+obj-y += pinctrl-meson-gxbb.o pinctrl-meson-gxl.o
obj-y += pinctrl-meson.o
diff --git a/drivers/pinctrl/meson/pinctrl-meson-gxl.c b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
new file mode 100644
index 0000000..25694f7
--- /dev/null
+++ b/drivers/pinctrl/meson/pinctrl-meson-gxl.c
@@ -0,0 +1,589 @@
+/*
+ * Pin controller and GPIO driver for Amlogic Meson GXL.
+ *
+ * Copyright (C) 2016 Endless Mobile, Inc.
+ * Author: Carlo Caione <carlo@endlessm.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <dt-bindings/gpio/meson-gxl-gpio.h>
+#include "pinctrl-meson.h"
+
+#define EE_OFF 10
+
+static const struct pinctrl_pin_desc meson_gxl_periphs_pins[] = {
+ MESON_PIN(GPIOZ_0, EE_OFF),
+ MESON_PIN(GPIOZ_1, EE_OFF),
+ MESON_PIN(GPIOZ_2, EE_OFF),
+ MESON_PIN(GPIOZ_3, EE_OFF),
+ MESON_PIN(GPIOZ_4, EE_OFF),
+ MESON_PIN(GPIOZ_5, EE_OFF),
+ MESON_PIN(GPIOZ_6, EE_OFF),
+ MESON_PIN(GPIOZ_7, EE_OFF),
+ MESON_PIN(GPIOZ_8, EE_OFF),
+ MESON_PIN(GPIOZ_9, EE_OFF),
+ MESON_PIN(GPIOZ_10, EE_OFF),
+ MESON_PIN(GPIOZ_11, EE_OFF),
+ MESON_PIN(GPIOZ_12, EE_OFF),
+ MESON_PIN(GPIOZ_13, EE_OFF),
+ MESON_PIN(GPIOZ_14, EE_OFF),
+ MESON_PIN(GPIOZ_15, EE_OFF),
+
+ MESON_PIN(GPIOH_0, EE_OFF),
+ MESON_PIN(GPIOH_1, EE_OFF),
+ MESON_PIN(GPIOH_2, EE_OFF),
+ MESON_PIN(GPIOH_3, EE_OFF),
+ MESON_PIN(GPIOH_4, EE_OFF),
+ MESON_PIN(GPIOH_5, EE_OFF),
+ MESON_PIN(GPIOH_6, EE_OFF),
+ MESON_PIN(GPIOH_7, EE_OFF),
+ MESON_PIN(GPIOH_8, EE_OFF),
+ MESON_PIN(GPIOH_9, EE_OFF),
+
+ MESON_PIN(BOOT_0, EE_OFF),
+ MESON_PIN(BOOT_1, EE_OFF),
+ MESON_PIN(BOOT_2, EE_OFF),
+ MESON_PIN(BOOT_3, EE_OFF),
+ MESON_PIN(BOOT_4, EE_OFF),
+ MESON_PIN(BOOT_5, EE_OFF),
+ MESON_PIN(BOOT_6, EE_OFF),
+ MESON_PIN(BOOT_7, EE_OFF),
+ MESON_PIN(BOOT_8, EE_OFF),
+ MESON_PIN(BOOT_9, EE_OFF),
+ MESON_PIN(BOOT_10, EE_OFF),
+ MESON_PIN(BOOT_11, EE_OFF),
+ MESON_PIN(BOOT_12, EE_OFF),
+ MESON_PIN(BOOT_13, EE_OFF),
+ MESON_PIN(BOOT_14, EE_OFF),
+ MESON_PIN(BOOT_15, EE_OFF),
+
+ MESON_PIN(CARD_0, EE_OFF),
+ MESON_PIN(CARD_1, EE_OFF),
+ MESON_PIN(CARD_2, EE_OFF),
+ MESON_PIN(CARD_3, EE_OFF),
+ MESON_PIN(CARD_4, EE_OFF),
+ MESON_PIN(CARD_5, EE_OFF),
+ MESON_PIN(CARD_6, EE_OFF),
+
+ MESON_PIN(GPIODV_0, EE_OFF),
+ MESON_PIN(GPIODV_1, EE_OFF),
+ MESON_PIN(GPIODV_2, EE_OFF),
+ MESON_PIN(GPIODV_3, EE_OFF),
+ MESON_PIN(GPIODV_4, EE_OFF),
+ MESON_PIN(GPIODV_5, EE_OFF),
+ MESON_PIN(GPIODV_6, EE_OFF),
+ MESON_PIN(GPIODV_7, EE_OFF),
+ MESON_PIN(GPIODV_8, EE_OFF),
+ MESON_PIN(GPIODV_9, EE_OFF),
+ MESON_PIN(GPIODV_10, EE_OFF),
+ MESON_PIN(GPIODV_11, EE_OFF),
+ MESON_PIN(GPIODV_12, EE_OFF),
+ MESON_PIN(GPIODV_13, EE_OFF),
+ MESON_PIN(GPIODV_14, EE_OFF),
+ MESON_PIN(GPIODV_15, EE_OFF),
+ MESON_PIN(GPIODV_16, EE_OFF),
+ MESON_PIN(GPIODV_17, EE_OFF),
+ MESON_PIN(GPIODV_19, EE_OFF),
+ MESON_PIN(GPIODV_20, EE_OFF),
+ MESON_PIN(GPIODV_21, EE_OFF),
+ MESON_PIN(GPIODV_22, EE_OFF),
+ MESON_PIN(GPIODV_23, EE_OFF),
+ MESON_PIN(GPIODV_24, EE_OFF),
+ MESON_PIN(GPIODV_25, EE_OFF),
+ MESON_PIN(GPIODV_26, EE_OFF),
+ MESON_PIN(GPIODV_27, EE_OFF),
+ MESON_PIN(GPIODV_28, EE_OFF),
+ MESON_PIN(GPIODV_29, EE_OFF),
+
+ MESON_PIN(GPIOX_0, EE_OFF),
+ MESON_PIN(GPIOX_1, EE_OFF),
+ MESON_PIN(GPIOX_2, EE_OFF),
+ MESON_PIN(GPIOX_3, EE_OFF),
+ MESON_PIN(GPIOX_4, EE_OFF),
+ MESON_PIN(GPIOX_5, EE_OFF),
+ MESON_PIN(GPIOX_6, EE_OFF),
+ MESON_PIN(GPIOX_7, EE_OFF),
+ MESON_PIN(GPIOX_8, EE_OFF),
+ MESON_PIN(GPIOX_9, EE_OFF),
+ MESON_PIN(GPIOX_10, EE_OFF),
+ MESON_PIN(GPIOX_11, EE_OFF),
+ MESON_PIN(GPIOX_12, EE_OFF),
+ MESON_PIN(GPIOX_13, EE_OFF),
+ MESON_PIN(GPIOX_14, EE_OFF),
+ MESON_PIN(GPIOX_15, EE_OFF),
+ MESON_PIN(GPIOX_16, EE_OFF),
+ MESON_PIN(GPIOX_17, EE_OFF),
+ MESON_PIN(GPIOX_18, EE_OFF),
+
+ MESON_PIN(GPIOCLK_0, EE_OFF),
+ MESON_PIN(GPIOCLK_1, EE_OFF),
+
+ MESON_PIN(GPIO_TEST_N, EE_OFF),
+};
+
+static const unsigned int emmc_nand_d07_pins[] = {
+ PIN(BOOT_0, EE_OFF), PIN(BOOT_1, EE_OFF), PIN(BOOT_2, EE_OFF),
+ PIN(BOOT_3, EE_OFF), PIN(BOOT_4, EE_OFF), PIN(BOOT_5, EE_OFF),
+ PIN(BOOT_6, EE_OFF), PIN(BOOT_7, EE_OFF),
+};
+static const unsigned int emmc_clk_pins[] = { PIN(BOOT_8, EE_OFF) };
+static const unsigned int emmc_cmd_pins[] = { PIN(BOOT_10, EE_OFF) };
+static const unsigned int emmc_ds_pins[] = { PIN(BOOT_15, EE_OFF) };
+
+static const unsigned int sdcard_d0_pins[] = { PIN(CARD_1, EE_OFF) };
+static const unsigned int sdcard_d1_pins[] = { PIN(CARD_0, EE_OFF) };
+static const unsigned int sdcard_d2_pins[] = { PIN(CARD_5, EE_OFF) };
+static const unsigned int sdcard_d3_pins[] = { PIN(CARD_4, EE_OFF) };
+static const unsigned int sdcard_cmd_pins[] = { PIN(CARD_3, EE_OFF) };
+static const unsigned int sdcard_clk_pins[] = { PIN(CARD_2, EE_OFF) };
+
+static const unsigned int sdio_d0_pins[] = { PIN(GPIOX_0, EE_OFF) };
+static const unsigned int sdio_d1_pins[] = { PIN(GPIOX_1, EE_OFF) };
+static const unsigned int sdio_d2_pins[] = { PIN(GPIOX_2, EE_OFF) };
+static const unsigned int sdio_d3_pins[] = { PIN(GPIOX_3, EE_OFF) };
+static const unsigned int sdio_cmd_pins[] = { PIN(GPIOX_4, EE_OFF) };
+static const unsigned int sdio_clk_pins[] = { PIN(GPIOX_5, EE_OFF) };
+static const unsigned int sdio_irq_pins[] = { PIN(GPIOX_7, EE_OFF) };
+
+static const unsigned int nand_ce0_pins[] = { PIN(BOOT_8, EE_OFF) };
+static const unsigned int nand_ce1_pins[] = { PIN(BOOT_9, EE_OFF) };
+static const unsigned int nand_rb0_pins[] = { PIN(BOOT_10, EE_OFF) };
+static const unsigned int nand_ale_pins[] = { PIN(BOOT_11, EE_OFF) };
+static const unsigned int nand_cle_pins[] = { PIN(BOOT_12, EE_OFF) };
+static const unsigned int nand_wen_clk_pins[] = { PIN(BOOT_13, EE_OFF) };
+static const unsigned int nand_ren_wr_pins[] = { PIN(BOOT_14, EE_OFF) };
+static const unsigned int nand_dqs_pins[] = { PIN(BOOT_15, EE_OFF) };
+
+static const unsigned int uart_tx_a_pins[] = { PIN(GPIOX_12, EE_OFF) };
+static const unsigned int uart_rx_a_pins[] = { PIN(GPIOX_13, EE_OFF) };
+static const unsigned int uart_cts_a_pins[] = { PIN(GPIOX_14, EE_OFF) };
+static const unsigned int uart_rts_a_pins[] = { PIN(GPIOX_15, EE_OFF) };
+
+static const unsigned int uart_tx_b_pins[] = { PIN(GPIODV_24, EE_OFF) };
+static const unsigned int uart_rx_b_pins[] = { PIN(GPIODV_25, EE_OFF) };
+
+static const unsigned int uart_tx_c_pins[] = { PIN(GPIOX_8, EE_OFF) };
+static const unsigned int uart_rx_c_pins[] = { PIN(GPIOX_9, EE_OFF) };
+
+static const unsigned int i2c_sck_a_pins[] = { PIN(GPIODV_25, EE_OFF) };
+static const unsigned int i2c_sda_a_pins[] = { PIN(GPIODV_24, EE_OFF) };
+
+static const unsigned int i2c_sck_b_pins[] = { PIN(GPIODV_27, EE_OFF) };
+static const unsigned int i2c_sda_b_pins[] = { PIN(GPIODV_26, EE_OFF) };
+
+static const unsigned int i2c_sck_c_pins[] = { PIN(GPIODV_29, EE_OFF) };
+static const unsigned int i2c_sda_c_pins[] = { PIN(GPIODV_28, EE_OFF) };
+
+static const unsigned int eth_mdio_pins[] = { PIN(GPIOZ_0, EE_OFF) };
+static const unsigned int eth_mdc_pins[] = { PIN(GPIOZ_1, EE_OFF) };
+static const unsigned int eth_clk_rx_clk_pins[] = { PIN(GPIOZ_2, EE_OFF) };
+static const unsigned int eth_rx_dv_pins[] = { PIN(GPIOZ_3, EE_OFF) };
+static const unsigned int eth_rxd0_pins[] = { PIN(GPIOZ_4, EE_OFF) };
+static const unsigned int eth_rxd1_pins[] = { PIN(GPIOZ_5, EE_OFF) };
+static const unsigned int eth_rxd2_pins[] = { PIN(GPIOZ_6, EE_OFF) };
+static const unsigned int eth_rxd3_pins[] = { PIN(GPIOZ_7, EE_OFF) };
+static const unsigned int eth_rgmii_tx_clk_pins[] = { PIN(GPIOZ_8, EE_OFF) };
+static const unsigned int eth_tx_en_pins[] = { PIN(GPIOZ_9, EE_OFF) };
+static const unsigned int eth_txd0_pins[] = { PIN(GPIOZ_10, EE_OFF) };
+static const unsigned int eth_txd1_pins[] = { PIN(GPIOZ_11, EE_OFF) };
+static const unsigned int eth_txd2_pins[] = { PIN(GPIOZ_12, EE_OFF) };
+static const unsigned int eth_txd3_pins[] = { PIN(GPIOZ_13, EE_OFF) };
+
+static const unsigned int pwm_e_pins[] = { PIN(GPIOX_16, EE_OFF) };
+
+static const struct pinctrl_pin_desc meson_gxl_aobus_pins[] = {
+ MESON_PIN(GPIOAO_0, 0),
+ MESON_PIN(GPIOAO_1, 0),
+ MESON_PIN(GPIOAO_2, 0),
+ MESON_PIN(GPIOAO_3, 0),
+ MESON_PIN(GPIOAO_4, 0),
+ MESON_PIN(GPIOAO_5, 0),
+ MESON_PIN(GPIOAO_6, 0),
+ MESON_PIN(GPIOAO_7, 0),
+ MESON_PIN(GPIOAO_8, 0),
+ MESON_PIN(GPIOAO_9, 0),
+};
+
+static const unsigned int uart_tx_ao_a_pins[] = { PIN(GPIOAO_0, 0) };
+static const unsigned int uart_rx_ao_a_pins[] = { PIN(GPIOAO_1, 0) };
+static const unsigned int uart_cts_ao_a_pins[] = { PIN(GPIOAO_2, 0) };
+static const unsigned int uart_rts_ao_a_pins[] = { PIN(GPIOAO_3, 0) };
+static const unsigned int uart_tx_ao_b_pins[] = { PIN(GPIOAO_0, 0) };
+static const unsigned int uart_rx_ao_b_pins[] = { PIN(GPIOAO_1, 0),
+ PIN(GPIOAO_5, 0) };
+static const unsigned int uart_cts_ao_b_pins[] = { PIN(GPIOAO_2, 0) };
+static const unsigned int uart_rts_ao_b_pins[] = { PIN(GPIOAO_3, 0) };
+
+static const unsigned int remote_input_ao_pins[] = {PIN(GPIOAO_7, 0) };
+
+static struct meson_pmx_group meson_gxl_periphs_groups[] = {
+ GPIO_GROUP(GPIOZ_0, EE_OFF),
+ GPIO_GROUP(GPIOZ_1, EE_OFF),
+ GPIO_GROUP(GPIOZ_2, EE_OFF),
+ GPIO_GROUP(GPIOZ_3, EE_OFF),
+ GPIO_GROUP(GPIOZ_4, EE_OFF),
+ GPIO_GROUP(GPIOZ_5, EE_OFF),
+ GPIO_GROUP(GPIOZ_6, EE_OFF),
+ GPIO_GROUP(GPIOZ_7, EE_OFF),
+ GPIO_GROUP(GPIOZ_8, EE_OFF),
+ GPIO_GROUP(GPIOZ_9, EE_OFF),
+ GPIO_GROUP(GPIOZ_10, EE_OFF),
+ GPIO_GROUP(GPIOZ_11, EE_OFF),
+ GPIO_GROUP(GPIOZ_12, EE_OFF),
+ GPIO_GROUP(GPIOZ_13, EE_OFF),
+ GPIO_GROUP(GPIOZ_14, EE_OFF),
+ GPIO_GROUP(GPIOZ_15, EE_OFF),
+
+ GPIO_GROUP(GPIOH_0, EE_OFF),
+ GPIO_GROUP(GPIOH_1, EE_OFF),
+ GPIO_GROUP(GPIOH_2, EE_OFF),
+ GPIO_GROUP(GPIOH_3, EE_OFF),
+ GPIO_GROUP(GPIOH_4, EE_OFF),
+ GPIO_GROUP(GPIOH_5, EE_OFF),
+ GPIO_GROUP(GPIOH_6, EE_OFF),
+ GPIO_GROUP(GPIOH_7, EE_OFF),
+ GPIO_GROUP(GPIOH_8, EE_OFF),
+ GPIO_GROUP(GPIOH_9, EE_OFF),
+
+ GPIO_GROUP(BOOT_0, EE_OFF),
+ GPIO_GROUP(BOOT_1, EE_OFF),
+ GPIO_GROUP(BOOT_2, EE_OFF),
+ GPIO_GROUP(BOOT_3, EE_OFF),
+ GPIO_GROUP(BOOT_4, EE_OFF),
+ GPIO_GROUP(BOOT_5, EE_OFF),
+ GPIO_GROUP(BOOT_6, EE_OFF),
+ GPIO_GROUP(BOOT_7, EE_OFF),
+ GPIO_GROUP(BOOT_8, EE_OFF),
+ GPIO_GROUP(BOOT_9, EE_OFF),
+ GPIO_GROUP(BOOT_10, EE_OFF),
+ GPIO_GROUP(BOOT_11, EE_OFF),
+ GPIO_GROUP(BOOT_12, EE_OFF),
+ GPIO_GROUP(BOOT_13, EE_OFF),
+ GPIO_GROUP(BOOT_14, EE_OFF),
+ GPIO_GROUP(BOOT_15, EE_OFF),
+
+ GPIO_GROUP(CARD_0, EE_OFF),
+ GPIO_GROUP(CARD_1, EE_OFF),
+ GPIO_GROUP(CARD_2, EE_OFF),
+ GPIO_GROUP(CARD_3, EE_OFF),
+ GPIO_GROUP(CARD_4, EE_OFF),
+ GPIO_GROUP(CARD_5, EE_OFF),
+ GPIO_GROUP(CARD_6, EE_OFF),
+
+ GPIO_GROUP(GPIODV_0, EE_OFF),
+ GPIO_GROUP(GPIODV_1, EE_OFF),
+ GPIO_GROUP(GPIODV_2, EE_OFF),
+ GPIO_GROUP(GPIODV_3, EE_OFF),
+ GPIO_GROUP(GPIODV_4, EE_OFF),
+ GPIO_GROUP(GPIODV_5, EE_OFF),
+ GPIO_GROUP(GPIODV_6, EE_OFF),
+ GPIO_GROUP(GPIODV_7, EE_OFF),
+ GPIO_GROUP(GPIODV_8, EE_OFF),
+ GPIO_GROUP(GPIODV_9, EE_OFF),
+ GPIO_GROUP(GPIODV_10, EE_OFF),
+ GPIO_GROUP(GPIODV_11, EE_OFF),
+ GPIO_GROUP(GPIODV_12, EE_OFF),
+ GPIO_GROUP(GPIODV_13, EE_OFF),
+ GPIO_GROUP(GPIODV_14, EE_OFF),
+ GPIO_GROUP(GPIODV_15, EE_OFF),
+ GPIO_GROUP(GPIODV_16, EE_OFF),
+ GPIO_GROUP(GPIODV_17, EE_OFF),
+ GPIO_GROUP(GPIODV_19, EE_OFF),
+ GPIO_GROUP(GPIODV_20, EE_OFF),
+ GPIO_GROUP(GPIODV_21, EE_OFF),
+ GPIO_GROUP(GPIODV_22, EE_OFF),
+ GPIO_GROUP(GPIODV_23, EE_OFF),
+ GPIO_GROUP(GPIODV_24, EE_OFF),
+ GPIO_GROUP(GPIODV_25, EE_OFF),
+ GPIO_GROUP(GPIODV_26, EE_OFF),
+ GPIO_GROUP(GPIODV_27, EE_OFF),
+ GPIO_GROUP(GPIODV_28, EE_OFF),
+ GPIO_GROUP(GPIODV_29, EE_OFF),
+
+ GPIO_GROUP(GPIOX_0, EE_OFF),
+ GPIO_GROUP(GPIOX_1, EE_OFF),
+ GPIO_GROUP(GPIOX_2, EE_OFF),
+ GPIO_GROUP(GPIOX_3, EE_OFF),
+ GPIO_GROUP(GPIOX_4, EE_OFF),
+ GPIO_GROUP(GPIOX_5, EE_OFF),
+ GPIO_GROUP(GPIOX_6, EE_OFF),
+ GPIO_GROUP(GPIOX_7, EE_OFF),
+ GPIO_GROUP(GPIOX_8, EE_OFF),
+ GPIO_GROUP(GPIOX_9, EE_OFF),
+ GPIO_GROUP(GPIOX_10, EE_OFF),
+ GPIO_GROUP(GPIOX_11, EE_OFF),
+ GPIO_GROUP(GPIOX_12, EE_OFF),
+ GPIO_GROUP(GPIOX_13, EE_OFF),
+ GPIO_GROUP(GPIOX_14, EE_OFF),
+ GPIO_GROUP(GPIOX_15, EE_OFF),
+ GPIO_GROUP(GPIOX_16, EE_OFF),
+ GPIO_GROUP(GPIOX_17, EE_OFF),
+ GPIO_GROUP(GPIOX_18, EE_OFF),
+
+ GPIO_GROUP(GPIOCLK_0, EE_OFF),
+ GPIO_GROUP(GPIOCLK_1, EE_OFF),
+
+ GPIO_GROUP(GPIO_TEST_N, EE_OFF),
+
+ /* Bank X */
+ GROUP(sdio_d0, 5, 31),
+ GROUP(sdio_d1, 5, 30),
+ GROUP(sdio_d2, 5, 29),
+ GROUP(sdio_d3, 5, 28),
+ GROUP(sdio_cmd, 5, 27),
+ GROUP(sdio_clk, 5, 26),
+ GROUP(sdio_irq, 5, 24),
+ GROUP(uart_tx_a, 5, 19),
+ GROUP(uart_rx_a, 5, 18),
+ GROUP(uart_cts_a, 5, 17),
+ GROUP(uart_rts_a, 5, 16),
+ GROUP(uart_tx_c, 5, 13),
+ GROUP(uart_rx_c, 5, 12),
+ GROUP(pwm_e, 5, 15),
+
+ /* Bank Z */
+ GROUP(eth_mdio, 4, 22),
+ GROUP(eth_mdc, 4, 23),
+ GROUP(eth_clk_rx_clk, 4, 21),
+ GROUP(eth_rx_dv, 4, 20),
+ GROUP(eth_rxd0, 4, 19),
+ GROUP(eth_rxd1, 4, 18),
+ GROUP(eth_rxd2, 4, 17),
+ GROUP(eth_rxd3, 4, 16),
+ GROUP(eth_rgmii_tx_clk, 4, 15),
+ GROUP(eth_tx_en, 4, 14),
+ GROUP(eth_txd0, 4, 13),
+ GROUP(eth_txd1, 4, 12),
+ GROUP(eth_txd2, 4, 11),
+ GROUP(eth_txd3, 4, 10),
+
+ /* Bank DV */
+ GROUP(uart_tx_b, 2, 16),
+ GROUP(uart_rx_b, 2, 15),
+ GROUP(i2c_sck_a, 1, 15),
+ GROUP(i2c_sda_a, 1, 14),
+ GROUP(i2c_sck_b, 1, 13),
+ GROUP(i2c_sda_b, 1, 12),
+ GROUP(i2c_sck_c, 1, 11),
+ GROUP(i2c_sda_c, 1, 10),
+
+ /* Bank BOOT */
+ GROUP(emmc_nand_d07, 7, 31),
+ GROUP(emmc_clk, 7, 30),
+ GROUP(emmc_cmd, 7, 29),
+ GROUP(emmc_ds, 7, 28),
+ GROUP(nand_ce0, 7, 7),
+ GROUP(nand_ce1, 7, 6),
+ GROUP(nand_rb0, 7, 5),
+ GROUP(nand_ale, 7, 4),
+ GROUP(nand_cle, 7, 3),
+ GROUP(nand_wen_clk, 7, 2),
+ GROUP(nand_ren_wr, 7, 1),
+ GROUP(nand_dqs, 7, 0),
+
+ /* Bank CARD */
+ GROUP(sdcard_d1, 6, 5),
+ GROUP(sdcard_d0, 6, 4),
+ GROUP(sdcard_d3, 6, 1),
+ GROUP(sdcard_d2, 6, 0),
+ GROUP(sdcard_cmd, 6, 2),
+ GROUP(sdcard_clk, 6, 3),
+};
+
+static struct meson_pmx_group meson_gxl_aobus_groups[] = {
+ GPIO_GROUP(GPIOAO_0, 0),
+ GPIO_GROUP(GPIOAO_1, 0),
+ GPIO_GROUP(GPIOAO_2, 0),
+ GPIO_GROUP(GPIOAO_3, 0),
+ GPIO_GROUP(GPIOAO_4, 0),
+ GPIO_GROUP(GPIOAO_5, 0),
+ GPIO_GROUP(GPIOAO_6, 0),
+ GPIO_GROUP(GPIOAO_7, 0),
+ GPIO_GROUP(GPIOAO_8, 0),
+ GPIO_GROUP(GPIOAO_9, 0),
+
+ /* bank AO */
+ GROUP(uart_tx_ao_b, 0, 26),
+ GROUP(uart_rx_ao_b, 0, 25),
+ GROUP(uart_tx_ao_a, 0, 12),
+ GROUP(uart_rx_ao_a, 0, 11),
+ GROUP(uart_cts_ao_a, 0, 10),
+ GROUP(uart_rts_ao_a, 0, 9),
+ GROUP(uart_cts_ao_b, 0, 8),
+ GROUP(uart_rts_ao_b, 0, 7),
+ GROUP(remote_input_ao, 0, 0),
+};
+
+static const char * const gpio_periphs_groups[] = {
+ "GPIOZ_0", "GPIOZ_1", "GPIOZ_2", "GPIOZ_3", "GPIOZ_4",
+ "GPIOZ_5", "GPIOZ_6", "GPIOZ_7", "GPIOZ_8", "GPIOZ_9",
+ "GPIOZ_10", "GPIOZ_11", "GPIOZ_12", "GPIOZ_13", "GPIOZ_14",
+ "GPIOZ_15",
+
+ "GPIOH_0", "GPIOH_1", "GPIOH_2", "GPIOH_3", "GPIOH_4",
+ "GPIOH_5", "GPIOH_6", "GPIOH_7", "GPIOH_8", "GPIOH_9",
+
+ "BOOT_0", "BOOT_1", "BOOT_2", "BOOT_3", "BOOT_4",
+ "BOOT_5", "BOOT_6", "BOOT_7", "BOOT_8", "BOOT_9",
+ "BOOT_10", "BOOT_11", "BOOT_12", "BOOT_13", "BOOT_14",
+ "BOOT_15",
+
+ "CARD_0", "CARD_1", "CARD_2", "CARD_3", "CARD_4",
+ "CARD_5", "CARD_6",
+
+ "GPIODV_0", "GPIODV_1", "GPIODV_2", "GPIODV_3", "GPIODV_4",
+ "GPIODV_5", "GPIODV_6", "GPIODV_7", "GPIODV_8", "GPIODV_9",
+ "GPIODV_10", "GPIODV_11", "GPIODV_12", "GPIODV_13", "GPIODV_14",
+ "GPIODV_15", "GPIODV_16", "GPIODV_17", "GPIODV_18", "GPIODV_19",
+ "GPIODV_20", "GPIODV_21", "GPIODV_22", "GPIODV_23", "GPIODV_24",
+ "GPIODV_25", "GPIODV_26", "GPIODV_27", "GPIODV_28", "GPIODV_29",
+
+ "GPIOX_0", "GPIOX_1", "GPIOX_2", "GPIOX_3", "GPIOX_4",
+ "GPIOX_5", "GPIOX_6", "GPIOX_7", "GPIOX_8", "GPIOX_9",
+ "GPIOX_10", "GPIOX_11", "GPIOX_12", "GPIOX_13", "GPIOX_14",
+ "GPIOX_15", "GPIOX_16", "GPIOX_17", "GPIOX_18",
+
+ "GPIO_TEST_N",
+};
+
+static const char * const emmc_groups[] = {
+ "emmc_nand_d07", "emmc_clk", "emmc_cmd", "emmc_ds",
+};
+
+static const char * const sdcard_groups[] = {
+ "sdcard_d0", "sdcard_d1", "sdcard_d2", "sdcard_d3",
+ "sdcard_cmd", "sdcard_clk",
+};
+
+static const char * const sdio_groups[] = {
+ "sdio_d0", "sdio_d1", "sdio_d2", "sdio_d3",
+ "sdio_cmd", "sdio_clk", "sdio_irq",
+};
+
+static const char * const nand_groups[] = {
+ "nand_ce0", "nand_ce1", "nand_rb0", "nand_ale", "nand_cle",
+ "nand_wen_clk", "nand_ren_wr", "nand_dqs",
+};
+
+static const char * const uart_a_groups[] = {
+ "uart_tx_a", "uart_rx_a", "uart_cts_a", "uart_rts_a",
+};
+
+static const char * const uart_b_groups[] = {
+ "uart_tx_b", "uart_rx_b",
+};
+
+static const char * const uart_c_groups[] = {
+ "uart_tx_c", "uart_rx_c",
+};
+
+static const char * const i2c_a_groups[] = {
+ "i2c_sck_a", "i2c_sda_a",
+};
+
+static const char * const i2c_b_groups[] = {
+ "i2c_sck_b", "i2c_sda_b",
+};
+
+static const char * const i2c_c_groups[] = {
+ "i2c_sck_c", "i2c_sda_c",
+};
+
+static const char * const eth_groups[] = {
+ "eth_mdio", "eth_mdc", "eth_clk_rx_clk", "eth_rx_dv",
+ "eth_rxd0", "eth_rxd1", "eth_rxd2", "eth_rxd3",
+ "eth_rgmii_tx_clk", "eth_tx_en",
+ "eth_txd0", "eth_txd1", "eth_txd2", "eth_txd3",
+};
+
+static const char * const pwm_e_groups[] = {
+ "pwm_e",
+};
+
+static const char * const gpio_aobus_groups[] = {
+ "GPIOAO_0", "GPIOAO_1", "GPIOAO_2", "GPIOAO_3", "GPIOAO_4",
+ "GPIOAO_5", "GPIOAO_6", "GPIOAO_7", "GPIOAO_8", "GPIOAO_9",
+};
+
+static const char * const uart_ao_groups[] = {
+ "uart_tx_ao_a", "uart_rx_ao_a", "uart_cts_ao_a", "uart_rts_ao_a",
+};
+
+static const char * const uart_ao_b_groups[] = {
+ "uart_tx_ao_b", "uart_rx_ao_b", "uart_cts_ao_b", "uart_rts_ao_b",
+};
+
+static const char * const remote_input_ao_groups[] = {
+ "remote_input_ao",
+};
+
+static struct meson_pmx_func meson_gxl_periphs_functions[] = {
+ FUNCTION(gpio_periphs),
+ FUNCTION(emmc),
+ FUNCTION(sdcard),
+ FUNCTION(sdio),
+ FUNCTION(nand),
+ FUNCTION(uart_a),
+ FUNCTION(uart_b),
+ FUNCTION(uart_c),
+ FUNCTION(i2c_a),
+ FUNCTION(i2c_b),
+ FUNCTION(i2c_c),
+ FUNCTION(eth),
+ FUNCTION(pwm_e),
+};
+
+static struct meson_pmx_func meson_gxl_aobus_functions[] = {
+ FUNCTION(gpio_aobus),
+ FUNCTION(uart_ao),
+ FUNCTION(uart_ao_b),
+ FUNCTION(remote_input_ao),
+};
+
+static struct meson_bank meson_gxl_periphs_banks[] = {
+ /* name first last pullen pull dir out in */
+ BANK("X", PIN(GPIOX_0, EE_OFF), PIN(GPIOX_18, EE_OFF), 4, 0, 4, 0, 12, 0, 13, 0, 14, 0),
+ BANK("DV", PIN(GPIODV_0, EE_OFF), PIN(GPIODV_29, EE_OFF), 0, 0, 0, 0, 0, 0, 1, 0, 2, 0),
+ BANK("H", PIN(GPIOH_0, EE_OFF), PIN(GPIOH_9, EE_OFF), 1, 20, 1, 20, 3, 20, 4, 20, 5, 20),
+ BANK("Z", PIN(GPIOZ_0, EE_OFF), PIN(GPIOZ_15, EE_OFF), 3, 0, 3, 0, 9, 0, 10, 0, 11, 0),
+ BANK("CARD", PIN(CARD_0, EE_OFF), PIN(CARD_6, EE_OFF), 2, 20, 2, 20, 6, 20, 7, 20, 8, 20),
+ BANK("BOOT", PIN(BOOT_0, EE_OFF), PIN(BOOT_15, EE_OFF), 2, 0, 2, 0, 6, 0, 7, 0, 8, 0),
+ BANK("CLK", PIN(GPIOCLK_0, EE_OFF), PIN(GPIOCLK_1, EE_OFF), 3, 28, 3, 28, 9, 28, 10, 28, 11, 28),
+};
+
+static struct meson_bank meson_gxl_aobus_banks[] = {
+ /* name first last pullen pull dir out in */
+ BANK("AO", PIN(GPIOAO_0, 0), PIN(GPIOAO_9, 0), 0, 0, 0, 16, 0, 0, 0, 16, 1, 0),
+};
+
+struct meson_pinctrl_data meson_gxl_periphs_pinctrl_data = {
+ .name = "periphs-banks",
+ .pin_base = 10,
+ .pins = meson_gxl_periphs_pins,
+ .groups = meson_gxl_periphs_groups,
+ .funcs = meson_gxl_periphs_functions,
+ .banks = meson_gxl_periphs_banks,
+ .num_pins = ARRAY_SIZE(meson_gxl_periphs_pins),
+ .num_groups = ARRAY_SIZE(meson_gxl_periphs_groups),
+ .num_funcs = ARRAY_SIZE(meson_gxl_periphs_functions),
+ .num_banks = ARRAY_SIZE(meson_gxl_periphs_banks),
+};
+
+struct meson_pinctrl_data meson_gxl_aobus_pinctrl_data = {
+ .name = "aobus-banks",
+ .pin_base = 0,
+ .pins = meson_gxl_aobus_pins,
+ .groups = meson_gxl_aobus_groups,
+ .funcs = meson_gxl_aobus_functions,
+ .banks = meson_gxl_aobus_banks,
+ .num_pins = ARRAY_SIZE(meson_gxl_aobus_pins),
+ .num_groups = ARRAY_SIZE(meson_gxl_aobus_groups),
+ .num_funcs = ARRAY_SIZE(meson_gxl_aobus_functions),
+ .num_banks = ARRAY_SIZE(meson_gxl_aobus_banks),
+};
diff --git a/drivers/pinctrl/meson/pinctrl-meson.c b/drivers/pinctrl/meson/pinctrl-meson.c
index 57122ed..a579126 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.c
+++ b/drivers/pinctrl/meson/pinctrl-meson.c
@@ -524,6 +524,14 @@ static int meson_gpio_get(struct gpio_chip *chip, unsigned gpio)
.compatible = "amlogic,meson-gxbb-aobus-pinctrl",
.data = &meson_gxbb_aobus_pinctrl_data,
},
+ {
+ .compatible = "amlogic,meson-gxl-periphs-pinctrl",
+ .data = &meson_gxl_periphs_pinctrl_data,
+ },
+ {
+ .compatible = "amlogic,meson-gxl-aobus-pinctrl",
+ .data = &meson_gxl_aobus_pinctrl_data,
+ },
{ },
};
diff --git a/drivers/pinctrl/meson/pinctrl-meson.h b/drivers/pinctrl/meson/pinctrl-meson.h
index 98b5080..1aa871d 100644
--- a/drivers/pinctrl/meson/pinctrl-meson.h
+++ b/drivers/pinctrl/meson/pinctrl-meson.h
@@ -169,3 +169,5 @@ struct meson_pinctrl {
extern struct meson_pinctrl_data meson8b_aobus_pinctrl_data;
extern struct meson_pinctrl_data meson_gxbb_periphs_pinctrl_data;
extern struct meson_pinctrl_data meson_gxbb_aobus_pinctrl_data;
+extern struct meson_pinctrl_data meson_gxl_periphs_pinctrl_data;
+extern struct meson_pinctrl_data meson_gxl_aobus_pinctrl_data;
diff --git a/include/dt-bindings/gpio/meson-gxl-gpio.h b/include/dt-bindings/gpio/meson-gxl-gpio.h
new file mode 100644
index 0000000..684d0d7
--- /dev/null
+++ b/include/dt-bindings/gpio/meson-gxl-gpio.h
@@ -0,0 +1,131 @@
+/*
+ * GPIO definitions for Amlogic Meson GXL SoCs
+ *
+ * Copyright (C) 2016 Endless Mobile, Inc.
+ * Author: Carlo Caione <carlo@endlessm.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef _DT_BINDINGS_MESON_GXL_GPIO_H
+#define _DT_BINDINGS_MESON_GXL_GPIO_H
+
+#define GPIOAO_0 0
+#define GPIOAO_1 1
+#define GPIOAO_2 2
+#define GPIOAO_3 3
+#define GPIOAO_4 4
+#define GPIOAO_5 5
+#define GPIOAO_6 6
+#define GPIOAO_7 7
+#define GPIOAO_8 8
+#define GPIOAO_9 9
+
+#define GPIOZ_0 0
+#define GPIOZ_1 1
+#define GPIOZ_2 2
+#define GPIOZ_3 3
+#define GPIOZ_4 4
+#define GPIOZ_5 5
+#define GPIOZ_6 6
+#define GPIOZ_7 7
+#define GPIOZ_8 8
+#define GPIOZ_9 9
+#define GPIOZ_10 10
+#define GPIOZ_11 11
+#define GPIOZ_12 12
+#define GPIOZ_13 13
+#define GPIOZ_14 14
+#define GPIOZ_15 15
+#define GPIOH_0 16
+#define GPIOH_1 17
+#define GPIOH_2 18
+#define GPIOH_3 19
+#define GPIOH_4 20
+#define GPIOH_5 21
+#define GPIOH_6 22
+#define GPIOH_7 23
+#define GPIOH_8 24
+#define GPIOH_9 25
+#define BOOT_0 26
+#define BOOT_1 27
+#define BOOT_2 28
+#define BOOT_3 29
+#define BOOT_4 30
+#define BOOT_5 31
+#define BOOT_6 32
+#define BOOT_7 33
+#define BOOT_8 34
+#define BOOT_9 35
+#define BOOT_10 36
+#define BOOT_11 37
+#define BOOT_12 38
+#define BOOT_13 39
+#define BOOT_14 40
+#define BOOT_15 41
+#define CARD_0 42
+#define CARD_1 43
+#define CARD_2 44
+#define CARD_3 45
+#define CARD_4 46
+#define CARD_5 47
+#define CARD_6 48
+#define GPIODV_0 49
+#define GPIODV_1 50
+#define GPIODV_2 51
+#define GPIODV_3 52
+#define GPIODV_4 53
+#define GPIODV_5 54
+#define GPIODV_6 55
+#define GPIODV_7 56
+#define GPIODV_8 57
+#define GPIODV_9 58
+#define GPIODV_10 59
+#define GPIODV_11 60
+#define GPIODV_12 61
+#define GPIODV_13 62
+#define GPIODV_14 63
+#define GPIODV_15 64
+#define GPIODV_16 65
+#define GPIODV_17 66
+#define GPIODV_18 67
+#define GPIODV_19 68
+#define GPIODV_20 69
+#define GPIODV_21 70
+#define GPIODV_22 71
+#define GPIODV_23 72
+#define GPIODV_24 73
+#define GPIODV_25 74
+#define GPIODV_26 75
+#define GPIODV_27 76
+#define GPIODV_28 77
+#define GPIODV_29 78
+#define GPIOX_0 79
+#define GPIOX_1 80
+#define GPIOX_2 81
+#define GPIOX_3 82
+#define GPIOX_4 83
+#define GPIOX_5 84
+#define GPIOX_6 85
+#define GPIOX_7 86
+#define GPIOX_8 87
+#define GPIOX_9 88
+#define GPIOX_10 89
+#define GPIOX_11 90
+#define GPIOX_12 91
+#define GPIOX_13 92
+#define GPIOX_14 93
+#define GPIOX_15 94
+#define GPIOX_16 95
+#define GPIOX_17 96
+#define GPIOX_18 97
+#define GPIOCLK_0 98
+#define GPIOCLK_1 99
+#define GPIO_TEST_N 100
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v5 2/2] drm: tilcdc: clear the sync lost bit in crtc isr
From: Karl Beldan @ 2016-10-31 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477923567-1610-3-git-send-email-bgolaszewski@baylibre.com>
Hi,
On Mon, Oct 31, 2016 at 2:19 PM, Bartosz Golaszewski
<bgolaszewski@baylibre.com> wrote:
> The frame synchronization error happens when the DMA engine attempts
> to read what it believes to be the first word of the video buffer but
> it cannot be recognized as such or when the LCDC is starved of data
> due to insufficient bandwidth of the system interconnect.
>
This also happens when the framebuffer boundaries are "incorrect", eg
when flipping while the crtc is enabled. The driver doesn't handle it yet,
so working around it is made via toggling LCDC_RASTER_ENABLE as
you put in this change, it is worth noting because that's how modetest
for example can "seem" to work with v1 when handling SYNC_LOST
and is partly why the "vsynced page flipping" of modetest won't work
either with v1 ATM. I haven't looked at the different trees since early
september but my guess would be that nobody has reworked this yet.
> On some SoCs (notably: da850) the memory settings do not meet the
> LCDC throughput requirements even after increasing the memory
> controller command re-ordering and the LDCD master peripheral
> priority, sometimes causing the sync lost error (typically when
> changing the resolution).
>
> When the sync lost error occurs, simply reset the input FIFO in the
> DMA controller unless a sync lost flood is detected in which case
> disable the interrupt.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> ---
> drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 50 ++++++++++++++++++++++++++----------
> drivers/gpu/drm/tilcdc/tilcdc_regs.h | 1 +
> 2 files changed, 37 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 937697d..c4c6323 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -163,7 +163,7 @@ static void tilcdc_crtc_enable_irqs(struct drm_device *dev)
>
> if (priv->rev == 1) {
> tilcdc_set(dev, LCDC_RASTER_CTRL_REG,
> - LCDC_V1_UNDERFLOW_INT_ENA);
> + LCDC_V1_UNDERFLOW_INT_ENA | LCDC_V1_SYNC_LOST_ENA);
> tilcdc_set(dev, LCDC_DMA_CTRL_REG,
> LCDC_V1_END_OF_FRAME_INT_ENA);
> } else {
> @@ -181,7 +181,9 @@ static void tilcdc_crtc_disable_irqs(struct drm_device *dev)
> /* disable irqs that we might have enabled: */
> if (priv->rev == 1) {
> tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
> - LCDC_V1_UNDERFLOW_INT_ENA | LCDC_V1_PL_INT_ENA);
> + LCDC_V1_UNDERFLOW_INT_ENA |
> + LCDC_V1_PL_INT_ENA |
> + LCDC_V1_SYNC_LOST_ENA);
> tilcdc_clear(dev, LCDC_DMA_CTRL_REG,
> LCDC_V1_END_OF_FRAME_INT_ENA);
> } else {
> @@ -885,24 +887,44 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
> wake_up(&tilcdc_crtc->frame_done_wq);
> }
>
> - if (stat & LCDC_SYNC_LOST) {
> - dev_err_ratelimited(dev->dev, "%s(0x%08x): Sync lost",
> - __func__, stat);
> - tilcdc_crtc->frame_intact = false;
> - if (tilcdc_crtc->sync_lost_count++ >
> - SYNC_LOST_COUNT_LIMIT) {
> - dev_err(dev->dev, "%s(0x%08x): Sync lost flood detected, disabling the interrupt", __func__, stat);
> - tilcdc_write(dev, LCDC_INT_ENABLE_CLR_REG,
> - LCDC_SYNC_LOST);
> - }
> - }
> -
> /* Indicate to LCDC that the interrupt service routine has
> * completed, see 13.3.6.1.6 in AM335x TRM.
> */
> tilcdc_write(dev, LCDC_END_OF_INT_IND_REG, 0);
> }
>
> + if (stat & LCDC_SYNC_LOST) {
> + dev_err_ratelimited(dev->dev, "%s(0x%08x): Sync lost",
> + __func__, stat);
> +
> + tilcdc_crtc->frame_intact = false;
> + if (tilcdc_crtc->sync_lost_count++ > SYNC_LOST_COUNT_LIMIT) {
> + dev_err(dev->dev,
> + "%s(0x%08x): Sync lost flood detected, disabling the interrupt",
> + __func__, stat);
> + if (priv->rev == 2)
> + tilcdc_write(dev, LCDC_INT_ENABLE_CLR_REG,
> + LCDC_SYNC_LOST);
> + else if (priv->rev == 1)
> + tilcdc_clear(dev, LCDC_RASTER_CTRL_REG,
> + LCDC_V1_SYNC_LOST_ENA);
> + }
> +
> + if (priv->rev == 2) {
> + /*
> + * Indicate to LCDC that the interrupt service routine
> + * has completed, see 13.3.6.1.6 in AM335x TRM.
> + */
> + tilcdc_write(dev, LCDC_END_OF_INT_IND_REG, 0);
> + } else if (priv->rev == 1) {
> + /* Reset the input FIFO in the DMA controller. */
> + tilcdc_clear(dev,
> + LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
> + tilcdc_set(dev,
> + LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
Here you are leaving the RASTER_ENABLE bit set unconditionnally.
It is disabled in tilcdc_crtc_disable with the irqs on (for v2 to handle
the last vblank), if the controller loses sync in the window between
disabling it and disabling the irqs in tilcdc_crtc_disable it is likely to
be problematic for the next call to tilcdc_crtc_enable.
Regards,
Karl
^ permalink raw reply
* [PATCH] ARM: DT: stm32: move dma translation to board files
From: Bruno Herrera @ 2016-10-31 16:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFvLkMQ6YMg4sf2Ug8x4-YshwnjbLz3aVzm+JpKP6zG9r-WU4Q@mail.gmail.com>
On Mon, Oct 31, 2016 at 12:14 PM, Rados?aw Pietrzyk
<radoslaw.pietrzyk@gmail.com> wrote:
> This is weird because dma ddresses are recalculated using parent's
> dma-ranges property and soc already has it so there should be absolutely no
> problem.
These are my DTS and DTSI file.
>
> 2016-10-31 11:27 GMT+01:00 Bruno Herrera <bruherrera@gmail.com>:
>>
>> On Fri, Oct 28, 2016 at 5:09 AM, Rados?aw Pietrzyk
>> <radoslaw.pietrzyk@gmail.com> wrote:
>> > Have you defined your sdio node within soc node ?
>>
>> It is in the SOC node of the DSTI file.
>>
>> >
>> > 2016-10-27 14:57 GMT+02:00 Bruno Herrera <bruherrera@gmail.com>:
>> >>
>> >> Hi Alex,
>> >>
>> >> On Thu, Oct 27, 2016 at 10:21 AM, Alexandre Torgue
>> >> <alexandre.torgue@st.com> wrote:
>> >> > Hi Bruno,
>> >> >
>> >> >
>> >> > On 10/27/2016 12:43 PM, Bruno Herrera wrote:
>> >> >>
>> >> >> Hi Alex,
>> >> >>
>> >> >> On Wed, Oct 26, 2016 at 7:09 AM, Alexandre Torgue
>> >> >> <alexandre.torgue@st.com> wrote:
>> >> >>>
>> >> >>> Hi Bruno,
>> >> >>>
>> >> >>> On 10/25/2016 11:06 PM, Bruno Herrera wrote:
>> >> >>>>
>> >> >>>>
>> >> >>>> Hi Alexandre,
>> >> >>>>
>> >> >>>>>
>> >> >>>>> stm32f469-disco and stm32f429-eval boards use SDRAM start address
>> >> >>>>> remapping
>> >> >>>>> (to @0) to boost performances. A DMA translation through
>> >> >>>>> "dma-ranges"
>> >> >>>>> property was needed for other masters than the M4 CPU.
>> >> >>>>> stm32f429-disco doesn't use remapping so doesn't need this DMA
>> >> >>>>> translation.
>> >> >>>>> This patches moves this DMA translation definition from stm32f429
>> >> >>>>> soc
>> >> >>>>> file
>> >> >>>>> to board files.
>> >> >>>>>
>> >> >>>>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>> >> >>>>>
>> >> >>>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >>>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >>>>> index 13c7cd2..a763c15 100644
>> >> >>>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >>>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >>>>> @@ -82,6 +82,10 @@
>> >> >>>>> };
>> >> >>>>> };
>> >> >>>>>
>> >> >>>>> + soc {
>> >> >>>>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
>> >> >>>>> + };
>> >> >>>>> +
>> >> >>>>> usbotg_hs_phy: usbphy {
>> >> >>>>> #phy-cells = <0>;
>> >> >>>>> compatible = "usb-nop-xceiv";
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Shouldn't also the peripheral dma-ranges property move to board
>> >> >>>> specific
>> >> >>>> too?
>> >> >>>> I had this patch for while but I didn't had the time to submit:
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> Well spot I forgot it. Actually, discussing with Arnd ysterday on
>> >> >>> IIRC,
>> >> >>> empty dma-ranges is not needed. Can you test on your side by
>> >> >>> removing
>> >> >>> dma-ranges in usb node please ?
>> >> >>
>> >> >> Unfortunately will take a time for me to set up this environment on
>> >> >> the STM32F4-EVAL board.
>> >> >> And on the discovery boards we dont have this scenario. That was the
>> >> >> main reason I did not submit the patch right away.
>> >> >> My conclusion and I might be wrong but is based on the my tests with
>> >> >> SDIO device at STM32F469I-DISCO board.
>> >> >>
>> >> >> I started this issue as discussion at ST Forum but Maxime gave me
>> >> >> the
>> >> >> hint.
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fDMA2%20and%20SYSCFG_MEMRMP%20relationship&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=44
>> >> >>
>> >> >>> I will push a v2 by removing empty dma-ranges if tests are ok in
>> >> >>> your
>> >> >>> side.
>> >> >>
>> >> >>
>> >> >> From my understating/conclusion is: when empty property(dma-ranges)
>> >> >> is
>> >> >> the device node, the mapping will be taken in consideration when
>> >> >> using
>> >> >> DMA otherwise the mapping is ignored.
>> >> >> And in the SDIO case it is needed for DEV->MEM(SDRAM) and
>> >> >> MEM(SDRAM)->DEV. If it is not the case for the devices in question
>> >> >> so
>> >> >> I suppose it can work without the property.
>> >> >
>> >> >
>> >> > For sure translation has to be done but I'm not sure that an empty
>> >> > "dma-ranges" is needed in device node to activate it. For Ethernet
>> >> > empty
>> >> > "dma-ranges" is not needed. I will try with usb.
>> >>
>> >> In the case of SDIO it is needed. As example this is my working SDIO
>> >> node:
>> >>
>> >> sdio: sdio at 40012c00 {
>> >> compatible = "arm,pl18x", "arm,primecell";
>> >> arm,primecell-periphid = <0x00480181>;
>> >> reg = <0x40012c00 0x400>;
>> >> dmas = <&dma2 6 4 0x10400 0x3>, /* Logical - DevToMem */
>> >> <&dma2 3 4 0x10400 0x3>; /* Logical - MemToDev */
>> >> dma-names = "rx", "tx";
>> >> clocks = <&rcc 0 171>;
>> >> clock-names = "apb_pclk";
>> >> interrupts = <49>;
>> >> status = "disabled";
>> >> };
>> >>
>> >> &sdio {
>> >> status = "okay";
>> >> vmmc-supply = <&wlan_en>;
>> >> bus-width = <4>;
>> >> max-frequency = <24000000>;
>> >> pinctrl-names = "default";
>> >> pinctrl-0 = <&sdio_pins>;
>> >> ti,non-removable;
>> >> ti,needs-special-hs-handling;
>> >> dma-ranges;
>> >> cap-power-off-card;
>> >> keep-power-in-suspend;
>> >>
>> >> #address-cells = <1>;
>> >> #size-cells = <0>;
>> >> wlcore: wlcore at 0 {
>> >> compatible = "ti,wl1835";
>> >> reg = <2>;
>> >> interrupt-parent = <&gpioa>;
>> >> interrupts = <8 IRQ_TYPE_EDGE_RISING>;
>> >> };
>> >> };
>> >>
>> >> >
>> >> > alex
>> >> >
>> >> >
>> >> >>
>> >> >>>
>> >> >>> Thanks in advance
>> >> >>> Alex
>> >> >>>
>> >> >>>
>> >> >>>>
>> >> >>>> Author: Bruno Herrera <bruherrera@gmail.com>
>> >> >>>> Date: Sun Oct 16 14:50:00 2016 -0200
>> >> >>>>
>> >> >>>> ARM: DT: STM32: Use dma-ranges property per board not at dtsi
>> >> >>>> file
>> >> >>>>
>> >> >>>> diff --git a/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >>>> b/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >>>> index 6bfc595..2a22a82 100644
>> >> >>>> --- a/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >>>> +++ b/arch/arm/boot/dts/stm32429i-eval.dts
>> >> >>>> @@ -52,6 +52,10 @@
>> >> >>>> model = "STMicroelectronics STM32429i-EVAL board";
>> >> >>>> compatible = "st,stm32429i-eval", "st,stm32f429";
>> >> >>>>
>> >> >>>> + soc {
>> >> >>>> + dma-ranges = <0xC0000000 0x0 0x10000000>;
>> >> >>>> + };
>> >> >>>> +
>> >> >>>> chosen {
>> >> >>>> bootargs = "root=/dev/ram rdinit=/linuxrc";
>> >> >>>> stdout-path = "serial0:115200n8";
>> >> >>>> @@ -96,6 +100,7 @@
>> >> >>>>
>> >> >>>> ðernet0 {
>> >> >>>> status = "okay";
>> >> >>>> + dma-ranges;
>> >> >>>> pinctrl-0 = <ðernet0_mii>;
>> >> >>>> pinctrl-names = "default";
>> >> >>>> phy-mode = "mii-id";
>> >> >>>> @@ -116,6 +121,7 @@
>> >> >>>> };
>> >> >>>>
>> >> >>>> &usbotg_hs {
>> >> >>>> + dma-ranges;
>> >> >>>> dr_mode = "host";
>> >> >>>> phys = <&usbotg_hs_phy>;
>> >> >>>> phy-names = "usb2-phy";
>> >> >>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>> >> >>>> b/arch/arm/boot/dts/stm32f429.dtsi
>> >> >>>> index 7d624a2..697a133 100644
>> >> >>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> >> >>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> >> >>>> @@ -59,7 +59,6 @@
>> >> >>>> };
>> >> >>>>
>> >> >>>> soc {
>> >> >>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
>> >> >>>>
>> >> >>>> timer2: timer at 40000000 {
>> >> >>>> compatible = "st,stm32-timer";
>> >> >>>> @@ -472,13 +471,11 @@
>> >> >>>> st,syscon = <&syscfg 0x4>;
>> >> >>>> snps,pbl = <8>;
>> >> >>>> snps,mixed-burst;
>> >> >>>> - dma-ranges;
>> >> >>>> status = "disabled";
>> >> >>>> };
>> >> >>>>
>> >> >>>> usbotg_hs: usb at 40040000 {
>> >> >>>> compatible = "snps,dwc2";
>> >> >>>> - dma-ranges;
>> >> >>>> reg = <0x40040000 0x40000>;
>> >> >>>> interrupts = <77>;
>> >> >>>> clocks = <&rcc 0 29>;
>> >> >>>>
>> >> >>>>
>> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>> >> >>>>> b/arch/arm/boot/dts/stm32f429.dtsi
>> >> >>>>> index 0596d60..3a1cfdd 100644
>> >> >>>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> >> >>>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> >> >>>>> @@ -59,8 +59,6 @@
>> >> >>>>> };
>> >> >>>>>
>> >> >>>>> soc {
>> >> >>>>> - dma-ranges = <0xc0000000 0x0 0x10000000>;
>> >> >>>>> -
>> >> >>>>> timer2: timer at 40000000 {
>> >> >>>>> compatible = "st,stm32-timer";
>> >> >>>>> reg = <0x40000000 0x400>;
>> >> >>>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
>> >> >>>>> b/arch/arm/boot/dts/stm32f469-disco.dts
>> >> >>>>> index 9e73656..c2213c0 100644
>> >> >>>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>> >> >>>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>> >> >>>>> @@ -64,6 +64,10 @@
>> >> >>>>> aliases {
>> >> >>>>> serial0 = &usart3;
>> >> >>>>> };
>> >> >>>>> +
>> >> >>>>> + soc {
>> >> >>>>> + dma-ranges = <0xc0000000 0x0 0x10000000>;
>> >> >>>>> + };
>> >> >>>>> };
>> >> >>>>>
>> >> >>>>> &clk_hse {
>> >> >>>>> --
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Br.,
>> >> >>>> Bruno
>> >> >>>>
>> >> >>>
>> >> >
>> >>
>> >> _______________________________________________
>> >> linux-arm-kernel mailing list
>> >> linux-arm-kernel at lists.infradead.org
>> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> >
>> >
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stm32f469-disco.dts
Type: application/octet-stream
Size: 3330 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/f28cc5d8/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stm32f429.dtsi
Type: application/octet-stream
Size: 12741 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/f28cc5d8/attachment-0003.obj>
^ 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