> > s/regmap/Regmap
>
> It's consistently written regmap in all the documentation and so on :)
Furry muff; but the comments still stand for the acronyms.
> > addmap{0,1} doesn't quite sit right with me.
>
> > REVISIT: Ah, it's address-map, rather than add map. Okay, not as bad
> > as I first th
On 04/17/2014 05:33 AM, Jisheng Zhang wrote:
> On Wed, 16 Apr 2014 05:40:10 -0700
> Antoine Ténart wrote:
>> Add the SDHCI nodes for the Marvell Berlin BG2Q, using the berlin-sdhci
>> driver.
[...]
>> +sdhci0: sdhci@ab {
>> +compatible = "marvell,berlin2q-sdhci"
On 31.07.2013 16:37, Lothar Waßmann wrote:
Signed-off-by: Lothar Waßmann
---
...
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcdif_24bit_pins_a &lcdif_sync_pins_a &lcdif_ctrl_pins_a>;
+ lcd-supply = <®_lcd>;
+ display = <&display>;
+ status = "okay";
+
This add Freescale Periodic Interrupt Timer (PIT-RTI) devicetree
Documentation, The PIT-RTI binding has already been used on Vybrid,
so this add a binding document for it.
Signed-off-by: Xiubo Li
Cc: Shawn Guo
Cc: Jingchang Lu
---
.../devicetree/bindings/timer/fsl,vf610-pit.txt | 21 ++
Hi Laurent
Thank you for the comment.
On 04/17/2014 06:26 AM, Laurent Pinchart wrote:
Hi YoungJun,
Thank you for the patch.
On Tuesday 15 April 2014 14:47:33 YoungJun Cho wrote:
In case of using CPU interface panel, the relevant registers should be set.
So this patch adds relevant dt binding
Hi Vikas,
As you comment, I found the history of this patch in mailing list.
It seems like that this patch stop the review.
Besides, Pankaj posted same patch to support PMU as following:
- https://lkml.org/lkml/2014/4/2/48
Do you have a plan to resend or not?
because I need this patch to remove
Hi Antoine,
On Wed, 16 Apr 2014 05:40:10 -0700
Antoine Ténart wrote:
> Add the SDHCI nodes for the Marvell Berlin BG2Q, using the berlin-sdhci
> driver.
>
> Signed-off-by: Antoine Ténart
> ---
> arch/arm/boot/dts/berlin2q.dtsi | 40
> 1 file changed, 40
On Wed, 2014-04-16 at 19:39 -0700, Iyappan Subramanian wrote:
> This patch adds a MAINTAINERS entry for APM X-Gene SoC
> ethernet driver.
[]
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -686,6 +686,14 @@ S: Maintained
> F: drivers/net/appletalk/
> F: net/appletalk/
>
> +APPLIED MI
On Wed, 2014-04-16 at 19:39 -0700, Iyappan Subramanian wrote:
> This patch adds network driver for APM X-Gene SoC ethernet.
[]
> diff --git a/drivers/net/ethernet/apm/xgene/Kconfig
> b/drivers/net/ethernet/apm/xgene/Kconfig
[]
> @@ -0,0 +1,10 @@
> +config NET_XGENE
> + tristate "APM X-Gene SoC
Adding APM X-Gene SoC Ethernet driver.
v3: Address comments from v2 review
* cleaned up set_desc and get_desc functions
* added dtb mdio node and phy-handle subnode
* renamed dtb phy-mode to phy-connection-type
* added of_phy_connect call to connec to PHY
* added empty line after last local variab
This patch adds a MAINTAINERS entry for APM X-Gene SoC
ethernet driver.
Signed-off-by: Iyappan Subramanian
Signed-off-by: Ravi Patel
Signed-off-by: Keyur Chudgar
---
MAINTAINERS |8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 11b3937..bc32a01 1006
This patch adds bindings for APM X-Gene SoC ethernet driver.
Signed-off-by: Iyappan Subramanian
Signed-off-by: Ravi Patel
Signed-off-by: Keyur Chudgar
---
arch/arm64/boot/dts/apm-mustang.dts |4
arch/arm64/boot/dts/apm-storm.dtsi | 27 ---
2 files changed, 2
This patch adds documentation for APM X-Gene SoC ethernet DTS binding.
Signed-off-by: Iyappan Subramanian
Signed-off-by: Ravi Patel
Signed-off-by: Keyur Chudgar
---
.../devicetree/bindings/net/apm-xgene-enet.txt | 66
1 file changed, 66 insertions(+)
create mode 100
Hi,
Please find my response inline.
On Mon, Apr 14, 2014 at 7:05 AM, Ben Dooks wrote:
> On 12/04/14 04:06, Iyappan Subramanian wrote:
>>
>> This patch adds network driver for APM X-Gene SoC ethernet.
>>
>> Signed-off-by: Iyappan Subramanian
>> Signed-off-by: Ravi Patel
>
>
> [snip]
>
>
>> +{
>
On Thu, Apr 17, 2014 at 01:20:42AM +0100, Liviu Dudau wrote:
> > No spec says you can put config space into the ranges at all, nobody
> > should be doing that today, obviously some cases were missed during
> > review..
>
> ePAPR documents allows that when ss == 00.
Which do you mean? The 'PCI Bu
On Wed, Apr 16, 2014 at 03:21:04PM -0600, Jason Gunthorpe wrote:
> On Wed, Apr 16, 2014 at 06:05:45PM +0100, Liviu Dudau wrote:
>
> > I have found out that we cannot pasd the config ranges from the DT into the
> > pci_host_bridge structure as the PCI framework doesn't have a resource type
> > for
The tps65090 regulator allows you to specify how long you want it to
wait before detecting an overcurrent condition. Allow specifying that
through the device tree (or through platform data).
Signed-off-by: Doug Anderson
Signed-off-by: Simon Glass
Signed-off-by: Michael Spang
Signed-off-by: Sea
These five patches bring tps65090 up to speed with what's currently
in the Chromium OS kernel 3.8 tree and running on the Samsung ARM
Chromebook. Changes were tested atop the current linux tree
(v3.15-rc1). FET retries were tested on a machine with a known flaky
tps65090. Since display isn't wor
Randy,
On Wed, Apr 16, 2014 at 1:33 PM, Randy Dunlap wrote:
> On 04/16/2014 11:25 AM, Doug Anderson wrote:
>> diff --git a/drivers/regulator/tps65090-regulator.c
>> b/drivers/regulator/tps65090-regulator.c
>> index 2e92ef6..ca13a1a 100644
>> --- a/drivers/regulator/tps65090-regulator.c
>> +++ b/
On Wed, Apr 16, 2014 at 11:57:21PM +0100, Russell King - ARM Linux wrote:
> On Wed, Apr 16, 2014 at 05:46:47PM -0500, Rob Herring wrote:
> > On Wed, Apr 16, 2014 at 3:43 AM, Russell King
> > wrote:
> > > Spread-spectrum doesn't work with Cubox-i hardware, so we have to
> > > disable this feature.
On Wed, Apr 16, 2014 at 05:46:47PM -0500, Rob Herring wrote:
> On Wed, Apr 16, 2014 at 3:43 AM, Russell King
> wrote:
> > Spread-spectrum doesn't work with Cubox-i hardware, so we have to
> > disable this feature. Add a DT property so that platforms can
> > indicate that this feature should not b
On Wed, Apr 16, 2014 at 3:43 AM, Russell King
wrote:
> Spread-spectrum doesn't work with Cubox-i hardware, so we have to
> disable this feature. Add a DT property so that platforms can
> indicate that this feature should not be enabled.
This is for spread-spectrum tx or rx? Transmit SS is option
This patch adds support for the v1.3.0 version of the BAM dma ip block. This
patch adds register access abstraction to deal with the changes to the register
map between the two versions. Blocks of registers moved around within the
address space, and multipliers used for calculating the pipe regis
This set of patches adds support for the v1.3.0 version of the QCOM BAM
dmaengine driver. The older version of the BAM is present in the MSM8x64,
APQ8064, and IPQ8064 processors.
Due to register address space changes between versions, all of the register
accesses have to be calculated using diffe
Add the device tree binding support for the v1.3.0 version of the QCOM BAM DMA
driver.
Signed-off-by: Andy Gross
---
.../devicetree/bindings/dma/qcom_bam_dma.txt |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt
This adds a driver for the HDA block in Tegra SoCs. The HDA bus is
used to communicate with the HDMI codec on Tegra124.
Most of the code is re-used from the Intel/PCI HDA driver. It brings
over only the power_save module parameter.
Signed-off-by: Dylan Reid
---
Changes since v2:
Remove runtim
Hi YoungJun,
Thank you for the patch.
On Wednesday 16 April 2014 13:38:57 YoungJun Cho wrote:
> This patch adds DT bindings for s6e3fa0 panel.
> The bindings describes panel resources, display timings, delays
> and physical size.
>
> Changelog v2:
> - Adds unit address (commented by Sachin Kamat
From: Sumit Bhattacharya
Add the Tegra 12x HDMI controller id to patch_hdmi.
Signed-off-by: Sumit Bhattacharya
Signed-off-by: Dylan Reid
---
No changes since v1.
---
sound/pci/hda/patch_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/pat
On Wed, Apr 16, 2014 at 4:23 PM, delicious quinoa
wrote:
> On Thu, Apr 3, 2014 at 3:40 PM, delicious quinoa
> wrote:
>> On Fri, Mar 28, 2014 at 1:27 PM, delicious quinoa
>> wrote:
>>> On Tue, Mar 18, 2014 at 4:55 PM, Pantelis Antoniou
>>> wrote:
The following patchset introduces Device Tre
On Wed, Apr 16, 2014 at 12:06:03PM +0100, Lee Jones wrote:
> s/regmap/Regmap
It's consistently written regmap in all the documentation and so on :)
> addmap{0,1} doesn't quite sit right with me.
> REVISIT: Ah, it's address-map, rather than add map. Okay, not as bad
> as I first thought, but sti
Hi YoungJun,
Thank you for the patch.
On Tuesday 15 April 2014 14:47:33 YoungJun Cho wrote:
> In case of using CPU interface panel, the relevant registers should be set.
> So this patch adds relevant dt bindings.
>
> Signed-off-by: YoungJun Cho
> Signed-off-by: Inki Dae
> Signed-off-by: Kyungm
On Thu, Apr 3, 2014 at 3:40 PM, delicious quinoa
wrote:
> On Fri, Mar 28, 2014 at 1:27 PM, delicious quinoa
> wrote:
>> On Tue, Mar 18, 2014 at 4:55 PM, Pantelis Antoniou
>> wrote:
>>> The following patchset introduces Device Tree overlays, a method
>>> of dynamically altering the kernel's live
On Wed, Apr 16, 2014 at 06:05:45PM +0100, Liviu Dudau wrote:
> I have found out that we cannot pasd the config ranges from the DT into the
> pci_host_bridge structure as the PCI framework doesn't have a resource type
> for config resources. Leaving the translation between range flags and
> resourc
On Wed, Apr 16, 2014 at 01:09:39PM -0700, Jane Wan wrote:
> Make FSL eSPI CSnBEF and CSnAFT fields in ESPI_SPMODEn registers
> (n=0,1,2,3) configurable through device tree.
Applied, thanks.
signature.asc
Description: Digital signature
On Tue, 2014-04-15 at 14:54 +0400, Alexander Popov wrote:
>
> Introduce a device tree binding document for the MPC512x DMA controller
>
> Signed-off-by: Gerhard Sittig
> Signed-off-by: Alexander Popov
I'm not certain whether the attribution is right. Is the S-o-b
appropriate when the patch is
On 04/16/2014 11:25 AM, Doug Anderson wrote:
> diff --git a/drivers/regulator/tps65090-regulator.c
> b/drivers/regulator/tps65090-regulator.c
> index 2e92ef6..ca13a1a 100644
> --- a/drivers/regulator/tps65090-regulator.c
> +++ b/drivers/regulator/tps65090-regulator.c
> @@ -28,15 +28,57 @@
> +/**
One Thousand Gnomes wrote:
>On Wed, 16 Apr 2014 23:01:47 +0400
>Sergei Ianovich wrote:
>
>> One Thousand Gnomes wrote:
>> >> + baud = uart_get_baud_rate(port, termios, old,
>> >> + port->uartclk / 16 / 0x,
>> >> + port->uartclk / 16);
>> >>
On Wed, 16 Apr 2014 20:42:39 +0200
Arnd Bergmann wrote:
> On Wednesday 16 April 2014 19:41:09 One Thousand Gnomes wrote:
> > On Wed, 16 Apr 2014 21:17:18 +0400
> > Sergei Ianovich wrote:
> >
> > > This patch implements probing for the bus and reporting the number
> > > of available expansion sl
On Thu, 17 Apr 2014, Abhilash Kesavan wrote:
> Hi Nicolas,
>
> On Fri, Apr 11, 2014 at 11:44 PM, Nicolas Pitre
> wrote:
> > On Fri, 11 Apr 2014, Abhilash Kesavan wrote:
> >
> >> From: Andrew Bresticker
> >>
> >> Do not enable the big.LITTLE switcher on systems that do not have an
> >> ARM CCI (
Make FSL eSPI CSnBEF and CSnAFT fields in ESPI_SPMODEn registers
(n=0,1,2,3) configurable through device tree.
CSnBEF is the chip select setup time. It's the delay in bits from the
activation of chip select pin to the first clock for data frame.
CSnAFT is the chip select hold time. It's the del
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of sundeep subbaraya
> Sent: Wednesday, April 16, 2014 3:39 AM
>
> Hi Felipe,
>
> On Thu, Apr 3, 2014 at 8:28 PM, Felipe Balbi wrote:
>
> >> +static int start_dma(struct xusb_ep *ep, u32 src, u32 dst,
On Wed, 16 Apr 2014 23:01:47 +0400
Sergei Ianovich wrote:
> One Thousand Gnomes wrote:
> >> + baud = uart_get_baud_rate(port, termios, old,
> >> +port->uartclk / 16 / 0x,
> >> +port->uartclk / 16);
> >> + switch (baud) {
> >> + case
One Thousand Gnomes wrote:
>On Wed, 16 Apr 2014 21:17:18 +0400
>Sergei Ianovich wrote:
>
>> This patch implements probing for the bus and reporting the number
>> of available expansion slots.
>
>This appears to be a bus not a misc device. I don't think it belongs in
>misc. As you've got devices o
On 04/16/2014 11:11 AM, Jisheng Zhang wrote:
> On Wed, 16 Apr 2014 00:46:33 -0700
> Antoine Ténart wrote:
>
>> This series add the support for the GPIOs of the Berlin BG2Q. We use the
>> newly integrated dwapb GPIO driver here.
>>
>> This applies on top of Alexandre's BG2Q symbol introduction[1]
Hi Dave.
On Mon, Apr 14, 2014 at 4:11 PM, Dave Martin wrote:
> On Fri, Apr 11, 2014 at 04:23:04PM -0400, Nicolas Pitre wrote:
>> On Fri, 11 Apr 2014, Abhilash Kesavan wrote:
>>
>> > Add machine-dependent MCPM call-backs for Exynos5420. These are used
>> > to power up/down the secondary CPUs during
Hi Dave,
On Tue, Apr 15, 2014 at 2:06 PM, Dave Martin wrote:
> On Mon, Apr 14, 2014 at 10:01:27AM -0400, Nicolas Pitre wrote:
>> On Mon, 14 Apr 2014, Dave Martin wrote:
>>
>> > On Fri, Apr 11, 2014 at 04:23:04PM -0400, Nicolas Pitre wrote:
>> > > On Fri, 11 Apr 2014, Abhilash Kesavan wrote:
>> >
Hi Nicolas,
On Fri, Apr 11, 2014 at 11:44 PM, Nicolas Pitre
wrote:
> On Fri, 11 Apr 2014, Abhilash Kesavan wrote:
>
>> From: Andrew Bresticker
>>
>> Do not enable the big.LITTLE switcher on systems that do not have an
>> ARM CCI (cache-coherent interconnect) present. Since the CCI is used
>> to
Hi Nicolas and Dave,
Thanks for the review.
On Sat, Apr 12, 2014 at 1:53 AM, Nicolas Pitre wrote:
> On Fri, 11 Apr 2014, Abhilash Kesavan wrote:
>
>> Add machine-dependent MCPM call-backs for Exynos5420. These are used
>> to power up/down the secondary CPUs during boot, shutdown, s2r and
>> swit
Hi Dave and Arnd,
On Mon, Apr 14, 2014 at 6:54 PM, Arnd Bergmann wrote:
> On Monday 14 April 2014 12:59:11 Dave Martin wrote:
>> On Mon, Apr 14, 2014 at 01:47:56PM +0200, Arnd Bergmann wrote:
>> > On Monday 14 April 2014 12:25:20 Dave Martin wrote:
>> > > Arnd, what was your preferred solution?
On 03/20/2014 09:39 PM, Sebastian Hesselbarth wrote:
> This adds scu and general purpose registers device nodes required for
> SMP on Berlin BG2 and BG2Q SoCs. The secondary CPUs will pick their jump
> address from general purpose (SW generic) register 1.
>
> Signed-off-by: Sebastian Hesselbarth
One Thousand Gnomes wrote:
>> +baud = uart_get_baud_rate(port, termios, old,
>> + port->uartclk / 16 / 0x,
>> + port->uartclk / 16);
>> +switch (baud) {
>> +case 2400:
>> +len |= 1;
>> +break;
>> +
On Wednesday 16 April 2014 19:41:09 One Thousand Gnomes wrote:
> On Wed, 16 Apr 2014 21:17:18 +0400
> Sergei Ianovich wrote:
>
> > This patch implements probing for the bus and reporting the number
> > of available expansion slots.
>
> This appears to be a bus not a misc device. I don't think it
On Wed, 16 Apr 2014 21:17:18 +0400
Sergei Ianovich wrote:
> This patch implements probing for the bus and reporting the number
> of available expansion slots.
This appears to be a bus not a misc device. I don't think it belongs in
misc. As you've got devices on this bus (or nailed into the 'bus'
> + baud = uart_get_baud_rate(port, termios, old,
> + port->uartclk / 16 / 0x,
> + port->uartclk / 16);
> + switch (baud) {
> + case 2400:
> + len |= 1;
> + break;
> + case 4800:
> +
The tps65090 regulator allows you to specify how long you want it to
wait before detecting an overcurrent condition. Allow specifying that
through the device tree (or through platform data).
Signed-off-by: Doug Anderson
Signed-off-by: Simon Glass
Signed-off-by: Michael Spang
Signed-off-by: Sea
These five patches bring tps65090 up to speed with what's currently
in the Chromium OS kernel 3.8 tree and running on the Samsung ARM
Chromebook. Changes were tested atop the current linux tree
(v3.15-rc1). FET retries were tested on a machine with a known flaky
tps65090. Since display isn't wor
Mark,
On Tue, Apr 15, 2014 at 3:52 PM, Mark Brown wrote:
> On Tue, Apr 15, 2014 at 01:14:36PM -0700, Doug Anderson wrote:
>
>> Mitigate the problem by:
>> * Allow setting the overcurrent wait time so devices with this problem
>> can set it to the max.
>> * Add retry logic on enables of FETs.
>
Hi Jacek,
Thanks for the update!
On Fri, Apr 11, 2014 at 04:56:56PM +0200, Jacek Anaszewski wrote:
> This patch adds helper functions for registering/unregistering
> LED class flash devices as V4L2 subdevs. The functions should
> be called from the LED subsystem device driver. In case the
> suppo
Hi,
On Wed, Apr 16, 2014 at 04:09:28PM +0530, sundeep subbaraya wrote:
> Hi Felipe,
>
> On Thu, Apr 3, 2014 at 8:28 PM, Felipe Balbi wrote:
>
> >> +static int start_dma(struct xusb_ep *ep, u32 src, u32 dst, u32 length)
> >
> > please prepend this with xudc_, it makes tracing a lot easier.
> >
>
at24c128 write protection is implemented by a separate GPIO line.
EEPROM driver doesn't provide this option, so we implement it
in the board-specific device.
Signed-off-by: Sergei Ianovich
---
v3..v4
* move DTS binding to a different patch (8/21)
v2..v3
* new patch
.../devicetree/b
On Wed, Apr 16, 2014 at 04:39:47PM +, Jane Wan wrote:
> On Mon, Apr 14, 2014 at 09:51:56PM +0100, Mark Brown wrote:
> > > + if (spi_raw_rxdata_to_user[m->spi->chip_select])
> > > + espi_trans->len = n_tx;
> > > + else
> > > + espi_trans->len = tr
This patch enumerates parallel modules in expansion slots and exposes
model numbers via sysfs.
Signed-off-by: Sergei Ianovich
---
v3..v4
* move DTS binding to a different patch (8/21)
v2..v3
* no changes (except number 13/16 -> 18/21)
v0..v2
* use device tree
* use devm hel
Serial modules (I-870xxW series) implement DCON protocol which
allows one-master-many-slaves configuration over RS-485. When
these modules are installed into the device, they could be
accessed using the 2nd PXA built-in UART port (/dev/ttyS1).
However, it seems that addresses are not processed by t
Hi Jacek,
Thanks for the patch! Comments below.
On Fri, Apr 11, 2014 at 04:56:54PM +0200, Jacek Anaszewski wrote:
> This patch adds led-flash support to Maxim max77693 chipset.
> A device can be exposed to user space through LED subsystem
> sysfs interface or through V4L2 subdevice when the suppo
Signed-off-by: Sergei Ianovich
---
v3..v4
* move DTS bindings to a different patch (8/21)
v2..v3
* use usleep_range instead of custom nsleep
* number change (07/16 -> 09/21)
v0..v2
* use device tree
* use devm helpers where possible
.../devicetree/bindings/rtc/rtc-ds130
This provides an MTD device driver for 512kB of battery backed up SRAM
on ICPDAS LP-8X4X programmable automation controllers.
SRAM chip is connected via FPGA and is not accessible without a driver,
unlike flash memory which is wired to CPU MMU.
This SRAM becomes an excellent persisent storage of
ICP DAS calls LP-8x4x 'programmable automation controller'. It is
an industrial computer based on PXA270 SoC. They ship it with a 2.6.19
kernel and proprietary kernel module and userspace library to access
its industrial IO.
This patch allows to boot the device with a modern kernel with device
tre
ICP DAS LP-8x4x contains FPGA chip. The chip functions as an interrupt
source providing 16 additional interrupts among other things. The
interrupt lines are muxed to a GPIO pin of a 2nd level PXA-GPIO
interrupt controller. GPIO pins of the 2nd level controller are in turn
muxed to a CPU interrupt l
This patch implements probing for the bus and reporting the number
of available expansion slots.
Signed-off-by: Sergei Ianovich
---
v3..v4
* move DTS binding to a different patch (8/21)
v2..v3
* fixed goto after bus_register
* number change (11/16 -> 13/21)
v0..v2
* use dev
Hi,
Am Mittwoch, 16. April 2014, 16:35:36 schrieb Arnd Bergmann:
> On Wednesday 16 April 2014 17:20:51 Sachin Kamat wrote:
> > Instead of hardcoding the SYSRAM details for each SoC,
> > pass this information through device tree (DT) and make
> > the code SoC agnostic.
> >
> > Signed-off-by: Sachi
The patch adds support for 3 additional LP-8x4x built-in serial
ports.
The device can also host up to 8 extension cards with 4 serial ports
on each card for a total of 35 ports. However, I don't have
the hardware to test extension cards, so they are not supported, yet.
Signed-off-by: Sergei Ianov
Signed-off-by: Sergei Ianovich
---
v3..v4
* move DTS binding to a different patch (8/21)
v2..v3
* new patch
.../devicetree/bindings/misc/lp8x4x-bus.txt| 8 ++--
Documentation/misc-devices/lp8x4x_bus.txt | 3 ++
drivers/misc/lp8x4x_bus.c |
Signed-off-by: Sergei Ianovich
---
v3..v4
* move DTS binding to a different patch (8/21)
v2..v3
* new patch
.../devicetree/bindings/misc/lp8x4x-bus.txt| 2 ++
Documentation/misc-devices/lp8x4x_bus.txt | 3 +++
drivers/misc/lp8x4x_bus.c | 2
Non-dts implementation supply required DMA channel numbers as
IORESOURCE_DMA. We can also get them from the device tree, if it
is present.
This patch updates device tree with the proper dmaengine-based
"marvell,pdma-1.0" DMA.
There is no actual data handling in this patch, because the existing
dr
Signed-off-by: Sergei Ianovich
CC: Daniel Mack
CC: Haojian Zhuang
CC: Arnd Bergmann
---
v3..v4
v2..v3
v1..v2
* no changes
arch/arm/boot/dts/pxa2xx.dtsi | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/pxa2xx.dtsi b/arch/arm/boot/dts/pxa2xx
Signed-off-by: Sergei Ianovich
CC: Daniel Mack
CC: Haojian Zhuang
CC: Arnd Bergmann
---
v3..v4
v2..v3
v1..v2
* no changes
arch/arm/boot/dts/pxa27x.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index a70
pxa2xx-uart was a separate uart platform driver. It was declaring
the same device names and numbers as 8250 driver. As a result,
it was impossible to use 8250 driver on PXA SoCs.
Upon closer examination pxa2xx-uart turned out to be a clone of
8250_core driver.
Workaround for Erratum #19 according
Dear Jason Cooper,
On Wed, 16 Apr 2014 12:55:48 -0400, Jason Cooper wrote:
> > Sounds like a good plan. Try to keep all the mess to support Z1 in one
> > place so that it can be easily taken out once people have A0.
>
> Agreed. Thomas, do you think you'll be able to get a definitive answer
> fr
On Wed, Mar 26, 2014 at 09:28:42AM -0500, Rob Herring wrote:
> On Wed, Mar 19, 2014 at 6:12 PM, Tanmay Inamdar wrote:
> > This patch adds the device tree nodes for APM X-Gene PCIe controller and
> > PCIe clock interface. Since X-Gene SOC supports maximum 5 ports, 5 dts
> > nodes are added.
>
> [s
On Wed, Apr 16, 2014 at 06:34:47PM +0200, Andrew Lunn wrote:
> > So, I would like to see the Z1 stepping supported for now, and have the
> > freedom to remove its support later once we are all ready to switch to
> > A0.
>
> Hi Thomas
>
> Sounds like a good plan. Try to keep all the mess to suppor
This add bindings documentation for the clock and reset unit found on
rk3188 SoCs from Rockchip.
Signed-off-by: Heiko Stuebner
---
.../bindings/clock/rockchip,rk3188-cru.txt | 72 ++
1 file changed, 72 insertions(+)
create mode 100644
Documentation/devicetree/bindin
On Wed, Apr 16, 2014 at 12:49:27PM -0300, Ezequiel Garcia wrote:
> On Apr 16, Jason Cooper wrote:
> > On Wed, Apr 16, 2014 at 11:15:18AM -0300, Ezequiel Garcia wrote:
> > > + /* This is only needed on A375 Z1 SoC silicon revision */
> > > + reg |= A375_Z1_WORKAROUND_BIT;
> >
> > and this seem to b
On Mon, Apr 14, 2014 at 09:51:56PM +0100, Mark Brown wrote:
> On Sat, Apr 12, 2014 at 11:48:36AM -0700, Jane Wan wrote:
> > Make FSL eSPI CSnBEF and CSnAFT in ESPI_SPMODEn registers (n=0,1,2,3)
> > configurable through device tree. FSL eSPI driver hardcodes them to 0.
> > Some device requires diff
> So, I would like to see the Z1 stepping supported for now, and have the
> freedom to remove its support later once we are all ready to switch to
> A0.
Hi Thomas
Sounds like a good plan. Try to keep all the mess to support Z1 in one
place so that it can be easily taken out once people have A0.
On Wed, Apr 16, 2014 at 10:20:45AM +0200, Lucas Stach wrote:
> Am Dienstag, den 15.04.2014, 12:30 -0600 schrieb Bjorn Helgaas:
> > On Tue, Apr 15, 2014 at 12:07:34PM +0200, Lucas Stach wrote:
> > > Hi Bjorn,
> > >
> > > Am Freitag, den 04.04.2014, 10:55 -0600 schrieb Bjorn Helgaas:
> > > > On Wed,
On Wed, Apr 16, 2014 at 11:16:19AM -0500, Felipe Balbi wrote:
> On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
> > Hi,
> >
> > On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
> > > From: George Cherian
> > >
> > > Added dr_mode property in dwc3 and set its default mode to d
On Fri, Oct 11, 2013 at 05:46:12PM +0300, Roger Quadros wrote:
> Hi,
>
> On 10/10/2013 01:49 PM, Kishon Vijay Abraham I wrote:
> > From: George Cherian
> >
> > Added dr_mode property in dwc3 and set its default mode to device.
>
> If there is a specific reason why this is not set to "otg", we n
Dear Andrew Lunn,
On Wed, 16 Apr 2014 18:08:24 +0200, Andrew Lunn wrote:
> > For minor differences such as SoC stepping, I personally prefer to not
> > have separate Device Trees. We already have many of them, for each
> > variant of the various SOCs. If we add the different steppings, it's
> > go
> For minor differences such as SoC stepping, I personally prefer to not
> have separate Device Trees. We already have many of them, for each
> variant of the various SOCs. If we add the different steppings, it's
> going to be even more complicated. Also, there will be a new iteration
> of the Arma
Dear Sebastian Hesselbarth,
On Wed, 16 Apr 2014 17:59:05 +0200, Sebastian Hesselbarth wrote:
> Are we sure, we want to fixup quirks like this the way below?
We already have an exactly identical quirk for the A0 I2C issue, in the
same file, right above the quirk Ezequiel is adding here. So using
On 04/16/2014 04:15 PM, Ezequiel Garcia wrote:
The initial release of the Armada 375 DB board has an Armada 375
Z1 stepping silicon. This commit introduces a quirk that allows
to workaround a series of issues with the thermal sensor in this
stepping, but updating the devicetree:
* Updates the
On Apr 16, Jason Cooper wrote:
> On Wed, Apr 16, 2014 at 11:15:18AM -0300, Ezequiel Garcia wrote:
> > In addition, we also add support for the Z1 SoC stepping, which needs
> > an initialization-quirk to work properly.
> ...
> > diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.t
Jason,
Thanks for taking a look.
On Apr 16, Jason Cooper wrote:
> On Wed, Apr 16, 2014 at 11:15:18AM -0300, Ezequiel Garcia wrote:
> > + /* This is only needed on A375 Z1 SoC silicon revision */
> > + reg |= A375_Z1_WORKAROUND_BIT;
>
> and this seem to be the only differences between the two
On Wed, Apr 16, 2014 at 11:15:18AM -0300, Ezequiel Garcia wrote:
> In addition, we also add support for the Z1 SoC stepping, which needs
> an initialization-quirk to work properly.
...
> diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
> b/Documentation/devicetree/bindings
This patch implements a generic CPU idle driver for ARM64 machines.
It relies on the DT idle states infrastructure to initialize idle
states count and respective parameters. Current code assumes the driver
is managing idle states on all possible CPUs but can be easily
generalized to support hetero
On most common ARM systems, the low-power states a CPU can be put into are
not discoverable in HW and require device tree bindings to describe
the respective power domains, power down protocol and idle states parameters.
In order to enable DT based idle states and configure idle drivers, this
patc
This patch implements the cpu_suspend cpu operations method through
the PSCI CPU_SUSPEND API. The PSCI implementation translates the idle state
index passed by the cpu_suspend core call into a valid PSCI state according to
the PSCI states initialized at boot by the PSCI suspend backend.
Entry poin
This patch updates the RTSM dts file with PSCI bindings and nodes
describing the AEMv8 model idle states parameters.
PSCI function IDs compliancy with PSCI v0.2 is still under development
so this patch provides PSCI function IDs for demonstration purposes only.
Signed-off-by: Lorenzo Pieralisi
-
This patchset is v2 of a previous posting:
http://www.spinics.net/lists/arm-kernel/msg316263.html
Changes in v2:
- Moved OF parsing code to drivers/cpuidle
- Improved states detection and sorting through linked list
- Split code in generic and ARM64 specific bits
- Moved idle enter function into
Ezequiel,
On Wed, Apr 16, 2014 at 11:15:18AM -0300, Ezequiel Garcia wrote:
> Now that a generic infrastructure is in place, it's possible to support
> the new Armada 375 SoC thermal sensor. This sensor is similar to the one
> available in the already supported SoCs, with its specific temperature f
1 - 100 of 187 matches
Mail list logo
