* [PATCH] ARM: dts: sunxi: Enable UEXT related nodes for Olimex A20 SOM EVB
From: Emmanuel Vadot @ 2016-11-23 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123080350.fstwdfndghk7c5xx@lukather>
On Wed, 23 Nov 2016 09:03:50 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Mon, Nov 21, 2016 at 05:49:11PM +0100, Emmanuel Vadot wrote:
> > UEXT are Universal EXTension connector from Olimex. They embed i2c, spi
> > and uart pins along power in one connector and are found on most,
> > if not all, Olimex boards.
> > The Olimex A20 SOM EVB have two UEXT connector so enable the nodes found on
> > those two connectors.
> >
> > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
>
> Fixed the indentation of the spi pinctrl cells, and applied.
>
> Please note that I'm note planning to send any new pull request, so
> this will likely end up in 4.11.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Sorry about the indentation, I'll be more carefull next time.
Thank you.
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
* [PATCH 1/4] serial: core: Add LED trigger support
From: Mathieu Poirier @ 2016-11-23 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123100106.15969-2-s.hauer@pengutronix.de>
On Wed, Nov 23, 2016 at 11:01:03AM +0100, Sascha Hauer wrote:
> With this patch the serial core provides LED triggers for RX and TX.
>
> As the serial core layer does not know when the hardware actually sends
> or receives characters, this needs help from the UART drivers. The
> LED triggers are registered in uart_add_led_triggers() called from
> the UART drivers which want to support LED triggers. All the driver
> has to do then is to call uart_led_trigger_[tx|rx] to indicate
> activite.
Hello Sascha,
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> drivers/tty/serial/serial_core.c | 73 ++++++++++++++++++++++++++++++++++++++++
> include/linux/serial_core.h | 10 ++++++
> 2 files changed, 83 insertions(+)
>
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index f2303f3..3e8afb7 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -34,6 +34,7 @@
> #include <linux/serial_core.h>
> #include <linux/delay.h>
> #include <linux/mutex.h>
> +#include <linux/leds.h>
>
> #include <asm/irq.h>
> #include <asm/uaccess.h>
> @@ -2703,6 +2704,77 @@ static const struct attribute_group tty_dev_attr_group = {
> .attrs = tty_dev_attrs,
> };
>
> +void uart_led_trigger_tx(struct uart_port *uport)
> +{
> + unsigned long delay = 50;
> +
> + led_trigger_blink_oneshot(uport->led_trigger_tx, &delay, &delay, 0);
> +}
> +
> +void uart_led_trigger_rx(struct uart_port *uport)
> +{
> + unsigned long delay = 50;
> +
> + led_trigger_blink_oneshot(uport->led_trigger_rx, &delay, &delay, 0);
For both rx/tx the core constrains the delay_on/off along with the inversion.
Instead of adding the led_trigger_rx/tx and led_trigger_rx/tx_name to the
struct uart_port, wouldn't it be better to add a new struct led_trigger that
would encapsulate those along wit the on/off delay and the inversion?
That way those values could be communicated to the core at registration time
instead of hard-coding things.
> +}
> +
> +/**
> + * uart_add_led_triggers - register LED triggers for a UART
> + * @drv: pointer to the uart low level driver structure for this port
> + * @uport: uart port structure to use for this port.
> + *
> + * Called by the driver to register LED triggers for a UART. It's the
> + * drivers responsibility to call uart_led_trigger_rx/tx on received
> + * and transmitted chars then.
> + */
> +int uart_add_led_triggers(struct uart_driver *drv, struct uart_port *uport)
> +{
> + int ret;
> +
> + if (!IS_ENABLED(CONFIG_LEDS_TRIGGERS))
> + return 0;
Since this is a public interface, checking for valid led_trigger_tx/rx before
moving on with the rest of the initialisation is probably a good idea.
Thanks,
Mathieu
> +
> + uport->led_trigger_tx_name = kasprintf(GFP_KERNEL, "%s%d-tx",
> + drv->dev_name, uport->line);
> + uport->led_trigger_rx_name = kasprintf(GFP_KERNEL, "%s%d-rx",
> + drv->dev_name, uport->line);
> + if (!uport->led_trigger_tx_name || !uport->led_trigger_rx_name) {
> + ret = -ENOMEM;
> + goto err_alloc;
> + }
> +
> + led_trigger_register_simple(uport->led_trigger_tx_name,
> + &uport->led_trigger_tx);
> + led_trigger_register_simple(uport->led_trigger_rx_name,
> + &uport->led_trigger_rx);
> +
> + return 0;
> +
> +err_alloc:
> + kfree(uport->led_trigger_tx_name);
> + kfree(uport->led_trigger_rx_name);
> +
> + return ret;
> +}
> +
> +/**
> + * uart_remove_led_triggers - remove LED triggers
> + * @drv: pointer to the uart low level driver structure for this port
> + * @uport: uart port structure to use for this port.
> + *
> + * Remove LED triggers previously registered with uart_add_led_triggers
> + */
> +void uart_remove_led_triggers(struct uart_port *uport)
> +{
> + if (uport->led_trigger_rx)
> + led_trigger_unregister_simple(uport->led_trigger_rx);
> + kfree(uport->led_trigger_rx_name);
> +
> + if (uport->led_trigger_tx)
> + led_trigger_unregister_simple(uport->led_trigger_tx);
> + kfree(uport->led_trigger_tx_name);
> +}
> +
> /**
> * uart_add_one_port - attach a driver-defined port structure
> * @drv: pointer to the uart low level driver structure for this port
> @@ -2872,6 +2944,7 @@ int uart_remove_one_port(struct uart_driver *drv, struct uart_port *uport)
> WARN_ON(atomic_dec_return(&state->refcount) < 0);
> wait_event(state->remove_wait, !atomic_read(&state->refcount));
> state->uart_port = NULL;
> +
> mutex_unlock(&port->mutex);
> out:
> mutex_unlock(&port_mutex);
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index 3442014..1b0a169 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -29,6 +29,7 @@
> #include <linux/tty.h>
> #include <linux/mutex.h>
> #include <linux/sysrq.h>
> +#include <linux/leds.h>
> #include <uapi/linux/serial_core.h>
>
> #ifdef CONFIG_SERIAL_CORE_CONSOLE
> @@ -249,6 +250,10 @@ struct uart_port {
> const struct attribute_group **tty_groups; /* all attributes (serial core use only) */
> struct serial_rs485 rs485;
> void *private_data; /* generic platform data pointer */
> + struct led_trigger *led_trigger_rx;
> + char *led_trigger_rx_name;
> + struct led_trigger *led_trigger_tx;
> + char *led_trigger_tx_name;
> };
>
> static inline int serial_port_in(struct uart_port *up, int offset)
> @@ -392,6 +397,11 @@ void uart_console_write(struct uart_port *port, const char *s,
> unsigned int count,
> void (*putchar)(struct uart_port *, int));
>
> +int uart_add_led_triggers(struct uart_driver *drv, struct uart_port *uport);
> +void uart_remove_led_triggers(struct uart_port *uport);
> +void uart_led_trigger_tx(struct uart_port *port);
> +void uart_led_trigger_rx(struct uart_port *port);
> +
> /*
> * Port/driver registration/removal
> */
> --
> 2.10.2
>
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-11-23 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F931E08@lhreml507-mbx>
On Wednesday, November 23, 2016 3:22:33 PM CET Gabriele Paoloni wrote:
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> > On Friday, November 18, 2016 5:03:11 PM CET Gabriele Paoloni wrote:
> > > I think this is effectively what we are doing so far with patch 2/3.
> > > The problem with this patch is that we are carving out a "forbidden"
> > > IO tokens range that goes from 0 to PCIBIOS_MIN_IO.
> > >
> > > I think that the proper solution would be to have the LPC driver to
> > > set the carveout threshold used in pci_register_io_range(),
> > > pci_pio_to_address(), pci_address_to_pio(), but this would impose
> > > a probe dependency on the LPC itself that should be probed before
> > > the PCI controller (or before any other devices calling these
> > > functions...)
> >
> > Why do you think the order matters? My point was that we should
> > be able to register any region of logical port numbers for any
> > bus here.
>
> Maybe I have not followed well so let's roll back to your previous
> comment...
>
> "we need to associate a bus address with a logical Linux port number,
> both in of_address_to_resource and in inb()/outb()"
>
> Actually of_address_to_resource() returns the port number to used
> in inb/outb(); inb() and outb() add the port number to PCI_IOBASE
> to rd/wr to the right virtual address.
Correct.
> Our LPC cannot operate on the virtual address and it operates on
> a bus address range that for LPC is also equal to the cpu address
> range and goes from 0 to 0x1000.
There is no "cpu address" here, otherwise this is correct.
> Now as I understand it is risky and not appropriate to reserve
> the logical port numbers from 0 to 0x1000 or to whatever other
> upper bound because existing systems may rely on these port numbers
> retrieved by __of_address_to_resource().
Right again.
> In this scenario I think the best thing to do would be
> in the probe function of the LPC driver:
> 1) call pci_register_io_range() passing [0, 0x1000] (that is the
> range for LPC)
pci_register_io_range() takes a physical address, not a port number,
so that would not be appropriate as you say above. We can however
add a variant that reserves a range of port numbers in io_range_list
for an indirect access method.
> 2) retrieve the logical port numbers associated to the LPC range
> by calling pci_address_to_pio() for 0 and 0x1000 and assign
> them to extio_ops_node->start and extio_ops_node->end
Again, calling pci_address_to_pio() doesn't seem right here, because
we don't have a phys_addr_t address
> 3) implement the LPC accessors to operate on the logical ports
> associated to the LPC range (in practice in the accessors
> implementation we will call pci_pio_to_address to retrieve
> the cpu address to operate on)
Please don't proliferate the use of
pci_pio_to_address/pci_address_to_pio here, computing the physical
address from the logical address is trivial, you just need to
subtract the start of the range that you already use when matching
the port number range.
The only thing we need here is to make of_address_to_resource()
return the correct logical port number that was registered for
a given host device when asked to translate an address that
does not have a CPU address associated with it.
Arnd
^ permalink raw reply
* [PATCH 1/7] add binding for stm32 multifunctions timer driver
From: Benjamin Gaignard @ 2016-11-23 17:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123092148.GO10134@dell.home>
2016-11-23 10:21 GMT+01:00 Lee Jones <lee.jones@linaro.org>:
> On Wed, 23 Nov 2016, Benjamin Gaignard wrote:
>
>> 2016-11-22 17:52 GMT+01:00 Lee Jones <lee.jones@linaro.org>:
>> > On Tue, 22 Nov 2016, Benjamin Gaignard wrote:
>> >
>> >> Add bindings information for stm32 timer MFD
>> >>
>> >> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> >> ---
>> >> .../devicetree/bindings/mfd/stm32-timer.txt | 53 ++++++++++++++++++++++
>> >> 1 file changed, 53 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timer.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mfd/stm32-timer.txt b/Documentation/devicetree/bindings/mfd/stm32-timer.txt
>> >> new file mode 100644
>> >> index 0000000..3cefce1
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/mfd/stm32-timer.txt
>> >> @@ -0,0 +1,53 @@
>> >> +STM32 multifunctions timer driver
>> >
>> > "STM32 Multi-Function Timer/PWM device bindings"
>> >
>> > Doesn't this shared device have a better name?
>>
>> In SoC documentation those hardware blocks are named "advanced-control
>> timers", "general purpose timers" or "basic timers"
>> "stm32-timer" name is already used for clock source driver, that why I
>> have prefix it with mfd
>
> MFD is a Linuxisum and has no place in hardware description.
>
> Please used one of the names you mentioned above.
I will go for "st,stm32-advanced-timer"
>
> Hopefully the one that best fits.
>
>> >> +stm32 timer MFD allow to handle at the same time pwm and IIO timer devices
>> >
>> > No need for this sentence.
>> >
>> OK
>>
>> >> +Required parameters:
>> >> +- compatible: must be one of the follow value:
>> >> + "st,stm32-mfd-timer1"
>> >> + "st,stm32-mfd-timer2"
>> >> + "st,stm32-mfd-timer3"
>> >> + "st,stm32-mfd-timer4"
>> >> + "st,stm32-mfd-timer5"
>> >> + "st,stm32-mfd-timer6"
>> >> + "st,stm32-mfd-timer7"
>> >> + "st,stm32-mfd-timer8"
>> >> + "st,stm32-mfd-timer9"
>> >> + "st,stm32-mfd-timer10"
>> >> + "st,stm32-mfd-timer11"
>> >> + "st,stm32-mfd-timer12"
>> >> + "st,stm32-mfd-timer13"
>> >> + "st,stm32-mfd-timer14"
>> >
>> > We don't normally number devices.
>> >
>> > What's stopping you from simply doing:
>> >
>> > pwm1: pwm1 at 40010000 {
>> > compatible = "st,stm32-pwm";
>> > };
>> > pwm2: pwm1 at 40020000 {
>> > compatible = "st,stm32-pwm";
>> > };
>> > pwm3: pwm1 at 40030000 {
>> > compatible = "st,stm32-pwm";
>> > };
>> >
>>
>> Because each instance of the hardware is slightly different: number of
>> pwm channels, triggers capabilities, etc ..
>> so I need to distinguish them.
>> Since it look to be a problem I will follow your suggestion and add a
>> property this driver to be able to identify each instance.
>> Do you think that "id" parameter (integer for 1 to 14) is acceptable ?
>
> Unfortunately not. IDs aren't allowed in DT.
>
> What about "pwm-chans" and "trigger"?
>
> pwm-chans : Number of available channels available
For pwm I need those 4 properties:
st,pwm-number: the number of PWM devices
st,complementary: if exist have complementary ouput
st,32bit-counter: if exist have 32 bits counter
st,breakinput-polarity: if set enable break input feature.
Is it acceptable from pwm maintainer point of view ?
> trigger : Boolean value specifying whether a timer is present
Following our discussion on IRC I will try to code for your proposal:
advanced-timer at 40010000 {
compatible = "st,stm32-advanced-timer";
reg = <0x40010000 0x400>;
clocks = <&rcc 0 160>;
clock-names = "clk_int";
pwm at 0 {
compatible = "st,stm32-pwm";
st,pwm-number= <4>;
st,complementary;
st,breakinput;
};
timer at 0 {
reg = <1>;
compatible = "st,stm32-iio-timer";
interrupts = <27>;
triggers = <5 2 3 4>;
};
};
triggers parameter will be used to know which trigger are valid for
the IIO device
[snip]
^ permalink raw reply
* [PATCH 3/3] ARM: dts: da850: Add node for pullup/pulldown pinconf
From: David Lechner @ 2016-11-23 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8c3e6535-4b79-9731-f801-c13f007e48ab@ti.com>
On 11/23/2016 05:12 AM, Sekhar Nori wrote:
> On Wednesday 23 November 2016 08:59 AM, David Lechner wrote:
>> This SoC has a separate pin controller for configuring pullup/pulldown
>> bias on groups of pins.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>> ---
>> arch/arm/boot/dts/da850.dtsi | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 8945815..1c0224c 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -210,6 +210,11 @@
>> };
>>
>> };
>> + pinconf: pin-controller at 22c00c {
>> + compatible = "ti,da850-pupd";
>> + reg = <0x22c00c 0x8>;
>> + status = "disabled";
>> + };
>
> Can you please place this below the i2c1 node. I am trying to keep the
> nodes sorted by unit address. I know thats broken in many places today,
> but lets add the new ones where they should eventually end up.
I can do this, but it seems that the predominant sorting pattern here is
to keep subsystems together (e.g. all i2c are together, all uart are
together, etc.)
Would a separate patch to sort everything by unit address to get this
cleaned up be acceptable?
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH 2/3] pinctrl: New driver for TI DA8XX/OMAP-L138/AM18XX pinconf
From: David Lechner @ 2016-11-23 16:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <88b3d16b-6e5b-ea75-d770-35d9adc6c677@ti.com>
On 11/23/2016 05:04 AM, Sekhar Nori wrote:
> On Wednesday 23 November 2016 08:59 AM, David Lechner wrote:
>> This adds a new driver for pinconf on TI DA8XX/OMAP-L138/AM18XX. These
>
> s/DA8XX/DA850/
>
>> SoCs have a separate controller for controlling pullup/pulldown groups.
>>
>> Signed-off-by: David Lechner <david@lechnology.com>
>
>> +static const char *da850_pupd_get_get_group_name(struct pinctrl_dev *pctldev,
>> + unsigned int selector)
>> +{
>> + return da850_pupd_group_names[selector];
>> +}
>> +
>> +static int da850_pupd_get_get_group_pins(struct pinctrl_dev *pctldev,
>> + unsigned int selector,
>> + const unsigned int **pins,
>> + unsigned int *num_pins)
>> +{
>> + *num_pins = 0;
>> +
>> + return 0;
>> +}
>
> usage of get_get_ in the function names above is odd.
Will fix (copy/paste error)
>
> Thanks,
> Sekhar
>
^ permalink raw reply
* [PATCH 2/2] ARM64: dts: meson-gxm: add SCPI configuration for GXM
From: Martin Blumenstingl @ 2016-11-23 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123162040.24843-1-martin.blumenstingl@googlemail.com>
This adds the SCPI DVFS clock index and configures the CPU cores
accordingly.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
index c1974bb..2b1d276e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
@@ -85,6 +85,7 @@
reg = <0x0 0x100>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 1>;
};
cpu5: cpu at 101 {
@@ -93,6 +94,7 @@
reg = <0x0 0x101>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 1>;
};
cpu6: cpu at 102 {
@@ -101,6 +103,7 @@
reg = <0x0 0x102>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 1>;
};
cpu7: cpu at 103 {
@@ -109,6 +112,12 @@
reg = <0x0 0x103>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 1>;
};
};
};
+
+&scpi_dvfs {
+ clock-indices = <0 1>;
+ clock-output-names = "vbig", "vlittle";
+};
--
2.10.2
^ permalink raw reply related
* [PATCH 1/2] ARM64: dts: meson-gx: move the SCPI and SRAM nodes to meson-gx
From: Martin Blumenstingl @ 2016-11-23 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123162040.24843-1-martin.blumenstingl@googlemail.com>
SCPI and SRAM are identical on GXBB and GXL. Moving the corresponding
nodes to meson-gx adds support for the thermal sensor on GXL based
devices.
While here, also rename the second compatible string because
"arm,legacy-scpi" was replaced by "arm,scpi-pre-1.0".
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 45 +++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 57 -----------------------------
2 files changed, 45 insertions(+), 57 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index fc033c0..47ab306 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -65,6 +65,7 @@
reg = <0x0 0x0>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 0>;
};
cpu1: cpu at 1 {
@@ -73,6 +74,7 @@
reg = <0x0 0x1>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 0>;
};
cpu2: cpu at 2 {
@@ -81,6 +83,7 @@
reg = <0x0 0x2>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 0>;
};
cpu3: cpu at 3 {
@@ -89,6 +92,7 @@
reg = <0x0 0x3>;
enable-method = "psci";
next-level-cache = <&l2>;
+ clocks = <&scpi_dvfs 0>;
};
l2: l2-cache0 {
@@ -153,6 +157,28 @@
};
};
+ scpi {
+ compatible = "amlogic,meson-gxbb-scpi", "arm,scpi-pre-1.0";
+ mboxes = <&mailbox 1 &mailbox 2>;
+ shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
+
+ clocks {
+ compatible = "arm,scpi-clocks";
+
+ scpi_dvfs: scpi_clocks at 0 {
+ compatible = "arm,scpi-dvfs-clocks";
+ #clock-cells = <1>;
+ clock-indices = <0>;
+ clock-output-names = "vcpu";
+ };
+ };
+
+ scpi_sensors: sensors {
+ compatible = "arm,scpi-sensors";
+ #thermal-sensor-cells = <1>;
+ };
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
@@ -264,6 +290,25 @@
#address-cells = <0>;
};
+ sram: sram at c8000000 {
+ compatible = "amlogic,meson-gxbb-sram", "mmio-sram";
+ reg = <0x0 0xc8000000 0x0 0x14000>;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0xc8000000 0x14000>;
+
+ cpu_scp_lpri: scp-shmem at 0 {
+ compatible = "amlogic,meson-gxbb-scp-shmem";
+ reg = <0x13000 0x400>;
+ };
+
+ cpu_scp_hpri: scp-shmem at 200 {
+ compatible = "amlogic,meson-gxbb-scp-shmem";
+ reg = <0x13400 0x400>;
+ };
+ };
+
aobus: aobus at c8100000 {
compatible = "simple-bus";
reg = <0x0 0xc8100000 0x0 0x100000>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index ac5ad3b..76465e7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -50,28 +50,6 @@
/ {
compatible = "amlogic,meson-gxbb";
- scpi {
- compatible = "amlogic,meson-gxbb-scpi";
- mboxes = <&mailbox 1 &mailbox 2>;
- shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
-
- clocks {
- compatible = "arm,scpi-clocks";
-
- scpi_dvfs: scpi_clocks at 0 {
- compatible = "arm,scpi-dvfs-clocks";
- #clock-cells = <1>;
- clock-indices = <0>;
- clock-output-names = "vcpu";
- };
- };
-
- scpi_sensors: sensors {
- compatible = "arm,scpi-sensors";
- #thermal-sensor-cells = <1>;
- };
- };
-
soc {
usb0_phy: phy at c0000000 {
compatible = "amlogic,meson-gxbb-usb2-phy";
@@ -93,25 +71,6 @@
status = "disabled";
};
- sram: sram at c8000000 {
- compatible = "amlogic,meson-gxbb-sram", "mmio-sram";
- reg = <0x0 0xc8000000 0x0 0x14000>;
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges = <0 0x0 0xc8000000 0x14000>;
-
- cpu_scp_lpri: scp-shmem at 0 {
- compatible = "amlogic,meson-gxbb-scp-shmem";
- reg = <0x13000 0x400>;
- };
-
- cpu_scp_hpri: scp-shmem at 200 {
- compatible = "amlogic,meson-gxbb-scp-shmem";
- reg = <0x13400 0x400>;
- };
- };
-
usb0: usb at c9000000 {
compatible = "amlogic,meson-gxbb-usb", "snps,dwc2";
reg = <0x0 0xc9000000 0x0 0x40000>;
@@ -138,22 +97,6 @@
};
};
-&cpu0 {
- clocks = <&scpi_dvfs 0>;
-};
-
-&cpu1 {
- clocks = <&scpi_dvfs 0>;
-};
-
-&cpu2 {
- clocks = <&scpi_dvfs 0>;
-};
-
-&cpu3 {
- clocks = <&scpi_dvfs 0>;
-};
-
&cbus {
spifc: spi at 8c80 {
compatible = "amlogic,meson-gxbb-spifc";
--
2.10.2
^ permalink raw reply related
* [PATCH 0/2] minor GXL and GXM improvements
From: Martin Blumenstingl @ 2016-11-23 16:20 UTC (permalink / raw)
To: linux-arm-kernel
This series adds SCPI support to GXL and GXM SoCs by moving the nodes
to meson-gx.dtsi. Additionally this updates the compatible string to
match the recent changes, see [0]
Now that we have SCPI support for GXM we can also use it to configure
the CPU cores using the SCPI DVFS clocks.
[0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001632.html
Martin Blumenstingl (2):
ARM64: dts: meson-gx: move the SCPI and SRAM nodes to meson-gx
ARM64: dts: meson-gxm: add SCPI configuration for GXM
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 45 +++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 57 -----------------------------
arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 9 +++++
3 files changed, 54 insertions(+), 57 deletions(-)
--
2.10.2
^ permalink raw reply
* [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: David Lechner @ 2016-11-23 16:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJVqog0Fno_DO0NQKmVNvzu5d=3GOLk145wBmB-V70BLeg@mail.gmail.com>
On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
> 2016-11-22 23:23 GMT+01:00 David Lechner <david@lechnology.com>:
>> On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
>>>
>>> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
>>> controller drivers to da850.dtsi.
>>>
>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>> ---
>>> v1 -> v2:
>>> - moved the priority controller node above the cfgchip node
>>> - renamed added nodes to better reflect their purpose
>>>
>>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index 1bb1f6d..412eec6 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -210,6 +210,10 @@
>>> };
>>>
>>> };
>>> + prictrl: priority-controller at 14110 {
>>> + compatible = "ti,da850-mstpri";
>>> + reg = <0x14110 0x0c>;
>>
>>
>> I think we should add status = "disabled"; here and let boards opt in.
>>
>>> + };
>>> cfgchip: chip-controller at 1417c {
>>> compatible = "ti,da830-cfgchip", "syscon",
>>> "simple-mfd";
>>> reg = <0x1417c 0x14>;
>>> @@ -451,4 +455,8 @@
>>> 1 0 0x68000000 0x00008000>;
>>> status = "disabled";
>>> };
>>> + memctrl: memory-controller at b0000000 {
>>> + compatible = "ti,da850-ddr-controller";
>>> + reg = <0xb0000000 0xe8>;
>>
>>
>> same here. status = "disabled";
>>
>>> + };
>>> };
>>>
>
> Hi David,
>
> I did that initially[1][2] and it was rejected by Kevin[3] and Laurent[4].
>
> FYI this patch has already been queued by Sekhar.
Thanks. I did not see those threads.
FYI to maintainers, having these enabled by default causes error
messages in the kernel log for other boards that are not supported by
the drivers. Since there is only one board that is supported and soon to
be 2 that are not, I would rather have this disabled by default to avoid
the error messages.
>
> Best regards,
> Bartosz Golaszewski
>
> [1] https://www.spinics.net/lists/arm-kernel/msg539638.html
> [2] http://www.spinics.net/lists/devicetree/msg148575.html
> [3] http://www.spinics.net/lists/devicetree/msg148667.html
> [4] http://www.spinics.net/lists/devicetree/msg148655.html
>
^ permalink raw reply
* reboot fails on at91sam9g20 with kernel 4.x
From: Alexander Dahl @ 2016-11-23 16:13 UTC (permalink / raw)
To: linux-arm-kernel
Hei hei,
while upgrading a at91sam9g20 based board to a recent kernel I stumbled
over a problem I can not solve by myself. We have a board which is more
or less a stripped down version of the at91sam9g20ek. The kernels I was
trying lately with a custom DT were 3.14.79, 3.18.44 (didn't work),
4.4.32, 4.8.6 and 4.9-rc6+. The rootfs is built with
OSELAS.Toolchain-2014.12.2, ptxdist 2016.11.0, gcc 4.9.2, glibc 2.20,
busybox v1.24.2 and it's on a UBIFS on NAND flash.
The following happens if I try to reboot a 4.x kernel from console:
The system is going down NOW!
Sent SIGTERM to all processes
macb fffc4000.ethernet eth0: link down
Requesting system reboot
reboot: Restarting system
Reboot failed -- System halted
The last message obviously comes from arch/arm/kernel/reboot.c and
something fails. ;-)
Searching the web I found someone having a similar problem here:
https://groups.google.com/forum/#!topic/acmesystems/vC_66zmcatk
Reboot works with 3.x kernels (if they run at all). I'll try a 4.1
tomorrow, but I would be happy if someone could assist me in debugging
this.
Greets
Alex
^ permalink raw reply
* [PATCH v2] ARM: dts: am335x-baltos: use phy-phandle declarations
From: Tony Lindgren @ 2016-11-23 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479916166-6633-1-git-send-email-yegorslists@googlemail.com>
* yegorslists at googlemail.com <yegorslists@googlemail.com> [161123 07:49]:
> From: Yegor Yefremov <yegorslists@googlemail.com>
>
> phy-phandle is now a preferred method to reference a PHY device.
> Especially in regards to cpsw it enables PHY specific settings like
> max-speed etc. being specified in DTS.
Applying into omap-for-v4.10/dt thanks.
Tony
^ permalink raw reply
* [RFC PATCH 03/11] ARM: omap: do not select HIGHMEM explicitly
From: Vladimir Murzin @ 2016-11-23 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123154957.GD4082@atomide.com>
On 23/11/16 15:49, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@armlinux.org.uk> [161122 01:51]:
>> On Tue, Nov 22, 2016 at 09:26:00AM +0000, Vladimir Murzin wrote:
>>> Explicit selection of HIGHMEM breaks NOMMU builds. It seems that
>>> HIGHMEM is user selectable option, so probably it would be better to
>>> let user to make a decision on this options or, at least, move it to
>>> defconfig.
>>
>> That's kind of the point of ARCH_OMAP2PLUS_TYPICAL - it's a user
>> option to let the user select a range of options for typical OMAP2+
>> configurations, so that the user doesn't have to dig around looking
>> for multiple options, some of which are hard requirements for OMAP
>> to be functional. OMAP is a particularly difficult case because the
>> hardware tends to be very complex.
>>
>> However, HIGHMEM should never be a requirement to boot, so this looks
>> sane.
>
> Yeah we can add that to the defconfig:
>
> Acked-by: Tony Lindgren <tony@atomide.com>
>
Thanks!
Vladimir
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Vladimir Murzin @ 2016-11-23 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123154829.GA2489@afzalpc>
On 23/11/16 15:48, Afzal Mohammed wrote:
> Hi,
>
> On Tue, Nov 22, 2016 at 04:57:31PM +0000, Vladimir Murzin wrote:
>
>> I used defconfigs
>
> Which defconfig was used ?
>
I had a script to traverse config directory, but seems that I messed
things up.
Now I'm running allmodconfig per Arnd suggestion.
> multi_v7_defconfig, MMU & SMP disabled - thus spake the compiler,
>
> kernel/built-in.o: In function `kimage_free_entry':
> memremap.c:(.text+0x4dafc): undefined reference to
> `arch_phys_to_idmap_offset'
> memremap.c:(.text+0x4db04): undefined reference to
> `arch_phys_to_idmap_offset'
> kernel/built-in.o: In function `kimage_alloc_page':
> memremap.c:(.text+0x4dbc0): undefined reference to
> `arch_phys_to_idmap_offset'
> memremap.c:(.text+0x4dbc8): undefined reference to
> `arch_phys_to_idmap_offset'
> memremap.c:(.text+0x4dc1c): undefined reference to
> `arch_phys_to_idmap_offset'
> kernel/built-in.o:memremap.c:(.text+0x4dc30): more undefined
> references to `arch_phys_to_idmap_offset' follow
I think this one is fixed by
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 8e7496c..c3349b9 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2019,7 +2019,7 @@ config XIP_PHYS_ADDR
config KEXEC
bool "Kexec system call (EXPERIMENTAL)"
depends on (!SMP || PM_SLEEP_SMP)
- depends on !CPU_V7M
+ depends on MMU
select KEXEC_CORE
help
kexec is a system call that implements the ability to shutdown your
but there are others I'm working on.
>
> multi_v7_defconfig & MMU disabled, stderr was more verbose and was
> unhappy with Kconfig dependencies,
>
> warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects
> SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL &&
> MMU)
> warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects
> SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL &&
> MMU)
These we fixed in 9001214 ("ARM: imx: no need to select SMP_ON_UP explicitly")
>
> Ulterior motive here is to try !MMU on Cortex A
>
Thanks for trying it. Just a gentle remainder not to forget to set DRAM_BASE
and DRAM_SIZE ;)
> Regards
> afzal
>
^ permalink raw reply related
* [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible
From: Marcin Wojtas @ 2016-11-23 16:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mvgqmjiy.fsf@free-electrons.com>
Hi Gregory,
2016-11-23 14:07 GMT+01:00 Gregory CLEMENT <gregory.clement@free-electrons.com>:
> Hi Jisheng, Arnd,
>
>
> Thanks for your feedback.
>
>
> On mer., nov. 23 2016, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Wednesday, November 23, 2016 5:53:41 PM CET Jisheng Zhang wrote:
>>> On Tue, 22 Nov 2016 22:04:12 +0100 Arnd Bergmann wrote:
>>>
>>> > On Tuesday, November 22, 2016 5:48:41 PM CET Gregory CLEMENT wrote:
>>> > > +#ifdef CONFIG_64BIT
>>> > > + void *data_tmp;
>>> > > +
>>> > > + /* In Neta HW only 32 bits data is supported, so in order to
>>> > > + * obtain whole 64 bits address from RX descriptor, we store
>>> > > + * the upper 32 bits when allocating buffer, and put it back
>>> > > + * when using buffer cookie for accessing packet in memory.
>>> > > + * Frags should be allocated from single 'memory' region,
>>> > > + * hence common upper address half should be sufficient.
>>> > > + */
>>> > > + data_tmp = mvneta_frag_alloc(pp->frag_size);
>>> > > + if (data_tmp) {
>>> > > + pp->data_high = (u64)upper_32_bits((u64)data_tmp) << 32;
>>> > > + mvneta_frag_free(pp->frag_size, data_tmp);
>>> > > + }
>>> > >
>>> >
>>> > How does this work when the region spans a n*4GB address boundary?
>>>
>>> indeed. We also make use of this driver on 64bit platforms. We use
>>> different solution to make the driver 64bit safe.
>>>
>>> solA: make use of the reserved field in the mvneta_rx_desc, such
>>> as reserved2 etc. Yes, the field is marked as "for future use, PnC", but
>>> now it's not used at all. This is one possible solution however.
>>
>> Right, this sounds like the most straightforward choice.
>
> The PnC (which stands for Parsing and Classification) is not used yet
> indeed but this field will be needed when we will enable it. It is
> something we want to do but it is not planned in a near future. However
> from the datasheets I have it seems only present on the Armada XP. It is
> not mentioned on datasheets for the Armada 38x or the Armada 3700.
>
It is not mentioned in A38x spec, but this SoC has exactly the same
PnC as Armada XP (they differ only with used SRAM details). I wouldn't
be surprised if it was supported on A3700 as well.
> That would mean it was safe to use on of this field in 64-bits mode on
> the Armada 3700.
>
> So I am going to take this approach.
>
I think for now it's safe and is much easier than handling extra
software ring for virtual addresses.
Best regards,
Marcin
^ permalink raw reply
* [PATCH v2 1/2] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-23 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCAbUK-6uLc_ceJ5d-oD4N_HGz9rbtCvivTp1N8OOVBNBg@mail.gmail.com>
Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
> On Tue, Nov 22, 2016 at 11:00 AM, Neil Armstrong
> <narmstrong@baylibre.com> wrote:
>> Following the Amlogic Linux kernel, it seem the only differences
>> between the GXL and GXM SoCs are the CPU Clusters.
>>
>> This commit renames the gxl-s905d-p23x DTSI in a common file for
>> S905D p23x and S912 q20x boards.
>>
>> Then adds a meson-gxm dtsi and reproduce the P23x to Q20x boards
>> dts files since the S905D and S912 SoCs shares the same pinout
>> and the P23x and Q20x boards are identical.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
> I have tested this successfully on a Mecool BB2 (similar to the Q200
> reference board).
Thanks for testing (and reporting),
Kevin
^ permalink raw reply
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Tony Lindgren @ 2016-11-23 15:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <583478FB.4020008@arm.com>
* Vladimir Murzin <vladimir.murzin@arm.com> [161122 08:57]:
> On 22/11/16 10:17, Arnd Bergmann wrote:
> > Another question is what architecture levels and what platforms
> > we want to support without MMU. The only ARMv4/v5 platform we
> > still have that can actually use NOMMU cores is Integrator
> > with its ARM7TDMI, ARM920T and ARM966E core tiles (and possibly
> > others I couldn't immediately find). Do we actually care about
> > them any more now that all the NOMMU world is ARMv7-M? Are
> > there any benefits in running an ARM920T or ARM926E core
> > with MMU disabled, and does this work with your patches?
> >
>
> I don't have such hardware, so I can't acctually test it - it is why "there is
> no guaranty" :( OTOH, if sombody has these platforms these pathces is a good
> start to try NOMMU.
I believe the reason to run them without MMU might be still
valid if we ever get mainline Linux kernel working on some
3G/LTE modems for latency reasons. Not that I know of any
use cases, but if we have it working we might as well keep
it working.
Regards,
Tony
^ permalink raw reply
* [RFC PATCH 03/11] ARM: omap: do not select HIGHMEM explicitly
From: Tony Lindgren @ 2016-11-23 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122095136.GU1041@n2100.armlinux.org.uk>
* Russell King - ARM Linux <linux@armlinux.org.uk> [161122 01:51]:
> On Tue, Nov 22, 2016 at 09:26:00AM +0000, Vladimir Murzin wrote:
> > Explicit selection of HIGHMEM breaks NOMMU builds. It seems that
> > HIGHMEM is user selectable option, so probably it would be better to
> > let user to make a decision on this options or, at least, move it to
> > defconfig.
>
> That's kind of the point of ARCH_OMAP2PLUS_TYPICAL - it's a user
> option to let the user select a range of options for typical OMAP2+
> configurations, so that the user doesn't have to dig around looking
> for multiple options, some of which are hard requirements for OMAP
> to be functional. OMAP is a particularly difficult case because the
> hardware tends to be very complex.
>
> However, HIGHMEM should never be a requirement to boot, so this looks
> sane.
Yeah we can add that to the defconfig:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v2] ARM: dts: am335x-baltos: use phy-phandle declarations
From: yegorslists at googlemail.com @ 2016-11-23 15:49 UTC (permalink / raw)
To: linux-arm-kernel
From: Yegor Yefremov <yegorslists@googlemail.com>
phy-phandle is now a preferred method to reference a PHY device.
Especially in regards to cpsw it enables PHY specific settings like
max-speed etc. being specified in DTS.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
Changes:
v2: add patch description (Tony Lindgren)
arch/arm/boot/dts/am335x-baltos-ir2110.dts | 10 ++++++++--
arch/arm/boot/dts/am335x-baltos-ir3220.dts | 2 +-
arch/arm/boot/dts/am335x-baltos-ir5221.dts | 2 +-
arch/arm/boot/dts/am335x-baltos.dtsi | 5 ++++-
4 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-baltos-ir2110.dts b/arch/arm/boot/dts/am335x-baltos-ir2110.dts
index a9a9730..501c752 100644
--- a/arch/arm/boot/dts/am335x-baltos-ir2110.dts
+++ b/arch/arm/boot/dts/am335x-baltos-ir2110.dts
@@ -54,16 +54,22 @@
dr_mode = "host";
};
+&davinci_mdio {
+ phy0: ethernet-phy at 0 {
+ reg = <1>;
+ };
+};
+
&cpsw_emac0 {
- phy_id = <&davinci_mdio>, <1>;
phy-mode = "rmii";
dual_emac_res_vlan = <1>;
+ phy-handle = <&phy0>;
};
&cpsw_emac1 {
- phy_id = <&davinci_mdio>, <7>;
phy-mode = "rgmii-txid";
dual_emac_res_vlan = <2>;
+ phy-handle = <&phy1>;
};
&phy_sel {
diff --git a/arch/arm/boot/dts/am335x-baltos-ir3220.dts b/arch/arm/boot/dts/am335x-baltos-ir3220.dts
index fe002a1..19f53b8 100644
--- a/arch/arm/boot/dts/am335x-baltos-ir3220.dts
+++ b/arch/arm/boot/dts/am335x-baltos-ir3220.dts
@@ -109,9 +109,9 @@
};
&cpsw_emac1 {
- phy_id = <&davinci_mdio>, <7>;
phy-mode = "rgmii-txid";
dual_emac_res_vlan = <2>;
+ phy-handle = <&phy1>;
};
&phy_sel {
diff --git a/arch/arm/boot/dts/am335x-baltos-ir5221.dts b/arch/arm/boot/dts/am335x-baltos-ir5221.dts
index f599350..2b9d7f4 100644
--- a/arch/arm/boot/dts/am335x-baltos-ir5221.dts
+++ b/arch/arm/boot/dts/am335x-baltos-ir5221.dts
@@ -127,9 +127,9 @@
};
&cpsw_emac1 {
- phy_id = <&davinci_mdio>, <7>;
phy-mode = "rgmii-txid";
dual_emac_res_vlan = <2>;
+ phy-handle = <&phy1>;
};
&phy_sel {
diff --git a/arch/arm/boot/dts/am335x-baltos.dtsi b/arch/arm/boot/dts/am335x-baltos.dtsi
index 09b9541..efb5eae 100644
--- a/arch/arm/boot/dts/am335x-baltos.dtsi
+++ b/arch/arm/boot/dts/am335x-baltos.dtsi
@@ -364,11 +364,14 @@
};
&davinci_mdio {
+ status = "okay";
pinctrl-names = "default", "sleep";
pinctrl-0 = <&davinci_mdio_default>;
pinctrl-1 = <&davinci_mdio_sleep>;
- status = "okay";
+ phy1: ethernet-phy at 1 {
+ reg = <7>;
+ };
};
&mmc1 {
--
2.1.4
^ permalink raw reply related
* [RFC PATCH 11/11] ARM: Allow ARCH_MULTIPLATFORM to be selected for NOMMU
From: Afzal Mohammed @ 2016-11-23 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <583478FB.4020008@arm.com>
Hi,
On Tue, Nov 22, 2016 at 04:57:31PM +0000, Vladimir Murzin wrote:
> I used defconfigs
Which defconfig was used ?
multi_v7_defconfig, MMU & SMP disabled - thus spake the compiler,
kernel/built-in.o: In function `kimage_free_entry':
memremap.c:(.text+0x4dafc): undefined reference to
`arch_phys_to_idmap_offset'
memremap.c:(.text+0x4db04): undefined reference to
`arch_phys_to_idmap_offset'
kernel/built-in.o: In function `kimage_alloc_page':
memremap.c:(.text+0x4dbc0): undefined reference to
`arch_phys_to_idmap_offset'
memremap.c:(.text+0x4dbc8): undefined reference to
`arch_phys_to_idmap_offset'
memremap.c:(.text+0x4dc1c): undefined reference to
`arch_phys_to_idmap_offset'
kernel/built-in.o:memremap.c:(.text+0x4dc30): more undefined
references to `arch_phys_to_idmap_offset' follow
multi_v7_defconfig & MMU disabled, stderr was more verbose and was
unhappy with Kconfig dependencies,
warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects
SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL &&
MMU)
warning: (SOC_IMX31 && SOC_IMX35 && SOC_VF610 && REALVIEW_DT) selects
SMP_ON_UP which has unmet direct dependencies (SMP && !XIP_KERNEL &&
MMU)
Ulterior motive here is to try !MMU on Cortex A
Regards
afzal
^ permalink raw reply
* [PATCH] ARM: dts: am335x-baltos: use phy-phandle declarations
From: Tony Lindgren @ 2016-11-23 15:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479894757-32736-1-git-send-email-yegorslists@googlemail.com>
* yegorslists at googlemail.com <yegorslists@googlemail.com> [161123 01:53]:
> From: Yegor Yefremov <yegorslists@googlemail.com>
Description missing? Something like "do so and so because of" :)
Regards
Tony
^ permalink raw reply
* [PATCH 2/4] ARM: dts: davinci: da850: add VPIF
From: Kevin Hilman @ 2016-11-23 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d4e696d1-f9b2-665c-c44f-c661856c5098@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> On Wednesday 23 November 2016 11:13 AM, Kevin Hilman wrote:
>> David Lechner <david@lechnology.com> writes:
>>
>>> On 11/22/2016 01:45 PM, Kevin Hilman wrote:
>>>> Add VPIF and VPIF capture nodes to da850. VPIF capture has two input
>>>> channels describe using the standard DT ports and enpoints.
>>>>
>>>> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>>>> ---
>>>> arch/arm/boot/dts/da850.dtsi | 28 ++++++++++++++++++++++++++++
>>>> 1 file changed, 28 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>> index 6205917b4f59..e05e2bb834e8 100644
>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>> @@ -453,7 +453,35 @@
>>>> interrupts = <52>;
>>>> status = "disabled";
>>>> };
>>>> +
>>>> + vpif: video at 0x00217000 {
>>>
>>> Should be @217000
>>>
>>>> + compatible = "ti,da850-vpif";
>>>> + reg = <0x00217000 0x1000>;
>>>
>>> Could omit leading 0's to be consistent with existing entries.
>>>
>>> reg = <0x217000 0x1000>;
>>
>> Ugh, yeah. I hate that convention, but better to be consistent, I guess.
>>
>>>> + status = "disabled";
>>>> + };
>>>> +
>>>> + vpif_capture: video-capture at 0x00217000 {
>>>
>>> Again, @217000. But it seems odd to have two device nodes with the
>>> same address. Is enabling these mutually exclusive?
>>
>> They're not mutually exclusive because the vpif is the one that actually
>> maps the register range (since it's shared between vpif_display and
>> vpif_capture) so I guess I should just drop the reg property from the
>> vpif_capture node.
>
> Reading the documentation, VPIF is presented as a single device, with
> two channels dedicated to display and two for capture. Most of the
> channel registers are independent, but there are are some like interrupt
> enable which are common for all channels. So I believe we cannot use
> simple-mfd. But I believe VPIF display and capture should be subdevices
> of a single VPIF device.
OK, I can give it a try that way.
> It should look something like this, I think:
>
> vpif: video at 217000 {
> compatible = "ti,da850-vpif";
> reg = <0x217000 0x1000>;
> interrupts = <92>;
> status = "disabled";
>
> vpif_capture: video-capture {
> compatible = "ti,da850-vpif-capture"
> port {
> vpif_ch0: endpoint at 0 {
> reg = <0>;
> bus-width = <8>;
> };
>
> vpif_ch1: endpoint at 1 {
> reg = <1>;
> bus-width = <8>;
> data-shift = <8>;
> };
> };
> };
>
> vpif_display: video-display {
> compatible = "ti,da850-vpif-display"
> port {
> vpif_ch2: endpoint at 2 {
> reg = <2>;
> bus-width = <8>;
> data-shift = <16>;
> };
>
> vpif_ch3: endpoint at 3 {
> reg = <3>;
> bus-width = <8>;
> data-shift = <24>;
> };
> };
> };
> };
> The interrupt too, seems to be common interrupt for both display and
> capture. So, it should not be under the capture node.
Possibly. That will require reworking of the way the driver works
today, since the vpif driver doesn't request interrupts, but the capture
and display drivers both register interrupts, one per channel. I'll
have a closer look.
> BTW, I am sure
> what exactly data-shift is used for. It does not seem to be used in the
> driver patches too. I just extrapolated the values based on the pattern
> I saw.
For video out, the way I read the spec, and based on the schematics,
there appears to be a separate 16-bit parallel bus, so the data-shift on
the video-display endpoints should probably be zero and 16 like for
catpure. Anyways, I'll get to that when I get to the display part.
Kevin
^ permalink raw reply
* [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06
From: Gabriele Paoloni @ 2016-11-23 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2359248.XjnRfPbj1B@wuerfel>
Hi Arnd
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: 23 November 2016 14:16
> To: Gabriele Paoloni
> Cc: linux-arm-kernel at lists.infradead.org; mark.rutland at arm.com;
> benh at kernel.crashing.org; catalin.marinas at arm.com; liviu.dudau at arm.com;
> Linuxarm; lorenzo.pieralisi at arm.com; xuwei (O); Jason Gunthorpe; linux-
> serial at vger.kernel.org; linux-pci at vger.kernel.org;
> devicetree at vger.kernel.org; minyard at acm.org; will.deacon at arm.com; John
> Garry; zourongrong at gmail.com; robh+dt at kernel.org; bhelgaas at go og
> le.com; kantyzc at 163.com; zhichang.yuan02 at gmail.com; T homas Petazzoni;
> linux-kernel at vger.kernel.org; Yuanzhichang; olof at lixom.net
> Subject: Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on
> Hip06
>
> On Friday, November 18, 2016 5:03:11 PM CET Gabriele Paoloni wrote:
> > > On Friday, November 18, 2016 4:18:07 PM CET Gabriele Paoloni wrote:
> > > > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > > > > On Friday, November 18, 2016 12:53:08 PM CET Gabriele Paoloni
> > > wrote:
> > > > > For the ISA/LPC spaces there are only 4k of addresses, they
> > > > > the bus addresses always overlap, but we can trivially
> > > > > figure out the bus address from Linux I/O port number
> > > > > by subtracting the start of the range.
> > > >
> > > > Are you saying that our LPC controller should specify a
> > > > range property to map bus addresses into a cpu address range?
> > >
> > > No. There is not CPU address associated with it, because it's
> > > not memory mapped.
> > >
> > > Instead, we need to associate a bus address with a logical
> > > Linux port number, both in of_address_to_resource and
> > > in inb()/outb().
> >
> > I think this is effectively what we are doing so far with patch 2/3.
> > The problem with this patch is that we are carving out a "forbidden"
> > IO tokens range that goes from 0 to PCIBIOS_MIN_IO.
> >
> > I think that the proper solution would be to have the LPC driver to
> > set the carveout threshold used in pci_register_io_range(),
> > pci_pio_to_address(), pci_address_to_pio(), but this would impose
> > a probe dependency on the LPC itself that should be probed before
> > the PCI controller (or before any other devices calling these
> > functions...)
>
> Why do you think the order matters? My point was that we should
> be able to register any region of logical port numbers for any
> bus here.
Maybe I have not followed well so let's roll back to your previous
comment...
"we need to associate a bus address with a logical Linux port number,
both in of_address_to_resource and in inb()/outb()"
Actually of_address_to_resource() returns the port number to used
in inb/outb(); inb() and outb() add the port number to PCI_IOBASE
to rd/wr to the right virtual address.
Our LPC cannot operate on the virtual address and it operates on
a bus address range that for LPC is also equal to the cpu address
range and goes from 0 to 0x1000.
Now as I understand it is risky and not appropriate to reserve
the logical port numbers from 0 to 0x1000 or to whatever other
upper bound because existing systems may rely on these port numbers
retrieved by __of_address_to_resource().
In this scenario I think the best thing to do would be
in the probe function of the LPC driver:
1) call pci_register_io_range() passing [0, 0x1000] (that is the
range for LPC)
2) retrieve the logical port numbers associated to the LPC range
by calling pci_address_to_pio() for 0 and 0x1000 and assign
them to extio_ops_node->start and extio_ops_node->end
3) implement the LPC accessors to operate on the logical ports
associated to the LPC range (in practice in the accessors
implementation we will call pci_pio_to_address to retrieve
the cpu address to operate on)
What do you think?
Thanks
Gab
>
>
> > > > > > To be honest with you I would keep things simple for this
> > > > > > LPC and introduce more complex reworks later if more devices
> > > > > > need to be introduced.
> > > > > >
> > > > > > What if we stick on a single domain now where we introduce a
> > > > > > reserved threshold for the IO space (say INDIRECT_MAX_IO).
> > > > >
> > > > > I said having a single domain is fine, but I still don't
> > > > > like the idea of reserving low port numbers for this hack,
> > > > > it would mean that the numbers change for everyone else.
> > > >
> > > > I don't get this much...I/O tokens that are passed to the I/O
> > > > accessors are not fixed anyway and they vary depending on the
> order
> > > > of adding ranges to io_range_list...so I don't see a big issue
> > > > with this...
> > >
> > > On machines with a legacy devices behind the PCI bridge,
> > > there may still be a reason to have the low I/O port range
> > > reserved for the primary bus, e.g. to get a VGA text console
> > > to work.
> > >
> > > On powerpc, this is called the "primary" PCI host, i.e. the
> > > only one that is allowed to have an ISA bridge.
> >
> > Yes but
> > 1) isn't the PCI controller range property that defines how IO bus
> address
> > map into physical CPU addresses?
>
> Correct, but the DT knows nothing about logical port numbers in Linux.
>
> > 2) How can you guarantee that the cpu range associated with this
> > IO bus range is the first to be registered in
> pci_register_io_range()?
> > ( i.e. are you saying that they are just relying on the fact that
> it is the
> > only IO range in the system and by chance the IO tokens and
> corresponding
> > bus addresses are the same? )
>
> To clarify: the special properties of having the first 0x1000 logical
> port numbers go to a particular physical bus are very obscure. I think
> it's more important to not change the behavior for existing systems
> that might rely on it than for new systems that have no such legacy.
>
> The ipmi and uart drivers in particular will get the port numbers
> filled
> in their platform device from the DT bus scanning, so they don't care
> at all about having the same numeric value for port numbers on the bus
> and logical numbers, but other drivers might rely on particular ports
> to be mapped on a specific PCI host, especially when those drivers
> are used only on systems that don't have more than one PCI domain.
>
> Arnd
^ permalink raw reply
* [PATCH] PCI: Add information about describing PCI in ACPI
From: Bjorn Helgaas @ 2016-11-23 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-TW__+eZFS2p=1ZLN7fBs7pqQ+SitbEX46Z4JiS64egA@mail.gmail.com>
On Wed, Nov 23, 2016 at 07:28:12AM +0000, Ard Biesheuvel wrote:
> On 23 November 2016 at 01:06, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Tue, Nov 22, 2016 at 10:09:50AM +0000, Ard Biesheuvel wrote:
> >> On 17 November 2016 at 17:59, Bjorn Helgaas <bhelgaas@google.com> wrote:
> >
> >> > +PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should
> >> > +describe all the address space they consume. In principle, this would
> >> > +be all the windows they forward down to the PCI bus, as well as the
> >> > +bridge registers themselves. The bridge registers include things like
> >> > +secondary/subordinate bus registers that determine the bus range below
> >> > +the bridge, window registers that describe the apertures, etc. These
> >> > +are all device-specific, non-architected things, so the only way a
> >> > +PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which
> >> > +contain the device-specific details. These bridge registers also
> >> > +include ECAM space, since it is consumed by the bridge.
> >> > +
> >> > +ACPI defined a Producer/Consumer bit that was intended to distinguish
> >> > +the bridge apertures from the bridge registers [4, 5]. However,
> >> > +BIOSes didn't use that bit correctly, and the result is that OSes have
> >> > +to assume that everything in a PCI host bridge _CRS is a window. That
> >> > +leaves no way to describe the bridge registers in the PNP0A03/PNP0A08
> >> > +device itself.
> >>
> >> Is that universally true? Or is it still possible to do the right
> >> thing here on new ACPI architectures such as arm64?
> >
> > That's a very good question. I had thought that the ACPI spec had
> > given up on Consumer/Producer completely, but I was wrong. In the 6.0
> > spec, the Consumer/Producer bit is still documented in the Extended
> > Address Space Descriptor (sec 6.4.3.5.4). It is documented as
> > "ignored" in the QWord, DWord, and Word descriptors (sec 6.4.3.5.1,2,3).
> >
> > Linux looks at the producer_consumer bit in acpi_decode_space(), which
> > I think is used for all these descriptors (QWord, DWord, Word, and
> > Extended). This doesn't quite follow the spec -- we probably should
> > ignore it except for Extended. In any event, acpi_decode_space() sets
> > IORESOURCE_WINDOW for Producer descriptors, but we don't test
> > IORESOURCE_WINDOW in the PCI host bridge code.
> >
> > x86 and ia64 supply their own pci_acpi_root_prepare_resources()
> > functions that call acpi_pci_probe_root_resources(), which parses _CRS
> > and looks at producer_consumer. Then they do a little arch-specific
> > stuff on the result.
> >
> > On arm64 we use acpi_pci_probe_root_resources() directly, with no
> > arch-specific stuff.
> >
> > On all three arches, we ignore the Consumer/Producer bit, so all the
> > resources are treated as Producers, e.g., as bridge windows.
> >
> > I think we *could* implement an arm64 version of
> > pci_acpi_root_prepare_resources() that would pay attention to the
> > Consumer/Producer bit by checking IORESOURCE_WINDOW. To be spec
> > compliant, we would have to use Extended descriptors for all bridge
> > windows, even if they would fit in a DWord or QWord.
> >
> > Should we do that? I dunno. I'd like to hear your opinion(s).
> >
>
> Yes, I think we should. If the spec allows for a way for a PNP0A03
> device to describe all of its resources unambiguously, we should not
> be relying on workarounds that were designed for another architecture
> in another decade (for, presumably, another OS)
>
> Just for my understanding, we will need to use extended descriptors
> for all consumed *and* produced regions, even though dword/qword are
> implicitly produced-only, due to the fact that the bit is ignored?
>From an ACPI spec point of view, I would say QWord/DWord/Word
descriptors are implicitly *consumer*-only because ResourceConsumer
is the default and they don't have a bit to indicate otherwise.
The current code assumes all PNP0A03 resources are producers. If we
implement an arm64 pci_acpi_root_prepare_resources() that pays
attention to the Consumer/Producer bit, we would have to:
- Reserve all producer regions in the iomem/ioport trees. This is
already done via pci_acpi_root_add_resources(), but we might need
a new check to handle consumers differently.
- Reserve all consumer regions. This corresponds to what
pnp/system.c does for PNP0C02 devices. This is similar to the
producer regions, but I think the consumer ones should be marked
IORESOURCE_BUSY.
- Use every producer (IORESOURCE_WINDOW) as a host bridge window.
I think it's a bug that acpi_decode_space() looks at producer_consumer
for QWord/DWord/Word descriptors, but I think QWord/DWord/Word
descriptors for consumed regions should be safe, as long as they don't
set the Consumer/Producer bit.
^ permalink raw reply
* [PATCH] soc/fsl/qe: use builtin_platform_driver
From: Geliang Tang @ 2016-11-23 15:04 UTC (permalink / raw)
To: linux-arm-kernel
Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@gmail.com>
---
drivers/soc/fsl/qe/qe.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 2707a82..ade168f 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -717,9 +717,5 @@ static struct platform_driver qe_driver = {
.resume = qe_resume,
};
-static int __init qe_drv_init(void)
-{
- return platform_driver_register(&qe_driver);
-}
-device_initcall(qe_drv_init);
+builtin_platform_driver(qe_driver);
#endif /* defined(CONFIG_SUSPEND) && defined(CONFIG_PPC_85xx) */
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox