* [PATCH 17/18] arm64: dts: r8a7795: Add device node for PRR
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 681f54422375..a39a702b904d 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -321,6 +321,11 @@
#power-domain-cells = <0>;
};
+ prr: chipid at fff00044 {
+ compatible = "renesas,prr";
+ reg = <0 0xfff00044 0 4>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7795-sysc";
reg = <0 0xe6180000 0 0x0400>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 18/18] arm64: dts: r8a7796: Add device node for PRR
From: Simon Horman @ 2016-11-21 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1479726397.git.horms+renesas@verge.net.au>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 9599f5691099..41a050d2f192 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -243,6 +243,11 @@
#power-domain-cells = <0>;
};
+ prr: chipid at fff00044 {
+ compatible = "renesas,prr";
+ reg = <0 0xfff00044 0 4>;
+ };
+
sysc: system-controller at e6180000 {
compatible = "renesas,r8a7796-sysc";
reg = <0 0xe6180000 0 0x0400>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [BUG] i2c-designware silently fails on long transfers
From: Robin Murphy @ 2016-11-21 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121104329.GB1041@n2100.armlinux.org.uk>
On 21/11/16 10:43, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 12:29:01PM +0200, Mika Westerberg wrote:
>> On Fri, Nov 18, 2016 at 07:35:42PM +0000, Russell King - ARM Linux wrote:
>>> Another mitigation would be to lower the I2C bus frequency on Juno from
>>> 400kHz to 100kHz, so that there's 4x longer IRQ latency possible.
>>> However, even that isn't going to be reliable - even going to 100kHz
>>> isn't going to allow the above case to be solved - the interrupt is
>>> delayed by around 2ms, and it takes about 1.4ms to send/receive 16 bytes
>>> at 100kHz. (9 * 16 / (100*10^3)).
>>>
>>> So, I think all hope is lost for i2c-designware on Juno to cope with
>>> reading the EDID from TDA998x reliably.
>>
>> :-(
>>
>> I wonder if we can get it work more reliably by using DMA (provided that
>> there are DMA channels available for I2C in Juno)? That would allow the
>> hardware to perform longer reads without relying on how fast the
>> interrupt handler is able to empty the Rx FIFO.
>
> It would need to DMA to the Tx FIFO to keep it filled - it triggers the
> stop condition when the Tx FIFO empties. From what I can see in the
> driver, the Tx FIFO not only takes the data but also a "command" to tell
> the hardware what to do.
>
> The Rx FIFO would also need DMA to avoid it overflowing due to high
> interrupt latency.
>
> I don't know what state DMA is in on the Juno, or even whether it has
> DMA - it has a PL330 DMA controller, but I see nothing in the DT files
> making use of it.
There's no DMA request wired up for I2C, unfortunately - only for the
UARTs, I2S, FPFGA tile and trace unit. I recall Liviu did have a patch
to lower the I2C clock as the mitigation you mention, which I thought
had made it into mainline, but apparently not.
Robin.
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Russell King - ARM Linux @ 2016-11-21 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121113212.GF1005@e106497-lin.cambridge.arm.com>
On Mon, Nov 21, 2016 at 11:32:12AM +0000, Liviu Dudau wrote:
> On Mon, Nov 21, 2016 at 11:20:30AM +0000, Russell King - ARM Linux wrote:
> > I first noticed it when booting with the buggy I2C EDID reading, so
> > DRM wasn't seeing a valid EDID. Then when Xorg started up and shut
> > down, I noticed that the framebuffer console was shifted. It's actually
> > shifted to the left because framebuffer pixel 0,0 is not displayed.
>
> I see. So the reason why I did not notice this was the EDID transfers
> mostly working for me.
It also happens when EDID transfers work too!
> > > > Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> > > > and repeated disable/enable cycles do not make the issue re-appear.
> > >
> > > Do you resize the display mode as well afer re-enabling HDLCD?
> >
> > I quite literally just did:
> >
> > ./devmem2 0x7ff60230 w 0; ./devmem2 0x7ff60230 w 1
>
> Sorry, was not very clear. Under my assumption that you were resizing the
> display with xrandr, I was wondering if the issue you were seeing disappeared
> when using devmem2 plus the resizing.
I think the problems are much deeper. I've added this:
static void hdlcd_crtc_enable(struct drm_crtc *crtc)
{
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
printk("%s: active %d cmd %08x\n", __func__, crtc->state->active, hdlcd_read(hdlcd, HDLCD_REG_COMMAND));
clk_prepare_enable(hdlcd->clk);
...
static void hdlcd_crtc_disable(struct drm_crtc *crtc)
{
struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
printk("%s: active %d\n", __func__, crtc->state->active);
if (!crtc->state->active)
return;
What I see in the kernel log each time I change the resolution is:
[ 221.409577] hdlcd_crtc_disable: active 0
[ 221.430206] hdlcd_crtc_enable: active 1 cmd 00000001
[ 239.264672] hdlcd_crtc_disable: active 0
[ 239.285180] hdlcd_crtc_enable: active 1 cmd 00000001
[ 278.712792] hdlcd_crtc_disable: active 0
[ 278.730361] hdlcd_crtc_enable: active 1 cmd 00000001
[ 281.633841] hdlcd_crtc_disable: active 0
[ 281.668578] hdlcd_crtc_enable: active 1 cmd 00000001
So, when ->disable is called, active is always zero. This
leads to...
$ head -n3 /sys/kernel/debug/clk/clk_summary
clock enable_cnt prepare_cnt rate accuracy
phase
----------------------------------------------------------------------------------------
pxlclk 6 6 148500000 0 0
the enable and prepare counts for this clock incrementing by one each
time I change the resolution.
> > Maybe hdlcd shouldn't be implementing the ->enable callback but instead
> > the ->commit callback then?
>
> I believe we need ->enable for the initial setup (cold boot or module
> reloading).
Yes, I found a comment in DRM saying that ->commit is for legacy drivers
only.
I think the problem is that hdlcd is not really knowing what the true
state of the CRTC is, as illustrated by the clock counts increasing
and the state of crtc->state->active.
I'm wondering if this is a core DRM bug though... the comments and
code do not align:
/**
* drm_atomic_helper_commit_tail - commit atomic update to hardware
* @state: new modeset state to be committed
void drm_atomic_helper_commit_tail(struct drm_atomic_state *state)
{
struct drm_device *dev = state->dev;
drm_atomic_helper_commit_modeset_disables(dev, state);
/**
* drm_atomic_helper_commit_modeset_disables - modeset commit to disable outputs * @dev: DRM device
* @old_state: atomic state object with old state structures
void drm_atomic_helper_commit_modeset_disables(struct drm_device *dev,
struct drm_atomic_state *old_state)
So, is "state" in drm_atomic_helper_commit_tail the old state or the
new state? Should this state be passed to
drm_atomic_helper_commit_modeset_disables(), which seems to expect
the old state?
It looks _really_ screwed up here - in any case, it really doesn't
help when you're not experienced with atomic mode set to work out
what the hell this code is doing... it seems to be a horrible mess.
Maybe someone who understands this code ought to read through it
from the point of view of someone who doesn't understand it and fix
the comments, or get rid of the down-right misleading comments.
Comments are worse than useless if they mislead. Better to have no
comments than misleading comments.
Daniel?
--
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] PM / Domains: Fix compatible for domain idle state
From: Brendan Jackman @ 2016-11-21 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478210075-92045-2-git-send-email-lina.iyer@linaro.org>
Hi,
On Thu, Nov 03 2016 at 21:54, Lina Iyer <lina.iyer@linaro.org> wrote:
> Re-using idle state definition provided by arm,idle-state for domain
> idle states creates a lot of confusion and limits further evolution of
> the domain idle definition. To keep things clear and simple, define a
> idle states for domain using a new compatible "domain-idle-state".
>
> Fix existing PM domains code to look for the newly defined compatible.
This looks good to me, pinging for review from others/queue for merge.
Best,
Brendan
>
> Cc: <devicetree@vger.kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
> ---
> .../bindings/power/domain-idle-state.txt | 33 ++++++++++++++++++++++
> .../devicetree/bindings/power/power_domain.txt | 8 +++---
> drivers/base/power/domain.c | 2 +-
> 3 files changed, 38 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt
>
> diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.txt b/Documentation/devicetree/bindings/power/domain-idle-state.txt
> new file mode 100644
> index 0000000..eefc7ed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/domain-idle-state.txt
> @@ -0,0 +1,33 @@
> +PM Domain Idle State Node:
> +
> +A domain idle state node represents the state parameters that will be used to
> +select the state when there are no active components in the domain.
> +
> +The state node has the following parameters -
> +
> +- compatible:
> + Usage: Required
> + Value type: <string>
> + Definition: Must be "domain-idle-state".
> +
> +- entry-latency-us
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing worst case latency in
> + microseconds required to enter the idle state.
> + The exit-latency-us duration may be guaranteed
> + only after entry-latency-us has passed.
> +
> +- exit-latency-us
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing worst case latency
> + in microseconds required to exit the idle state.
> +
> +- min-residency-us
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing minimum residency duration
> + in microseconds after which the idle state will yield
> + power benefits after overcoming the overhead in entering
> +i the idle state.
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index e165036..723e1ad 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -31,7 +31,7 @@ Optional properties:
>
> - domain-idle-states : A phandle of an idle-state that shall be soaked into a
> generic domain power state. The idle state definitions are
> - compatible with arm,idle-state specified in [1].
> + compatible with domain-idle-state specified in [1].
> The domain-idle-state property reflects the idle state of this PM domain and
> not the idle states of the devices or sub-domains in the PM domain. Devices
> and sub-domains have their own idle-states independent of the parent
> @@ -85,7 +85,7 @@ Example 3:
> };
>
> DOMAIN_RET: state at 0 {
> - compatible = "arm,idle-state";
> + compatible = "domain-idle-state";
> reg = <0x0>;
> entry-latency-us = <1000>;
> exit-latency-us = <2000>;
> @@ -93,7 +93,7 @@ Example 3:
> };
>
> DOMAIN_PWR_DN: state at 1 {
> - compatible = "arm,idle-state";
> + compatible = "domain-idle-state";
> reg = <0x1>;
> entry-latency-us = <5000>;
> exit-latency-us = <8000>;
> @@ -118,4 +118,4 @@ The node above defines a typical PM domain consumer device, which is located
> inside a PM domain with index 0 of a power controller represented by a node
> with the label "power".
>
> -[1]. Documentation/devicetree/bindings/arm/idle-states.txt
> +[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 661737c..f0bc672 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2048,7 +2048,7 @@ int genpd_dev_pm_attach(struct device *dev)
> EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
>
> static const struct of_device_id idle_state_match[] = {
> - { .compatible = "arm,idle-state", },
> + { .compatible = "domain-idle-state", },
> { }
> };
^ permalink raw reply
* [PATCH v4 1/6] arm64: arch_timer: Add device tree binding for hisilicon-161601 erratum
From: Ding Tianhong @ 2016-11-21 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479212167-5812-1-git-send-email-dingtianhong@huawei.com>
Ping....
On 2016/11/15 20:16, Ding Tianhong wrote:
> This erratum describes a bug in logic outside the core, so MIDR can't be
> used to identify its presence, and reading an SoC-specific revision
> register from common arch timer code would be awkward. So, describe it
> in the device tree.
>
> v2: Use the new erratum name and update the description.
>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
> index ef5fbe9..c27b2c4 100644
> --- a/Documentation/devicetree/bindings/arm/arch_timer.txt
> +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
> @@ -31,6 +31,14 @@ to deliver its interrupts via SPIs.
> This also affects writes to the tval register, due to the implicit
> counter read.
>
> +- hisilicon,erratum-161601 : A boolean property. Indicates the presence of
> + erratum 161601, which says that reading the counter is unreliable unless
> + reading twice on the register and the value of the second read is larger
> + than the first by less than 32. If the verification is unsuccessful, then
> + discard the value of this read and repeat this procedure until the verification
> + is successful. This also affects writes to the tval register, due to the
> + implicit counter read.
> +
> ** Optional properties:
>
> - arm,cpu-registers-not-fw-configured : Firmware does not initialize
>
^ permalink raw reply
* Synopsys Ethernet QoS Driver
From: Giuseppe CAVALLARO @ 2016-11-21 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1248f4ce-4859-10e6-fef9-342ea543f8d4@synopsys.com>
Hello Joao
On 11/21/2016 1:32 PM, Joao Pinto wrote:
> Hello,
>
> On 21-11-2016 05:29, Rayagond Kokatanur wrote:
>> On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent <rabin@rab.in> wrote:
>>> On Fri, Nov 18, 2016 at 02:20:27PM +0000, Joao Pinto wrote:
>>>> For now we are interesting in improving the synopsys QoS driver under
>>>> /nect/ethernet/synopsys. For now the driver structure consists of a single file
>>>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and platform
>>>> related stuff.
>>>>
>>>> Our strategy would be:
>>>>
>>>> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
>>>> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
>>>> c) Implement a "core driver" (dwc_eth_qos.c) that would only have Ethernet QoS
>>>> related stuff to be reused by the platform / pci drivers
>>>> d) Add a set of features to the "core driver" that we have available internally
>>>
>>> Note that there are actually two drivers in mainline for this hardware:
>>>
>>> drivers/net/ethernet/synopsis/
>>> drivers/net/ethernet/stmicro/stmmac/
>>
>> Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
>> both 3.x and 4.x. It has glue layer for pci, platform, core etc,
>> please refer this driver once before you start.
>>
>> You can start adding missing feature of 4.x in stmmac driver.
>
> Thanks you all for all the info.
> Well, I think we are in a good position to organize the ethernet drivers
> concerning Synopsys IPs.
>
> First of all, in my opinion, it does not make sense to have a ethernet/synopsis
> (typo :)) when ethernet/stmicro is also for a synopsys IP. If we have another
> vendor using the same IP it should be able to reuse the commonn operations. But
> I would put that discussion for later :)
>
> For now I suggest that for we create ethernet/qos and create there a folder
> called dwc (designware controller) where all the synopsys qos IP specific code
> in order to be reused for example by ethernet/stmicro/stmmac/. We just have to
> figure out a clean interface for "client drivers" like stmmac to interact with
> the new qos driver.
>
> What do you think about this approach?
The stmmac drivers run since many years on several platforms
(sh4, stm32, arm, x86, mips ...) and it supports an huge of amount of
configurations starting from 3.1x to 3.7x databooks.
It also supports QoS hardware; for example, 4.00a, 4.10a and 4.20a
are fully working.
Also the stmmac has platform, device-tree and pcie supports and
a lot of maintained glue-logic files.
It is fully documented inside the kernel tree.
I am happy to have new enhancements from other developers.
So, on my side, if you want to spend your time on improving it on your
platforms please feel free to do it!
Concerning the stmicro/stmmac naming, these come from a really old
story and have no issue to adopt new folder/file names.
I am also open to merge fixes and changes from ethernet/synopsis.
I want to point you on some benchmarks made by Alex some months ago
(IIRC) that showed an stmmac winner (due to the several optimizations
analyzed and reviewed in this mailing list).
Peppe
>
>
>>
>>>
>>> (See http://lists.openwall.net/netdev/2016/02/29/127)
>>>
>>> The former only supports 4.x of the hardware.
>>>
>>> The later supports 4.x and 3.x and already has a platform glue driver
>>> with support for several platforms, a PCI glue driver, and a core driver
>>> with several features not present in the former (for example: TX/RX
>>> interrupt coalescing, EEE, PTP).
>>>
>>> Have you evaluated both drivers? Why have you decided to work on the
>>> former rather than the latter?
>>
>>
>
> Thanks.
>
>
>
>
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Liviu Dudau @ 2016-11-21 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121122556.GE1041@n2100.armlinux.org.uk>
On Mon, Nov 21, 2016 at 12:25:56PM +0000, Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 11:32:12AM +0000, Liviu Dudau wrote:
> > On Mon, Nov 21, 2016 at 11:20:30AM +0000, Russell King - ARM Linux wrote:
> > > I first noticed it when booting with the buggy I2C EDID reading, so
> > > DRM wasn't seeing a valid EDID. Then when Xorg started up and shut
> > > down, I noticed that the framebuffer console was shifted. It's actually
> > > shifted to the left because framebuffer pixel 0,0 is not displayed.
> >
> > I see. So the reason why I did not notice this was the EDID transfers
> > mostly working for me.
>
> It also happens when EDID transfers work too!
>
> > > > > Using devmem2 to disable and re-enable the HDLCD resolves the issue,
> > > > > and repeated disable/enable cycles do not make the issue re-appear.
> > > >
> > > > Do you resize the display mode as well afer re-enabling HDLCD?
> > >
> > > I quite literally just did:
> > >
> > > ./devmem2 0x7ff60230 w 0; ./devmem2 0x7ff60230 w 1
> >
> > Sorry, was not very clear. Under my assumption that you were resizing the
> > display with xrandr, I was wondering if the issue you were seeing disappeared
> > when using devmem2 plus the resizing.
>
> I think the problems are much deeper. I've added this:
>
> static void hdlcd_crtc_enable(struct drm_crtc *crtc)
> {
> struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> printk("%s: active %d cmd %08x\n", __func__, crtc->state->active, hdlcd_read(hdlcd, HDLCD_REG_COMMAND));
> clk_prepare_enable(hdlcd->clk);
>
> ...
> static void hdlcd_crtc_disable(struct drm_crtc *crtc)
> {
> struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> printk("%s: active %d\n", __func__, crtc->state->active);
> if (!crtc->state->active)
> return;
>
> What I see in the kernel log each time I change the resolution is:
>
> [ 221.409577] hdlcd_crtc_disable: active 0
> [ 221.430206] hdlcd_crtc_enable: active 1 cmd 00000001
> [ 239.264672] hdlcd_crtc_disable: active 0
> [ 239.285180] hdlcd_crtc_enable: active 1 cmd 00000001
> [ 278.712792] hdlcd_crtc_disable: active 0
> [ 278.730361] hdlcd_crtc_enable: active 1 cmd 00000001
> [ 281.633841] hdlcd_crtc_disable: active 0
> [ 281.668578] hdlcd_crtc_enable: active 1 cmd 00000001
>
> So, when ->disable is called, active is always zero.
That is expected, the DRM framework will determine that the crtc is no longer active and
call ->disable hook on the CRTC helper struct.
> This leads to...
>
> $ head -n3 /sys/kernel/debug/clk/clk_summary
> clock enable_cnt prepare_cnt rate accuracy
> phase
> ----------------------------------------------------------------------------------------
> pxlclk 6 6 148500000 0 0
>
> the enable and prepare counts for this clock incrementing by one each
> time I change the resolution.
That is mostly due to the check in hdlcd_crtc_disable() which I should remove,
I've added it because I was getting a ->disable() hook call before any ->enable()
was called at startup time. I need to revisit this as I remember Daniel was commenting
that this was not needed.
>
> > > Maybe hdlcd shouldn't be implementing the ->enable callback but instead
> > > the ->commit callback then?
> >
> > I believe we need ->enable for the initial setup (cold boot or module
> > reloading).
>
> Yes, I found a comment in DRM saying that ->commit is for legacy drivers
> only.
>
> I think the problem is that hdlcd is not really knowing what the true
> state of the CRTC is, as illustrated by the clock counts increasing
> and the state of crtc->state->active.
I think crtc->state->active is correct, we are just not acting as we should
in HDLCD.
>
> I'm wondering if this is a core DRM bug though... the comments and
> code do not align:
>
> /**
> * drm_atomic_helper_commit_tail - commit atomic update to hardware
> * @state: new modeset state to be committed
>
> void drm_atomic_helper_commit_tail(struct drm_atomic_state *state)
> {
> struct drm_device *dev = state->dev;
>
> drm_atomic_helper_commit_modeset_disables(dev, state);
>
> /**
> * drm_atomic_helper_commit_modeset_disables - modeset commit to disable outputs * @dev: DRM device
> * @old_state: atomic state object with old state structures
> void drm_atomic_helper_commit_modeset_disables(struct drm_device *dev,
> struct drm_atomic_state *old_state)
>
> So, is "state" in drm_atomic_helper_commit_tail the old state or the
> new state? Should this state be passed to
> drm_atomic_helper_commit_modeset_disables(), which seems to expect
> the old state?
Yes, you have reached one (of the many?) DRM quirks. When drm_atomic_helper_commit_tail()
gets called the *state pointer contains the old state that was swapped
out by drm_atomic_helper_commit() function before calling commit_tail().
The comment on drm_atomic_helper_commit_tail function (and maybe parameter name)
should be updated.
>
> It looks _really_ screwed up here - in any case, it really doesn't
> help when you're not experienced with atomic mode set to work out
> what the hell this code is doing... it seems to be a horrible mess.
> Maybe someone who understands this code ought to read through it
> from the point of view of someone who doesn't understand it and fix
> the comments, or get rid of the down-right misleading comments.
>
> Comments are worse than useless if they mislead. Better to have no
> comments than misleading comments.
Sometimes code gets shuffled around and functions that made sense in
one workflow are kept in the new workflow except their order gets changed.
I believe that was the case for the function above.
Best regards,
Liviu
>
> Daniel?
>
> --
> 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.
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH V5 1/3] ARM64 LPC: Indirect ISA port IO introduced
From: John Garry @ 2016-11-21 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478647002.7430.69.camel@kernel.crashing.org>
On 08/11/2016 23:16, Benjamin Herrenschmidt wrote:
> On Tue, 2016-11-08 at 12:03 +0000, Mark Rutland wrote:
>> On Tue, Nov 08, 2016 at 11:47:07AM +0800, zhichang.yuan wrote:
>>>
>>> For arm64, there is no I/O space as other architectural platforms, such as
>>> X86. Most I/O accesses are achieved based on MMIO. But for some arm64 SoCs,
>>> such as Hip06, when accessing some legacy ISA devices connected to LPC, those
>>> known port addresses are used to control the corresponding target devices, for
>>> example, 0x2f8 is for UART, 0xe4 is for ipmi-bt. It is different from the
>>> normal MMIO mode in using.
>>
>> This has nothing to do with arm64. Hardware with this kind of indirect
>> bus access could be integrated with a variety of CPU architectures. It
>> simply hasn't been, yet.
>
> On some ppc's we also use similar indirect access methods for IOs. We
> have a generic infrastructure for re-routing some memory or IO regions
> to hooks.
>
> On POWER8, our PCIe doesn't do IO at all, but we have an LPC bus behind
> firmware calls ;-) We use that infrastructure to plumb in the LPC bus.
>
Hi,
I would like to mention another topic on supporting LPC, and this is
regard to eSPI support.
eSPI is seen as the successor for LPC, and some BMCs already support it.
I had a chat with Arnd on this, and the idea to model LPC as a SPI bus
adpater (and also eSPI).
However it seems to me that most platforms will/should support eSPI as a
transparent bridge, same as LPC on x86. So I don't think that this is
much point in modelling LPC/eSPI as a bus.
So we shall continue with indriect-IO support...
Thanks,
John
^ permalink raw reply
* [GIT PULL] Allwinner late DT changes for 4.10
From: Maxime Ripard @ 2016-11-21 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161119002733.GA15902@localhost>
On Fri, Nov 18, 2016 at 04:27:33PM -0800, Olof Johansson wrote:
> On Tue, Nov 15, 2016 at 10:00:34PM +0100, Maxime Ripard wrote:
> > Hi Arnd, Olof,
> >
> > Here is a pull request that should be merged after the pinctrl PR,
> > hence probably in your late PR.
> >
> > This is just a mechanic conversion to the generic pinconf bindings and
> > removal of the useless pinmux properties we had.
> >
> > This is based on the previous DT PR I just sent.
> >
> > Thanks!
> > Maxime
> >
> > The following changes since commit e39a30cf736144814b0bddb3fff28fbbc2a8be0f:
> >
> > ARM: sunxi: Add the missing clocks to the pinctrl nodes (2016-11-15 18:49:47 +0100)
> >
> > are available in the git repository at:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-dt-late-for-4.10
> >
> > for you to fetch changes up to 1d20ba07ea57ae227a925302b42221df5b830f2b:
> >
> > ARM: sunxi: Convert pinctrl nodes to generic bindings (2016-11-15 21:56:30 +0100)
>
> Nice cleanup!
>
> Unfortuantely, see comment on previous pull request, so this would need
> to be rebased.
>
> Also, this won't work since this branch does not contain the required
> pinctrl changes. If we merge this without basing it on those changes we lose
> bisectability.
>
> It'd be easiest if you just held off on these until right after 4.10-rc1, and
> we could get them in before -rc2.
That works for me. I'll respin it as soon as rc1 is out.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161121/e2a43eee/attachment.sig>
^ permalink raw reply
* [PATCH v2 5/8] dt-bindings: mfd: Provide human readable defines for TPS65217 interrupts
From: Milo Kim @ 2016-11-21 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118151051.GV4082@atomide.com>
On 11/19/2016 12:10 AM, Tony Lindgren wrote:
>>> +#define TPS65217_IRQ_USB 0
>>> > > +#define TPS65217_IRQ_AC 1
>>> > > +#define TPS65217_IRQ_PB 2
>> >
>> > What are "AC" and "PB". Seeing as these are meant to be "human
>> > readable", let's make them more human friendly.
> Good idea. Milo, please do an incremental single follow-up patch as
> I already have applied this and the dts changes using it.
Thanks for catching this. Let me send a patch soon.
Best regards,
Milo
^ permalink raw reply
* [PATCH] clk: sunxi-ng: sun6i-a31: Enable PLL-MIPI LDOs when ungating it
From: Maxime Ripard @ 2016-11-21 13:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118071557.30195-1-wens@csie.org>
On Fri, Nov 18, 2016 at 03:15:57PM +0800, Chen-Yu Tsai wrote:
> The PLL-MIPI clock is somewhat special as it has its own LDOs which
> need to be turned on for this PLL to actually work and output a clock
> signal.
>
> Add the 2 LDO enable bits to the gate bits. This fixes issues with
> the TCON not sending vblank interrupts when the tcon and dot clock are
> indirectly clocked from the PLL-MIPI clock.
>
> Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161121/9c40b2a4/attachment.sig>
^ permalink raw reply
* [PATCH] PM / Domains: Fix compatible for domain idle state
From: Rafael J. Wysocki @ 2016-11-21 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zikt6mc1.fsf@arm.com>
On Mon, Nov 21, 2016 at 1:37 PM, Brendan Jackman
<brendan.jackman@arm.com> wrote:
> Hi,
>
> On Thu, Nov 03 2016 at 21:54, Lina Iyer <lina.iyer@linaro.org> wrote:
>> Re-using idle state definition provided by arm,idle-state for domain
>> idle states creates a lot of confusion and limits further evolution of
>> the domain idle definition. To keep things clear and simple, define a
>> idle states for domain using a new compatible "domain-idle-state".
>>
>> Fix existing PM domains code to look for the newly defined compatible.
>
> This looks good to me, pinging for review from others/queue for merge.
Well, I need an ACK from at least one DT bindings maintainer so that I
can queue it up.
>> Cc: <devicetree@vger.kernel.org>
>> Cc: Rob Herring <robh@kernel.org>
>> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
>> ---
>> .../bindings/power/domain-idle-state.txt | 33 ++++++++++++++++++++++
>> .../devicetree/bindings/power/power_domain.txt | 8 +++---
>> drivers/base/power/domain.c | 2 +-
>> 3 files changed, 38 insertions(+), 5 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt
>>
>> diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.txt b/Documentation/devicetree/bindings/power/domain-idle-state.txt
>> new file mode 100644
>> index 0000000..eefc7ed
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power/domain-idle-state.txt
>> @@ -0,0 +1,33 @@
>> +PM Domain Idle State Node:
>> +
>> +A domain idle state node represents the state parameters that will be used to
>> +select the state when there are no active components in the domain.
>> +
>> +The state node has the following parameters -
>> +
>> +- compatible:
>> + Usage: Required
>> + Value type: <string>
>> + Definition: Must be "domain-idle-state".
>> +
>> +- entry-latency-us
>> + Usage: Required
>> + Value type: <prop-encoded-array>
>> + Definition: u32 value representing worst case latency in
>> + microseconds required to enter the idle state.
>> + The exit-latency-us duration may be guaranteed
>> + only after entry-latency-us has passed.
>> +
>> +- exit-latency-us
>> + Usage: Required
>> + Value type: <prop-encoded-array>
>> + Definition: u32 value representing worst case latency
>> + in microseconds required to exit the idle state.
>> +
>> +- min-residency-us
>> + Usage: Required
>> + Value type: <prop-encoded-array>
>> + Definition: u32 value representing minimum residency duration
>> + in microseconds after which the idle state will yield
>> + power benefits after overcoming the overhead in entering
>> +i the idle state.
>> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
>> index e165036..723e1ad 100644
>> --- a/Documentation/devicetree/bindings/power/power_domain.txt
>> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
>> @@ -31,7 +31,7 @@ Optional properties:
>>
>> - domain-idle-states : A phandle of an idle-state that shall be soaked into a
>> generic domain power state. The idle state definitions are
>> - compatible with arm,idle-state specified in [1].
>> + compatible with domain-idle-state specified in [1].
>> The domain-idle-state property reflects the idle state of this PM domain and
>> not the idle states of the devices or sub-domains in the PM domain. Devices
>> and sub-domains have their own idle-states independent of the parent
>> @@ -85,7 +85,7 @@ Example 3:
>> };
>>
>> DOMAIN_RET: state at 0 {
>> - compatible = "arm,idle-state";
>> + compatible = "domain-idle-state";
>> reg = <0x0>;
>> entry-latency-us = <1000>;
>> exit-latency-us = <2000>;
>> @@ -93,7 +93,7 @@ Example 3:
>> };
>>
>> DOMAIN_PWR_DN: state at 1 {
>> - compatible = "arm,idle-state";
>> + compatible = "domain-idle-state";
>> reg = <0x1>;
>> entry-latency-us = <5000>;
>> exit-latency-us = <8000>;
>> @@ -118,4 +118,4 @@ The node above defines a typical PM domain consumer device, which is located
>> inside a PM domain with index 0 of a power controller represented by a node
>> with the label "power".
>>
>> -[1]. Documentation/devicetree/bindings/arm/idle-states.txt
>> +[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
>> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
>> index 661737c..f0bc672 100644
>> --- a/drivers/base/power/domain.c
>> +++ b/drivers/base/power/domain.c
>> @@ -2048,7 +2048,7 @@ int genpd_dev_pm_attach(struct device *dev)
>> EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
>>
>> static const struct of_device_id idle_state_match[] = {
>> - { .compatible = "arm,idle-state", },
>> + { .compatible = "domain-idle-state", },
>> { }
>> };
> --
Thanks,
Rafael
^ permalink raw reply
* [PATCH 16/18] arm64: dts: h3ulcb: rename SDHI0 pins
From: Sergei Shtylyov @ 2016-11-21 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <93373c309a703b57690216db4106a4a534929c15.1479726397.git.horms+renesas@verge.net.au>
Hello.
On 11/21/2016 03:05 PM, Simon Horman wrote:
> From: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
>
> This changes SDHI0 pin names for H3ULCB board
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> index 8d0ac076d8e2..6ffb0517421a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
> @@ -163,13 +163,13 @@
> function = "avb";
> };
>
> - sdhi0_pins_3v3: sd0_3v3 {
> + sdhi0_pins: sd0 {
> groups = "sdhi0_data4", "sdhi0_ctrl";
> function = "sdhi0";
> power-source = <3300>;
> };
>
> - sdhi0_pins_1v8: sd0_1v8 {
> + sdhi0_pins_uhs: sd0 {
I'm afraid the following will just override the props of the node above
which is not what we ant.
> groups = "sdhi0_data4", "sdhi0_ctrl";
> function = "sdhi0";
> power-source = <1800>;
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH] dt-bindings: mfd: Improve readability for TPS65217 interrupt sources
From: Milo Kim @ 2016-11-21 13:15 UTC (permalink / raw)
To: linux-arm-kernel
AC and USB interrupts are related with external power input.
PB interrupt means push button pressed or released event.
Use better human readable definitions.
Signed-off-by: Milo Kim <woogyom.kim@gmail.com>
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 4 ++--
include/dt-bindings/mfd/tps65217.h | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi b/arch/arm/boot/dts/am335x-bone-common.dtsi
index dc561d5..1848d58 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -319,13 +319,13 @@
ti,pmic-shutdown-controller;
charger {
- interrupts = <TPS65217_IRQ_AC>, <TPS65217_IRQ_USB>;
+ interrupts = <TPS65217_IRQ_AC_POWER>, <TPS65217_IRQ_USB_POWER>;
interrupts-names = "AC", "USB";
status = "okay";
};
pwrbutton {
- interrupts = <TPS65217_IRQ_PB>;
+ interrupts = <TPS65217_IRQ_PUSHBUTTON>;
status = "okay";
};
diff --git a/include/dt-bindings/mfd/tps65217.h b/include/dt-bindings/mfd/tps65217.h
index cafb9e6..0293fdd 100644
--- a/include/dt-bindings/mfd/tps65217.h
+++ b/include/dt-bindings/mfd/tps65217.h
@@ -19,8 +19,8 @@
#ifndef __DT_BINDINGS_TPS65217_H__
#define __DT_BINDINGS_TPS65217_H__
-#define TPS65217_IRQ_USB 0
-#define TPS65217_IRQ_AC 1
-#define TPS65217_IRQ_PB 2
+#define TPS65217_IRQ_USB_POWER 0 /* USB power state change */
+#define TPS65217_IRQ_AC_POWER 1 /* AC power state change */
+#define TPS65217_IRQ_PUSHBUTTON 2 /* Push button state change */
#endif
--
2.9.3
^ permalink raw reply related
* [PATCH 03/10] mfd: sun6i-prcm: Add codec analog controls sub-device for Allwinner A23
From: Lee Jones @ 2016-11-21 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161112064648.26779-4-wens@csie.org>
On Sat, 12 Nov 2016, Chen-Yu Tsai wrote:
> The PRCM block on the A23 contains a message box like interface to
> the registers for the analog path controls of the internal codec.
>
> Add a sub-device for it.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> drivers/mfd/sun6i-prcm.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/mfd/sun6i-prcm.c b/drivers/mfd/sun6i-prcm.c
> index 011fcc555945..4abbf2ede944 100644
> --- a/drivers/mfd/sun6i-prcm.c
> +++ b/drivers/mfd/sun6i-prcm.c
> @@ -12,6 +12,9 @@
> #include <linux/init.h>
> #include <linux/of.h>
>
> +#define SUN8I_CODEC_ANALOG_BASE 0x1c0
> +#define SUN8I_CODEC_ANALOG_END (SUN8I_CODEC_ANALOG_BASE + 0x4 - 1)
> +
> struct prcm_data {
> int nsubdevs;
> const struct mfd_cell *subdevs;
> @@ -57,6 +60,14 @@ static const struct resource sun6i_a31_apb0_rstc_res[] = {
> },
> };
>
> +static const struct resource sun8i_codec_analog_res[] = {
> + {
> + .start = SUN8I_CODEC_ANALOG_BASE,
> + .end = SUN8I_CODEC_ANALOG_END,
> + .flags = IORESOURCE_MEM,
> + },
> +};
Use the DEVICE_RES_* macros.
> static const struct mfd_cell sun6i_a31_prcm_subdevs[] = {
> {
> .name = "sun6i-a31-ar100-clk",
> @@ -109,6 +120,12 @@ static const struct mfd_cell sun8i_a23_prcm_subdevs[] = {
> .num_resources = ARRAY_SIZE(sun6i_a31_apb0_rstc_res),
> .resources = sun6i_a31_apb0_rstc_res,
> },
> + {
> + .name = "sun8i-codec-analog",
> + .of_compatible = "allwinner,sun8i-a23-codec-analog",
> + .num_resources = ARRAY_SIZE(sun8i_codec_analog_res),
> + .resources = sun8i_codec_analog_res,
> + },
> };
>
> static const struct prcm_data sun6i_a31_prcm_data = {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [BUG] hdlcd gets confused about base address
From: Russell King - ARM Linux @ 2016-11-21 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121125653.GJ1005@e106497-lin.cambridge.arm.com>
On Mon, Nov 21, 2016 at 12:56:53PM +0000, Liviu Dudau wrote:
> That is mostly due to the check in hdlcd_crtc_disable() which I should
> remove, I've added it because I was getting a ->disable() hook call
> before any ->enable() was called at startup time. I need to revisit
> this as I remember Daniel was commenting that this was not needed.
Removing that test results in:
[drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out
and the kernel hanging, seemingly in an IRQs-off region.
--
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 v8 6/7] arm/arm64: vgic: Implement VGICv3 CPU interface access
From: Vijay Kilari @ 2016-11-21 13:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121101930.GD23588@cbox>
On Mon, Nov 21, 2016 at 3:49 PM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Fri, Nov 18, 2016 at 10:28:34PM +0530, Vijay Kilari wrote:
>> On Thu, Nov 17, 2016 at 9:39 PM, Christoffer Dall
>> <christoffer.dall@linaro.org> wrote:
>> > On Thu, Nov 17, 2016 at 09:25:59PM +0530, Vijay Kilari wrote:
>> >> On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
>> >> <christoffer.dall@linaro.org> wrote:
>> >> > On Fri, Nov 04, 2016 at 04:43:32PM +0530, vijay.kilari at gmail.com wrote:
>> >> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >> >>
>> >> >> VGICv3 CPU interface registers are accessed using
>> >> >> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
>> >> >> as 64-bit. The cpu MPIDR value is passed along with register id.
>> >> >> is used to identify the cpu for registers access.
>> >> >>
>> >> >> The version of VGIC v3 specification is define here
>> >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>> >> >>
>> >> >> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
>> >> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >> >> ---
>> >> >> arch/arm64/include/uapi/asm/kvm.h | 3 +
>> >> >> arch/arm64/kvm/Makefile | 1 +
>> >> >> include/kvm/arm_vgic.h | 9 +
>> >> >> virt/kvm/arm/vgic/vgic-kvm-device.c | 27 +++
>> >> >> virt/kvm/arm/vgic/vgic-mmio-v3.c | 19 +++
>> >> >> virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 324 ++++++++++++++++++++++++++++++++++++
>> >> >> virt/kvm/arm/vgic/vgic-v3.c | 8 +
>> >> >> virt/kvm/arm/vgic/vgic.h | 4 +
>> >> >> 8 files changed, 395 insertions(+)
>> >> >>
>> >> >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> >> >> index 56dc08d..91c7137 100644
>> >> >> --- a/arch/arm64/include/uapi/asm/kvm.h
>> >> >> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> >> >> @@ -206,9 +206,12 @@ struct kvm_arch_memory_slot {
>> >> >> (0xffffffffULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
>> >> >> #define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
>> >> >> #define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
>> >> >> +#define KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK (0xffff)
>> >> >> #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
>> >> >> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
>> >> >> #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
>> >> >> +#define KVM_DEV_ARM_VGIC_CPU_SYSREGS 6
>> >> >> +
>> >> >> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>> >> >>
>> >> >> /* Device Control API on vcpu fd */
>> >> >> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
>> >> >> index d50a82a..1a14e29 100644
>> >> >> --- a/arch/arm64/kvm/Makefile
>> >> >> +++ b/arch/arm64/kvm/Makefile
>> >> >> @@ -32,5 +32,6 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v3.o
>> >> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-kvm-device.o
>> >> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-its.o
>> >> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/irqchip.o
>> >> >> +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-sys-reg-v3.o
>> >> >
>> >> > Thi is making me wonder: Are we properly handling GICv3 save/restore
>> >> > for AArch32 now that we have GICv3 support for AArch32? By properly I
>> >> > mean that either it is clearly only supported on AArch64 systems or it's
>> >> > supported on both AArch64 and AArch32, but it shouldn't break randomly
>> >> > on AArch32.
>> >>
>> >> It supports both AArch64 and AArch64 in handling of system registers
>> >> save/restore.
>> >> All system registers that we save/restore are 32-bit for both aarch64
>> >> and aarch32.
>> >> Though opcode op0 should be zero for aarch32, the remaining Op and CRn codes
>> >> are same. However the codes sent by qemu is matched and register
>> >> are handled properly irrespective of AArch32 or AArch64.
>> >>
>> >> I don't have platform which support AArch32 guests to verify.
>> >
>> > Actually this is not about the guest, it's about an ARMv8 AArch32 host
>> > that has a GICv3.
>> >
>> > I just tried to do a v7 compile with your patches, and it results in an
>> > epic failure, so there's something for you to look at.
>> >
>> >> >
>> >> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/arch_timer.o
>> >> >> kvm-$(CONFIG_KVM_ARM_PMU) += $(KVM)/arm/pmu.o
>> >> >> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
>> >> >> index 002f092..730a18a 100644
>> >> >> --- a/include/kvm/arm_vgic.h
>> >> >> +++ b/include/kvm/arm_vgic.h
>> >> >> @@ -71,6 +71,9 @@ struct vgic_global {
>> >> >>
>> >> >> /* GIC system register CPU interface */
>> >> >> struct static_key_false gicv3_cpuif;
>> >> >> +
>> >> >> + /* Cache ICH_VTR_EL2 reg value */
>> >> >> + u32 ich_vtr_el2;
>> >> >> };
>> >> >>
>> >> >> extern struct vgic_global kvm_vgic_global_state;
>> >> >> @@ -269,6 +272,12 @@ struct vgic_cpu {
>> >> >> u64 pendbaser;
>> >> >>
>> >> >> bool lpis_enabled;
>> >> >> +
>> >> >> + /* Cache guest priority bits */
>> >> >> + u32 num_pri_bits;
>> >> >> +
>> >> >> + /* Cache guest interrupt ID bits */
>> >> >> + u32 num_id_bits;
>> >> >> };
>> >> >>
>> >> >> extern struct static_key_false vgic_v2_cpuif_trap;
>> >> >> diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c b/virt/kvm/arm/vgic/vgic-kvm-device.c
>> >> >> index 6c7d30c..da532d1 100644
>> >> >> --- a/virt/kvm/arm/vgic/vgic-kvm-device.c
>> >> >> +++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
>> >> >> @@ -504,6 +504,14 @@ static int vgic_v3_attr_regs_access(struct kvm_device *dev,
>> >> >> if (!is_write)
>> >> >> *reg = tmp32;
>> >> >> break;
>> >> >> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> >> >> + u64 regid;
>> >> >> +
>> >> >> + regid = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
>> >> >> + ret = vgic_v3_cpu_sysregs_uaccess(vcpu, is_write,
>> >> >> + regid, reg);
>> >> >> + break;
>> >> >> + }
>> >> >> default:
>> >> >> ret = -EINVAL;
>> >> >> break;
>> >> >> @@ -537,6 +545,15 @@ static int vgic_v3_set_attr(struct kvm_device *dev,
>> >> >> reg = tmp32;
>> >> >> return vgic_v3_attr_regs_access(dev, attr, ®, true);
>> >> >> }
>> >> >> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> >> >> + u64 __user *uaddr = (u64 __user *)(long)attr->addr;
>> >> >> + u64 reg;
>> >> >> +
>> >> >> + if (get_user(reg, uaddr))
>> >> >> + return -EFAULT;
>> >> >> +
>> >> >> + return vgic_v3_attr_regs_access(dev, attr, ®, true);
>> >> >> + }
>> >> >> }
>> >> >> return -ENXIO;
>> >> >> }
>> >> >> @@ -563,6 +580,15 @@ static int vgic_v3_get_attr(struct kvm_device *dev,
>> >> >> tmp32 = reg;
>> >> >> return put_user(tmp32, uaddr);
>> >> >> }
>> >> >> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> >> >> + u64 __user *uaddr = (u64 __user *)(long)attr->addr;
>> >> >> + u64 reg;
>> >> >> +
>> >> >> + ret = vgic_v3_attr_regs_access(dev, attr, ®, false);
>> >> >> + if (ret)
>> >> >> + return ret;
>> >> >> + return put_user(reg, uaddr);
>> >> >> + }
>> >> >> }
>> >> >>
>> >> >> return -ENXIO;
>> >> >> @@ -581,6 +607,7 @@ static int vgic_v3_has_attr(struct kvm_device *dev,
>> >> >> break;
>> >> >> case KVM_DEV_ARM_VGIC_GRP_DIST_REGS:
>> >> >> case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:
>> >> >> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS:
>> >> >> return vgic_v3_has_attr_regs(dev, attr);
>> >> >> case KVM_DEV_ARM_VGIC_GRP_NR_IRQS:
>> >> >> return 0;
>> >> >> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> >> >> index b35fb83..519b919 100644
>> >> >> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> >> >> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
>> >> >> @@ -23,6 +23,7 @@
>> >> >>
>> >> >> #include "vgic.h"
>> >> >> #include "vgic-mmio.h"
>> >> >> +#include "sys_regs.h"
>> >> >>
>> >> >> /* extract @num bytes at @offset bytes offset in data */
>> >> >> unsigned long extract_bytes(u64 data, unsigned int offset,
>> >> >> @@ -639,6 +640,24 @@ int vgic_v3_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr)
>> >> >> nr_regions = ARRAY_SIZE(vgic_v3_rdbase_registers);
>> >> >> break;
>> >> >> }
>> >> >> + case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
>> >> >> + u64 reg, id;
>> >> >> + unsigned long vgic_mpidr, mpidr_reg;
>> >> >> + struct kvm_vcpu *vcpu;
>> >> >> +
>> >> >> + vgic_mpidr = (attr->attr & KVM_DEV_ARM_VGIC_V3_MPIDR_MASK) >>
>> >> >> + KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT;
>> >> >> +
>> >> >> + /* Convert plain mpidr value to MPIDR reg format */
>> >> >> + mpidr_reg = VGIC_TO_MPIDR(vgic_mpidr);
>> >> >> +
>> >> >> + vcpu = kvm_mpidr_to_vcpu(dev->kvm, mpidr_reg);
>> >> >> + if (!vcpu)
>> >> >> + return -EINVAL;
>> >> >> +
>> >> >> + id = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
>> >> >> + return vgic_v3_has_cpu_sysregs_attr(vcpu, 0, id, ®);
>> >> >> + }
>> >> >> default:
>> >> >> return -ENXIO;
>> >> >> }
>> >> >> diff --git a/virt/kvm/arm/vgic/vgic-sys-reg-v3.c b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>> >> >> new file mode 100644
>> >> >> index 0000000..69d8597
>> >> >> --- /dev/null
>> >> >> +++ b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>> >> >
>> >> > Shouldn't we have a GPL header here?
>> >> >
>> >> >> @@ -0,0 +1,324 @@
>> >> >> +#include <linux/irqchip/arm-gic-v3.h>
>> >> >> +#include <linux/kvm.h>
>> >> >> +#include <linux/kvm_host.h>
>> >> >> +#include <kvm/iodev.h>
>> >> >> +#include <kvm/arm_vgic.h>
>> >> >> +#include <asm/kvm_emulate.h>
>> >> >> +#include <asm/kvm_arm.h>
>> >> >> +#include <asm/kvm_mmu.h>
>> >> >> +
>> >> >> +#include "vgic.h"
>> >> >> +#include "vgic-mmio.h"
>> >> >> +#include "sys_regs.h"
>> >> >> +
>> >> >> +static bool access_gic_ctlr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >> >> + const struct sys_reg_desc *r)
>> >> >> +{
>> >> >> + struct vgic_cpu *vgic_v3_cpu = &vcpu->arch.vgic_cpu;
>> >> >> + struct vgic_vmcr vmcr;
>> >> >> + u64 val;
>> >> >> + u32 num_pri_bits, num_id_bits;
>> >> >> +
>> >> >> + vgic_get_vmcr(vcpu, &vmcr);
>> >> >> + if (p->is_write) {
>> >> >> + val = p->regval;
>> >> >> +
>> >> >> + /*
>> >> >> + * Does not allow update of ICC_CTLR_EL1 if HW does not support
>> >> >> + * guest programmed ID and PRI bits
>> >> >> + */
>> >> >
>> >> > I would suggest rewording this comment:
>> >> > Disallow restoring VM state not supported by this hardware.
>> >> >
>> >> >> + num_pri_bits = ((val & ICC_CTLR_EL1_PRI_BITS_MASK) >>
>> >> >> + ICC_CTLR_EL1_PRI_BITS_SHIFT) + 1;
>> >> >> + if (num_pri_bits > vgic_v3_cpu->num_pri_bits)
>> >> >> + return false;
>> >> >> +
>> >> >> + vgic_v3_cpu->num_pri_bits = num_pri_bits;
>> >> >
>> >> > hmmm, this looks weird to me, because vgic_v3_cpu->num_pri_bits I don't
>> >> > understand which effect this is intended to have?
>> >> >
>> >> > Sure, it may limit what you do with other registers later, but since
>> >> > there's no ordering requirement that the ctlr be restored first, I'm not
>> >> > sure it makes sense.
>> >> >
>> >> > Also, since this field is RO in the ICH_VTR, we'll have a strange
>> >> > situation during runtime after a GICv3 restore where the
>> >> > vgic_v3_cpu->num_pri_its differs from the hardware's ICH_VTR_EL2 field,
>> >> > which is never the case if you didn't do a save/restore.
>> >>
>> >> Yes, but in any case, vgic_v3_cpu->num_pri_bits will be always less
>> >> than HW supported
>> >> value.
>> >>
>> >
>> > So answer my question: What is the intended effect of writing this
>> > value? Is it just so that if you migrate this platform back again, then
>> > you're checking compatibility with what the guest would potentially do,
>>
>> Yes
>
> Then add a comment explaining that
>
>> and also to limit the valid aprn registers access as you said above.
>> But that has ordering restriction. Which I think we should follow.
>>
>
> I'm sorry, now I'm confused. Is there an ordering requirement in the
> API, or how should we follow this?
There is no ordering requirement mentioned in the API doc.
However the APRn registers depends on num_pri_bits. Hence first
ICC_CTLR_EL1 should be restored before APRn restore.
If ordering is not followed then APRn registers restore is allowed
as per hw supported num_pri_bits.
This should be mentioned in doc.
^ permalink raw reply
* [GIT PULL] Allwinner DT changes for 4.10
From: Maxime Ripard @ 2016-11-21 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161119002316.GN8882@localhost>
Hi Olof,
On Fri, Nov 18, 2016 at 04:23:16PM -0800, Olof Johansson wrote:
> Hi,
>
> On Tue, Nov 15, 2016 at 09:41:22PM +0100, Maxime Ripard wrote:
> > Hi Arnd, Olof,
> >
> > Here is our pull request for the next merge window.
> >
> > Thanks!
> > Maxime
> >
> > The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
> >
> > Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
> >
> > are available in the git repository at:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git tags/sunxi-dt-for-4.10
> >
> > for you to fetch changes up to e39a30cf736144814b0bddb3fff28fbbc2a8be0f:
> >
> > ARM: sunxi: Add the missing clocks to the pinctrl nodes (2016-11-15 18:49:47 +0100)
> >
> > ----------------------------------------------------------------
> > Allwinner DT additions for 4.10
> >
> > The usual bunch of DT additions, but most notably:
> > - A31 DRM driver
> > - A31 audio codec
> > - WiFi for the A80-Based boards and the CHIP
> > - Support for the NextThing Co CHIP Pro (the first board with NAND
> > enabled)
> > - New boards: NanoPi M1,
> >
> [...]
>
> > Maxime Ripard (16):
> > ARM: sun5i: a13-olinuxino: Enable VGA bridge
> > ARM: gr8: Add the UART3
> > ARM: gr8: Fix typo in the i2s mclk pin group
> > ARM: gr8: Add missing pwm channel 1 pin
> > ARM: gr8: Add UART2 pins
> > ARM: gr8: Add UART3 pins
> > ARM: gr8: Add CHIP Pro support
> > ARM: sun5i: chip: Enable Wi-Fi SDIO chip
> > ARM: sun5i: Rename A10s pins
> > ARM: sun5i: Add SPI2 pins
> > ARM: sun5i: Add RGB 565 LCD pins
> > ARM: sun5i: chip: Add optional buses
> > ARM: gr8: evb: Enable SPDIF
> > ARM: gr8: evb: Add i2s codec
> > ARM: sun8i: sina33: Enable USB gadget
> > ARM: sunxi: Add the missing clocks to the pinctrl nodes
> >
> [...]
>
> > arch/arm/boot/dts/Makefile | 1 +
> > arch/arm/boot/dts/ntc-gr8-chip-pro.dts | 266 +++++++++++++++++++++
> > arch/arm/boot/dts/ntc-gr8-evb.dts | 33 +++
> > arch/arm/boot/dts/ntc-gr8.dtsi | 47 +++-
> > arch/arm/boot/dts/sun4i-a10.dtsi | 3 +-
>
> NTC isn't the SoC manufacturer, and we try to keep the prefixes down to
> manufacturer to keep the namespace a little more manageable, even if
> we never got subdirectories setup as on arm64.
>
> I think this should probably be sun4i-a10-gr8 or sun4i-r8-gr8 as prefix?
The users really expect a SoC from Nextthing, it's always been
marketed that way, the marking on the SoC also says so, etc. The fact
that it's been a design in cooperation with Allwinner, and that the
design is based on some earlier family is an implementation detail,
and I'd really like not for it to have the sun5i prefix, it's just
confusing.
And the ntc prefix has been asked for during the reviews...
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161121/93468ce6/attachment.sig>
^ permalink raw reply
* [PATCH] PM / Domains: Fix compatible for domain idle state
From: Ulf Hansson @ 2016-11-21 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478210075-92045-2-git-send-email-lina.iyer@linaro.org>
On 3 November 2016 at 22:54, Lina Iyer <lina.iyer@linaro.org> wrote:
> Re-using idle state definition provided by arm,idle-state for domain
> idle states creates a lot of confusion and limits further evolution of
> the domain idle definition. To keep things clear and simple, define a
> idle states for domain using a new compatible "domain-idle-state".
>
> Fix existing PM domains code to look for the newly defined compatible.
>
> Cc: <devicetree@vger.kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Lina Iyer <lina.iyer@linaro.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
> ---
> .../bindings/power/domain-idle-state.txt | 33 ++++++++++++++++++++++
> .../devicetree/bindings/power/power_domain.txt | 8 +++---
> drivers/base/power/domain.c | 2 +-
> 3 files changed, 38 insertions(+), 5 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/domain-idle-state.txt
>
> diff --git a/Documentation/devicetree/bindings/power/domain-idle-state.txt b/Documentation/devicetree/bindings/power/domain-idle-state.txt
> new file mode 100644
> index 0000000..eefc7ed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/domain-idle-state.txt
> @@ -0,0 +1,33 @@
> +PM Domain Idle State Node:
> +
> +A domain idle state node represents the state parameters that will be used to
> +select the state when there are no active components in the domain.
> +
> +The state node has the following parameters -
> +
> +- compatible:
> + Usage: Required
> + Value type: <string>
> + Definition: Must be "domain-idle-state".
> +
> +- entry-latency-us
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing worst case latency in
> + microseconds required to enter the idle state.
> + The exit-latency-us duration may be guaranteed
> + only after entry-latency-us has passed.
> +
> +- exit-latency-us
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing worst case latency
> + in microseconds required to exit the idle state.
> +
> +- min-residency-us
> + Usage: Required
> + Value type: <prop-encoded-array>
> + Definition: u32 value representing minimum residency duration
> + in microseconds after which the idle state will yield
> + power benefits after overcoming the overhead in entering
> +i the idle state.
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index e165036..723e1ad 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -31,7 +31,7 @@ Optional properties:
>
> - domain-idle-states : A phandle of an idle-state that shall be soaked into a
> generic domain power state. The idle state definitions are
> - compatible with arm,idle-state specified in [1].
> + compatible with domain-idle-state specified in [1].
> The domain-idle-state property reflects the idle state of this PM domain and
> not the idle states of the devices or sub-domains in the PM domain. Devices
> and sub-domains have their own idle-states independent of the parent
> @@ -85,7 +85,7 @@ Example 3:
> };
>
> DOMAIN_RET: state at 0 {
> - compatible = "arm,idle-state";
> + compatible = "domain-idle-state";
> reg = <0x0>;
> entry-latency-us = <1000>;
> exit-latency-us = <2000>;
> @@ -93,7 +93,7 @@ Example 3:
> };
>
> DOMAIN_PWR_DN: state at 1 {
> - compatible = "arm,idle-state";
> + compatible = "domain-idle-state";
> reg = <0x1>;
> entry-latency-us = <5000>;
> exit-latency-us = <8000>;
> @@ -118,4 +118,4 @@ The node above defines a typical PM domain consumer device, which is located
> inside a PM domain with index 0 of a power controller represented by a node
> with the label "power".
>
> -[1]. Documentation/devicetree/bindings/arm/idle-states.txt
> +[1]. Documentation/devicetree/bindings/power/domain-idle-state.txt
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 661737c..f0bc672 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2048,7 +2048,7 @@ int genpd_dev_pm_attach(struct device *dev)
> EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
>
> static const struct of_device_id idle_state_match[] = {
> - { .compatible = "arm,idle-state", },
> + { .compatible = "domain-idle-state", },
> { }
> };
>
> --
> 2.7.4
>
^ permalink raw reply
* Synopsys Ethernet QoS Driver
From: Lars Persson @ 2016-11-21 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87c8a24b-0812-7850-cb3f-7be691bab432@st.com>
> 21 nov. 2016 kl. 13:53 skrev Giuseppe CAVALLARO <peppe.cavallaro@st.com>:
>
> Hello Joao
>
>> On 11/21/2016 1:32 PM, Joao Pinto wrote:
>> Hello,
>>
>>> On 21-11-2016 05:29, Rayagond Kokatanur wrote:
>>>> On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent <rabin@rab.in> wrote:
>>>>> On Fri, Nov 18, 2016 at 02:20:27PM +0000, Joao Pinto wrote:
>>>>> For now we are interesting in improving the synopsys QoS driver under
>>>>> /nect/ethernet/synopsys. For now the driver structure consists of a single file
>>>>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and platform
>>>>> related stuff.
>>>>>
>>>>> Our strategy would be:
>>>>>
>>>>> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
>>>>> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
>>>>> c) Implement a "core driver" (dwc_eth_qos.c) that would only have Ethernet QoS
>>>>> related stuff to be reused by the platform / pci drivers
>>>>> d) Add a set of features to the "core driver" that we have available internally
>>>>
>>>> Note that there are actually two drivers in mainline for this hardware:
>>>>
>>>> drivers/net/ethernet/synopsis/
>>>> drivers/net/ethernet/stmicro/stmmac/
>>>
>>> Yes the later driver (drivers/net/ethernet/stmicro/stmmac/) supports
>>> both 3.x and 4.x. It has glue layer for pci, platform, core etc,
>>> please refer this driver once before you start.
>>>
>>> You can start adding missing feature of 4.x in stmmac driver.
>>
>> Thanks you all for all the info.
>> Well, I think we are in a good position to organize the ethernet drivers
>> concerning Synopsys IPs.
>>
>> First of all, in my opinion, it does not make sense to have a ethernet/synopsis
>> (typo :)) when ethernet/stmicro is also for a synopsys IP. If we have another
>> vendor using the same IP it should be able to reuse the commonn operations. But
>> I would put that discussion for later :)
>>
>> For now I suggest that for we create ethernet/qos and create there a folder
>> called dwc (designware controller) where all the synopsys qos IP specific code
>> in order to be reused for example by ethernet/stmicro/stmmac/. We just have to
>> figure out a clean interface for "client drivers" like stmmac to interact with
>> the new qos driver.
>>
>> What do you think about this approach?
>
> The stmmac drivers run since many years on several platforms
> (sh4, stm32, arm, x86, mips ...) and it supports an huge of amount of
> configurations starting from 3.1x to 3.7x databooks.
>
> It also supports QoS hardware; for example, 4.00a, 4.10a and 4.20a
> are fully working.
>
> Also the stmmac has platform, device-tree and pcie supports and
> a lot of maintained glue-logic files.
>
> It is fully documented inside the kernel tree.
>
> I am happy to have new enhancements from other developers.
> So, on my side, if you want to spend your time on improving it on your
> platforms please feel free to do it!
>
> Concerning the stmicro/stmmac naming, these come from a really old
> story and have no issue to adopt new folder/file names.
>
> I am also open to merge fixes and changes from ethernet/synopsis.
> I want to point you on some benchmarks made by Alex some months ago
> (IIRC) that showed an stmmac winner (due to the several optimizations
> analyzed and reviewed in this mailing list).
>
> Peppe
>
Hello Joao and others,
As the maintainer of dwc_eth_qos.c I prefer also that we put efforts on the most mature driver, the stmmac.
I hope that the code can migrate into an ethernet/synopsys folder to keep the convention of naming the folder after the vendor. This makes it easy for others to find the driver.
The dwc_eth_qos.c will eventually be removed and its DT binding interface can then be implemented in the stmmac driver.
- Lars
>>
>>
>>>
>>>>
>>>> (See http://lists.openwall.net/netdev/2016/02/29/127)
>>>>
>>>> The former only supports 4.x of the hardware.
>>>>
>>>> The later supports 4.x and 3.x and already has a platform glue driver
>>>> with support for several platforms, a PCI glue driver, and a core driver
>>>> with several features not present in the former (for example: TX/RX
>>>> interrupt coalescing, EEE, PTP).
>>>>
>>>> Have you evaluated both drivers? Why have you decided to work on the
>>>> former rather than the latter?
>>>
>>>
>>
>> Thanks.
>>
>>
>>
>>
>
^ permalink raw reply
* [PATCH v8 6/7] arm/arm64: vgic: Implement VGICv3 CPU interface access
From: Vijay Kilari @ 2016-11-21 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120132005.GC23588@cbox>
On Sun, Nov 20, 2016 at 6:50 PM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Sat, Nov 19, 2016 at 12:18:53AM +0530, Vijay Kilari wrote:
>> On Thu, Nov 17, 2016 at 9:39 PM, Christoffer Dall
>> <christoffer.dall@linaro.org> wrote:
>> > On Thu, Nov 17, 2016 at 09:25:59PM +0530, Vijay Kilari wrote:
>> >> On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
>> >> <christoffer.dall@linaro.org> wrote:
>> >> > On Fri, Nov 04, 2016 at 04:43:32PM +0530, vijay.kilari at gmail.com wrote:
>> >> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >> >>
>> >> >> VGICv3 CPU interface registers are accessed using
>> >> >> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
>> >> >> as 64-bit. The cpu MPIDR value is passed along with register id.
>> >> >> is used to identify the cpu for registers access.
>> >> >>
>> >> >> The version of VGIC v3 specification is define here
>> >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>> >> >>
>> >> >> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
>> >> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >> >> ---
>> >> >> arch/arm64/include/uapi/asm/kvm.h | 3 +
>> >> >> arch/arm64/kvm/Makefile | 1 +
>> >> >> include/kvm/arm_vgic.h | 9 +
>> >> >> virt/kvm/arm/vgic/vgic-kvm-device.c | 27 +++
>> >> >> virt/kvm/arm/vgic/vgic-mmio-v3.c | 19 +++
>> >> >> virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 324 ++++++++++++++++++++++++++++++++++++
>> >> >> virt/kvm/arm/vgic/vgic-v3.c | 8 +
>> >> >> virt/kvm/arm/vgic/vgic.h | 4 +
>> >> >> 8 files changed, 395 insertions(+)
>> >> >>
>> >> >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> >> >> index 56dc08d..91c7137 100644
>> >> >> --- a/arch/arm64/include/uapi/asm/kvm.h
>> >> >> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> >> >> @@ -206,9 +206,12 @@ struct kvm_arch_memory_slot {
>> >> >> (0xffffffffULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
>> >> >> #define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
>> >> >> #define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
>> >> >> +#define KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK (0xffff)
>> >> >> #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
>> >> >> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
>> >> >> #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
>> >> >> +#define KVM_DEV_ARM_VGIC_CPU_SYSREGS 6
>> >> >> +
>> >> >> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>> >> >>
>> >> >> /* Device Control API on vcpu fd */
>> >> >> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
>> >> >> index d50a82a..1a14e29 100644
>> >> >> --- a/arch/arm64/kvm/Makefile
>> >> >> +++ b/arch/arm64/kvm/Makefile
>> >> >> @@ -32,5 +32,6 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v3.o
>> >> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-kvm-device.o
>> >> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-its.o
>> >> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/irqchip.o
>> >> >> +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-sys-reg-v3.o
>> >> >
>> >> > Thi is making me wonder: Are we properly handling GICv3 save/restore
>> >> > for AArch32 now that we have GICv3 support for AArch32? By properly I
>> >> > mean that either it is clearly only supported on AArch64 systems or it's
>> >> > supported on both AArch64 and AArch32, but it shouldn't break randomly
>> >> > on AArch32.
>> >>
>> >> It supports both AArch64 and AArch64 in handling of system registers
>> >> save/restore.
>> >> All system registers that we save/restore are 32-bit for both aarch64
>> >> and aarch32.
>> >> Though opcode op0 should be zero for aarch32, the remaining Op and CRn codes
>> >> are same. However the codes sent by qemu is matched and register
>> >> are handled properly irrespective of AArch32 or AArch64.
>> >>
>> >> I don't have platform which support AArch32 guests to verify.
>> >
>> > Actually this is not about the guest, it's about an ARMv8 AArch32 host
>> > that has a GICv3.
>> >
>> > I just tried to do a v7 compile with your patches, and it results in an
>> > epic failure, so there's something for you to look at.
>> >
>>
>> Could you please share you config file?. I tried with multi_v7 defconfig with
>> CONFIG KVM and CONFIG_KVM_ARM_HOST enabled. it compiled for me.
>
> I think this has to do with which branch you apply your patches to.
> When applied to kvmarm/next, it fails.
>
> Here's the integration I did:
> https://git.linaro.org/people/christoffer.dall/linux-kvm-arm.git tmp-gicv3-migrate-v8
>
> Here's the config:
> https://transfer.sh/xkAxp/.config
>
Thanks for shareing the details, I could reproduce them.
However virt/kvm/arm/vgic/vgic-sys-reg-v3.c is written with
sys_regs_desc for AArch64.
For AArch32/v7, it has be to coproc_reg. I propose to add separate file for arm
which handles ICC* reg save/restore using coproc_reg.
> Here's the compile output:
>
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-mmio-v3.c:26:22: fatal error: sys_regs.h: No such file or directory
> #include "sys_regs.h"
> ^
> compilation terminated.
> make[2]: *** [arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-mmio-v3.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_parse_attr?:
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:438:29: error: ?KVM_DEV_ARM_VGIC_V3_MPIDR_MASK? undeclared (first use in this function)
> vgic_mpidr = (attr->attr & KVM_DEV_ARM_VGIC_V3_MPIDR_MASK) >>
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:438:29: note: each undeclared identifier is reported only once for each function it appears in
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:439:9: error: ?KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT? undeclared (first use in this function)
> KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT;
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:441:2: error: implicit declaration of function ?MPIDR_LEVEL_SHIFT? [-Werror=implicit-function-declaration]
> mpidr_reg = VGIC_TO_MPIDR(vgic_mpidr);
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_attr_regs_access?:
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:497:7: error: ?KVM_DEV_ARM_VGIC_GRP_REDIST_REGS? undeclared (first use in this function)
> case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:505:7: error: ?KVM_DEV_ARM_VGIC_CPU_SYSREGS? undeclared (first use in this function)
> case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:508:25: error: ?KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK? undeclared (first use in this function)
> regid = (attr->attr & KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK);
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:513:7: error: ?KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO? undeclared (first use in this function)
> case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:516:24: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK? undeclared (first use in this function)
> info = (attr->attr & KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK) >>
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:517:4: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT? undeclared (first use in this function)
> KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT;
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:518:15: error: ?VGIC_LEVEL_INFO_LINE_LEVEL? undeclared (first use in this function)
> if (info == VGIC_LEVEL_INFO_LINE_LEVEL) {
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:522:5: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK? undeclared (first use in this function)
> KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK;
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_set_attr?:
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:554:7: error: ?KVM_DEV_ARM_VGIC_GRP_REDIST_REGS? undeclared (first use in this function)
> case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS: {
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:565:7: error: ?KVM_DEV_ARM_VGIC_CPU_SYSREGS? undeclared (first use in this function)
> case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:574:7: error: ?KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO? undeclared (first use in this function)
> case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_get_attr?:
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:600:7: error: ?KVM_DEV_ARM_VGIC_GRP_REDIST_REGS? undeclared (first use in this function)
> case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS: {
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:611:7: error: ?KVM_DEV_ARM_VGIC_CPU_SYSREGS? undeclared (first use in this function)
> case KVM_DEV_ARM_VGIC_CPU_SYSREGS: {
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:620:7: error: ?KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO? undeclared (first use in this function)
> case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c: In function ?vgic_v3_has_attr?:
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:647:7: error: ?KVM_DEV_ARM_VGIC_GRP_REDIST_REGS? undeclared (first use in this function)
> case KVM_DEV_ARM_VGIC_GRP_REDIST_REGS:
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:648:7: error: ?KVM_DEV_ARM_VGIC_CPU_SYSREGS? undeclared (first use in this function)
> case KVM_DEV_ARM_VGIC_CPU_SYSREGS:
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:652:7: error: ?KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO? undeclared (first use in this function)
> case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:653:22: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK? undeclared (first use in this function)
> if (((attr->attr & KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK) >>
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:654:9: error: ?KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT? undeclared (first use in this function)
> KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT) ==
> ^
> /home/christoffer/src/kvmarm/linux/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.c:655:9: error: ?VGIC_LEVEL_INFO_LINE_LEVEL? undeclared (first use in this function)
> VGIC_LEVEL_INFO_LINE_LEVEL)
> ^
> cc1: some warnings being treated as errors
> make[2]: *** [arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-kvm-device.o] Error 1
> make[1]: *** [arch/arm/kvm] Error 2
> make[1]: *** Waiting for unfinished jobs....
> make: *** [sub-make] Error 2
>
> Thanks,
> -Christoffer
^ permalink raw reply
* [PATCH v5 0/3] Add basic support for the I2C units of the Armada 3700
From: Romain Perier @ 2016-11-21 13:32 UTC (permalink / raw)
To: linux-arm-kernel
This series add basic support for the I2C bus interface units present
in the Armada 3700 to the pxa-i2c driver. It also add the definitions of
the device nodes to the devicetree at the SoC level and for its official
development board: the Armada 3720 DB.
Romain Perier (3):
i2c: pxa: Add support for the I2C units found in Armada 3700
arm64: dts: marvell: Add I2C definitions for the Armada 3700
dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 +++++++++++++++++
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 24 +++++++++++++++++++++--
5 files changed, 46 insertions(+), 3 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v5 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-21 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121133247.29889-1-romain.perier@free-electrons.com>
The Armada 3700 has two I2C controllers that is compliant with the I2C
Bus Specificiation 2.1, supports multi-master and different bus speed:
Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
High speed mode (up to 3.4 Mhz).
This IP block has a lot of similarity with the PXA, except some register
offsets and bitfield. This commits adds a basic support for this I2C
unit.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
Changes in v5:
- Don't define registers for armada-3700, we can re-use the ones
for PXA3XX.
- Define registers mask when OF is not used, in probe_pdata.
Changes in v4:
- Replaced the type of hs_mask and fm_mask by u32, instead of
unsigned int, As writel() take an u32 as first argument...
Changes in v3:
- Replaced the type of hs_mask and fm_mask by unsigned int,
instead of unsigned long.
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 24 ++++++++++++++++++++++--
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..2f56a26 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -763,7 +763,7 @@ config I2C_PUV3
config I2C_PXA
tristate "Intel PXA2XX I2C adapter"
- depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+ depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
help
If you have devices in the PXA I2C bus, say yes to this option.
This driver can also be built as a module. If so, the module
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index e28b825..374d17c 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -98,6 +98,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa3xx-pwri2c", REGS_PXA3XX },
{ "ce4100-i2c", REGS_CE4100 },
{ "pxa910-i2c", REGS_PXA910 },
+ { "armada-3700-i2c", REGS_PXA3XX },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -122,7 +123,9 @@ MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
#define ICR_SADIE (1 << 13) /* slave address detected int enable */
#define ICR_UR (1 << 14) /* unit reset */
#define ICR_FM (1 << 15) /* fast mode */
+#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
#define ICR_HS (1 << 16) /* High Speed mode */
+#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
#define ICR_GPIOEN (1 << 19) /* enable GPIO mode for SCL in HS */
#define ISR_RWM (1 << 0) /* read/write mode */
@@ -193,6 +196,8 @@ struct pxa_i2c {
unsigned char master_code;
unsigned long rate;
bool highmode_enter;
+ u32 fm_mask;
+ u32 hs_mask;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -503,8 +508,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(i2c->slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
- writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
+ writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(&i2c->adap.dev, "Enabling slave mode\n");
@@ -1137,6 +1142,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
+ { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_PXA3XX },
{}
};
MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
@@ -1158,6 +1164,13 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
i2c->use_pio = 1;
if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
i2c->fast_mode = 1;
+ if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
+ i2c->fm_mask = ICR_BUSMODE_FM;
+ i2c->hs_mask = ICR_BUSMODE_HS;
+ } else {
+ i2c->fm_mask = ICR_FM;
+ i2c->hs_mask = ICR_HS;
+ }
*i2c_types = (enum pxa_i2c_types)(of_id->data);
@@ -1181,6 +1194,13 @@ static int i2c_pxa_probe_pdata(struct platform_device *pdev,
i2c->master_code = 0xe;
i2c->rate = plat->rate;
}
+ if (!strcmp(id->name, "armada-3700-i2c")) {
+ i2c->fm_mask = ICR_BUSMODE_FM;
+ i2c->hs_mask = ICR_BUSMODE_HS;
+ } else {
+ i2c->fm_mask = ICR_FM;
+ i2c->hs_mask = ICR_HS;
+ }
return 0;
}
--
2.9.3
^ permalink raw reply related
* [PATCH v5 2/3] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-11-21 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161121133247.29889-1-romain.perier@free-electrons.com>
The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
};
};
+&i2c0 {
+ status = "okay";
+};
+
/* CON3 */
&sata {
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index e9bd587..1b0fd21 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ i2c0: i2c at 11000 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11000 0x24>;
+ clocks = <&nb_periph_clk 10>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 11080 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11080 0x24>;
+ clocks = <&nb_periph_clk 9>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
uart0: serial at 12000 {
compatible = "marvell,armada-3700-uart";
reg = <0x12000 0x400>;
--
2.9.3
^ 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