* Applied "ASoC: sun4i-codec: Rename sun4i_codec_widgets for consistency" to the asoc tree
From: Mark Brown @ 2016-09-26 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915143922.4890-2-dannym@scratchpost.org>
The patch
ASoC: sun4i-codec: Rename sun4i_codec_widgets for consistency
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 c9e902f4b37a3c108eb5dc51f1340c09becd7232 Mon Sep 17 00:00:00 2001
From: Danny Milosavljevic <dannym@scratchpost.org>
Date: Sat, 24 Sep 2016 22:05:01 +0200
Subject: [PATCH] ASoC: sun4i-codec: Rename sun4i_codec_widgets for consistency
Rename "sun4i_codec_widgets" to "sun4i_codec_controls" for
consistency with the struct field name.
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index e51f363ff786..e047ec06d538 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -509,7 +509,7 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute =
static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
-static const struct snd_kcontrol_new sun4i_codec_widgets[] = {
+static const struct snd_kcontrol_new sun4i_codec_controls[] = {
SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
sun4i_codec_pa_volume_scale),
@@ -629,8 +629,8 @@ static const struct snd_soc_dapm_route sun4i_codec_codec_dapm_routes[] = {
static struct snd_soc_codec_driver sun4i_codec_codec = {
.component_driver = {
- .controls = sun4i_codec_widgets,
- .num_controls = ARRAY_SIZE(sun4i_codec_widgets),
+ .controls = sun4i_codec_controls,
+ .num_controls = ARRAY_SIZE(sun4i_codec_controls),
.dapm_widgets = sun4i_codec_codec_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(sun4i_codec_codec_dapm_widgets),
.dapm_routes = sun4i_codec_codec_dapm_routes,
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] gpio: Add a driver for the Raspberry Pi's firmware GPIO calls.
From: Stephen Warren @ 2016-09-26 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mviy92qw.fsf@eliezer.anholt.net>
On 09/23/2016 07:15 AM, Eric Anholt wrote:
> Linus Walleij <linus.walleij@linaro.org> writes:
>
>> On Mon, Sep 19, 2016 at 6:13 PM, Eric Anholt <eric@anholt.net> wrote:
>>
>>> This driver will be used for accessing the FXL6408 GPIO exander on the
>>> Pi3. We can't drive it directly from Linux because the firmware is
>>> continuously polling one of the expander's lines to do its
>>> undervoltage detection.
>>>
>>> Signed-off-by: Eric Anholt <eric@anholt.net>
>> (...)
>>
>>> +config GPIO_RASPBERRYPI
>>> + tristate "Raspberry Pi firmware-based GPIO access"
>>> + depends on OF_GPIO && RASPBERRYPI_FIRMWARE && (ARCH_BCM2835 || COMPILE_TEST)
>>> + help
>>> + Turns on support for using the Raspberry Pi firmware to
>>> + control GPIO pins. Used for access to the FXL6408 GPIO
>>> + expander on the Pi 3.
>>
>> Maybe it should be named GPIO_RPI_FXL6408 ?
>>
>> (No strong opinion.)
>
> See DT binding comment -- I think since this driver has no dependency on
> being to the 6408 on the pi3, we shouldn't needlessly bind it to the
> FXL6408. (the help comment was just context for why you would want the
> driver today).
I'd suggest including "FW" or "FIRMWARE" in the Kconfig option too; the
Raspberry Pi has multiple GPIO drivers; one accessing the BCM283x HW
directly and the other going through the FW. It'd be good if each
Kconfig name was pretty explicit re: which one it represented.
^ permalink raw reply
* [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers
From: Vinod Koul @ 2016-09-26 16:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160810112219.17964-1-niklas.soderlund+renesas@ragnatech.se>
On Wed, Aug 10, 2016 at 01:22:13PM +0200, Niklas S?derlund wrote:
> Hi,
>
> This series tries to solve the problem with DMA with device registers
> (MMIO registers) that are behind an IOMMU for the rcar-dmac driver. A
> recent patch '9575632 (dmaengine: make slave address physical)'
> clarifies that DMA slave address provided by clients is the physical
> address. This puts the task of mapping the DMA slave address from a
> phys_addr_t to a dma_addr_t on the DMA engine.
>
> Without an IOMMU this is easy since the phys_addr_t and dma_addr_t are
> the same and no special care is needed. However if you have a IOMMU you
> need to map the DMA slave phys_addr_t to a dma_addr_t using something
> like this.
>
> This series is based on top of v4.8-rc1. And I'm hoping to be able to collect a
> Ack from Russell King on patch 4/6 that adds the ARM specific part and then be
> able to take the whole series through the dmaengine tree. If this is not the
> best route I'm more then happy to do it another way.
>
> It's tested on a Koelsch with CONFIG_IPMMU_VMSA and by enabling the
> ipmmu_ds node in r8a7791.dtsi. I verified operation by interacting with
> /dev/mmcblk1, i2c and the serial console which are devices behind the
> iommu.
>
> Furthermore I have audited to the best of my ability all call paths
> involved to make sure that the dma_addr_t obtained from
> dma_map_resource() to is not used in a way where it would be expected
> for the mapping to be RAM (have a struct page). Many thanks to Christoph
> Hellwig and Laurent Pinchart for there input in this effort.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH 1/2] clk: rockchip: add I2S internal clock IDs for rk3288
From: John Keeping @ 2016-09-26 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21692410.II2VYnELL8@phil>
On Sun, 25 Sep 2016 23:50:29 +0200, Heiko Stuebner wrote:
> Am Mittwoch, 7. September 2016, 19:18:23 CEST schrieb John Keeping:
> > On Wed, 07 Sep 2016 19:58:31 +0200, Heiko Stuebner wrote:
> > > Am Mittwoch, 7. September 2016, 17:53:29 CEST schrieb John Keeping:
> > > > To minimize jitter on the I2S clocks, it is important that the
> > > > denominator in the fractional divider is much greater than the
> > > > numerator. Add identifiers for these internal clocks so that the
> > > > specific clock topology and rates can be specified in the device tree.
> > >
> > > The TRM states that the denominator must be bigger than 20. Is this the
> > > one
> > > you found or did you find further constraints?
> >
> > Is it not that the denominator must be bigger than 20 times the
> > numerator? That's what we found, although it seems that the greater the
> > divisor the better, so our aim is dividing down from 594MHz from GPLL to
> > the target rate in i2s_frac.
>
> That is good to know ... the TRM probably lost the real information during
> translation or so and only states that hard value. Looking at the rk3368 TRM
> just now, the value really is 20 times greater than the numerator.
>
>
> > > Did you try teaching the fractional divider to handle these constraints
> > > before going this way?
> >
> > No, I hadn't looked at doing that. I'm not sure how that would work,
> > we'd need to add support for fractional divider changing the parent rate
> > wouldn't we?
>
> Doug had a somewhat similar problem, mentioning the lack of a "bestdiv"
> equivalent that the standard divider provides. I'm not sure if there isn't a
> way to provide something like this and/or make the fractional clock honor
> specific requirments concerning numerator/denominator - any mathematicians
> around? :-)
Yes, this is difficult, although I expect a simple approach of setting
the input as fast as possible would work reasonably well in practice.
But even when the input is a mux with a fixed set of possible rates it
is difficult to extract its maximum frequency within the clock
framework.
> One could also replace the generic fraction divider use with a rockchip-
> specific implementation that somehow handles that.
I hadn't considered that, I assumed there would be a strong preference
for enhancing the generic code rather than writing a special case
implementation.
> > > Exporting the internal clocks really would be sort of plan d or e, after
> > > handling this in the clock framework failed. Especially as i2s rates are
> > > probably dependant on the media being handled (frequencies and such), so
> > > setting fractional rates statically in the dts won't help you much in the
> > > general case, as any new playback could trigger a clk_set_rate call
> > > anyway?
> >
> > We're not setting the fractional rate specifically, instead we're
> > setting the i2s_pre rate and parent explicitly and banning the i2s_src
> > mux setting to i2s_pre, which means that clk_set_rate on sclk_i2s0 will
> > always change i2s_frac but leave i2s_pre alone.
>
> But then you are again in the situation where some requested rate can ignore
> those fractional-divider constraints? In general I really don't like encoding
> such board-specific behaviour into the generic clock tree, like needing to
> disable parent relationships.
Yes, I wouldn't suggest changing the clock mux in the upstream kernel.
I was hoping specifying an assigned parent in DT would be enough to keep
the parent set correctly, but it doesn't seem to be.
> It works for your board now but does not necessarily for all other boards,
> which might require other "hacks" and also doesn't solve the general problem
> for all other fractional dividers we have.
The sensible heuristic is to minimize the length of the clock path when
there are two equally good routes, which would handle the case where the
I2S clock can be generated without the need for a fractional divider.
But I don't think the clock framework has any way to take into account
that a mux may end up bypassing another clock.
It seems that even without the fractional divider we can't get low
enough jitter to meet our requirements, so we've decided to use an
external clock for I2S. As a result of that, we're no longer using this
part of the clock tree at all, so I'm happy to drop these patches.
John
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Add reboot reason support for Trats2
From: Krzysztof Kozlowski @ 2016-09-26 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160925073445.GA2469@kozik-lap>
On Sun, Sep 25, 2016 at 09:34:45AM +0200, Krzysztof Kozlowski wrote:
> On Sat, Sep 24, 2016 at 11:04:49PM +0200, Wolfgang Wiedmeyer wrote:
> >
> > Krzysztof Kozlowski writes:
> >
> > > On Thu, Sep 22, 2016 at 08:59:03PM +0200, Wolfgang Wiedmeyer wrote:
> > >>
> > >> Krzysztof Kozlowski writes:
> > >>
> > >> > On Thu, Sep 22, 2016 at 06:48:35PM +0200, Wolfgang Wiedmeyer wrote:
> > >> >> This allows to reboot the device into recovery mode and into the download
> > >> >> mode of the bootloader.
> > >> >
> > >> > Which bootloader? Probably UBoot... or Samsung stock one? Could you put
> > >> > that information here?
> > >>
> > >> I'm only working with the stock one. I was under the impression that the
> > >> stock bootloader cannot be replaced on a i9300 because there's a
> > >> signature check. Is UBoot loaded after the stock one on Trats2 or how
> > >> does this work? I didn't find information on that.
> > >
> > > +CC Marek,
> > >
> > > Trats2 is working with U-Boot. Just U-Boot. However I never converted S3
> > > into Trats2 on my own. I always used targets prepared to be "Trats2"
> > > type.
> >
> > It would be awesome to be able to run U-Boot on i9300. Is there a way to
> > test this by not risking to brick the device, e.g. by booting from the
> > SD card? Then I could send an updated version of the patch that is
> > compatible with U-Boot :)
>
> I don't think the stock bootloader supports chaining another bootloader
> from SD card. There is a way of booting from SD card by shortening a
> resistor but it is an emergency rescue procedure to overwrite existing
> bootloader with data from SD card (to restore device). This thread might
> be interesting:
> http://forum.xda-developers.com/showpost.php?p=47234165&postcount=220
> https://smyl.es/samsung-galaxy-iii-s3-gt-i9300-jtag-leaked-document-how-to-repair-soft-bricked-galaxy-s3/
>
> On xda-developers you might find more data about this (including the
> procedure for emergency restore from SD card). Somehow people flash and
> unbrick their devices when playing with CyanogenMod...
Hi Wolfgang,
Few more info from my side. It is (rather) not possible to just flash
GT-I9300 with U-Boot. It still requires S-Boot as a primary bootloader
(probably different than the stock one). I think such binary S-Boot was
published along with Tizen images for Trats2 (called RD-PQ). These
images however started to disappear from download.tizen.org. You can
still find some, e.g.:
http://download.tizen.org/releases/system/Tizen_RD-PQ_System_20130716_1.tar
(better download it soon :) ) This 'tar' should be uploaded through
Lthor (also from tizen.org) however it might require appropriate
Partition Information Table (PIT).
On Tizen Wiki you might find some guides for flashing/upgrading-PIT on Trats2.
However, please be careful, as all of these steps (and linked binary) are
targeted to existing RD-PQ/Trats2 boards. They are not intended as a
way of converting GT-I9300 into Trats2. The conversion might work but...
it might not.
Before playing with it, I think it would be wise to have the emergency
recovery procedure (with SD card) ready.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v26 6/7] arm64: kdump: update a kernel doc
From: Matthias Brugger @ 2016-09-26 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DC18FC.9000807@arm.com>
On 16/09/16 18:08, James Morse wrote:
> Hi Akashi,
>
> On 07/09/16 05:29, AKASHI Takahiro wrote:
>> This patch adds arch specific descriptions about kdump usage on arm64
>> to kdump.txt.
>
>> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
>
>> @@ -249,6 +249,13 @@ Dump-capture kernel config options (Arch Dependent, arm)
>>
>> AUTO_ZRELADDR=y
>>
>> +Dump-capture kernel config options (Arch Dependent, arm64)
>> +----------------------------------------------------------
>> +
>> +- Please note that kvm of the dump-capture kernel will not be enabled
>> + on non-VHE systems even if it is configured. This is because the CPU
>> + cannot be reset to EL2 on panic.
>
> Nit:
> cannot be -> will not be
>
> We could try to do this, but its more code that could prevent us reaching the
> kdump kernel, so we choose not to.
>
>
>> @@ -370,6 +381,9 @@ For s390x:
>> For arm:
>> "1 maxcpus=1 reset_devices"
>>
>> +For arm64:
>> + "1 maxcpus=1 reset_devices"
>> +
>
> 'maxcpus=1' is a bit fragile. Since 44dbcc93ab67145 ("arm64: Fix behavior of
> maxcpus=N") udev on ubuntu vivid (running on Juno) has taken it upon itself to
> bring the secondary cores online, even when booted with 'maxcpus=1'.
>
This looks pretty much like a bug to me and should get fixed on their site.
> Can we change the recomendation to "1 nosmp reset_devices"?
>
>
> Thanks,
>
> James
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH 00/24] ste_dma40: Fine-tuning for several function implementations
From: Vinod Koul @ 2016-09-26 17:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <92810066-69b6-94e7-dcec-a28594b1328f@users.sourceforge.net>
On Sat, Sep 17, 2016 at 05:05:16PM +0200, SF Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Sat, 17 Sep 2016 16:56:56 +0200
>
> Several update suggestions were taken into account
> from static source code analysis.
Applied all, thanks
--
~Vinod
^ permalink raw reply
* [PATCH v3] dmaengine: s3c24xx: Add dma_slave_map for s3c2440 devices
From: Vinod Koul @ 2016-09-26 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474570275-7238-1-git-send-email-sam.van.den.berge@telenet.be>
On Thu, Sep 22, 2016 at 08:51:15PM +0200, Sam Van Den Berge wrote:
> This patch updates the s3c24xx dma driver to be able to pass a
> dma_slave_map array via the platform data. This is needed to
> be able to use the new, simpler dmaengine API [1].
> I used the virtual DMA channels as a parameter for the dma_filter
> function. By doing that, I could reuse the existing filter function in
> drivers/dma/s3c24xx-dma.c.
>
> I have tested this on my mini2440 board with the audio driver.
> According to my observations, dma_request_slave_channel in the
> function dmaengine_pcm_new in the file
> sound/soc/soc-generic-dmaengine-pcm.c now returns a valid DMA channel
> whereas before no DMA channel was returned at that point.
>
> Entries for DMACH_XD0, DMACH_XD1 and DMACH_TIMER are missing because I
> don't realy know which driver to use for these.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH] dmaengine: sun6i: Add support for Allwinner A83T (sun8i) variant
From: Vinod Koul @ 2016-09-26 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79efe054-3640-45ec-9c11-3f60d497b1e0@orsmsx104.amr.corp.intel.com>
On Sun, Sep 18, 2016 at 09:59:50AM +0200, Jean-Francois Moine wrote:
> The A83T SoC has the same dma engine as the A31 (sun6i), with a reduced
> amount of endpoints and physical channels.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.
From: Stefan Wahren @ 2016-09-26 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fa11c543-2ad3-b2ae-f816-62a1acd42911@wwwdotorg.org>
> Stephen Warren <swarren@wwwdotorg.org> hat am 26. September 2016 um 18:38
> geschrieben:
>
>
> On 09/23/2016 12:39 PM, Stefan Wahren wrote:
> > Hi Eric,
> >
> >> Eric Anholt <eric@anholt.net> hat am 19. September 2016 um 18:13
> >> geschrieben:
> >>
> >>
> >> The RPi firmware exposes all of the board's GPIO lines through
> >> property calls. Linux chooses to control most lines directly through
> >> the pinctrl driver, but for the FXL6408 GPIO expander on the Pi3, we
> >> need to access them through the firmware.
> >>
> >> Signed-off-by: Eric Anholt <eric@anholt.net>
> >> ---
> >> .../bindings/gpio/gpio-raspberrypi-firmware.txt | 22
> >> ++++++++++++++++++++++
> >> 1 file changed, 22 insertions(+)
> >> create mode 100644
> >> Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
> >> b/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
> >> new file mode 100644
> >> index 000000000000..2b635c23a6f8
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/gpio/gpio-raspberrypi-firmware.txt
> >> @@ -0,0 +1,22 @@
> >> +Raspberry Pi power domain driver
> >> +
> >> +Required properties:
> >> +
> >> +- compatible: Should be "raspberrypi,firmware-gpio"
> >
> > i think the compatible should be more specific like
> >
> > raspberrypi,rpi3-firmware-gpio
> >
> > and all information which aren't requestable from the firmware should be
> > stored
> > in a info structure. This makes the driver easier to extend in the future by
> > adding new compatibles and their info structures.
>
> Is this actually specific to the Pi3 at all?
AFAIK only the Raspberry Pi 3 has a GPIO expander which is accessible via the
common FW. My suggestion tries to follow the basic guideline "A precise
compatible string is better than a vague one" from Device Tree for Dummies [1].
So in case the next Raspberry Pi would have a different GPIO expander with
different parameters we could add a new compatible.
But you are right the word order in "rpi3-firmware-gpio" suggests that there are
different FW which is wrong. At the end it's only a compatible string. So no
strong opinion about the naming.
[1] -
https://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf
> Isn't the FW the same
> across all Pis; the part that's specific to the Pi3 is whether it's
> useful to use that API?
>
> As such, I'd suggest just raspberrypi,firmware-gpio as the compatible value.
>
^ permalink raw reply
* [PATCH] clk: lpc32xx: fix pwm clock divider computation
From: Sylvain Lemieux @ 2016-09-26 18:44 UTC (permalink / raw)
To: linux-arm-kernel
From: Sylvain Lemieux <slemieux@tycoint.com>
A zero value in the PWM clock divider register
(PWM1_FREQ/PWM2_FREQ) turn off the PWM clock.
The "CLK_DIVIDER_ALLOW_ZERO" option is used for hardware that handle
the zero divider by not modifying their clock input (i.e. bypass).
See "/include/linux/clk-provider.h" for details.
Remove the CLK_DIVIDER_ALLOW_ZERO option and add support to handle
the clock rate computation of the PWM clock divider 0 value.
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
---
Note:
* Should we include a new CLK_DIVIDER option for this case
(i.e. clock off when zero ) in "clk-provider.h"?
drivers/clk/nxp/clk-lpc32xx.c | 52 +++++++++++++++++++++++++++++++++++++++----
1 file changed, 48 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/nxp/clk-lpc32xx.c b/drivers/clk/nxp/clk-lpc32xx.c
index 34c9735..3ca3a14 100644
--- a/drivers/clk/nxp/clk-lpc32xx.c
+++ b/drivers/clk/nxp/clk-lpc32xx.c
@@ -959,6 +959,25 @@ static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
divider->flags);
}
+static unsigned long clk_divider_pwm_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct lpc32xx_clk_div *divider = to_lpc32xx_div(hw);
+ unsigned int val;
+
+ regmap_read(clk_regmap, divider->reg, &val);
+
+ val >>= divider->shift;
+ val &= div_mask(divider->width);
+
+ /* Handle 0 divider -> PWM clock is off. */
+ if(val == 0)
+ return 0;
+
+ return divider_recalc_rate(hw, parent_rate, val, divider->table,
+ divider->flags);
+}
+
static long clk_divider_round_rate(struct clk_hw *hw, unsigned long rate,
unsigned long *prate)
{
@@ -999,6 +1018,12 @@ static const struct clk_ops lpc32xx_clk_divider_ops = {
.set_rate = clk_divider_set_rate,
};
+static const struct clk_ops lpc32xx_clk_pwm_divider_ops = {
+ .recalc_rate = clk_divider_pwm_recalc_rate,
+ .round_rate = clk_divider_round_rate,
+ .set_rate = clk_divider_set_rate,
+};
+
static u8 clk_mux_get_parent(struct clk_hw *hw)
{
struct lpc32xx_clk_mux *mux = to_lpc32xx_mux(hw);
@@ -1151,6 +1176,25 @@ struct clk_hw_proto {
}, \
}
+#define LPC32XX_DEFINE_PWM_DIV(_idx, _reg, _shift, _width, _tab, _fl) \
+[CLK_PREFIX(_idx)] = { \
+ .type = CLK_DIV, \
+ { \
+ .hw0 = { \
+ .ops = &lpc32xx_clk_pwm_divider_ops, \
+ { \
+ .div = { \
+ .reg = LPC32XX_CLKPWR_ ## _reg, \
+ .shift = (_shift), \
+ .width = (_width), \
+ .table = (_tab), \
+ .flags = (_fl), \
+ }, \
+ }, \
+ }, \
+ }, \
+}
+
#define LPC32XX_DEFINE_GATE(_idx, _reg, _bit, _flags) \
[CLK_PREFIX(_idx)] = { \
.type = CLK_GATE, \
@@ -1281,14 +1325,14 @@ static struct clk_hw_proto clk_hw_proto[LPC32XX_CLK_HW_MAX] = {
LPC32XX_DEFINE_GATE(MCPWM, TIMCLK_CTRL1, 6, 0),
LPC32XX_DEFINE_MUX(PWM1_MUX, PWMCLK_CTRL, 1, 0x1, NULL, 0),
- LPC32XX_DEFINE_DIV(PWM1_DIV, PWMCLK_CTRL, 4, 4, NULL,
- CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO),
+ LPC32XX_DEFINE_PWM_DIV(PWM1_DIV, PWMCLK_CTRL, 4, 4, NULL,
+ CLK_DIVIDER_ONE_BASED),
LPC32XX_DEFINE_GATE(PWM1_GATE, PWMCLK_CTRL, 0, 0),
LPC32XX_DEFINE_COMPOSITE(PWM1, PWM1_MUX, PWM1_DIV, PWM1_GATE),
LPC32XX_DEFINE_MUX(PWM2_MUX, PWMCLK_CTRL, 3, 0x1, NULL, 0),
- LPC32XX_DEFINE_DIV(PWM2_DIV, PWMCLK_CTRL, 8, 4, NULL,
- CLK_DIVIDER_ONE_BASED | CLK_DIVIDER_ALLOW_ZERO),
+ LPC32XX_DEFINE_PWM_DIV(PWM2_DIV, PWMCLK_CTRL, 8, 4, NULL,
+ CLK_DIVIDER_ONE_BASED),
LPC32XX_DEFINE_GATE(PWM2_GATE, PWMCLK_CTRL, 2, 0),
LPC32XX_DEFINE_COMPOSITE(PWM2, PWM2_MUX, PWM2_DIV, PWM2_GATE),
--
1.8.3.1
^ permalink raw reply related
* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Stephen Boyd @ 2016-09-26 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160926032927.GA25395@b29397-desktop>
Quoting Peter Chen (2016-09-25 20:29:27)
> On Thu, Sep 22, 2016 at 11:51:02AM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-09-16 18:16:05)
> > > On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > > > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > > > board to mux the D+/D- lines from the SoC between a micro usb
> > > > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > > > we need to change this mux to forward the D+/D- lines to either
> > > > > the port or the hub. Therefore, introduce a driver for this
> > > > > device that intercepts extcon USB_HOST events and logically
> > > > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > > > attached. When the cable goes away, it will logically deassert
> > > > > the gpio and mux the "device" lines.
> > > > >
> > > > > [1] https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > > > >
> > > > > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > > > > Cc: Chanwoo Choi <cw00.choi@samsung.com>
> > > > > Cc: <devicetree@vger.kernel.org>
> > > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > > > ---
> > > > >
> > > > > Should I make the extcon part optional? I could see a case where there are two
> > > > > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > > > > software may want to mux between them at runtime. If we mandate an extcon,
> > > > > that won't be possible to support. Perhaps it would be better to have
> > > > > the node, but connect it to the usb controller with a phandle (maybe of_graph
> > > > > endpoints would be useful too) so that when the controller wants to mux over
> > > > > a port it can do so.
> > > >
> > > > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > > > haven't written any code around it, but the idea is to allow the binding
> > > > to specify how the mux is connected to upstream and downstream D+/D-
> > > > lines. This way, we can do some dt parsing of the endpoints and their
> > > > parent nodes to figure out if the mux needs to be set high or low to use
> > > > a device connector or a usb hub based on if the id cable is present.
> > > > Maybe I'm over thinking things though and we could just have a DT
> > > > property for that.
> > > >
> > > > soc {
> > > > usb at 78d9000 {
> > > > extcon = <&usb_id>, <&usb_id>;
> > >
> > > Why you have two same extcon phandler? From my mind, one should id,
> > > another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
> > > vbus support, how you support vbus detection for
> > > connection/disconnection with PC for your chipidea msm patch set?
> >
> > This was already in the dts files for db410c. In the chipidea binding
> > one is for EXTCON_USB (vbus) and one is for EXTCON_USB_HOST (id). My
> > understanding is that extcon-usb-gpio.c sends events for both EXTCON_USB
> > and EXTCON_USB_HOST when the gpio changes state. vbus detection is not
> > that great on this board because we only have on gpio for this.
>
> I think extcon-usb-gpio.c needs to extend for supporting vbus event,
> otherwise, the micro-b cable's connect/disconnect will introduce
> EXTCON_USB_HOST event, if you use two <&usb_idx> for both id and
> vbus event.
>
Sorry, I'm lost now. extcon-usb-gpio.c already supports EXTCON_USB as an
event. Is the problem that we're using two of the same phandles in the
binding?
^ permalink raw reply
* [PATCH] ARM: dts: lpc32xx: add pwm-cells to base dts file
From: Sylvain Lemieux @ 2016-09-26 18:47 UTC (permalink / raw)
To: linux-arm-kernel
From: Sylvain Lemieux <slemieux@tycoint.com>
There is no need to define the "pwm-cells" in the board
specific dts file; move the entry to the base dts file.
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
---
Note:
* This patch should be apply after
"ARM: dts: lpc32xx: set default parent clock for pwm1 & pwm2"
http://www.spinics.net/lists/arm-kernel/msg530277.html
- There is no dependency between the patches.
arch/arm/boot/dts/lpc32xx.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index 218d9fa..c031c94 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -472,6 +472,7 @@
assigned-clocks = <&clk LPC32XX_CLK_PWM1>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
status = "disabled";
+ #pwm-cells = <2>;
};
pwm2: pwm at 4005C004 {
@@ -481,6 +482,7 @@
assigned-clocks = <&clk LPC32XX_CLK_PWM2>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
status = "disabled";
+ #pwm-cells = <2>;
};
timer3: timer at 40060000 {
--
1.8.3.1
^ permalink raw reply related
* [PATCH] ARM: dts: lpc32xx: set pwm1 & pwm2 default clock rate
From: Sylvain Lemieux @ 2016-09-26 18:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Sylvain Lemieux <slemieux@tycoint.com>
Probably most of NXP LPC32xx boards have 13MHz main oscillator
and therefore for HCLK PLL and ARM core clock rate default
hardware setting of 16 * 13MHz = 208MHz and the AHB bus clock
rate of 208MHz / 2 = 104MHz.
The change explicitly defines the peripheral PWM1/PWM2 default
clock output rate of 104MHz. If needed it can be redefined
in a board DTS file.
Signed-off-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
---
Note:
* There is a dependency on the following patch:
"ARM: dts: lpc32xx: set default parent clock for pwm1 & pwm2"
http://www.spinics.net/lists/arm-kernel/msg530277.html
* This patch should be apply after
"ARM: dts: lpc32xx: add pwm-cells to base dts file"
http://www.spinics.net/lists/arm-kernel/msg534050.html
- There is no dependency between the patches.
arch/arm/boot/dts/lpc32xx.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/lpc32xx.dtsi b/arch/arm/boot/dts/lpc32xx.dtsi
index c031c94..d669200 100644
--- a/arch/arm/boot/dts/lpc32xx.dtsi
+++ b/arch/arm/boot/dts/lpc32xx.dtsi
@@ -471,6 +471,7 @@
clocks = <&clk LPC32XX_CLK_PWM1>;
assigned-clocks = <&clk LPC32XX_CLK_PWM1>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
+ assigned-clock-rates = <104000000>;
status = "disabled";
#pwm-cells = <2>;
};
@@ -481,6 +482,7 @@
clocks = <&clk LPC32XX_CLK_PWM2>;
assigned-clocks = <&clk LPC32XX_CLK_PWM2>;
assigned-clock-parents = <&clk LPC32XX_CLK_PERIPH>;
+ assigned-clock-rates = <104000000>;
status = "disabled";
#pwm-cells = <2>;
};
--
1.8.3.1
^ permalink raw reply related
* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Stephen Boyd @ 2016-09-26 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923143513.GA29714@rob-hp-laptop>
Quoting Rob Herring (2016-09-23 07:35:13)
> On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > board to mux the D+/D- lines from the SoC between a micro usb
> > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > we need to change this mux to forward the D+/D- lines to either
> > > the port or the hub. Therefore, introduce a driver for this
> > > device that intercepts extcon USB_HOST events and logically
> > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > attached. When the cable goes away, it will logically deassert
> > > the gpio and mux the "device" lines.
> > >
> > > [1] https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > >
> > > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > > Cc: Chanwoo Choi <cw00.choi@samsung.com>
> > > Cc: <devicetree@vger.kernel.org>
> > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > ---
> > >
> > > Should I make the extcon part optional? I could see a case where there are two
> > > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > > software may want to mux between them at runtime. If we mandate an extcon,
> > > that won't be possible to support. Perhaps it would be better to have
> > > the node, but connect it to the usb controller with a phandle (maybe of_graph
> > > endpoints would be useful too) so that when the controller wants to mux over
> > > a port it can do so.
>
> I've mentioned my opinion on extcon before. The first clue that it needs
> work is a Linux subsystem name is used for the binding.
>
> > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > haven't written any code around it, but the idea is to allow the binding
> > to specify how the mux is connected to upstream and downstream D+/D-
> > lines. This way, we can do some dt parsing of the endpoints and their
> > parent nodes to figure out if the mux needs to be set high or low to use
> > a device connector or a usb hub based on if the id cable is present.
> > Maybe I'm over thinking things though and we could just have a DT
> > property for that.
>
> I think the connector nodes are on the right track, but of-graph doesn't
> work here because we already have a way to describe USB buses in DT.
> Following that, would something like this work for you? The vbus-supply
> and id-gpios are just examples and may not always be there like if the
> hub controls each port's vbus directly.
My philosophical problem with this is that I don't view this usb-switch
as a usb device. It isn't addressable via the typical USB addressing
scheme. It's just a simple chip wired down on the board that muxes two
wires without considering what goes across those wires.
I would agree if this switch was a usb device itself that had a vid/pid
that we could talk to to switch the mux. But that isn't the case here.
>
> usb-controller at 1234 {
> usb-switch at 0 {
> compatible = "toshiba,tc7usb40mu";
> hub at 0 {
> compatible = "some-hub";
> port at 0 {
> compatible = "usb-A-connector"
> vbus-supply = ...;
> };
> port at 1 {
> compatible = "usb-A-connector"
> vbus-supply = ...;
> };
>
> };
> connector at 1 {
> compatible = "usb-ub-connector";
> vbus-supply = ...;
> id-gpios = <>;
> };
> };
> };
>
What do we do about a hub downstream of the mux like usb3503? If that's
on the i2c bus and we need to do some initial setup, shouldn't we put
the hub under the i2c bus (because that's the addressing scheme) instead
of under the switch and then use of-graph to describe the connections
that aren't being used for addressing? My understanding of of-graph is
pretty weak so perhaps I missed something.
^ permalink raw reply
* [PATCH v2] ARM: dts: socfpga: Add Macnica sodia board
From: Dinh Nguyen @ 2016-09-26 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160924235945.32128-1-iwamatsu@nigauri.org>
On 09/24/2016 06:59 PM, Nobuhiro Iwamatsu wrote:
> Add support for board based on the Altera Cyclone V SoC.
> This board has the following functions:
> - 1 GiB of DRAM
> - 1 Gigabit ethernet
> - 1 SD card slot
> - 1 USB gadget port
> - QSPI NOR Flash
> - I2C EEPROMs and I2C RTC
> - DVI output
> - Audio port
>
> This commit supports without QSPI, DVI and Audio.
>
> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> ---
> V2: move the PHY of setting to the Ethetnet PHY node level.
>
Applied. Thanks!
Dinh
^ permalink raw reply
* [PATCH v6 0/6] ARM: dts: imx6q: Add Engicam i.CoreM6 dts
From: Jagan Teki @ 2016-09-26 19:23 UTC (permalink / raw)
To: linux-arm-kernel
This is series add dts support for Engicam I.Core M6 qdl modules on
top of */shawnguo/linux.git for-next.
Jagan Teki (6):
of: Add vendor prefix for Engicam s.r.l company
ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
ARM: dts: imx6q: Add Engicam i.CoreM6 DualLite/Solo initial support
ARM: dts: imx6qdl-icore: Add usbhost support
ARM: dts: imx6qdl-icore: Add usbotg support
ARM: dts: imx6qdl-icore: Add FEC support
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 2 +
arch/arm/boot/dts/imx6dl-icore.dts | 59 +++++
arch/arm/boot/dts/imx6q-icore.dts | 59 +++++
arch/arm/boot/dts/imx6qdl-icore.dtsi | 271 +++++++++++++++++++++
5 files changed, 392 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-icore.dts
create mode 100644 arch/arm/boot/dts/imx6q-icore.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-icore.dtsi
--
2.7.4
^ permalink raw reply
* [PATCH v6 1/6] of: Add vendor prefix for Engicam s.r.l company
From: Jagan Teki @ 2016-09-26 19:25 UTC (permalink / raw)
To: linux-arm-kernel
From: Jagan Teki <jagan@amarulasolutions.com>
Engicam providing design services of electronic systems with
high content of technology, relying on a long experience in
electronic design.
For more info visit
http://www.engicam.com/en/
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v6:
- Added Acked-by: tag
Changes for v5:
- none
Changes for v4:
- new patch
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 3003f33..327e4c7 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -85,6 +85,7 @@ elan Elan Microelectronic Corp.
embest Shenzhen Embest Technology Co., Ltd.
emmicro EM Microelectronic
energymicro Silicon Laboratories (formerly Energy Micro AS)
+engicam Engicam S.r.l.
epcos EPCOS AG
epfl Ecole Polytechnique F?d?rale de Lausanne
epson Seiko Epson Corp.
--
2.7.4
^ permalink raw reply related
* [PATCH v6 2/6] ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
From: Jagan Teki @ 2016-09-26 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474917937-29336-1-git-send-email-jteki@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
i.CoreM6 Quad/Dual modules are system on module solutions manufactured
by Engicam with following characteristics:
CPU NXP i.MX6 DQ, 800MHz
RAM 1GB, 32, 64 bit, DDR3-800/1066
NAND SLC,512MB
Power supply Single 5V
MAX LCD RES FULLHD
and more info at
http://www.engicam.com/en/products/embedded/som/sodimm/i-core-m6s-dl-d-q
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v6:
- none
Changes for v5:
- removed fsl,legacy-bch-geometry property from gpmi node
Changes for v4:
- new patch
Changes for v3:
- Use compatible as engicam,imx6-icore instead of fsl,imx6-icore
- Update IOMUX value for can1 and can2 nodes
- Added reg_3p3v for can1 and can2 nodes
Changes for v2:
- s/oaky/okay/g
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6q-icore.dts | 59 +++++++++++
arch/arm/boot/dts/imx6qdl-icore.dtsi | 196 +++++++++++++++++++++++++++++++++++
3 files changed, 256 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6q-icore.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-icore.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f79cac2..511510d 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -374,6 +374,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6q-gw553x.dtb \
imx6q-h100.dtb \
imx6q-hummingboard.dtb \
+ imx6q-icore.dtb \
imx6q-icore-rqs.dtb \
imx6q-marsboard.dtb \
imx6q-nitrogen6x.dtb \
diff --git a/arch/arm/boot/dts/imx6q-icore.dts b/arch/arm/boot/dts/imx6q-icore.dts
new file mode 100644
index 0000000..025f543
--- /dev/null
+++ b/arch/arm/boot/dts/imx6q-icore.dts
@@ -0,0 +1,59 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6q.dtsi"
+#include "imx6qdl-icore.dtsi"
+
+/ {
+ model = "Engicam i.CoreM6 Quad/Dual Starter Kit";
+ compatible = "engicam,imx6-icore", "fsl,imx6q";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&can2 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
new file mode 100644
index 0000000..f424cd5
--- /dev/null
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -0,0 +1,196 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+ memory {
+ reg = <0x10000000 0x80000000>;
+ };
+
+ reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ xceiver-supply = <®_3p3v>;
+};
+
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ xceiver-supply = <®_3p3v>;
+};
+
+&clks {
+ assigned-clocks = <&clks IMX6QDL_CLK_LVDS2_SEL>;
+ assigned-clock-parents = <&clks IMX6QDL_CLK_OSC>;
+};
+
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ nand-on-flash-bbt;
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x1b020
+ MX6QDL_PAD_KEY_COL2__FLEXCAN1_TX 0x1b020
+ >;
+ };
+
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL4__FLEXCAN2_TX 0x1b020
+ MX6QDL_PAD_KEY_ROW4__FLEXCAN2_RX 0x1b020
+ >;
+ };
+
+ pinctrl_gpmi_nand: gpmi-nand {
+ fsl,pins = <
+ MX6QDL_PAD_NANDF_CLE__NAND_CLE 0xb0b1
+ MX6QDL_PAD_NANDF_ALE__NAND_ALE 0xb0b1
+ MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0xb0b1
+ MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0xb000
+ MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0xb0b1
+ MX6QDL_PAD_NANDF_CS1__NAND_CE1_B 0xb0b1
+ MX6QDL_PAD_SD4_CMD__NAND_RE_B 0xb0b1
+ MX6QDL_PAD_SD4_CLK__NAND_WE_B 0xb0b1
+ MX6QDL_PAD_NANDF_D0__NAND_DATA00 0xb0b1
+ MX6QDL_PAD_NANDF_D1__NAND_DATA01 0xb0b1
+ MX6QDL_PAD_NANDF_D2__NAND_DATA02 0xb0b1
+ MX6QDL_PAD_NANDF_D3__NAND_DATA03 0xb0b1
+ MX6QDL_PAD_NANDF_D4__NAND_DATA04 0xb0b1
+ MX6QDL_PAD_NANDF_D5__NAND_DATA05 0xb0b1
+ MX6QDL_PAD_NANDF_D6__NAND_DATA06 0xb0b1
+ MX6QDL_PAD_NANDF_D7__NAND_DATA07 0xb0b1
+ MX6QDL_PAD_SD4_DAT0__NAND_DQS 0x00b1
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_D21__I2C1_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D28__I2C1_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_EB2__I2C2_SCL 0x4001b8b1
+ MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D18__I2C3_SDA 0x4001b8b1
+ MX6QDL_PAD_GPIO_0__CCM_CLKO1 0x130b0
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
+ MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17070
+ MX6QDL_PAD_SD1_CLK__SD1_CLK 0x10070
+ MX6QDL_PAD_SD1_DAT0__SD1_DATA0 0x17070
+ MX6QDL_PAD_SD1_DAT1__SD1_DATA1 0x17070
+ MX6QDL_PAD_SD1_DAT2__SD1_DATA2 0x17070
+ MX6QDL_PAD_SD1_DAT3__SD1_DATA3 0x17070
+ >;
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v6 3/6] ARM: dts: imx6q: Add Engicam i.CoreM6 DualLite/Solo initial support
From: Jagan Teki @ 2016-09-26 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474917937-29336-1-git-send-email-jteki@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
i.CoreM6 DualLite/Solo modules are system on module solutions manufactured
by Engicam with following characteristics:
CPU NXP i.MX6 DL, 800MHz
RAM 1GB, 32, 64 bit, DDR3-800/1066
NAND SLC,512MB
Power supply Single 5V
MAX LCD RES FULLHD
and more info at
http://www.engicam.com/en/products/embedded/som/sodimm/i-core-m6s-dl-d-q
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v6:
- none
Changes for v5:
- none
Changes for v4:
- new patch
Changes for v3:
- Use compatible as engicam,imx6-icore instead of fsl,imx6-icore
Changes for v2:
- s/oaky/okay/g
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6dl-icore.dts | 59 ++++++++++++++++++++++++++++++++++++++
2 files changed, 60 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6dl-icore.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 511510d..6175f44 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -333,6 +333,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
imx6dl-gw552x.dtb \
imx6dl-gw553x.dtb \
imx6dl-hummingboard.dtb \
+ imx6dl-icore.dtb \
imx6dl-nit6xlite.dtb \
imx6dl-nitrogen6x.dtb \
imx6dl-phytec-pbab01.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-icore.dts b/arch/arm/boot/dts/imx6dl-icore.dts
new file mode 100644
index 0000000..aec332c
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-icore.dts
@@ -0,0 +1,59 @@
+/*
+ * Copyright (C) 2016 Amarula Solutions B.V.
+ * Copyright (C) 2016 Engicam S.r.l.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file is distributed in the hope that it will be useful
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-icore.dtsi"
+
+/ {
+ model = "Engicam i.CoreM6 DualLite/Solo Starter Kit";
+ compatible = "engicam,imx6-icore", "fsl,imx6dl";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&can2 {
+ status = "okay";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v6 4/6] ARM: dts: imx6qdl-icore: Add usbhost support
From: Jagan Teki @ 2016-09-26 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474917937-29336-1-git-send-email-jteki@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
Add usbhost support for Engicam i.CoreM6 dql modules.
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v6:
- none
Changes for v5:
- none
Changes for v4:
- new patch
arch/arm/boot/dts/imx6qdl-icore.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
index f424cd5..ffec879 100644
--- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -56,6 +56,15 @@
regulator-boot-on;
regulator-always-on;
};
+
+ reg_usb_h1_vbus: usb_h1_vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_h1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
};
&can1 {
@@ -109,6 +118,12 @@
status = "okay";
};
+&usbh1 {
+ vbus-supply = <®_usb_h1_vbus>;
+ disable-over-current;
+ status = "okay";
+};
+
&usdhc1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc1>;
--
2.7.4
^ permalink raw reply related
* [PATCH v6 5/6] ARM: dts: imx6qdl-icore: Add usbotg support
From: Jagan Teki @ 2016-09-26 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474917937-29336-1-git-send-email-jteki@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
Add usbotg support for Engicam i.CoreM6 dql modules.
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v6:
- none
Changes for v5:
- none
Changes for v4:
- new patch
arch/arm/boot/dts/imx6qdl-icore.dtsi | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
index ffec879..4e79858 100644
--- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -65,6 +65,15 @@
regulator-boot-on;
regulator-always-on;
};
+
+ reg_usb_otg_vbus: usb_otg_vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
};
&can1 {
@@ -124,6 +133,14 @@
status = "okay";
};
+&usbotg {
+ vbus-supply = <®_usb_otg_vbus>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg>;
+ disable-over-current;
+ status = "okay";
+};
+
&usdhc1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usdhc1>;
@@ -198,6 +215,12 @@
>;
};
+ pinctrl_usbotg: usbotggrp {
+ fsl,pins = <
+ MX6QDL_PAD_GPIO_1__USB_OTG_ID 0x17059
+ >;
+ };
+
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <
MX6QDL_PAD_SD1_CMD__SD1_CMD 0x17070
--
2.7.4
^ permalink raw reply related
* [PATCH v6 6/6] ARM: dts: imx6qdl-icore: Add FEC support
From: Jagan Teki @ 2016-09-26 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474917937-29336-1-git-send-email-jteki@openedev.com>
From: Jagan Teki <jagan@amarulasolutions.com>
Add FEC support for Engicam i.CoreM6 dql modules.
Observed similar 'eth0: link is not ready' issue which was
discussed in [1] due rmii mode with external ref_clk, so added
clock node along with the properties mentioned by Shawn in [2]
FEC link log:
------------
$ ifconfig eth0 up
[ 27.905187] SMSC LAN8710/LAN8720 2188000.ethernet:00: attached PHY driver
[SMSC LAN8710/LAN8720] (mii_bus:phy_addr=2188000.ethernet:00, irq=-1)
[ 27.918982] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[1] https://patchwork.kernel.org/patch/3491061/
[2] https://patchwork.kernel.org/patch/3490511/
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Matteo Lisi <matteo.lisi@engicam.com>
Cc: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v6:
- none
Changes for v5:
- new patch
arch/arm/boot/dts/imx6qdl-icore.dtsi | 37 ++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
index 4e79858..972f48f 100644
--- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
@@ -48,6 +48,18 @@
reg = <0x10000000 0x80000000>;
};
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rmii_clk: clock at 0 {
+ compatible = "fixed-clock";
+ reg = <0>;
+ #clock-cells = <0>;
+ clock-frequency = <25000000>; /* 25MHz for example */
+ };
+ };
+
reg_3p3v: regulator-3p3v {
compatible = "regulator-fixed";
regulator-name = "3P3V";
@@ -93,6 +105,15 @@
assigned-clock-parents = <&clks IMX6QDL_CLK_OSC>;
};
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet>;
+ phy-reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ clocks = <&clks 117>, <&clks 117>, <&rmii_clk>;
+ phy-mode = "rmii";
+ status = "okay";
+};
+
&gpmi {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gpmi_nand>;
@@ -150,6 +171,22 @@
};
&iomuxc {
+ pinctrl_enet: enetgrp {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0
+ MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x1b0b1
+ MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
+ MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0
+ MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_ENET_REF_CLK__GPIO1_IO23 0x1b0b0
+ MX6QDL_PAD_GPIO_17__GPIO7_IO12 0x1b0b0
+ >;
+ };
+
pinctrl_flexcan1: flexcan1grp {
fsl,pins = <
MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x1b020
--
2.7.4
^ permalink raw reply related
* [PATCH 0/4] kill get_clock_tick_rate()
From: Robert Jarzmik @ 2016-09-26 19:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474312335-20997-1-git-send-email-robert.jarzmik@free.fr>
Robert Jarzmik <robert.jarzmik@free.fr> writes:
> Hi,
>
> This serie aims at killing get_clock_tick_rate() from pxa and sa1100 and replace
> it by clock API calls.
>
> I'd like to have this reviewed and acked afterwards at least by :
> - Russell for the mach-sa1100 and sa1100_wdt.c
> - Stephen or Michael for the clk-pxa25x.c
> - Thomas or Daniel for the clocksource part
> - Wim for sa1100_wdt.c
>
> If the review converges, I'd also like to take it through the pxa/for-next tree,
> or alternatively Russell's tree if there is a dependency I'm not seeing, for
> v4.10 cycle.
Hi Russell,
Would you have time within the next 2 weeks to give this serie a review and
maybe an Ack from the sa1100 impacted parts (that would be patches 2, 3 and 4) ?
I can also resend the serie if it's easier in your workflow.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH] ARM: dts: socfpga: enable arm,shared-override in the pl310
From: dinguyen at opensource.altera.com @ 2016-09-26 19:34 UTC (permalink / raw)
To: linux-arm-kernel
From: Dinh Nguyen <dinguyen@opensource.altera.com>
Enable the bit(22) shared-override bit for the SoCFPGA family. While at it,
enable the prefetch-data and prefetch-instr settings for the Arria10.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
arch/arm/boot/dts/socfpga.dtsi | 1 +
arch/arm/boot/dts/socfpga_arria10.dtsi | 3 +++
2 files changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 9f48141..28ff6e4 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -686,6 +686,7 @@
arm,data-latency = <2 1 1>;
prefetch-data = <1>;
prefetch-instr = <1>;
+ arm,shared-override;
};
mmc: dwmmc0 at ff704000 {
diff --git a/arch/arm/boot/dts/socfpga_arria10.dtsi b/arch/arm/boot/dts/socfpga_arria10.dtsi
index 94000cb..16fcb9f 100644
--- a/arch/arm/boot/dts/socfpga_arria10.dtsi
+++ b/arch/arm/boot/dts/socfpga_arria10.dtsi
@@ -573,6 +573,9 @@
interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
cache-unified;
cache-level = <2>;
+ prefetch-data = <1>;
+ prefetch-instr = <1>;
+ arm,shared-override;
};
mmc: dwmmc0 at ff808000 {
--
1.7.9.5
^ permalink raw reply related
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