* [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 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
* [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
* 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
* [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
* [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
* [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
* [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
* [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
* [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 16/18] arm64: dts: h3ulcb: rename SDHI0 pins
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: 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 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
power-source = <1800>;
@@ -291,8 +291,8 @@
};
&sdhi0 {
- pinctrl-0 = <&sdhi0_pins_3v3>;
- pinctrl-1 = <&sdhi0_pins_1v8>;
+ pinctrl-0 = <&sdhi0_pins>;
+ pinctrl-1 = <&sdhi0_pins_uhs>;
pinctrl-names = "default", "state_uhs";
vmmc-supply = <&vcc_sdhi0>;
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 15/18] arm64: dts: h3ulcb: enable SDHI2
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: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This supports SDHI2 for H3ULCB onboard eMMC
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 | 43 ++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index f178fe1730de..8d0ac076d8e2 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -62,6 +62,24 @@
clock-frequency = <24576000>;
};
+ reg_1p8v: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
vcc_sdhi0: regulator-vcc-sdhi0 {
compatible = "regulator-fixed";
@@ -157,6 +175,18 @@
power-source = <1800>;
};
+ sdhi2_pins: sd2 {
+ groups = "sdhi2_data8", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <3300>;
+ };
+
+ sdhi2_pins_uhs: sd2_uhs {
+ groups = "sdhi2_data8", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <1800>;
+ };
+
sound_pins: sound {
groups = "ssi01239_ctrl", "ssi0_data", "ssi1_data_a";
function = "ssi";
@@ -273,6 +303,19 @@
status = "okay";
};
+&sdhi2 {
+ /* used for on-board 8bit eMMC */
+ pinctrl-0 = <&sdhi2_pins>;
+ pinctrl-1 = <&sdhi2_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_1p8v>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
&ssi1 {
shared-pin;
};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 14/18] arm64: dts: m3ulcb: enable SDHI2
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: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This supports SDHI2 for M3ULCB onboard eMMC
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 43 ++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index d209e5480ff6..c3f064ac2cb4 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -55,6 +55,24 @@
};
};
+ reg_1p8v: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_3p3v: regulator1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
vcc_sdhi0: regulator-vcc-sdhi0 {
compatible = "regulator-fixed";
@@ -113,6 +131,18 @@
function = "sdhi0";
power-source = <1800>;
};
+
+ sdhi2_pins: sd2 {
+ groups = "sdhi2_data8", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <3300>;
+ };
+
+ sdhi2_pins_uhs: sd2_uhs {
+ groups = "sdhi2_data8", "sdhi2_ctrl";
+ function = "sdhi2";
+ power-source = <1800>;
+ };
};
&sdhi0 {
@@ -128,6 +158,19 @@
status = "okay";
};
+&sdhi2 {
+ /* used for on-board 8bit eMMC */
+ pinctrl-0 = <&sdhi2_pins>;
+ pinctrl-1 = <&sdhi2_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <®_3p3v>;
+ vqmmc-supply = <®_1p8v>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
&scif2 {
pinctrl-0 = <&scif2_pins>;
pinctrl-names = "default";
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 13/18] arm64: dts: m3ulcb: enable SDHI0
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: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This supports SDHI0 on M3ULCB board SD card slot
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 49 ++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 593d0b4ab31a..d209e5480ff6 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -54,6 +54,30 @@
gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
};
};
+
+ vcc_sdhi0: regulator-vcc-sdhi0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "SDHI0 Vcc";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&gpio5 2 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ vccq_sdhi0: regulator-vccq-sdhi0 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "SDHI0 VccQ";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <3300000 1
+ 1800000 0>;
+ };
};
&extal_clk {
@@ -77,6 +101,31 @@
groups = "scif_clk_a";
function = "scif_clk";
};
+
+ sdhi0_pins: sd0 {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <3300>;
+ };
+
+ sdhi0_pins_uhs: sd0_uhs {
+ groups = "sdhi0_data4", "sdhi0_ctrl";
+ function = "sdhi0";
+ power-source = <1800>;
+ };
+};
+
+&sdhi0 {
+ pinctrl-0 = <&sdhi0_pins>;
+ pinctrl-1 = <&sdhi0_pins_uhs>;
+ pinctrl-names = "default", "state_uhs";
+
+ vmmc-supply = <&vcc_sdhi0>;
+ vqmmc-supply = <&vccq_sdhi0>;
+ cd-gpios = <&gpio3 12 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ sd-uhs-sdr50;
+ status = "okay";
};
&scif2 {
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 12/18] arm64: dts: m3ulcb: enable WDT
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: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This supports watchdog timer for M3ULCB 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/r8a7796-m3ulcb.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 5567c46f3753..593d0b4ab31a 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -90,3 +90,8 @@
clock-frequency = <14745600>;
status = "okay";
};
+
+&wdt0 {
+ timeout-sec = <60>;
+ status = "okay";
+};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 11/18] arm64: dts: m3ulcb: enable EXTALR clk
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: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This enables EXTALR clock that can be used for the watchdog.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 2f8f183ea0cd..5567c46f3753 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -60,6 +60,10 @@
clock-frequency = <16666666>;
};
+&extalr_clk {
+ clock-frequency = <32768>;
+};
+
&pfc {
pinctrl-0 = <&scif_clk_pins>;
pinctrl-names = "default";
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 10/18] arm64: dts: m3ulcb: enable GPIO keys
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: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This supports GPIO keys on M3ULCB 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/r8a7796-m3ulcb.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 49162bd488f8..2f8f183ea0cd 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -12,6 +12,7 @@
/dts-v1/;
#include "r8a7796.dtsi"
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
/ {
model = "Renesas M3ULCB board based on r8a7796";
@@ -41,6 +42,18 @@
gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>;
};
};
+
+ keyboard {
+ compatible = "gpio-keys";
+
+ key-1 {
+ linux,code = <KEY_1>;
+ label = "SW3";
+ wakeup-source;
+ debounce-interval = <20>;
+ gpios = <&gpio6 11 GPIO_ACTIVE_LOW>;
+ };
+ };
};
&extal_clk {
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 09/18] arm64: dts: m3ulcb: enable GPIO leds
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: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This supports GPIO leds on M3ULCB 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/r8a7796-m3ulcb.dts | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 96cda59c2698..49162bd488f8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -30,6 +30,17 @@
/* first 128MB is reserved for secure area. */
reg = <0x0 0x48000000 0x0 0x38000000>;
};
+
+ leds {
+ compatible = "gpio-leds";
+
+ led5 {
+ gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
+ };
+ led6 {
+ gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>;
+ };
+ };
};
&extal_clk {
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 08/18] arm64: dts: m3ulcb: enable SCIF clk and pins
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: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This enables the external crystal for the SCIF_CLK and its pinctrl, to
be used by the Baud Rate Generator for External Clock (BRG) on (H)SCIF.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
index 1ae0708bb495..96cda59c2698 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -37,10 +37,18 @@
};
&pfc {
+ pinctrl-0 = <&scif_clk_pins>;
+ pinctrl-names = "default";
+
scif2_pins: scif2 {
groups = "scif2_data_a";
function = "scif2";
};
+
+ scif_clk_pins: scif_clk {
+ groups = "scif_clk_a";
+ function = "scif_clk";
+ };
};
&scif2 {
@@ -49,3 +57,8 @@
status = "okay";
};
+
+&scif_clk {
+ clock-frequency = <14745600>;
+ status = "okay";
+};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 07/18] arm64: dts: m3ulcb: initial device tree
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: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Add the initial device tree for the R8A7796 SoC based M3ULCB low cost
board (R-Car Starter Kit Pro)
This commit supports the following peripherals:
- SCIF (console)
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/Makefile | 2 +-
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts | 51 ++++++++++++++++++++++++++
2 files changed, 52 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile
index eb72830ec9eb..1618e0a3c81d 100644
--- a/arch/arm64/boot/dts/renesas/Makefile
+++ b/arch/arm64/boot/dts/renesas/Makefile
@@ -1,5 +1,5 @@
dtb-$(CONFIG_ARCH_R8A7795) += r8a7795-salvator-x.dtb r8a7795-h3ulcb.dtb
-dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb
+dtb-$(CONFIG_ARCH_R8A7796) += r8a7796-salvator-x.dtb r8a7796-m3ulcb.dtb
always := $(dtb-y)
clean-files := *.dtb
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
new file mode 100644
index 000000000000..1ae0708bb495
--- /dev/null
+++ b/arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dts
@@ -0,0 +1,51 @@
+/*
+ * Device Tree Source for the M3ULCB (R-Car Starter Kit Pro) board
+ *
+ * Copyright (C) 2016 Renesas Electronics Corp.
+ * Copyright (C) 2016 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include "r8a7796.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ model = "Renesas M3ULCB board based on r8a7796";
+ compatible = "renesas,m3ulcb", "renesas,r8a7796";
+
+ aliases {
+ serial0 = &scif2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory at 48000000 {
+ device_type = "memory";
+ /* first 128MB is reserved for secure area. */
+ reg = <0x0 0x48000000 0x0 0x38000000>;
+ };
+};
+
+&extal_clk {
+ clock-frequency = <16666666>;
+};
+
+&pfc {
+ scif2_pins: scif2 {
+ groups = "scif2_data_a";
+ function = "scif2";
+ };
+};
+
+&scif2 {
+ pinctrl-0 = <&scif2_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 06/18] arm64: dts: m3ulcb: add M3ULCB board DT bindings
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: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Add M3ULCB Device tree bindings Documentation, listing it as a supported
board.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 1c2499ca1bee..29bf24ca0b7b 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -61,6 +61,8 @@ Boards:
compatible = "renesas,kzm9g", "renesas,sh73a0"
- Lager (RTP0RC7790SEB00010S)
compatible = "renesas,lager", "renesas,r8a7790"
+ - M3ULCB (R-Car Starter Kit Pro, RTP0RC7796SKB00010S)
+ compatible = "renesas,m3ulcb", "renesas,r8a7796";
- Marzen
compatible = "renesas,marzen", "renesas,r8a7779"
- Porter (M2-LCDP)
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 05/18] arm64: dts: h3ulcb: update header
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: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This updates H3ULCB device tree header with official board name
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 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
index bcb11a868343..f178fe1730de 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7795-h3ulcb.dts
@@ -1,5 +1,5 @@
/*
- * Device Tree Source for the H3ULCB board
+ * Device Tree Source for the H3ULCB (R-Car Starter Kit Premier) board
*
* Copyright (C) 2016 Renesas Electronics Corp.
* Copyright (C) 2016 Cogent Embedded, Inc.
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 04/18] arm64: dts: h3ulcb: update documentation with official board name
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: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
This updates H3ULCB Device tree bindings Documentation with
official board name
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
Documentation/devicetree/bindings/arm/shmobile.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt
index 2f0b7169f132..1c2499ca1bee 100644
--- a/Documentation/devicetree/bindings/arm/shmobile.txt
+++ b/Documentation/devicetree/bindings/arm/shmobile.txt
@@ -49,7 +49,7 @@ Boards:
compatible = "renesas,genmai", "renesas,r7s72100"
- Gose
compatible = "renesas,gose", "renesas,r8a7793"
- - H3ULCB (RTP0RC7795SKB00010S)
+ - H3ULCB (R-Car Starter Kit Premier, RTP0RC7795SKB00010S)
compatible = "renesas,h3ulcb", "renesas,r8a7795";
- Henninger
compatible = "renesas,henninger", "renesas,r8a7791"
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 03/18] arm64: dts: r8a7796: salvator-x: enable I2C
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: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
index a9c296b1e1b7..f35e96ca7d60 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
+++ b/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts
@@ -111,6 +111,11 @@
function = "scif_clk";
};
+ i2c2_pins: i2c2 {
+ groups = "i2c2_a";
+ function = "i2c2";
+ };
+
sdhi0_pins: sd0 {
groups = "sdhi0_data4", "sdhi0_ctrl";
function = "sdhi0";
@@ -208,6 +213,13 @@
status = "okay";
};
+&i2c2 {
+ pinctrl-0 = <&i2c2_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
&wdt0 {
timeout-sec = <60>;
status = "okay";
--
2.7.0.rc3.207.g0ac5344
^ permalink raw reply related
* [PATCH 02/18] arm64: dts: r8a7796: Enable I2C DMA
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: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 2e940ff61378..9599f5691099 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -257,6 +257,9 @@
interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 931>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ dmas = <&dmac1 0x91>, <&dmac1 0x90>,
+ <&dmac2 0x91>, <&dmac2 0x90>;
+ dma-names = "tx", "rx", "tx", "rx";
i2c-scl-internal-delay-ns = <110>;
status = "disabled";
};
@@ -269,6 +272,9 @@
interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 930>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ dmas = <&dmac1 0x93>, <&dmac1 0x92>,
+ <&dmac2 0x93>, <&dmac2 0x92>;
+ dma-names = "tx", "rx", "tx", "rx";
i2c-scl-internal-delay-ns = <6>;
status = "disabled";
};
@@ -281,6 +287,9 @@
interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 929>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ dmas = <&dmac1 0x95>, <&dmac1 0x94>,
+ <&dmac2 0x95>, <&dmac2 0x94>;
+ dma-names = "tx", "rx", "tx", "rx";
i2c-scl-internal-delay-ns = <6>;
status = "disabled";
};
@@ -293,6 +302,8 @@
interrupts = <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 928>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ dmas = <&dmac0 0x97>, <&dmac0 0x96>;
+ dma-names = "tx", "rx";
i2c-scl-internal-delay-ns = <110>;
status = "disabled";
};
@@ -305,6 +316,8 @@
interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 927>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ dmas = <&dmac0 0x99>, <&dmac0 0x98>;
+ dma-names = "tx", "rx";
i2c-scl-internal-delay-ns = <110>;
status = "disabled";
};
@@ -317,6 +330,8 @@
interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 919>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ dmas = <&dmac0 0x9b>, <&dmac0 0x9a>;
+ dma-names = "tx", "rx";
i2c-scl-internal-delay-ns = <110>;
status = "disabled";
};
@@ -329,6 +344,8 @@
interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 918>;
power-domains = <&sysc R8A7796_PD_ALWAYS_ON>;
+ dmas = <&dmac0 0x9d>, <&dmac0 0x9c>;
+ dma-names = "tx", "rx";
i2c-scl-internal-delay-ns = <6>;
status = "disabled";
};
--
2.7.0.rc3.207.g0ac5344
^ 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