* [PATCH v2 00/10] Add basic support for Rockchip RK1108 SOC
From: Andy Yan @ 2016-11-14 11:55 UTC (permalink / raw)
To: heiko
Cc: shawn.lin, linus.walleij, robh+dt, linux-clk, linux-rockchip,
devicetree, mturquette, sboyd, linux-gpio, linux,
linux-arm-kernel, ulf.hansson, linux-mmc, linux-kernel,
mark.rutland, Andy Yan
RK1108 is embedded with an ARM Cortex-A7 single core and a DSP core.
It is designed for varies application scenario such as car DVR, sports
DV, secure camera and UAV camera.
This patch series add basic support for it, which can boot a board with
initramfs into shell.
More new feathers will come soon.
Changes in v2:
- split dt-binding header from clk driver
- fix some CodingStyle issues
- add dt-binding documentation for pinctrl
- add pull and drive-strength functionality for pinctrl
- fix timer and gic dt description
- ordering devices by register address
- move the board in the rockchip.txt to the block of Rockchip boards
Andy Yan (6):
dt-bindings: add documentation for rk1108 pinctrl
pinctrl: rockchip: add support for rk1108
ARM: add low level debug uart for rk1108
ARM: dts: add basic support for Rockchip RK1108 SOC
ARM: rockchip: enable support for RK1108 SoC
ARM: dts: rockchip: add rockchip RK1108 Evaluation board
Shawn Lin (4):
dt-bindings: rockchip-dw-mshc: add RK1108 dw-mshc description
dt-bindings: add documentation for rk1108 cru
clk: rockchip: add dt-binding header for rk1108
clk: rockchip: add clock controller for rk1108
Documentation/devicetree/bindings/arm/rockchip.txt | 5 +-
.../bindings/clock/rockchip,rk1108-cru.txt | 60 +++
.../devicetree/bindings/mmc/rockchip-dw-mshc.txt | 1 +
.../bindings/pinctrl/rockchip,pinctrl.txt | 9 +-
arch/arm/Kconfig.debug | 30 ++
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk1108-evb.dts | 69 ++++
arch/arm/boot/dts/rk1108.dtsi | 428 +++++++++++++++++++
arch/arm/mach-rockchip/rockchip.c | 1 +
drivers/clk/rockchip/Makefile | 1 +
drivers/clk/rockchip/clk-rk1108.c | 451 +++++++++++++++++++++
drivers/clk/rockchip/clk.h | 14 +
drivers/pinctrl/pinctrl-rockchip.c | 87 +++-
include/dt-bindings/clock/rk1108-cru.h | 270 ++++++++++++
14 files changed, 1421 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/rockchip,rk1108-cru.txt
create mode 100644 arch/arm/boot/dts/rk1108-evb.dts
create mode 100644 arch/arm/boot/dts/rk1108.dtsi
create mode 100644 drivers/clk/rockchip/clk-rk1108.c
create mode 100644 include/dt-bindings/clock/rk1108-cru.h
--
2.7.4
^ permalink raw reply
* [PATCH v3] dts: omap5: board-common: fix wrong SMPS6 (VDD-DDR3) voltage
From: H. Nikolaus Schaller @ 2016-11-14 11:55 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Rob Herring, Mark Rutland,
Russell King
Cc: linux-omap, devicetree, linux-kernel, kernel,
H. Nikolaus Schaller
DDR3L is usually specified as
JEDEC standard 1.35V(1.28V~1.45V) & 1.5V(1.425V~1.575V)
Therefore setting smps6 regulator to 1.2V is definitively below
minimum. It appears that real world chips are more forgiving than
data sheets indicate, but let's set the regulator right.
Note: a board that uses other voltages (DDR with 1.5V) can
overwrite by referencing &smps6_reg.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
arch/arm/boot/dts/omap5-board-common.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi
index ab60a8e..e4a14d5 100644
--- a/arch/arm/boot/dts/omap5-board-common.dtsi
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi
@@ -476,8 +476,8 @@
smps6_reg: smps6 {
/* VDD_DDR3 - over VDD_SMPS6 */
regulator-name = "smps6";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
+ regulator-min-microvolt = <1350000>;
+ regulator-max-microvolt = <1350000>;
regulator-always-on;
regulator-boot-on;
};
--
2.7.3
^ permalink raw reply related
* Re: [PATCH v10 01/11] remoteproc: st_slim_rproc: add a slimcore rproc driver
From: Peter Griffin @ 2016-11-14 11:42 UTC (permalink / raw)
To: Vinod Koul
Cc: Bjorn Andersson, linux-arm-kernel, linux-kernel, kernel, ohad,
patrice.chotard, lee.jones, dmaengine, devicetree,
linux-remoteproc
In-Reply-To: <20161114051854.GW3000@localhost>
Hi Vinod,
On Mon, 14 Nov 2016, Vinod Koul wrote:
> On Mon, Nov 07, 2016 at 01:57:35PM +0000, Peter Griffin wrote:
> > >
> > > As you now make changes to the entire remoteproc Kconfig file, rather
> > > than simply add a Kconfig symbol we can't bring this in via Vinod's tree
> > > without providing Linus with a messy merge conflict.
> > >
> > > So the remoteproc parts now has to go through my tree.
> >
> > OK, I think the best approach is for Vinod to create an immutable
> > branch with the entire fdma series on, and then both of you merge that branch into
> > your respective trees.
>
> my topic/st_fdma is immutable branch. You cna merge it, if you need a signed
> tag, please do let me know
OK.
>
> >
> > That way there won't be any conflicts and you can both accept further changes
> > for v4.9 release. Trying to take half the series via rproc, and half via dma trees won't work
> > because they have dependencies on each other.
> >
> > I will send a v11 series in a moment which includes the feedback in this email
> > and also include the additional fixes which Vinod has applied since the driver
> > has been in linux-next.
>
> WHY.. Stuff is already merged twice!
When the feedback is "there is an unrelated change in this patch", the only way
you can fix that is by having a new version of the patch.
>Please send updated on top of already
> merged code!
You have dropped the remoteproc parts which were updated in v11, so
it is no longer merged. Bjorn can now pick the v11 versions if he chooses which
incporporates his feedback.
>This is how kernel developement is done...
regards,
Peter.
^ permalink raw reply
* Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: liviu.dudau @ 2016-11-14 11:26 UTC (permalink / raw)
To: Gabriele Paoloni
Cc: Arnd Bergmann, linux-arm-kernel@lists.infradead.org, Yuanzhichang,
mark.rutland@arm.com, devicetree@vger.kernel.org,
lorenzo.pieralisi@arm.com, minyard@acm.org,
linux-pci@vger.kernel.org, benh@kernel.crashing.org, John Garry,
will.deacon@arm.com, linux-kernel@vger.kernel.org, xuwei (O),
Linuxarm, zourongrong@gmail.com, robh+dt@kernel.org
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F90EA45@lhreml507-mbx>
On Mon, Nov 14, 2016 at 08:26:42AM +0000, Gabriele Paoloni wrote:
> Hi Liviu
>
[snip]
> > > >
> > > > Your idea is a good one, however you are abusing PCIBIOS_MIN_IO and
> > you
> > > > actually need another variable for "reserving" an area in the I/O
> > space
> > > > that can be used for physical addresses rather than I/O tokens.
> > > >
> > > > The one good example for using PCIBIOS_MIN_IO is when your
> > > > platform/architecture
> > > > does not support legacy ISA operations *at all*. In that case
> > someone
> > > > sets the PCIBIOS_MIN_IO to a non-zero value to reserve that I/O
> > range
> > > > so that it doesn't get used. With Zhichang's patch you now start
> > > > forcing
> > > > those platforms to have a valid address below PCIBIOS_MIN_IO.
> > >
> > > But if PCIBIOS_MIN_IO is 0 then it means that all I/O space is to be
> > used
> > > by PCI controllers only...
> >
> > Nope, that is not what it means. It means that PCI devices can see I/O
> > addresses
> > on the bus that start from 0. There never was any usage for non-PCI
> > controllers
>
> So I am a bit confused...
> From http://www.firmware.org/1275/bindings/isa/isa0_4d.ps
> It seems that ISA buses operate on cpu I/O address range [0, 0xFFF].
> I thought that was the reason why for most architectures we have
> PCIBIOS_MIN_IO equal to 0x1000 (so I thought that ISA controllers
> usually use [0, PCIBIOS_MIN_IO - 1] )
First of all, cpu I/O addresses is an x86-ism. ARM architectures and others
have no separate address space for I/O, it is all merged into one unified
address space. So, on arm/arm64 for example, PCIBIOS_MIN_IO = 0 could mean
that we don't care about ISA I/O because the platform does not support having
an ISA bus (e.g.).
>
> For those architectures whose PCIBIOS_MIN_IO != 0x1000 probably
> they are not fully compliant or they cannot fully support an ISA
> controller...?
Exactly. Not fully compliant is a bit strong, as ISA is a legacy feature and
when it comes to PCI-e you are allowed to ignore it. Having PCIBIOS_MIN_IO != 0x1000
is a way to signal that you don't fully support ISA.
>
> As said before this series forbid IO tokens to be in [0, PCIBIOS_MIN_IO)
> to allow special ISA controllers to use that range with special
> accessors.
> Having a variable threshold would make life much more difficult
> as there would be a probe dependency between the PCI controller and
> the special ISA one (PCI to wait for the special ISA device to be
> probed and set the right threshold value from DT or ACPI table).
>
> Instead using PCIBIOS_MIN_IO is easier and should not impose much
> constraint as [PCIBIOS_MIN_IO, IO_SPACE_LIMIT] is available to
> the PCI controller for I/O tokens...
What I am suggesting is to leave PCIBIOS_MIN_IO alone which still reserves
space for ISA controller and add a PCIBIOS_MIN_DIRECT_IO that will reserve
space for your direct address I/O on top of PCIBIOS_MIN_IO.
Best regards,
Liviu
>
> Thanks
>
> Gab
>
> > when PCIBIOS_MIN_IO != 0. That is what Zhichang is trying to do now and
> > what
> > I think is not the right thing (and not enough anyway).
> >
> > > so if you have a special bus device using
> > > an I/O range in this case should be a PCI controller...
> >
> > That has always been the case. It is this series that wants to
> > introduce the
> > new meaning.
> >
> > > i.e. I would
> > > expect it to fall back into the case of I/O tokens redirection rather
> > than
> > > physical addresses redirection (as mentioned below from my previous
> > reply).
> > > What do you think?
> >
> > I think you have looked too much at the code *with* Zhichang's patches
> > applied.
> > Take a step back and look at how PCIBIOS_MIN_IO is used now, before you
> > apply
> > the patches. It is all about PCI addresses and there is no notion of
> > non-PCI
> > busses using PCI framework. Only platforms and architectures that try
> > to work
> > around some legacy standards (ISA) or HW restrictions.
> >
> > Best regards,
> > Liviu
> >
> > >
> > > Thanks
> > >
> > > Gab
> > >
> > >
> > > >
> > > > For the general case you also have to bear in mind that
> > PCIBIOS_MIN_IO
> > > > could
> > > > be zero. In that case, what is your "forbidden" range? [0, 0) ? So
> > it
> > > > makes
> > > > sense to add a new #define that should only be defined by those
> > > > architectures/
> > > > platforms that want to reserve on top of PCIBIOS_MIN_IO another
> > region
> > > > where I/O tokens can't be generated for.
> > > >
> > > > Best regards,
> > > > Liviu
> > > >
> > > > >
> > > > > >
> > > > > > > > Your current version has
> > > > > > > >
> > > > > > > > if (arm64_extio_ops->pfout)
> > > > \
> > > > > > > > arm64_extio_ops->pfout(arm64_extio_ops-
> > > > >devpara,\
> > > > > > > > addr, value, sizeof(type));
> > > > \
> > > > > > > >
> > > > > > > > Instead, just subtract the start of the range from the
> > logical
> > > > > > > > port number to transform it back into a bus-local port
> > number:
> > > > > > >
> > > > > > > These accessors do not operate on IO tokens:
> > > > > > >
> > > > > > > If (arm64_extio_ops->start > addr || arm64_extio_ops->end <
> > addr)
> > > > > > > addr is not going to be an I/O token; in fact patch 2/3
> > imposes
> > > > that
> > > > > > > the I/O tokens will start at PCIBIOS_MIN_IO. So from 0 to
> > > > > > PCIBIOS_MIN_IO
> > > > > > > we have free physical addresses that the accessors can
> > operate
> > > > on.
> > > > > >
> > > > > > Ah, I missed that part. I'd rather not use PCIBIOS_MIN_IO to
> > refer
> > > > to
> > > > > > the logical I/O tokens, the purpose of that macro is really
> > meant
> > > > > > for allocating PCI I/O port numbers within the address space of
> > > > > > one bus.
> > > > >
> > > > > As I mentioned above, special devices operate on CPU addresses
> > > > directly,
> > > > > not I/O tokens. For them there is no way to distinguish....
> > > > >
> > > > > >
> > > > > > Note that it's equally likely that whichever next platform
> > needs
> > > > > > non-mapped I/O access like this actually needs them for PCI I/O
> > > > space,
> > > > > > and that will use it on addresses registered to a PCI host
> > bridge.
> > > > >
> > > > > Ok so here you are talking about a platform that has got an I/O
> > range
> > > > > under the PCI host controller, right?
> > > > > And this I/O range cannot be directly memory mapped but needs
> > special
> > > > > redirections for the I/O tokens, right?
> > > > >
> > > > > In this scenario registering the I/O ranges with the forbidden
> > range
> > > > > implemented by the current patch would still allow to redirect
> > I/O
> > > > > tokens as long as arm64_extio_ops->start >= PCIBIOS_MIN_IO
> > > > >
> > > > > So effectively the special PCI host controller
> > > > > 1) knows the physical range that needs special redirection
> > > > > 2) register such range
> > > > > 3) uses pci_pio_to_address() to retrieve the IO tokens for the
> > > > > special accessors
> > > > > 4) sets arm64_extio_ops->start/end to the IO tokens retrieved in
> > 3)
> > > > >
> > > > > So to be honest I think this patch can fit well both with
> > > > > special PCI controllers that need I/O tokens redirection and with
> > > > > special non-PCI controllers that need non-PCI I/O physical
> > > > > address redirection...
> > > > >
> > > > > Thanks (and sorry for the long reply but I didn't know how
> > > > > to make the explanation shorter :) )
> > > > >
> > > > > Gab
> > > > >
> > > > > >
> > > > > > If we separate the two steps:
> > > > > >
> > > > > > a) assign a range of logical I/O port numbers to a bus
> > > > > > b) register a set of helpers for redirecting logical I/O
> > > > > > port to a helper function
> > > > > >
> > > > > > then I think the code will get cleaner and more flexible.
> > > > > > It should actually then be able to replace the powerpc
> > > > > > specific implementation.
> > > > > >
> > > > > > Arnd
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH v5 0/3] Add clockevet for timer-nps driver to NPS400 SoC
From: Daniel Lezcano @ 2016-11-14 11:25 UTC (permalink / raw)
To: Noam Camus
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <DB6PR0501MB251893C085505B65DFFF7BFCAABC0-wTfl6qNNZ1PL+HUNrKNnF8DSnupUy6xnnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On Mon, Nov 14, 2016 at 09:35:59AM +0000, Noam Camus wrote:
> >From: Daniel Lezcano [mailto:daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org]
> >Sent: Monday, November 14, 2016 10:28 AM
>
> >Noam,
>
> >I know it is patch 0/3, but each time you send a change there are new typos.
>
> >Sending new versions as fast as possible without double checking the changes won't make them merged sooner.
>
> >Nobody is perfect but clearly you don't read your patch before sending and that does not make me confident about the code changes.
>
> >In the future, take some minutes to double-check and re-read your changes.
>
> Thank you Daniel,
> I will do an extra check next time.
Triple check then because there are still typos in v6.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 3/3] clocksource: Add clockevent support to NPS400 driver
From: Daniel Lezcano @ 2016-11-14 11:23 UTC (permalink / raw)
To: Noam Camus
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
tglx-hfZtesqFncYOwBW4kG4KsQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479021872-14237-4-git-send-email-noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
On Sun, Nov 13, 2016 at 09:24:32AM +0200, Noam Camus wrote:
> From: Noam Camus <noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> Till now we used clockevent from generic ARC driver.
> This was enough as long as we worked with simple multicore SoC.
> When we are working with multithread SoC each HW thread can be
> scheduled to receive timer interrupt using timer mask register.
> This patch will provide a way to control clock events per HW thread.
>
> The design idea is that for each core there is dedicated regirtser
s/regirtser/register/ (already spotted in v2).
> (TSI) serving all 16 HW threads.
> The register is a bitmask with one bit for each HW thread.
> When HW thread wants that next expiration of timer interrupt will
> hit it then the proper bit should be set in this dedicated register.
> When timer expires all HW threads within this core which their bit
> is set at the TSI register will be interrupted.
>
> Driver can be used from device tree by:
> compatible = "ezchip,nps400-timer0" <-- for clocksource
> compatible = "ezchip,nps400-timer1" <-- for clockevent
>
> Note that name convention for timer0/timer1 was taken from legacy
> ARC design. This design is our base before adding HW threads.
> For backward compatibility we keep "ezchip,nps400-timer" for clocksource
>
> Signed-off-by: Noam Camus <noamca-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> ---
> .../bindings/timer/ezchip,nps400-timer.txt | 15 --
> .../bindings/timer/ezchip,nps400-timer0.txt | 17 ++
> .../bindings/timer/ezchip,nps400-timer1.txt | 15 ++
> drivers/clocksource/timer-nps.c | 213 ++++++++++++++++++++
> 4 files changed, 245 insertions(+), 15 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
> create mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
> create mode 100644 Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
>
> diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
> deleted file mode 100644
> index c8c03d7..0000000
> --- a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer.txt
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -NPS Network Processor
> -
> -Required properties:
> -
> -- compatible : should be "ezchip,nps400-timer"
> -
> -Clocks required for compatible = "ezchip,nps400-timer":
> -- clocks : Must contain a single entry describing the clock input
> -
> -Example:
> -
> -timer {
> - compatible = "ezchip,nps400-timer";
> - clocks = <&sysclk>;
> -};
> diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
> new file mode 100644
> index 0000000..e3cfce8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer0.txt
> @@ -0,0 +1,17 @@
> +NPS Network Processor
> +
> +Required properties:
> +
> +- compatible : should be "ezchip,nps400-timer0"
> +
> +Clocks required for compatible = "ezchip,nps400-timer0":
> +- interrupts : The interrupt of the first timer
> +- clocks : Must contain a single entry describing the clock input
> +
> +Example:
> +
> +timer {
> + compatible = "ezchip,nps400-timer0";
> + interrupts = <3>;
> + clocks = <&sysclk>;
> +};
> diff --git a/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
> new file mode 100644
> index 0000000..c0ab419
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/timer/ezchip,nps400-timer1.txt
> @@ -0,0 +1,15 @@
> +NPS Network Processor
> +
> +Required properties:
> +
> +- compatible : should be "ezchip,nps400-timer1"
> +
> +Clocks required for compatible = "ezchip,nps400-timer1":
> +- clocks : Must contain a single entry describing the clock input
> +
> +Example:
> +
> +timer {
> + compatible = "ezchip,nps400-timer1";
> + clocks = <&sysclk>;
> +};
> diff --git a/drivers/clocksource/timer-nps.c b/drivers/clocksource/timer-nps.c
> index eeef9e9..ed4bce4 100644
> --- a/drivers/clocksource/timer-nps.c
> +++ b/drivers/clocksource/timer-nps.c
> @@ -109,3 +109,216 @@ static int __init nps_setup_clocksource(struct device_node *node)
>
> CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clksrc, "ezchip,nps400-timer",
> nps_setup_clocksource);
> +CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_src, "ezchip,nps400-timer1",
> + nps_setup_clocksource);
> +
> +#ifdef CONFIG_EZNPS_MTM_EXT
> +#include <soc/nps/mtm.h>
> +
> +/* Timer related Aux registers */
> +#define NPS_REG_TIMER0_TSI 0xFFFFF850
> +#define NPS_REG_TIMER0_LIMIT 0x23
> +#define NPS_REG_TIMER0_CTRL 0x22
> +#define NPS_REG_TIMER0_CNT 0x21
> +
> +/*
> + * Interrupt Enabled (IE) - re-arm the timer
> + * Not Halted (NH) - is cleared when working with JTAG (for debug)
> + */
> +#define TIMER0_CTRL_IE BIT(0)
> +#define TIMER0_CTRL_NH BIT(1)
> +
> +static unsigned long nps_timer0_freq;
> +static unsigned long nps_timer0_irq;
> +
> +/*
> + * Arm the timer to interrupt after @cycles
> + */
> +static void nps_clkevent_timer_event_setup(unsigned int cycles)
> +{
> + write_aux_reg(NPS_REG_TIMER0_LIMIT, cycles);
> + write_aux_reg(NPS_REG_TIMER0_CNT, 0);
> +
> + write_aux_reg(NPS_REG_TIMER0_CTRL, TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +}
> +
> +/*
> + * Clear from TSI the bit for this thread (if not in periodic mode)
> + * If still there are pending HW treads set next timer event
s/treads/threads/
> + */
> +static void nps_clkevent_rm_thread(bool remove_thread)
> +{
> + unsigned int cflags;
> + unsigned int enabled_threads = 0;
> + int thread;
> +
> + hw_schd_save(&cflags);
I'm not used with hardware scheduling. Can you explain why this is needed
here ? What window race we want to close ?
> +
> + enabled_threads = read_aux_reg(NPS_REG_TIMER0_TSI);
> +
> + /* remove thread from TSI1 */
> + if (remove_thread) {
> + thread = read_aux_reg(CTOP_AUX_THREAD_ID);
> + enabled_threads &= ~(1 << thread);
> + write_aux_reg(NPS_REG_TIMER0_TSI, enabled_threads);
> + }
> +
> + /* Re-arm the timer if needed */
> + if (!enabled_threads)
> + write_aux_reg(NPS_REG_TIMER0_CTRL, TIMER0_CTRL_NH);
> + else
> + write_aux_reg(NPS_REG_TIMER0_CTRL,
> + TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +
> + hw_schd_restore(cflags);
> +}
> +
> +static void nps_clkevent_add_thread(bool set_event)
> +{
> + int thread;
> + unsigned int cflags, enabled_threads;
> +
> + hw_schd_save(&cflags);
> +
> + /* add thread to TSI1 */
> + thread = read_aux_reg(CTOP_AUX_THREAD_ID);
> + enabled_threads = read_aux_reg(NPS_REG_TIMER0_TSI);
> + enabled_threads |= (1 << thread);
> + write_aux_reg(NPS_REG_TIMER0_TSI, enabled_threads);
> +
> + /* set next timer event */
> + if (set_event)
> + write_aux_reg(NPS_REG_TIMER0_CTRL,
> + TIMER0_CTRL_IE | TIMER0_CTRL_NH);
> +
> + hw_schd_restore(cflags);
> +}
Not sure the boolean parameters for *_rm_thread and *_add_thread helps
to clarify the code. Depending on the race window with hw_schd_save/restore
We should be able to simplify it.
> +static int nps_clkevent_set_next_event(unsigned long delta,
> + struct clock_event_device *dev)
> +{
> + nps_clkevent_add_thread(true);
> + enable_percpu_irq(nps_timer0_irq, IRQ_TYPE_NONE);
> +
> + return 0;
> +}
> +
> +/*
> + * Whenever anyone tries to change modes, we just mask interrupts
> + * and wait for the next event to get set.
> + */
> +static int nps_clkevent_timer_shutdown(struct clock_event_device *dev)
> +{
> + disable_percpu_irq(nps_timer0_irq);
> +
> + return 0;
> +}
> +
> +/*
> + * For each HW thread set its relevant bit at the TSI register
> + * To arm the timer only thread 0 is needed since it is shared
> + * by all HW threads within same core.
> + */
> +static int nps_clkevent_set_periodic(struct clock_event_device *dev)
> +{
> + nps_clkevent_add_thread(false);
> + if (read_aux_reg(CTOP_AUX_THREAD_ID) == 0)
> + nps_clkevent_timer_event_setup(nps_timer0_freq / HZ);
> +
> + return 0;
> +}
> +
> +static int nps_clkevent_set_oneshot(struct clock_event_device *dev)
> +{
> + nps_clkevent_rm_thread(true);
> + nps_clkevent_timer_shutdown(dev);
> +
> + return 0;
> +}
> +
> +static DEFINE_PER_CPU(struct clock_event_device, nps_clockevent_device) = {
> + .name = "NPS Timer0",
> + .features = CLOCK_EVT_FEAT_ONESHOT |
> + CLOCK_EVT_FEAT_PERIODIC,
> + .rating = 300,
> + .set_next_event = nps_clkevent_set_next_event,
> + .set_state_periodic = nps_clkevent_set_periodic,
> + .set_state_oneshot = nps_clkevent_set_oneshot,
> + .set_state_oneshot_stopped = nps_clkevent_timer_shutdown,
> + .set_state_shutdown = nps_clkevent_timer_shutdown,
Doesn't set_state_shutdown and set_state_oneshot_stopped need to remove
the HW thread from the TSI ?
> + .tick_resume = nps_clkevent_timer_shutdown,
> +};
> +
> +static irqreturn_t timer_irq_handler(int irq, void *dev_id)
> +{
> + struct clock_event_device *evt = dev_id;
> + int irq_reenable = clockevent_state_periodic(evt);
> +
> + /* Remove HW thread from TSI only if NOT in periodic state */
> + nps_clkevent_rm_thread(!irq_reenable);
> +
> + evt->event_handler(evt);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int nps_timer_starting_cpu(unsigned int cpu)
> +{
> + struct clock_event_device *evt = this_cpu_ptr(&nps_clockevent_device);
> +
> + evt->cpumask = cpumask_of(smp_processor_id());
> +
> + clockevents_config_and_register(evt, nps_timer0_freq, 0, ULONG_MAX);
> + enable_percpu_irq(nps_timer0_irq, IRQ_TYPE_NONE);
> +
> + return 0;
> +}
> +
> +static int nps_timer_dying_cpu(unsigned int cpu)
> +{
> + disable_percpu_irq(nps_timer0_irq);
> + return 0;
> +}
> +
> +static int __init nps_setup_clockevent(struct device_node *node)
> +{
> + struct clk *clk;
> + int ret;
> +
> + nps_timer0_irq = irq_of_parse_and_map(node, 0);
> + if (nps_timer0_irq <= 0) {
> + pr_err("clockevent: missing irq");
> + return -EINVAL;
> + }
> +
> + ret = nps_get_timer_clk(node, &nps_timer0_freq, &clk);
> + if (ret)
> + return ret;
> +
> + /* Needs apriori irq_set_percpu_devid() done in intc map function */
> + ret = request_percpu_irq(nps_timer0_irq, timer_irq_handler,
> + "Timer0 (per-cpu-tick)",
> + &nps_clockevent_device);
> + if (ret) {
> + pr_err("Couldn't request irq\n");
> + clk_disable_unprepare(clk);
> + return ret;
> + }
> +
> + ret = cpuhp_setup_state(CPUHP_AP_ARC_TIMER_STARTING,
> + "clockevents/nps:starting",
> + nps_timer_starting_cpu,
> + nps_timer_dying_cpu);
> + if (ret) {
> + pr_err("Failed to setup hotplug state");
> + clk_disable_unprepare(clk);
> + free_percpu_irq(nps_timer0_irq, &nps_clockevent_device);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +CLOCKSOURCE_OF_DECLARE(ezchip_nps400_clk_evt, "ezchip,nps400-timer0",
> + nps_setup_clockevent);
> +#endif /* CONFIG_EZNPS_MTM_EXT */
> --
> 1.7.1
>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver
From: Laurent Pinchart @ 2016-11-14 11:22 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jyri Sarha, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA, airlied-cv59FeDIM0c,
daniel-/w4YWyX8dFk, robdclark-Re5JQEeQqe8AvxtiuMwx3w,
bgolaszewski-rdvid1DuHRBWk0Htik3J/w,
khilman-rdvid1DuHRBWk0Htik3J/w, bcousson-rdvid1DuHRBWk0Htik3J/w
In-Reply-To: <ac8e0f72-fac2-45e5-0004-d6028ddeb221-l0cyMroinI0@public.gmane.org>
Hi Tomi,
On Monday 14 Nov 2016 13:16:49 Tomi Valkeinen wrote:
> On 14/11/16 13:10, Laurent Pinchart wrote:
> > On Monday 14 Nov 2016 10:49:43 Jyri Sarha wrote:
> >> On 11/03/16 19:46, Laurent Pinchart wrote:
> >>>> +Required properties:
> >>>>> + - compatible: "ti,tfp410"
> >>>
> >>> The device is an I2C slave, it should have a reg property. Given that
> >>> the chip can be used without being controlled through I2C, the reg
> >>> property should be optional. You should document this clearly, and
> >>> explain how the DT node can be instantiated as a child of an I2C
> >>> controller when the I2C interface is used, or in other parts of the
> >>> device tree otherwise.
> >>
> >> Shouldn't I have two different compatible strings if want to make both
> >> platform driver probe and i2c client probe to work?
> >
> > I don't think so, it's still the same chip.
> >
> >> Or can it be done with single compatible string? Would you know of an
> >> example of such a driver?
> >
> > You will need to register both a i2c_driver and a platform_driver in the
> > tfp410 driver. Both will advertise the same compatible string. As you'll
> > have two probe functions, it should be easy to handle the differences
> > between the
>
> If you have the same compatible string, won't both probes trigger? If
> so, how does, e.g., the platform driver know this is actually i2c case,
> and bail out? And if both probes don't trigger, why not? How does the
> device probing machinery know that this DT node is actually an i2c node,
> not a platform device node?
The driver for the bus on which the device is sitting is responsible for
instantiating a struct device corresponding to the bus type, and for binding
the corresponding bus drivers. This will be a struct i2c_client for I2C buses,
and a struct platform_device for platform buses. Only the corresponding driver
type will be probed.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
From: Arnd Bergmann @ 2016-11-14 11:22 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linuxppc-dev@lists.ozlabs.org, Geert Uytterhoeven,
Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, devicetree@vger.kernel.org, Dirk Behme,
linux-kernel@vger.kernel.org, Linux-Renesas,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAMuHMdWavRFnYFmiL2jy3KWZnHG_F8qaxK29zHx6fsLmqXEwiA@mail.gmail.com>
On Monday, November 14, 2016 11:51:15 AM CET Geert Uytterhoeven wrote:
> On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
> >> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
> >> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
> >> >> available, else fall back to hardcoded addresses for compatibility
> >> >> with existing DTBs,
>
> >> > It does seem wrong to have a device node for a specific register though.
> >> > Shouldn't the node be for the block of registers that these are inside
> >> > of?
> >>
> >> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
> >> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
> >
> > It just seems odd to have it at address 0xff000044 when all the other
> > devices are at page-aligned addresses. Do you mean that accessing
> > 0xff000040 or 0xff000048 will result in a bus-level exception for a
> > missing register and just 0xff000044 is actually valid for access,
> > or is it just the only thing that is documented?
>
> For PRR, all other registers in the page read as all zeroes on all SoCs that
> have it. So it really is a lone register.
Ok.
> >> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
> >> we further don't touch at all.
> >> On R-Car Gen2, it's not documented, but does exist.
> >
> > This is where the family names would come in handy ;-) I now have
> > no idea which chip(s) you are referring to.
>
> SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
> R-Car Gen2 are r8a779[0-4].
>
> > If you know the name of the register block, just put it into DT with
> > that name. The driver can trivially add the right offset.
>
> CCCR is different. The amount of registers that read as non-zero depends a lot
> on the actual SoC.
>
> HPB/APB is gonna need real DT bindings, which needs some more investigation.
> Hence if you don't mind, I'd like to postpone that part, which only affects
> the older SoCs. And I'll drop the "renesas,cccr" binding.
>
> For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
> most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
> waiting for this support. So I'd like to have that dependency in v4.10.
Ok, sounds good.
> >> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
> >> Hence I always need to look at the root nodes.
> >
> > Not sure what that would protect you from. Could you have a renesas,cccr
>
> Looks like you forgot to finish your sentence?
Yes, and I forgot what I was going to say there now. It's probably covered
by what we discussed above.
Arnd
^ permalink raw reply
* Re: [PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver
From: Tomi Valkeinen @ 2016-11-14 11:16 UTC (permalink / raw)
To: Laurent Pinchart, Jyri Sarha
Cc: devicetree, bcousson, khilman, dri-devel, bgolaszewski
In-Reply-To: <1740464.TP0bE1PYbC@avalon>
[-- Attachment #1.1.1: Type: text/plain, Size: 1481 bytes --]
On 14/11/16 13:10, Laurent Pinchart wrote:
> Hi Jyri,
>
> On Monday 14 Nov 2016 10:49:43 Jyri Sarha wrote:
>> On 11/03/16 19:46, Laurent Pinchart wrote:
>>>> +Required properties:
>>>>> + - compatible: "ti,tfp410"
>>>
>>> The device is an I2C slave, it should have a reg property. Given that the
>>> chip can be used without being controlled through I2C, the reg property
>>> should be optional. You should document this clearly, and explain how the
>>> DT node can be instantiated as a child of an I2C controller when the I2C
>>> interface is used, or in other parts of the device tree otherwise.
>>
>> Shouldn't I have two different compatible strings if want to make both
>> platform driver probe and i2c client probe to work?
>
> I don't think so, it's still the same chip.
>
>> Or can it be done with single compatible string? Would you know of an
>> example of such a driver?
>
> You will need to register both a i2c_driver and a platform_driver in the
> tfp410 driver. Both will advertise the same compatible string. As you'll have
> two probe functions, it should be easy to handle the differences between the
If you have the same compatible string, won't both probes trigger? If
so, how does, e.g., the platform driver know this is actually i2c case,
and bail out? And if both probes don't trigger, why not? How does the
device probing machinery know that this DT node is actually an i2c node,
not a platform device node?
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* [PATCH v4 3/3] PCI: qcom: add runtime pm support to pcie_port
From: Srinivas Kandagatla @ 2016-11-14 11:15 UTC (permalink / raw)
To: svarbanov-NEYub+7Iv8PQT0dZR+AlfA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, bhelgaas-hpIqsD4AKlfQT0dZR+AlfA
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479122155-13393-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
This patch is required when the pcie controller sits on a bus with
its own power domain and clocks which are controlled via a bus driver
like simple pm bus. As these bus driver have runtime pm enabled, it makes
sense to update the usage counter so that the runtime pm does not suspend
the clks or power domain associated with the bus driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
drivers/pci/host/pcie-qcom.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/host/pcie-qcom.c b/drivers/pci/host/pcie-qcom.c
index 03ba6b1..c2ca848 100644
--- a/drivers/pci/host/pcie-qcom.c
+++ b/drivers/pci/host/pcie-qcom.c
@@ -587,6 +587,8 @@ static void qcom_pcie_host_init(struct pcie_port *pp)
struct qcom_pcie *pcie = to_qcom_pcie(pp);
int ret;
+ pm_runtime_get_sync(pp->dev);
+
qcom_ep_reset_assert(pcie);
ret = pcie->ops->init(pcie);
@@ -617,6 +619,7 @@ static void qcom_pcie_host_init(struct pcie_port *pp)
phy_power_off(pcie->phy);
err_deinit:
pcie->ops->deinit(pcie);
+ pm_runtime_put_sync(pp->dev);
}
static int qcom_pcie_rd_own_conf(struct pcie_port *pp, int where, int size,
@@ -673,6 +676,7 @@ static int qcom_pcie_probe(struct platform_device *pdev)
if (!pcie)
return -ENOMEM;
+ pm_runtime_enable(dev);
pp = &pcie->pp;
pcie->ops = (struct qcom_pcie_ops *)of_device_get_match_data(dev);
--
2.10.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 2/3] PCI: qcom: add support to msm8996 PCIE controller
From: Srinivas Kandagatla @ 2016-11-14 11:15 UTC (permalink / raw)
To: svarbanov, linux-pci, bhelgaas
Cc: robh+dt, linux-arm-msm, srinivas.kandagatla, devicetree
In-Reply-To: <1479122155-13393-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds support to msm8996/apq8096 pcie, MSM8996 supports
Gen 1/2, One lane, 3 pcie root-complex with support to MSI and
legacy interrupts and it conforms to PCI Express Base 2.1 specification.
This patch adds post_init callback to qcom_pcie_ops, as this is pcie
pipe clocks are only setup after the phy is powered on.
It also adds ltssm_enable callback as it is very much different to other
supported SOCs in the driver.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
.../devicetree/bindings/pci/qcom,pcie.txt | 67 +++++++-
drivers/pci/host/pcie-qcom.c | 177 ++++++++++++++++++++-
2 files changed, 238 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
index 4059a6f..141d8c3 100644
--- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
@@ -7,6 +7,7 @@
- "qcom,pcie-ipq8064" for ipq8064
- "qcom,pcie-apq8064" for apq8064
- "qcom,pcie-apq8084" for apq8084
+ - "qcom,pcie-msm8996" for msm8996 or apq8096
- reg:
Usage: required
@@ -92,6 +93,17 @@
- "aux" Auxiliary (AUX) clock
- "bus_master" Master AXI clock
- "bus_slave" Slave AXI clock
+
+- clock-names:
+ Usage: required for msm8996/apq8096
+ Value type: <stringlist>
+ Definition: Should contain the following entries
+ - "pipe" Pipe Clock driving internal logic.
+ - "aux" Auxiliary (AUX) clock.
+ - "cfg" Configuration clk.
+ - "bus_master" Master AXI clock.
+ - "bus_slave" Slave AXI clock.
+
- resets:
Usage: required
Value type: <prop-encoded-array>
@@ -115,7 +127,7 @@
- "core" Core reset
- power-domains:
- Usage: required for apq8084
+ Usage: required for apq8084 and msm8996/apq8096
Value type: <prop-encoded-array>
Definition: A phandle and power domain specifier pair to the
power domain which is responsible for collapsing
@@ -231,3 +243,56 @@
pinctrl-0 = <&pcie0_pins_default>;
pinctrl-names = "default";
};
+
+* Example for apq8096:
+
+ pcie@608000{
+ compatible = "qcom,pcie-msm8996", "snps,dw-pcie";
+ power-domains = <&gcc PCIE1_GDSC>;
+ bus-range = <0x00 0xff>;
+ num-lanes = <1>;
+
+ reg = <0x00608000 0x2000>,
+ <0x0d000000 0xf1d>,
+ <0x0d000f20 0xa8>,
+ <0x0d100000 0x100000>;
+
+ reg-names = "parf", "dbi", "elbi", "config";
+
+ phys = <&pcie_phy 1>;
+ phy-names = "pciephy";
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x01000000 0x0 0x0d200000 0x0d200000 0x0 0x100000>,
+ <0x02000000 0x0 0x0d300000 0x0d300000 0x0 0xd00000>;
+
+ interrupts = <GIC_SPI 413 IRQ_TYPE_NONE>;
+ interrupt-names = "msi";
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 272 IRQ_TYPE_LEVEL_HIGH>, /* int_a */
+ <0 0 0 2 &intc 0 273 IRQ_TYPE_LEVEL_HIGH>, /* int_b */
+ <0 0 0 3 &intc 0 274 IRQ_TYPE_LEVEL_HIGH>, /* int_c */
+ <0 0 0 4 &intc 0 275 IRQ_TYPE_LEVEL_HIGH>; /* int_d */
+
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pcie1_clkreq_default &pcie1_perst_default &pcie1_wake_default>;
+ pinctrl-1 = <&pcie1_clkreq_sleep &pcie1_perst_default &pcie1_wake_sleep>;
+
+ vdda-1p8-supply = <&pm8994_l12>;
+ vdda-supply = <&pm8994_l28>;
+ linux,pci-domain = <1>;
+
+ clocks = <&gcc GCC_PCIE_1_PIPE_CLK>,
+ <&gcc GCC_PCIE_1_AUX_CLK>,
+ <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_1_SLV_AXI_CLK>;
+
+ clock-names = "pipe",
+ "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave";
+ };
diff --git a/drivers/pci/host/pcie-qcom.c b/drivers/pci/host/pcie-qcom.c
index 3593640..03ba6b1 100644
--- a/drivers/pci/host/pcie-qcom.c
+++ b/drivers/pci/host/pcie-qcom.c
@@ -36,11 +36,19 @@
#include "pcie-designware.h"
+#define PCIE20_PARF_DBI_BASE_ADDR 0x168
+
+#define PCIE20_PARF_SYS_CTRL 0x00
#define PCIE20_PARF_PHY_CTRL 0x40
#define PCIE20_PARF_PHY_REFCLK 0x4C
#define PCIE20_PARF_DBI_BASE_ADDR 0x168
#define PCIE20_PARF_SLV_ADDR_SPACE_SIZE 0x16c
+#define PCIE20_PARF_MHI_CLOCK_RESET_CTRL 0x174
#define PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT 0x178
+#define MSM8996_PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT 0x1A8
+#define PCIE20_PARF_LTSSM 0x1B0
+#define PCIE20_PARF_SID_OFFSET 0x234
+#define PCIE20_PARF_BDF_TRANSLATE_CFG 0x24C
#define PCIE20_ELBI_SYS_CTRL 0x04
#define PCIE20_ELBI_SYS_CTRL_LT_ENABLE BIT(0)
@@ -72,9 +80,18 @@ struct qcom_pcie_resources_v1 {
struct regulator *vdda;
};
+struct qcom_pcie_resources_v2 {
+ struct clk *aux_clk;
+ struct clk *master_clk;
+ struct clk *slave_clk;
+ struct clk *cfg_clk;
+ struct clk *pipe_clk;
+};
+
union qcom_pcie_resources {
struct qcom_pcie_resources_v0 v0;
struct qcom_pcie_resources_v1 v1;
+ struct qcom_pcie_resources_v2 v2;
};
struct qcom_pcie;
@@ -82,7 +99,9 @@ struct qcom_pcie;
struct qcom_pcie_ops {
int (*get_resources)(struct qcom_pcie *pcie);
int (*init)(struct qcom_pcie *pcie);
+ int (*post_init)(struct qcom_pcie *pcie);
void (*deinit)(struct qcom_pcie *pcie);
+ void (*ltssm_enable)(struct qcom_pcie *pcie);
};
struct qcom_pcie {
@@ -116,17 +135,33 @@ static irqreturn_t qcom_pcie_msi_irq_handler(int irq, void *arg)
return dw_handle_msi_irq(pp);
}
-static int qcom_pcie_establish_link(struct qcom_pcie *pcie)
+static void qcom_pcie_v0_v1_ltssm_enable(struct qcom_pcie *pcie)
{
u32 val;
-
- if (dw_pcie_link_up(&pcie->pp))
- return 0;
-
/* enable link training */
val = readl(pcie->elbi + PCIE20_ELBI_SYS_CTRL);
val |= PCIE20_ELBI_SYS_CTRL_LT_ENABLE;
writel(val, pcie->elbi + PCIE20_ELBI_SYS_CTRL);
+}
+
+static void qcom_pcie_v2_ltssm_enable(struct qcom_pcie *pcie)
+{
+ u32 val;
+ /* enable link training */
+ val = readl(pcie->parf + PCIE20_PARF_LTSSM);
+ val |= BIT(8);
+ writel(val, pcie->parf + PCIE20_PARF_LTSSM);
+}
+
+static int qcom_pcie_establish_link(struct qcom_pcie *pcie)
+{
+
+ if (dw_pcie_link_up(&pcie->pp))
+ return 0;
+
+ /* Enable Link Training state machine */
+ if (pcie->ops->ltssm_enable)
+ pcie->ops->ltssm_enable(pcie);
return dw_pcie_wait_for_link(&pcie->pp);
}
@@ -421,6 +456,113 @@ static int qcom_pcie_init_v1(struct qcom_pcie *pcie)
return ret;
}
+static int qcom_pcie_get_resources_v2(struct qcom_pcie *pcie)
+{
+ struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
+ struct device *dev = pcie->pp.dev;
+
+ res->aux_clk = devm_clk_get(dev, "aux");
+ if (IS_ERR(res->aux_clk))
+ return PTR_ERR(res->aux_clk);
+
+ res->cfg_clk = devm_clk_get(dev, "cfg");
+ if (IS_ERR(res->cfg_clk))
+ return PTR_ERR(res->cfg_clk);
+
+ res->master_clk = devm_clk_get(dev, "bus_master");
+ if (IS_ERR(res->master_clk))
+ return PTR_ERR(res->master_clk);
+
+ res->slave_clk = devm_clk_get(dev, "bus_slave");
+ if (IS_ERR(res->slave_clk))
+ return PTR_ERR(res->slave_clk);
+
+ res->pipe_clk = devm_clk_get(dev, "pipe");
+ if (IS_ERR(res->pipe_clk))
+ return PTR_ERR(res->pipe_clk);
+
+ return 0;
+}
+
+static int qcom_pcie_init_v2(struct qcom_pcie *pcie)
+{
+ struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
+ struct device *dev = pcie->pp.dev;
+ u32 val;
+ int ret;
+
+ ret = clk_prepare_enable(res->aux_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable aux clock\n");
+ return ret;
+ }
+
+ ret = clk_prepare_enable(res->cfg_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable cfg clock\n");
+ goto err_cfg_clk;
+ }
+
+ ret = clk_prepare_enable(res->master_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable master clock\n");
+ goto err_master_clk;
+ }
+
+ ret = clk_prepare_enable(res->slave_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable slave clock\n");
+ goto err_slave_clk;
+ }
+
+ /* enable PCIe clocks and resets */
+ val = readl(pcie->parf + PCIE20_PARF_PHY_CTRL);
+ val &= ~BIT(0);
+ writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
+
+ /* change DBI base address */
+ writel(0, pcie->parf + PCIE20_PARF_DBI_BASE_ADDR);
+
+ /* MAC PHY_POWERDOWN MUX DISABLE */
+ val = readl(pcie->parf + PCIE20_PARF_SYS_CTRL);
+ val &= ~BIT(29);
+ writel(val, pcie->parf + PCIE20_PARF_SYS_CTRL);
+
+ val = readl(pcie->parf + PCIE20_PARF_MHI_CLOCK_RESET_CTRL);
+ val |= BIT(4);
+ writel(val, pcie->parf + PCIE20_PARF_MHI_CLOCK_RESET_CTRL);
+
+ val = readl(pcie->parf + MSM8996_PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT);
+ val |= BIT(31);
+ writel(val, pcie->parf + MSM8996_PCIE20_PARF_AXI_MSTR_WR_ADDR_HALT);
+
+ return 0;
+
+err_slave_clk:
+ clk_disable_unprepare(res->master_clk);
+err_master_clk:
+ clk_disable_unprepare(res->cfg_clk);
+err_cfg_clk:
+ clk_disable_unprepare(res->aux_clk);
+
+ return ret;
+}
+
+static int qcom_pcie_post_init_v2(struct qcom_pcie *pcie)
+{
+ struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
+ struct device *dev = pcie->pp.dev;
+ int ret;
+
+ ret = clk_prepare_enable(res->pipe_clk);
+ if (ret) {
+ dev_err(dev, "cannot prepare/enable pipe clock\n");
+ return ret;
+ }
+
+ return 0;
+}
+
static int qcom_pcie_link_up(struct pcie_port *pp)
{
struct qcom_pcie *pcie = to_qcom_pcie(pp);
@@ -429,6 +571,17 @@ static int qcom_pcie_link_up(struct pcie_port *pp)
return !!(val & PCI_EXP_LNKSTA_DLLLA);
}
+static void qcom_pcie_deinit_v2(struct qcom_pcie *pcie)
+{
+ struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
+
+ clk_disable_unprepare(res->pipe_clk);
+ clk_disable_unprepare(res->slave_clk);
+ clk_disable_unprepare(res->master_clk);
+ clk_disable_unprepare(res->cfg_clk);
+ clk_disable_unprepare(res->aux_clk);
+}
+
static void qcom_pcie_host_init(struct pcie_port *pp)
{
struct qcom_pcie *pcie = to_qcom_pcie(pp);
@@ -444,6 +597,9 @@ static void qcom_pcie_host_init(struct pcie_port *pp)
if (ret)
goto err_deinit;
+ if (pcie->ops->post_init)
+ pcie->ops->post_init(pcie);
+
dw_pcie_setup_rc(pp);
if (IS_ENABLED(CONFIG_PCI_MSI))
@@ -487,12 +643,22 @@ static const struct qcom_pcie_ops ops_v0 = {
.get_resources = qcom_pcie_get_resources_v0,
.init = qcom_pcie_init_v0,
.deinit = qcom_pcie_deinit_v0,
+ .ltssm_enable = qcom_pcie_v0_v1_ltssm_enable,
};
static const struct qcom_pcie_ops ops_v1 = {
.get_resources = qcom_pcie_get_resources_v1,
.init = qcom_pcie_init_v1,
.deinit = qcom_pcie_deinit_v1,
+ .ltssm_enable = qcom_pcie_v0_v1_ltssm_enable,
+};
+
+static const struct qcom_pcie_ops ops_v2 = {
+ .get_resources = qcom_pcie_get_resources_v2,
+ .init = qcom_pcie_init_v2,
+ .post_init = qcom_pcie_post_init_v2,
+ .deinit = qcom_pcie_deinit_v2,
+ .ltssm_enable = qcom_pcie_v2_ltssm_enable,
};
static int qcom_pcie_probe(struct platform_device *pdev)
@@ -572,6 +738,7 @@ static const struct of_device_id qcom_pcie_match[] = {
{ .compatible = "qcom,pcie-ipq8064", .data = &ops_v0 },
{ .compatible = "qcom,pcie-apq8064", .data = &ops_v0 },
{ .compatible = "qcom,pcie-apq8084", .data = &ops_v1 },
+ { .compatible = "qcom,pcie-msm8996", .data = &ops_v2 },
{ }
};
--
2.10.1
^ permalink raw reply related
* [PATCH v4 1/3] bus: simple-pm: add support to pm clocks
From: Srinivas Kandagatla @ 2016-11-14 11:15 UTC (permalink / raw)
To: svarbanov, linux-pci, bhelgaas
Cc: robh+dt, linux-arm-msm, srinivas.kandagatla, devicetree
In-Reply-To: <1479122155-13393-1-git-send-email-srinivas.kandagatla@linaro.org>
This patch adds support to pm clocks via device tree, so that the clocks
can be turned on and off during runtime pm. This patch is required for
Qualcomm msm8996 pcie controller which sits on a bus with its own
power-domain and clocks.
Without this patch the clock associated with the bus are never turned on.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
drivers/bus/simple-pm-bus.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
index c5eb46c..63b7e8c 100644
--- a/drivers/bus/simple-pm-bus.c
+++ b/drivers/bus/simple-pm-bus.c
@@ -11,6 +11,7 @@
#include <linux/module.h>
#include <linux/of_platform.h>
#include <linux/platform_device.h>
+#include <linux/pm_clock.h>
#include <linux/pm_runtime.h>
@@ -22,17 +23,26 @@ static int simple_pm_bus_probe(struct platform_device *pdev)
pm_runtime_enable(&pdev->dev);
- if (np)
+ if (np) {
+ of_pm_clk_add_clks(&pdev->dev);
of_platform_populate(np, NULL, NULL, &pdev->dev);
+ }
return 0;
}
+static const struct dev_pm_ops simple_pm_bus_pm_ops = {
+ SET_RUNTIME_PM_OPS(pm_clk_suspend,
+ pm_clk_resume, NULL)
+};
+
static int simple_pm_bus_remove(struct platform_device *pdev)
{
dev_dbg(&pdev->dev, "%s\n", __func__);
pm_runtime_disable(&pdev->dev);
+ pm_clk_destroy(&pdev->dev);
+
return 0;
}
@@ -48,6 +58,7 @@ static struct platform_driver simple_pm_bus_driver = {
.driver = {
.name = "simple-pm-bus",
.of_match_table = simple_pm_bus_of_match,
+ .pm = &simple_pm_bus_pm_ops,
},
};
--
2.10.1
^ permalink raw reply related
* [PATCH v4 0/3] PCI: qcom: Add support to msm8996 pcie controller.
From: Srinivas Kandagatla @ 2016-11-14 11:15 UTC (permalink / raw)
To: svarbanov, linux-pci, bhelgaas
Cc: robh+dt, linux-arm-msm, srinivas.kandagatla, devicetree
This patchset adds support to msm8996 pcie controller. I tested this patch on
v4.9-rc2 along with phy driver patch [1] and
"PCI: designware: check for iATU unroll support after initializing host"
fix [2] on DB820c APQ8096 board on port B and port C using sata and
ethernet controller.
Changes since v3:
- remove unnesessary variable initialization spotted by vivek.
- moved pipe clk disable before other clocks suggested by vivek.
- fixed dt example suggested by Rob.
Changes since v2:
- Removed regulators that belong to phy, spotted by Stephen
- Removed clocks in to simple pm bus driver, spotted by Stephen
- renamed msm8996 ops to v2 ops as suggested by Stephen.
- cleanups as suggested by Stephen.
- Add runtime pm support to driver.
- Added pm clk support to simple pm bus driver.
Changes since v1:
- Fixed dt example as suggested by Rob
- added smmu bus clk dependency as smmu sits in between
system NOC and PCIe.
- Removed smmu configuration from bindings and driver as
the smmu Level2 translation on this SOC is controlled by
the secure world, and level 1 translation is disabled,
so there is one-to-one mapping of the address space.
Thanks,
srini
[1] https://patchwork.kernel.org/patch/9384711/
[2] https://patchwork.kernel.org/patch/9377557/
Srinivas Kandagatla (3):
bus: simple-pm: add support to pm clocks
PCI: qcom: add support to msm8996 PCIE controller
PCI: qcom: add runtime pm support to pcie_port
.../devicetree/bindings/pci/qcom,pcie.txt | 67 +++++++-
drivers/bus/simple-pm-bus.c | 13 +-
drivers/pci/host/pcie-qcom.c | 181 ++++++++++++++++++++-
3 files changed, 254 insertions(+), 7 deletions(-)
--
2.10.1
^ permalink raw reply
* Re: [PATCH v3 5/6] arm64: arch_timer: apci: Introduce a generic aquirk framework for erratum
From: Ding Tianhong @ 2016-11-14 11:15 UTC (permalink / raw)
To: Hanjun Guo, catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
marc.zyngier-5wv7dgnIgG8, mark.rutland-5wv7dgnIgG8,
oss-fOR+EgIDQEHk1uMJSBkQmQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, stuart.yoder-3arQi8VN3Tc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linuxarm-hv44wF8Li93QT0dZR+AlfA,
hanjun.guo-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <582971E0.4070403-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
OK, will wait more feedback and fix them together in the next version.
Thanks.
Ding
On 2016/11/14 16:12, Hanjun Guo wrote:
> On 2016/11/4 21:06, Ding Tianhong wrote:
>> From: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>
>> Introduce a general quirk framework for each timer erratum in ACPI,
>> which use the oem information in GTDT table for platform specific erratums.
>> The struct gtdt_arch_timer_fixup is introduced to record the oem
>> information to match the quirk and handle the erratum.
>>
>> v3: Introduce a generic aquick framework for erratum in ACPI mode.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Ding Tianhong <dingtianhong-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> ---
>> drivers/clocksource/arm_arch_timer.c | 37 ++++++++++++++++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
>> index 3d59af1..9bc93e5 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -1068,6 +1068,40 @@ CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
>> arch_timer_mem_init);
>>
>> #ifdef CONFIG_ACPI
>> +struct gtdt_arch_timer_fixup {
>> + char oem_id[ACPI_OEM_ID_SIZE];
>> + char oem_table_id[ACPI_OEM_TABLE_ID_SIZE];
>> + u32 oem_revision;
>> +
>> + /* quirk handler for arch timer erratum */
>> + void (*handler)(u32 erratum);
>> + u32 erratum;
>
> Hmm, I think we just use
>
> void *context;
>
> and we convert it in the platform specific handler, then this struct
> can be reused for other type of quirks.
>
>> +};
>> +
>> +/* note: this needs to be updated according to the doc of OEM ID
>> + * and TABLE ID for different board.
>> + */
>> +struct gtdt_arch_timer_fixup arch_timer_quirks[] __initdata = {
>> +};
>> +
>> +void __init arch_timer_acpi_quirks_handler(char *oem_id,
>> + char *oem_table_id,
>> + u32 oem_revision)
>> +{
>> + struct gtdt_arch_timer_fixup *quirks = arch_timer_quirks;
>> + int i;
>> +
>> + for (i = 0; i < ARRAY_SIZE(arch_timer_quirks); i++, quirks++) {
>> + if (!memcmp(quirks->oem_id, oem_id, ACPI_OEM_ID_SIZE) &&
>> + !memcmp(quirks->oem_table_id, oem_table_id, ACPI_OEM_TABLE_ID_SIZE) &&
>> + quirks->oem_revision == oem_revision) {
>> + if (quirks->handler && quirks->erratum)
>> + quirks->handler(quirks->erratum);
>> + break;
>
> we can't just break because we have multi quirks for different handlers.
>
> Thanks
> Hanjun
>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/3] PCI: qcom: add support to msm8996 PCIE controller
From: Vivek Gautam @ 2016-11-14 11:13 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: svarbanov, Bjorn Helgaas, linux-pci, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm
In-Reply-To: <2eae2624-fd5e-df55-5261-a49b3fe56a18@linaro.org>
Hi,
On Mon, Nov 14, 2016 at 4:02 PM, Srinivas Kandagatla
<srinivas.kandagatla@linaro.org> wrote:
>
>
> On 09/11/16 10:37, Vivek Gautam wrote:
>>
>> Hi,
>>
>> On Fri, Nov 4, 2016 at 6:29 PM, Srinivas Kandagatla
>> <srinivas.kandagatla@linaro.org> wrote:
>>>
>>> This patch adds support to msm8996/apq8096 pcie, MSM8996 supports
>>> Gen 1/2, One lane, 3 pcie root-complex with support to MSI and
>>> legacy interrupts and it conforms to PCI Express Base 2.1 specification.
>>>
>>> This patch adds post_init callback to qcom_pcie_ops, as this is pcie
>>> pipe clocks are only setup after the phy is powered on.
>>> It also adds ltssm_enable callback as it is very much different to other
>>> supported SOCs in the driver.
>>>
>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>> ---
>>
>>
>> Few minor nits.
>>
>>> .../devicetree/bindings/pci/qcom,pcie.txt | 68 +++++++-
>>> drivers/pci/host/pcie-qcom.c | 177
>>> ++++++++++++++++++++-
>>> 2 files changed, 239 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>>> b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>>> index 4059a6f..4a0538d 100644
>>> --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>>> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>>> @@ -7,6 +7,7 @@
>>> - "qcom,pcie-ipq8064" for ipq8064
>>> - "qcom,pcie-apq8064" for apq8064
>>> - "qcom,pcie-apq8084" for apq8084
>>> + - "qcom,pcie-msm8996" for msm8996 or apq8096
>>
>>
>> Since this works for both apq8096 and msm8996, compatible -
>> "qcom,pcie-apq8096" for uniformity ?
>
>
> AFAIK, compatible is selected based on SOC on which this IP is integrated
> first, So msm8996 seems to be correct, in that way.
>
> Also if we look at clk controller compatible strings, you would see them as
> *msm8996* rather than *8096*.
ok, cool. I didn't notice that. This looks good then.
Thanks
Vivek
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA
From: One Thousand Gnomes @ 2016-11-14 11:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Mark Rutland, zhichang.yuan, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, olof-nZhT3qVonbNeoWH0uzbU5w,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
lorenzo.pieralisi-5wv7dgnIgG8,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA, minyard-HInyCGIudOg,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r, liviu.dudau-5wv7dgnIgG8,
zourongrong-Re5JQEeQqe8AvxtiuMwx3w,
john.garry-hv44wF8Li93QT0dZR+AlfA,
gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA,
zhichang.yuan02-Re5JQEeQqe8AvxtiuMwx3w, kantyzc-9Onoh4P/yGk,
xuwei5-C8/M+/jPZTeaMJb+Lgu22Q, marc.zyngier-5wv7dgnIgG8
In-Reply-To: <5900275.i4NZvtxTcC@wuerfel>
> > It's not a safe assumption for x86 at least. There are a few systems with
> > multiple ISA busses particularly older laptops with a docking station.
>
> But do they have multiple ISA domains? There is no real harm in supporting
> it, the (small) downsides I can think of are:
I don't believe they x86 class ones have multiple ISA domains. But as
I've said I don't know how the electronics in the older ThinkPad worked
when it used two PIIX4s with some LPC or ISA stuff on each.
It works in DOS and unmodified Linux so I'm pretty sure there are no
additional domains. Likewise the various x86 schemes that route some bits
of ISA bus off into strange places work in DOS and don't have any
overlaps.
yenta_socket handles PCI/PCMCIA bridging and routes a range of that flat
ISA space appropriately to the card.
Alan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver
From: Laurent Pinchart @ 2016-11-14 11:10 UTC (permalink / raw)
To: Jyri Sarha
Cc: devicetree, bcousson, khilman, dri-devel, bgolaszewski,
tomi.valkeinen
In-Reply-To: <d035c76e-ca7f-0503-87da-7e93783d1cd0@ti.com>
Hi Jyri,
On Monday 14 Nov 2016 10:49:43 Jyri Sarha wrote:
> On 11/03/16 19:46, Laurent Pinchart wrote:
> >> +Required properties:
> >> > + - compatible: "ti,tfp410"
> >
> > The device is an I2C slave, it should have a reg property. Given that the
> > chip can be used without being controlled through I2C, the reg property
> > should be optional. You should document this clearly, and explain how the
> > DT node can be instantiated as a child of an I2C controller when the I2C
> > interface is used, or in other parts of the device tree otherwise.
>
> Shouldn't I have two different compatible strings if want to make both
> platform driver probe and i2c client probe to work?
I don't think so, it's still the same chip.
> Or can it be done with single compatible string? Would you know of an
> example of such a driver?
You will need to register both a i2c_driver and a platform_driver in the
tfp410 driver. Both will advertise the same compatible string. As you'll have
two probe functions, it should be easy to handle the differences between the
two situations there, with common code shared in common functions. A quick
grep points to at least drivers/power/bq27x00_battery.c as an example (albeit
without DT support).
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: One Thousand Gnomes @ 2016-11-14 11:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Gabriele Paoloni, Yuanzhichang,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org,
benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org,
minyard-HInyCGIudOg@public.gmane.org,
catalin.marinas-5wv7dgnIgG8@public.gmane.org, John Garry,
will.deacon-5wv7dgnIgG8@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, xuwei (O),
Linuxarm, olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
zourongrong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
In-Reply-To: <2825537.ADCNsGqGxn@wuerfel>
On Wed, 09 Nov 2016 22:34:38 +0100
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote:
> > > On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote:
> > > > + /*
> > > > + * The first PCIBIOS_MIN_IO is reserved specifically for
> > > indirectIO.
> > > > + * It will separate indirectIO range from pci host bridge to
> > > > + * avoid the possible PIO conflict.
> > > > + * Set the indirectIO range directly here.
> > > > + */
> > > > + lpcdev->io_ops.start = 0;
> > > > + lpcdev->io_ops.end = PCIBIOS_MIN_IO - 1;
> > > > + lpcdev->io_ops.devpara = lpcdev;
> > > > + lpcdev->io_ops.pfin = hisilpc_comm_in;
> > > > + lpcdev->io_ops.pfout = hisilpc_comm_out;
> > > > + lpcdev->io_ops.pfins = hisilpc_comm_ins;
> > > > + lpcdev->io_ops.pfouts = hisilpc_comm_outs;
> > >
> > > I have to look at patch 2 in more detail again, after missing a few
> > > review
> > > rounds. I'm still a bit skeptical about hardcoding a logical I/O port
> > > range here, and would hope that we can just go through the same
> > > assignment of logical port ranges that we have for PCI buses,
> > > decoupling
> > > the bus addresses from the linux-internal ones.
> >
> > The point here is that we want to avoid any conflict/overlap between
> > the LPC I/O space and the PCI I/O space. With the assignment above
> > we make sure that LPC never interfere with PCI I/O space.
>
> But we already abstract the PCI I/O space using dynamic registration.
> There is no need to hardcode the logical address for ISA, though
> I think we can hardcode the bus address to start at zero here.
Pedantically ISA starts at 0x100. The LPC may start at 0x00 as it also
covers motherboard devices (0x00-0xFF). It is also possible that the
'LPC' space is only partially routed to the PCI bridges because some if
it magially disappears on CPU die (at least on x86) and has done since
the era of socket 7 (eg the Cyrix 6x86 doesn't route 0x22/0x23 out of the
CPU).
Assuming LPC starts at 0 ought to be ok given the PCI root bridge
shouldn't see the transactions.
The LPC or it's equivalent may also not be routed via the PCI bridges at
all, so you could have an LPC mapping that is unused or partially used
with another bus actually getting some classes of LPC traffic - on x86 at
least.
Alan
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] of: changesets: Introduce changeset helper methods
From: Hans de Goede @ 2016-11-14 11:04 UTC (permalink / raw)
To: Frank Rowand, Rob Herring, Pantelis Antoniou
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <582968FA.4020800-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi,
On 14-11-16 08:34, Frank Rowand wrote:
> Hi Hans, Pantelis,
>
> On 11/12/16 18:15, Frank Rowand wrote:
>> On 11/04/16 07:42, Hans de Goede wrote:
>>> From: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>>>
>>> Changesets are very powerful, but the lack of a helper API
>>> makes using them cumbersome. Introduce a simple copy based
>>> API that makes things considerably easier.
>>>
>>> To wit, adding a property using the raw API.
>>>
>>> struct property *prop;
>>> prop = kzalloc(sizeof(*prop)), GFP_KERNEL);
>>> prop->name = kstrdup("compatible");
>>> prop->value = kstrdup("foo,bar");
>>> prop->length = strlen(prop->value) + 1;
>>> of_changeset_add_property(ocs, np, prop);
>>>
>>> while using the helper API
>>>
>>> of_changeset_add_property_string(ocs, np, "compatible",
>>> "foo,bar");
>>>
>>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
>>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> ---
>>> Changes in v2 (hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org):
>>> -Address review comments from:
>>> https://www.spinics.net/lists/kernel/msg2252845.html
>>
>> That points to the May 9 version 1 patches from Pantelis (as expected),
>> but containing 4, not 2, patches. Patch 1/4 was applied. Patch 4/4
>> seems to have disappeared?
>>
>> Pantelis then sent a version 2 set of the patches on May 16.
>>
>> Your version is a modification of the May 9 patches (as would be expected
>> of a version 2). It is confusing to have two different version 2 patch
>> sets. I don't have any brilliant ideas on how this patch set could have
>> been named differently to avoid that confusion.
>>
>> The point of this little side-track is simply to note the existence of two
>> different version 2 series so I won't be confused when I revisit this
>> thread in the future.
>>
>>> -Simplify (and fix) __of_changeset_add_update_property_copy OOM handling
>>> -Remove (by manual inlining) these 2 static helpers:
>>> __of_changeset_add_update_property_u32
>>> __of_changeset_add_update_property_bool
>>> -Remove the following exported helper method:
>>> of_changeset_node_move_to
>>
>> Not all comments were addressed.
>>
>> There are some other changes made that are not noted in the changelog.
>>
>> I am still reading through the patches. I will reply again either with
>> a reviewed-by or specific comments when I finish.
>
> Replying here for the entire patchset (there was no patch 0 to reply to).
>
> After reading through the patches, my reply is meta instead of specific
> comments about the code.
>
> There are very few users of change sets in tree. I do not see the need to
> add these helpers until such users are likely to appear.
>
> I would expect change sets to be _mostly_ used internally by the device tree
> overlay framework, not directly by drivers. If change sets are an attractive
> technology for drivers, I want to approach that usage very carefully to avoid
> inappropriate use, which could be very difficult to reign in after the fact.
>
> Even if helpers should be added, this seems to be an overly complex approach.
> If the need for these helpers becomes apparent I can provide review comments
> with the specifics about how it appears to be overly complex.
>
> Can you please provide some more insights into the needs driving the desire
> to have change set helpers and the expected use cases of them? Please put
> your architect's hat on when replying to this question.
My use case for this is discussed in this thread:
https://www.spinics.net/lists/arm-kernel/msg536111.html
With the dt-bindings for the hardware-manager I want to add here:
https://www.spinics.net/lists/arm-kernel/msg536109.html
Note that there is a lot of discussion in this thread whether or
not this belongs in the kernel. I strongly believe though that
some functionality like this will be needed in the kernel for
ARM+dt devices going forward, just like there is plenty of x86
code which adjusts itself to specific hardware, because whether
we like it or not hardware (revisions) will always have quirks.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-14 10:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev@lists.ozlabs.org, Geert Uytterhoeven,
Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, devicetree@vger.kernel.org, Dirk Behme,
linux-kernel@vger.kernel.org, Linux-Renesas,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <25057157.YlGi2v6RrE@wuerfel>
Hi Arnd,
On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
>> >> v2:
>> >> - Drop SoC families and family names; use fixed "Renesas" instead,
>> >
>> > I think I'd rather have seen the family names left in there, but it's
>> > not important, so up to you.
>>
>> They're not useful for matching, as family names may change anytime, and don't
>> always say much about the hardware capabilities.
>> E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
>> Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
>> SuperH.
>>
>> At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
>
> I think the marketing names are much more useful for humans looking
> at the sysfs files than the kernel doing matching on, but both use
> cases are important.
OK, I'll re-add the family names for humans reading sysfs.
>> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> >> available, else fall back to hardcoded addresses for compatibility
>> >> with existing DTBs,
>> > It does seem wrong to have a device node for a specific register though.
>> > Shouldn't the node be for the block of registers that these are inside
>> > of?
>>
>> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
>> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
>
> It just seems odd to have it at address 0xff000044 when all the other
> devices are at page-aligned addresses. Do you mean that accessing
> 0xff000040 or 0xff000048 will result in a bus-level exception for a
> missing register and just 0xff000044 is actually valid for access,
> or is it just the only thing that is documented?
For PRR, all other registers in the page read as all zeroes on all SoCs that
have it. So it really is a lone register.
>> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
>> we further don't touch at all.
>> On R-Car Gen2, it's not documented, but does exist.
>
> This is where the family names would come in handy ;-) I now have
> no idea which chip(s) you are referring to.
SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
R-Car Gen2 are r8a779[0-4].
> If you know the name of the register block, just put it into DT with
> that name. The driver can trivially add the right offset.
CCCR is different. The amount of registers that read as non-zero depends a lot
on the actual SoC.
HPB/APB is gonna need real DT bindings, which needs some more investigation.
Hence if you don't mind, I'd like to postpone that part, which only affects
the older SoCs. And I'll drop the "renesas,cccr" binding.
For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
waiting for this support. So I'd like to have that dependency in v4.10.
>> >> - Don't register the SoC bus if the chip ID register is missing,
>> >
>> > Why? My objection was to hardcoding the register, not to registering
>> > the device? I think I'd rather see the device registered with an
>> > empty revision string.
>>
>> If there's no chip ID register, there's no reason to use soc_device_match(),
>> as we can always look at a compatible value. All SoCs listed in this driver
>> have a chip ID register.
>
> But you may still have user space tools looking into sysfs, e.g. to
> figure out how to install a kernel that the boot loader can find,
> or which hardware specific distro packages to install.
>
>> if you want me to register the soc_bus for those SoCs regardless, I want to
>> re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
>> registers ;-)
>
> Right. Just don't encode too much knowledge about the SoCs into the
> driver, so we are prepared for adding new ones: We should still look
> for the registers in DT on all chips.
OK, will re-add.
>> >> +static int __init renesas_soc_init(void)
>> >> +{
>> >> + struct soc_device_attribute *soc_dev_attr;
>> >> + const struct of_device_id *match;
>> >> + void __iomem *chipid = NULL;
>> >> + struct soc_device *soc_dev;
>> >> + struct device_node *np;
>> >> + unsigned int product;
>> >> +
>> >> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
>> >> + if (!np)
>> >> + return -ENODEV;
>> >> +
>> >> + of_node_put(np);
>> >> +
>> >> + /* Try PRR first, then CCCR, then hardcoded fallback */
>> >> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
>> >> + if (!np)
>> >> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
>> >> + if (np) {
>> >> + chipid = of_iomap(np, 0);
>> >> + of_node_put(np);
>> >> + } else if (match->data) {
>> >> + chipid = ioremap((uintptr_t)match->data, 4);
>> >> + }
>> >> + if (!chipid)
>> >>
>> >
>> > Here, I'd turn the order around and look for the DT nodes of the
>> > devices first. Only if they are not found, look at the compatible
>> > string of the root node. No need to search for a node though,
>> > you know which one it is when you look for a compatible =
>> > "renesas,r8a73a4".
>>
>> "renesas,r8a73a4" is the root node, not the device, so it does not have the
>> "reg" property for reading the chip ID?
>
> I mean replace of_find_matching_node_and_match() with
> of_match_node(renesas_socs, of_root).
>
> It does the same thing, just more efficiently.
OK (didn't know "of_root" was available for public use ;-)
>> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
>> Hence I always need to look at the root nodes.
>
> Not sure what that would protect you from. Could you have a renesas,cccr
Looks like you forgot to finish your sentence?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 2/3] PCI: qcom: add support to msm8996 PCIE controller
From: Srinivas Kandagatla @ 2016-11-14 10:32 UTC (permalink / raw)
To: Vivek Gautam
Cc: svarbanov, Bjorn Helgaas, linux-pci, Rob Herring, Mark Rutland,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm
In-Reply-To: <CAFp+6iF7rspwXvANoz_3XgC33-CwSYzPvdpwsGK8UAfp064Jxg@mail.gmail.com>
On 09/11/16 10:37, Vivek Gautam wrote:
> Hi,
>
> On Fri, Nov 4, 2016 at 6:29 PM, Srinivas Kandagatla
> <srinivas.kandagatla@linaro.org> wrote:
>> This patch adds support to msm8996/apq8096 pcie, MSM8996 supports
>> Gen 1/2, One lane, 3 pcie root-complex with support to MSI and
>> legacy interrupts and it conforms to PCI Express Base 2.1 specification.
>>
>> This patch adds post_init callback to qcom_pcie_ops, as this is pcie
>> pipe clocks are only setup after the phy is powered on.
>> It also adds ltssm_enable callback as it is very much different to other
>> supported SOCs in the driver.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>
> Few minor nits.
>
>> .../devicetree/bindings/pci/qcom,pcie.txt | 68 +++++++-
>> drivers/pci/host/pcie-qcom.c | 177 ++++++++++++++++++++-
>> 2 files changed, 239 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>> index 4059a6f..4a0538d 100644
>> --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
>> @@ -7,6 +7,7 @@
>> - "qcom,pcie-ipq8064" for ipq8064
>> - "qcom,pcie-apq8064" for apq8064
>> - "qcom,pcie-apq8084" for apq8084
>> + - "qcom,pcie-msm8996" for msm8996 or apq8096
>
> Since this works for both apq8096 and msm8996, compatible -
> "qcom,pcie-apq8096" for uniformity ?
AFAIK, compatible is selected based on SOC on which this IP is
integrated first, So msm8996 seems to be correct, in that way.
Also if we look at clk controller compatible strings, you would see them
as *msm8996* rather than *8096*.
>> +
>> +static int qcom_pcie_init_v2(struct qcom_pcie *pcie)
>> +{
>> + struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
>> + struct device *dev = pcie->pp.dev;
>> + u32 val;
>> + int ret = 0;
>
> you don't need to initialize ret here.
Yep, I will fix it.
>
>> +
>> + ret = clk_prepare_enable(res->aux_clk);
>> + if (ret) {
>> + dev_err(dev, "cannot prepare/enable aux clock\n");
>> + return ret;
>> + }
>
> [snip]
>
>> @@ -429,6 +571,17 @@ static int qcom_pcie_link_up(struct pcie_port *pp)
>> return !!(val & PCI_EXP_LNKSTA_DLLLA);
>> }
>>
>> +static void qcom_pcie_deinit_v2(struct qcom_pcie *pcie)
>> +{
>> + struct qcom_pcie_resources_v2 *res = &pcie->res.v2;
>> +
>> + clk_disable_unprepare(res->slave_clk);
>> + clk_disable_unprepare(res->master_clk);
>> + clk_disable_unprepare(res->cfg_clk);
>> + clk_disable_unprepare(res->aux_clk);
>> + clk_disable_unprepare(res->pipe_clk);
>
> i am sure, this is not affecting the functionality, but the pipe clock
> is enabled after all the clocks.
> so it makes sense to disable it in the first place. you can just move
> this above slave_clk.
Sure.. will fix it.
>
> [snip]
>
^ permalink raw reply
* [PATCH] dt-bindings: Add Keith&Koep vendor prefix
From: Marek Vasut @ 2016-11-14 10:12 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Marek Vasut, Rob Herring, Fabio Estevam, Shawn Guo
Add vendor prefix for Keith&Koep GmbH , http://keith-koep.com/en/
Signed-off-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 721b079..7529de4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -152,6 +152,7 @@ karo Ka-Ro electronics GmbH
keithkoep Keith & Koep GmbH
keymile Keymile GmbH
kinetic Kinetic Technologies
+keithkoep Keith & Koep GmbH
kosagi Sutajio Ko-Usagi PTE Ltd.
kyo Kyocera Corporation
lacie LaCie
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 2/3] dt-bindings: mxsfb: Add new bindings for the MXSFB driver
From: Marek Vasut @ 2016-11-14 10:10 UTC (permalink / raw)
To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Cc: Marek Vasut, Rob Herring, Lucas Stach, Fabio Estevam, Shawn Guo,
Daniel Vetter, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161114101036.3505-1-marex-ynQEQJNshbs@public.gmane.org>
Add new DT bindings for new MXSFB driver that is using the
OF graph to parse the video output structure instead of
hard-coding the display properties into the MXSFB node.
The old MXSFB fbdev driver bindings are preserved in the
same file in the "Old bindings" section.
Signed-off-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Daniel Vetter <daniel.vetter-/w4YWyX8dFk@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
--
V2: - Merge the new bindings into mxsfb.txt file instead of keeping
them in separate mxsfb-drm.txt file.
- Add dedicated compatible for i.MX6SX
- Drop all references to DRM/KMS
- Repair the required bits in clock node
---
.../devicetree/bindings/display/mxsfb.txt | 37 ++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt
index a4431f2..6e92593 100644
--- a/Documentation/devicetree/bindings/display/mxsfb.txt
+++ b/Documentation/devicetree/bindings/display/mxsfb.txt
@@ -1,5 +1,42 @@
* Freescale MXS LCD Interface (LCDIF)
+New bindings:
+=============
+Required properties:
+- compatible: Should be "fsl,imx23-lcdif" for i.MX23.
+ Should be "fsl,imx28-lcdif" for i.MX28.
+ Should be "fsl,imx6sx-lcdif" for i.MX6SX.
+- reg: Address and length of the register set for lcdif
+- interrupts: Should contain lcdif interrupts
+- clocks: A list of phandle + clock-specifier pairs, one for each
+ entry in 'clock-names'.
+- clock-names: A list of clock names. For MXSFB it should contain:
+ - "pix" for the MXSFB block clock
+ - (MX6SX-only) "axi", "disp_axi" for the bus interface clock
+
+Required sub-nodes:
+ - port: The connection to an encoder chip.
+
+Example:
+
+ lcdif1: lcdif@02220000 {
+ compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
+ reg = <0x02220000 0x4000>;
+ interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6SX_CLK_LCDIF1_PIX>,
+ <&clks IMX6SX_CLK_LCDIF_APB>,
+ <&clks IMX6SX_CLK_DISPLAY_AXI>;
+ clock-names = "pix", "axi", "disp_axi";
+
+ port {
+ parallel_out: endpoint {
+ remote-endpoint = <&panel_in_parallel>;
+ };
+ };
+ };
+
+Old bindings:
+=============
Required properties:
- compatible: Should be "fsl,imx23-lcdif" for i.MX23.
Should be "fsl,imx28-lcdif" for i.MX28.
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 1/3] dt-bindings: mxsfb: Indentation cleanup
From: Marek Vasut @ 2016-11-14 10:10 UTC (permalink / raw)
To: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Cc: Marek Vasut, Rob Herring, Lucas Stach, Fabio Estevam, Shawn Guo,
Daniel Vetter, devicetree-u79uwXL29TY76Z2rM5mHXA
Clean up the ad-hoc indentation in the documentation, no functional change.
Signed-off-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Daniel Vetter <daniel.vetter-/w4YWyX8dFk@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
Documentation/devicetree/bindings/display/mxsfb.txt | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt
index 96ec517..a4431f2 100644
--- a/Documentation/devicetree/bindings/display/mxsfb.txt
+++ b/Documentation/devicetree/bindings/display/mxsfb.txt
@@ -1,20 +1,20 @@
* Freescale MXS LCD Interface (LCDIF)
Required properties:
-- compatible: Should be "fsl,<chip>-lcdif". Supported chips include
- imx23 and imx28.
-- reg: Address and length of the register set for lcdif
-- interrupts: Should contain lcdif interrupts
-- display : phandle to display node (see below for details)
+- compatible: Should be "fsl,imx23-lcdif" for i.MX23.
+ Should be "fsl,imx28-lcdif" for i.MX28.
+- reg: Address and length of the register set for lcdif
+- interrupts: Should contain lcdif interrupts
+- display: phandle to display node (see below for details)
* display node
Required properties:
-- bits-per-pixel : <16> for RGB565, <32> for RGB888/666.
-- bus-width : number of data lines. Could be <8>, <16>, <18> or <24>.
+- bits-per-pixel: <16> for RGB565, <32> for RGB888/666.
+- bus-width: number of data lines. Could be <8>, <16>, <18> or <24>.
Required sub-node:
-- display-timings : Refer to binding doc display-timing.txt for details.
+- display-timings: Refer to binding doc display-timing.txt for details.
Examples:
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: Re: [PATCH 3/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: Hans de Goede @ 2016-11-14 10:00 UTC (permalink / raw)
To: Chen-Yu Tsai, Maxime Ripard
Cc: Icenowy Zheng, Jonathan Corbet, Rob Herring, Mark Rutland,
Russell King, linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel, linux-kernel, devicetree, linux-sunxi
In-Reply-To: <CAGb2v677zQGihbz1o2izM-y5GJ4VDApf6-WDJAk3UyZdsK-vWQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
HI,
On 14-11-16 10:09, Chen-Yu Tsai wrote:
> On Mon, Nov 14, 2016 at 4:58 PM, Maxime Ripard
> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> Hi,
>>
>> On Sat, Nov 12, 2016 at 12:46:54AM +0800, Icenowy Zheng wrote:
>>> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
>>>
>>> Add a device tree file for it.
>>>
>>> As there's still no mainline-compatible driver for the SDIO WLAN card on
>>> board (a new card by Allwinner), the mmc1 controller is not enabled yet.
>>>
>>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>> ---
>>> arch/arm/boot/dts/Makefile | 1 +
>>> arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 148 +++++++++++++++++++++++
>>> 2 files changed, 149 insertions(+)
>>> create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index befcd26..9843fb0 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -818,6 +818,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>>> sun8i-a33-sinlinx-sina33.dtb \
>>> sun8i-a83t-allwinner-h8homlet-v2.dtb \
>>> sun8i-a83t-cubietruck-plus.dtb \
>>> + sun8i-h2plus-orangepi-zero.dtb \
>>> sun8i-h3-bananapi-m2-plus.dtb \
>>> sun8i-h3-nanopi-neo.dtb \
>>> sun8i-h3-orangepi-2.dtb \
>>> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>>> new file mode 100644
>>> index 0000000..581f56e
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>>> @@ -0,0 +1,148 @@
>>> +/*
>>> + * Copyright (C) 2016 Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
>>> + *
>>> + * Based on sun8i-h3-orangepi-one.dts, which is:
>>> + * Copyright (C) 2016 Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> + *
>>> + * This file is dual-licensed: you can use it either under the terms
>>> + * of the GPL or the X11 license, at your option. Note that this dual
>>> + * licensing only applies to this file, and not this project as a
>>> + * whole.
>>> + *
>>> + * a) This file is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU General Public License as
>>> + * published by the Free Software Foundation; either version 2 of the
>>> + * License, or (at your option) any later version.
>>> + *
>>> + * This file is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * Or, alternatively,
>>> + *
>>> + * b) Permission is hereby granted, free of charge, to any person
>>> + * obtaining a copy of this software and associated documentation
>>> + * files (the "Software"), to deal in the Software without
>>> + * restriction, including without limitation the rights to use,
>>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>>> + * sell copies of the Software, and to permit persons to whom the
>>> + * Software is furnished to do so, subject to the following
>>> + * conditions:
>>> + *
>>> + * The above copyright notice and this permission notice shall be
>>> + * included in all copies or substantial portions of the Software.
>>> + *
>>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>>> + * OTHER DEALINGS IN THE SOFTWARE.
>>> + */
>>> +
>>> +/dts-v1/;
>>> +#include "sun8i-h2plus.dtsi"
>>> +#include "sunxi-common-regulators.dtsi"
>>> +
>>> +#include <dt-bindings/gpio/gpio.h>
>>> +#include <dt-bindings/input/input.h>
>>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>>> +
>>> +/ {
>>> + model = "Xunlong Orange Pi Zero";
>>> + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus",
>>> + "allwinner,sun8i-h3";
>>
>> You don't need the H3 compatible here.
>>
>>> +
>>> + aliases {
>>> + serial0 = &uart0;
>>> + };
>>> +
>>> + chosen {
>>> + stdout-path = "serial0:115200n8";
>>> + };
>>> +
>>> + leds {
>>> + compatible = "gpio-leds";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
>>> +
>>> + pwr_led {
>>> + label = "orangepi:green:pwr";
>>> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
>>> + default-state = "on";
>>> + };
>>> +
>>> + status_led {
>>> + label = "orangepi:red:status";
>>> + gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
>>> + };
>>> + };
>>> +};
>>> +
>>> +&ehci1 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&mmc0 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
>>> + vmmc-supply = <®_vcc3v3>;
>>> + bus-width = <4>;
>>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
>>> + cd-inverted;
>>> + status = "okay";
>>> +};
>>> +
>>> +&ohci1 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&pio {
>>> + leds_opi0: led_pins@0 {
>>> + allwinner,pins = "PA17";
>>> + allwinner,function = "gpio_out";
>>> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>> + };
>>> +};
>>> +
>>> +&r_pio {
>>> + leds_r_opi0: led_pins@0 {
>>> + allwinner,pins = "PL10";
>>> + allwinner,function = "gpio_out";
>>> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>>> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>>
>> You can drop the drive and pull properties, and could you use the
>> generic pins and function properties for those nodes?
>
> Icenowy,
> Given that sunxi-next is currently broken for the pinctrl stuff,
> you will need this patch to test, until Linus merges it:
>
> https://github.com/wens/linux/commit/e8ce92925a6dd1b2b38ed8699e81d0bc9804de20
>
>>
>>> + };
>>> +};
>>> +
>>> +&uart0 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&uart0_pins_a>;
>>> + status = "okay";
>>> +};
>>> +
>>> +&uart1 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&uart1_pins>;
>>> + status = "disabled";
>>> +};
>>> +
>>> +&uart2 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&uart2_pins>;
>>> + status = "disabled";
>>> +};
>>> +
>>> +&uart3 {
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&uart3_pins>;
>>> + status = "disabled";
>>> +};
>>
>> I'm guessing that those UART are exposed on headers?
>>
>>> +
>>> +&usbphy {
>>> + /* USB VBUS is always on */
>>
>> You can put the always on regulators (I'm guessing reg_vcc5v0 ?) here.
>
> AFAIK the regulator properties are optional the the USB PHY.
> So we probably don't need to add it. Hans (CC-ed) could explain
> his original intent?
I've made the regulators optional exactly for boards like these,
where there is no regulator. Likely the Vbus is simply wired
directly to the 5V DC-in jack. So IMHO adding something like
the fixed reg_vcc5v0 a supply here just makes the dt
harder to read.
Regards,
Hans
>
> Regards
> ChenYu
>
>>
>>> + status = "okay";
>>> +};
>>
>> Thanks,
>> Maxime
>>
>> --
>> Maxime Ripard, Free Electrons
>> Embedded Linux and Kernel engineering
>> http://free-electrons.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox