On 26 June 2014 00:32, Stephen Boyd sb...@codeaurora.org wrote:
+ cpu_reg = regulator_get_optional(cpu_dev, cpu0);
I don't think this driver should be using regulator_get_optional() (Mark
B. please correct me if I'm wrong). I doubt a supply is actually
optional for CPUs, just some DTs
Is it possible to queue these patches for next rc?
Thanks,
srini
On 18/06/14 18:00, Srinivas Kandagatla wrote:
While testing usb host on Qualcomm APQ8064, I encountered few issues.
These patches fixes those issues.
Without these patches USB is not functional on AQ8064.
All the patches are
On 26 June 2014 00:32, Stephen Boyd sb...@codeaurora.org wrote:
I don't think this driver should be using regulator_get_optional() (Mark
B. please correct me if I'm wrong). I doubt a supply is actually
optional for CPUs, just some DTs aren't specifying them. In those cases,
the regulator core
On 06/26/2014 12:28 AM, Courtney Cavin wrote:
On Wed, Jun 25, 2014 at 11:18:57PM +0200, Rob Herring wrote:
On Wed, Jun 25, 2014 at 1:04 PM, Courtney Cavin
courtney.ca...@sonymobile.com wrote:
On Wed, Jun 25, 2014 at 01:07:13PM +0200, Stanimir Varbanov wrote:
On 06/25/2014 01:36 AM, Courtney
This patch set introduces the dmaengine driver for the Qualcomm Application
Data Mover (ADM) DMA controller present on MSM8960, APQ8064, and IPQ8064
devices.
The initial version of this driver will only support slave DMA operations
between system memory and peripherals. Flow control via the CRCI
Add device tree binding support for the QCOM ADM DMA driver.
Signed-off-by: Andy Gross agr...@codeaurora.org
---
Documentation/devicetree/bindings/dma/qcom_adm.txt | 60
1 file changed, 60 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/qcom_adm.txt
This patch adds DMA capabilities to the spi-qup driver. If DMA channels are
present, the QUP will use DMA instead of block mode for transfers to/from SPI
peripherals for transactions larger than the length of a block.
Signed-off-by: Andy Gross agr...@codeaurora.org
---
On Wed, Jun 25, 2014 at 12:02:25PM -0700, Stephen Boyd wrote:
I don't think this driver should be using regulator_get_optional() (Mark
B. please correct me if I'm wrong). I doubt a supply is actually
optional for CPUs, just some DTs aren't specifying them. In those cases,
the regulator core
Quoting Stephen Boyd (2014-06-26 17:06:00)
Finally, checking for equivalent pointers from clk_get() will work now,
Please don't do that. Even though it works for the current
implementation, comparing those pointers from a driver violates how
clkdev is supposed to work. The pointer returned by
On 27 June 2014 07:23, Mike Turquette mturque...@linaro.org wrote:
but it isn't future-proof if/when the clock framework starts returning
dynamically allocated clock pointers for each clk_get() invocation.
Maybe we need a function in the common clock framework that tells us if
the clocks are
On 27 June 2014 05:36, Stephen Boyd sb...@codeaurora.org wrote:
I gave it a spin. It looks mostly good except for the infinite loop:
Great !!
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index b7ee67c4d1c0..6744321ae33d 100644
---
11 matches
Mail list logo
