Hi,
On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
> On 09/30/2013 08:59 AM, Sricharan R wrote:
>> Some socs have a large number of interrupts requests to service
>> the needs of its many peripherals and subsystems. All of the interrupt
>> requests lines from t
Hi Thomas,
On Tuesday 17 September 2013 05:56 PM, Linus Walleij wrote:
> On Fri, Sep 13, 2013 at 4:24 PM, Thomas Gleixner wrote:
>
>> So why can't you make use of irq domains and have the whole routing
>> business implemented sanely?
>>
>> What's needed is in gic_init_bases():
>> irq
>>if
On Wednesday 18 September 2013 07:22 PM, Sricharan R wrote:
> Hi Thomas,
>
> On Tuesday 17 September 2013 05:56 PM, Linus Walleij wrote:
>> On Fri, Sep 13, 2013 at 4:24 PM, Thomas Gleixner wrote:
>>
>>> So why can't you make use of irq domains and have the who
Hi Mark,
On Friday 20 September 2013 02:28 PM, Mark Rutland wrote:
> Hi,
>
> I have a few comments, mostly on the DT binding and parsing.
>
Thanks for the review. The idea of seeing the crossbar as a new IRQCHIP
itself did not go and the latest direction on this was to handle it inside the
GIC.
been added here.
Sricharan R (4):
DRIVERS: IRQCHIP: Add crossbar irqchip driver
ARM: DTS: DRA: Add crossbar device binding
ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar
inputs.
ARM: DRA: Kconfig: Enable crossbar irqchip driver for DRA7xx
.../devicetree/bindin
only one
controller's input line. This models the crossbar as an interrupt
controller. This a cascaded irqchip where the peripheral interrupt
lines are connected to the crossbar and the crossbar's outputs
are in turn connected to the GIC.
Signed-off-by: Sricharan R
---
arch/arm/boot/dts/d
h crossbar and interrupt number
CPU0 CPU1
45:267 0 GIC OMAP UART0
205:267 0 CROSSBAR OMAP UART0
Cc: Thomas Gleixner
Cc: Linus Walleij
Cc: Santosh Shilimkar
Cc: Russell King
Cc: Tony Lindgren
Cc: Rajendra Nayak
Signed-off-by: Sricharan R
---
Enable the crossbar irqchip driver for DRA7xx soc.
Signed-off-by: Sricharan R
---
arch/arm/mach-omap2/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8413252..b602168 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b
-by: Sricharan R
---
arch/arm/boot/dts/dra7.dtsi | 88 +--
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index da977e1..2c541af 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch
On Friday 13 September 2013 07:12 AM, Santosh Shilimkar wrote:
> On Thursday 12 September 2013 08:26 PM, Thomas Gleixner wrote:
>> On Thu, 12 Sep 2013, Santosh Shilimkar wrote:
>>> On Thursday 12 September 2013 06:22 PM, Thomas Gleixner wrote:
Now the real question is, how that expansion mecha
ee
gic line for that gets allocated and configured when the peripheral's interrupt
is mapped.
The minimal crossbar driver to track and allocate free GIC lines and configure
the
crossbar is added here, along with the DT bindings.
Sricharan R (6):
DRIVERS: IRQCHIP: IRQ-GIC: Add support fo
and wakeup gen code
cannot rely on these numbers to access the irq registers. Instead
use the hwirq element of the irq_data which represent the physical
irq number.
Cc: Santosh Shilimkar
Cc: Rajendra Nayak
Cc: Tony Lindgren
Signed-off-by: Sricharan R
---
arch/arm/mach-omap2/omap-wakeupgen.c
Cousson
Cc: Santosh Shilimkar
Cc: Rajendra Nayak
Cc: Tony Lindgren
Signed-off-by: Sricharan R
---
arch/arm/boot/dts/dra7.dtsi | 88 +--
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7
only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.
Cc: Benoit Cousson
Cc: Santosh Shilimkar
Cc: Rajendra Nayak
Cc: Tony Lindgren
Signed-off-by: Sricharan R
---
arch/arm/boot/dts/dra7.dtsi |9 +
Enable the crossbar IP support for DRA7xx soc.
Cc: Santosh Shilimkar
Cc: Rajendra Nayak
Cc: Tony Lindgren
Signed-off-by: Sricharan R
---
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/omap4-common.c |4
2 files changed, 5 insertions(+)
diff --git a/arch/arm/mach
t, so that it is setup to handle the
irqchip callbacks.
Cc: Thomas Gleixner
Cc: Linus Walleij
Cc: Santosh Shilimkar
Cc: Russell King
Cc: Tony Lindgren
Cc: Rajendra Nayak
Cc: Marc Zyngier
Cc: Grant Likely
Cc: Rob Herring
Signed-off-by: Sricharan R
---
.../devicetree/bindings/arm
hould be implemented
to get a free irq and to configure the IP to route it.
Cc: Thomas Gleixner
Cc: Linus Walleij
Cc: Santosh Shilimkar
Cc: Russell King
Cc: Tony Lindgren
Cc: Rajendra Nayak
Cc: Marc Zyngier
Cc: Grant Likely
Cc: Rob Herring
Signed-off-by: Sricharan R
---
Document
On Monday 30 September 2013 07:52 PM, Santosh Shilimkar wrote:
> On Monday 30 September 2013 10:16 AM, Marc Zyngier wrote:
>> On 30/09/13 14:59, Sricharan R wrote:
>>> In some socs the gic can be preceded by a crossbar IP which
>>> routes the peripheral interrupts to the
Hi,
On Monday 23 September 2013 10:37 PM, Tony Lindgren wrote:
> * Javier Martinez Canillas [130923 10:09]:
>> On 09/23/2013 06:45 PM, Tony Lindgren wrote:
>>> Hmm does this still work for legacy platform data based
>>> drivers that are doing gpio_request() first?
>>>
>> Yes it still work when boo
On Tuesday 24 September 2013 01:24 PM, Javier Martinez Canillas wrote:
> On 09/24/2013 09:39 AM, Sricharan R wrote:
>> Hi,
>> On Monday 23 September 2013 10:37 PM, Tony Lindgren wrote:
>>> * Javier Martinez Canillas [130923 10:09]:
>>>> On 09/23/2013 06:45 PM,
Hi Linus,
On Thursday 22 August 2013 02:40 AM, Linus Walleij wrote:
> On Thu, Aug 15, 2013 at 11:14 PM, Santosh Shilimkar
> wrote:
>> On Thursday 15 August 2013 04:51 PM, Linus Walleij wrote:
> (...)
>>> Sorry I don't understand what thread that is... can you point me there?
>>> My previous state
Hi,
On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
> On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
>> maps crossbar number<-> to interrupt number and
>> calls request_irq(int_no, crossbar_handler,..)
> So will this mapping happen based on some data
On Friday 23 August 2013 12:06 PM, Sekhar Nori wrote:
> On Friday 23 August 2013 11:41 AM, Sricharan R wrote:
>> Hi,
>> On Friday 23 August 2013 10:17 AM, Rajendra Nayak wrote:
>>> On Thursday 22 August 2013 05:03 PM, Sricharan R wrote:
>>>> maps crossba
the basic DRA support from Rajendra [1][2]
[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/100763
[2] http://comments.gmane.org/gmane.linux.ports.arm.omap/100773
Sricharan R (3):
misc: Add crossbar driver
ARM: dts: DRA: Add crossbar device binding
ARM: DRA: Enable crossbar driver for
s mapped
during the crossbar device's probe. The mappings can also be specified by adding
the crossbar lines to the peripheral device nodes and map it with
crossbar_map/unmap apis.
Signed-off-by: Sricharan R
---
.../devicetree/bindings/arm/omap/crossbar.txt | 24 ++
g for some peripherals are
added with the crossbar nodes here.
Signed-off-by: Sricharan R
---
arch/arm/boot/dts/dra7.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index a5d9350..e6208b4 100644
--- a/arch/ar
Enable the crossbar driver to handle the irq/dma
crossbar devices in the soc.
Signed-off-by: Sricharan R
---
arch/arm/mach-omap2/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 80aaadc..3def350 100644
--- a/arch/arm
Hi,
On Friday 19 July 2013 05:43 AM, Nishanth Menon wrote:
> On Thu, Jul 18, 2013 at 6:39 PM, Santosh Shilimkar
> wrote:
>> On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
>>> On 07/18/2013 11:43 AM, Sricharan R wrote:
>>>> Some socs have a large num
On Friday 19 July 2013 12:47 PM, Tony Lindgren wrote:
>> On Thursday 18 July 2013 02:56 PM, Nishanth Menon wrote:
>>
>> Since the cross-bar is not limited t0 IRQ lines and applicable for
>> DMA request lines as well, making it IRQ chip doesn't make sense. Its
>> not typical pin control functionalit
Hi Linus,
On Sunday 21 July 2013 10:19 PM, Linus Walleij wrote:
> On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon wrote:
>
>> I carry forward my TI internal objection to this approach:
> It is actually a very good sign of FOSS-maturity that you as a company
> take unresolved architectural issues t
On Wednesday 24 July 2013 10:17 PM, Nishanth Menon wrote:
> On 07/24/2013 11:38 AM, Santosh Shilimkar wrote:
>> On Wednesday 24 July 2013 12:08 PM, Nishanth Menon wrote:
>>> That said, maybe a intermediate pinctrl approach might be more pragmatic
>>> and less theoretically flexible.
>>> an option
Hi Tony,
On Tuesday 13 August 2013 01:40 PM, Tony Lindgren wrote:
> * Santosh Shilimkar [130724 12:06]:
>> On Wednesday 24 July 2013 02:51 PM, Nishanth Menon wrote:
>>> On 07/24/2013 01:43 PM, Sricharan R wrote:
>>>> On Wednesday 24 July 2013 10:17 PM, Nishanth Me
On Tuesday 28 May 2013 06:35 PM, Will Deacon wrote:
> On Tue, May 28, 2013 at 11:48:20AM +0100, Po-Yu Chuang wrote:
>> This bug was introduced in commit e651eab0.
>> Some v4/v5 platforms failed to boot due to this.
>>
>> Signed-off-by: Po-Yu Chuang
>> ---
>> arch/arm/mm/mmu.c |4 +++-
>> 1 fi
On Tuesday 28 May 2013 07:37 PM, Will Deacon wrote:
> On Tue, May 28, 2013 at 03:03:36PM +0100, Sricharan R wrote:
>> On Tuesday 28 May 2013 06:35 PM, Will Deacon wrote:
>>> On Tue, May 28, 2013 at 11:48:20AM +0100, Po-Yu Chuang wrote:
>>>> This bug was introduced in
rpmsg: glink: Introduce glink smem based transport
rpmsg: glink: Make RX FIFO peak accessor to take an offset
Sricharan R (11):
rpmsg: glink: Fix default case while handling received commands
rpmsg: glink: Add support for transport version negotiation
rpmsg: glink: Fix idr_lock from mu
From: Bjorn Andersson
Renaming the glink_rpm_xx functions and structs to qcom_glink_xx
equivalents helps to reuse the core glink protocol while adding
support for smem based glink transport in the later patches.
Signed-off-by: Bjorn Andersson
Signed-off-by: Sricharan R
---
drivers/rpmsg
rpmsg: glink: Introduce glink smem based transport
rpmsg: glink: Make RX FIFO peak accessor to take an offset
Sricharan R (11):
rpmsg: glink: Fix default case while handling received commands
rpmsg: glink: Add support for transport version negotiation
rpmsg: glink: Fix idr_lock from mu
From: Bjorn Andersson
Move the common part of glink core protocol implementation to
glink_native.c that can be shared with the smem based glink
transport in the later patches.
Signed-off-by: Bjorn Andersson
Signed-off-by: Sricharan R
---
drivers/rpmsg/Kconfig |6 +-
drivers
Currently if we receive a command that we still do not
support, then its simply discarded. While doing so, the
RX FIFO pointer also needs to be incremented. Fixing this.
Signed-off-by: Sricharan R
---
drivers/rpmsg/qcom_glink_native.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers
Send RX data receive ack to remote and also inform
that local intent buffer is used and freed. This
informs the remote to request for next set of
intent buffers before doing a send operation.
Signed-off-by: Sricharan R
Signed-off-by: Bjorn Andersson
---
drivers/rpmsg/qcom_glink_native.c | 83
Just like we allocating and sending intent ids to remote,
remote side allocates and sends us the intents as well.
So save the intent ids and use it later while sending
data targeting the appropriate intents based on the size.
Signed-off-by: Sricharan R
Signed-off-by: Bjorn Andersson
Once the remote side sends a rx done ack, check
for the intent reuse information from it and
suitably discard or reuse the remote passed
intent buffers.
Signed-off-by: Sricharan R
Signed-off-by: Bjorn Andersson
---
drivers/rpmsg/qcom_glink_native.c | 42
allocate buffers of requested
size, store the buffer id locally and also communicate
the intent id to the remote.
Signed-off-by: Sricharan R
Signed-off-by: Bjorn Andersson
---
drivers/rpmsg/qcom_glink_native.c | 161 +-
drivers/rpmsg/qcom_glink_native.h | 3
So previously on request from remote side, we allocated local
intent buffers and passed the ids to the remote. Now when
we receive data buffers from remote directed to that intent
id, copy the data to the corresponding preallocated intent
buffer.
Signed-off-by: Sricharan R
Signed-off-by: Bjorn
While sending data, we search for suitable sized
intent to map and simply fail if a intent is not
found. Instead request for a intent of required
size and wait till one is alloted.
Signed-off-by: Sricharan R
Signed-off-by: Bjorn Andersson
---
drivers/rpmsg/qcom_glink_native.c | 73
While sending data, use the remote intent id buffer
of suitable size that was passed by remote previously.
Signed-off-by: Sricharan R
Signed-off-by: Bjorn Andersson
---
drivers/rpmsg/qcom_glink_native.c | 35 +--
1 file changed, 33 insertions(+), 2 deletions
introduce this.
Signed-off-by: Bjorn Andersson
Signed-off-by: Sricharan R
---
drivers/rpmsg/qcom_glink_native.c | 15 +++
drivers/rpmsg/qcom_glink_native.h | 2 +-
drivers/rpmsg/qcom_glink_rpm.c| 5 -
drivers/rpmsg/qcom_glink_smem.c | 5 -
4 files changed, 16 insertions
The channel members lcids, rcids synchronised using
the idr_lock is accessed in both atomic/non-atomic
contexts. The readers are not currently synchronised.
That no correct, so add the readers as well under the
lock and use a spinlock.
Signed-off-by: Sricharan R
Signed-off-by: Bjorn Andersson
rpmsg device gets probed.
Signed-off-by: Sricharan R
Signed-off-by: Bjorn Andersson
---
drivers/rpmsg/qcom_glink_native.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/rpmsg/qcom_glink_native.c
b/drivers/rpmsg/qcom_glink_native.c
index b8db74a..c111046 100644
alignment restriction.
Signed-off-by: Bjorn Andersson
Signed-off-by: Sricharan R
---
drivers/rpmsg/qcom_glink_native.c | 6 --
drivers/rpmsg/qcom_glink_rpm.c| 22 +-
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/rpmsg/qcom_glink_native.c
b
t register function and the
fifo accessors for the same.
Signed-off-by: Bjorn Andersson
Signed-off-by: Sricharan R
---
drivers/rpmsg/Kconfig| 10 ++
drivers/rpmsg/Makefile | 1 +
drivers/rpmsg/qcom_glink_smem.c | 304 +++
include/l
transport is opened and they cannot be changed after negotiation has
been completed.
Each full implementation of G-Link must support a minimum of the current
version, the previous version, and the base negotiation version called v0.
Signed-off-by: Sricharan R
Signed-off-by: Bjorn Andersson
tx)
behind indirections, so that the rest of the code can be shared.
For this, have a qcom_glink_pipe that can be used in the common code
containing the indirections and wrap it with glink_rpm_pipe that contains
the transport specific members.
Signed-off-by: Bjorn Andersson
Signed-off-by: S
emove as well.
Signed-off-by: Bjorn Andersson
Signed-off-by: Sricharan R
---
drivers/rpmsg/qcom_glink_rpm.c | 85 --
1 file changed, 49 insertions(+), 36 deletions(-)
diff --git a/drivers/rpmsg/qcom_glink_rpm.c b/drivers/rpmsg/qcom_glink_rpm.c
index 87
Hi Bjorn,
On 5/26/2017 12:33 AM, Bjorn Andersson wrote:
> On Mon 22 May 06:26 PDT 2017, Dwivedi, Avaneesh Kumar (avani) wrote:
>> On 5/22/2017 4:07 PM, Sricharan R wrote:
>>> Hi,
>>>
>>> On 5/22/2017 3:03 PM, Dwivedi, Avaneesh Kumar (avani) wrote:
>>>&
ormer. This takes care of resetting the dma_ops in the teardown
path.
Signed-off-by: Sricharan R
Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for
platform/amba/pci bus devices")
---
arch/arm/mm/dma-mapping.c | 25 ++---
1 file changed, 10 in
Hi Laurent,
On 5/26/2017 7:44 PM, Laurent Pinchart wrote:
> Hi Sricharan,
>
> Thank you for the patch.
>
> On Friday 26 May 2017 16:13:37 Sricharan R wrote:
>> arch_teardown_dma_ops() being the inverse of arch_setup_dma_ops()
>> ,dma_ops should be cleared in the tea
Reviewed-by: Laurent Pinchart
Tested-by: Will Deacon
Tested-by: Magnus Damn
Acked-by: Will Deacon
Signed-off-by: Sricharan R
---
drivers/iommu/of_iommu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 9f44ee8..e6e9bec 100644
--- a/driv
only -EPROBE_DEFER from
iort_iommu_configure.
Fixes: 5a1bb638d567 ("drivers: acpi: Handle IOMMU lookup failure with deferred
probing or error")
Signed-off-by: Sricharan R
---
drivers/acpi/arm64/iort.c | 6 ++
drivers/acpi/scan.c | 4 ++--
2 files changed, 8 insertions(+), 2 deletions(-
From: Laurent Pinchart
arch_setup_dma_ops() is used in device probe code paths to create an
IOMMU mapping and attach it to the device. The function assumes that the
device is attached to a device-specific IOMMU instance (or at least a
device-specific TLB in a shared IOMMU instance) and thus creat
ormer. This takes care of resetting the dma_ops in the teardown
path.
Fixes: 09515ef5ddad ("of/acpi: Configure dma operations at probe time for
platform/amba/pci bus devices")
Reviewed-by: Laurent Pinchart
Signed-off-by: Sricharan R
---
arch/arm/mm/dma-mapping.c | 25 ++
From: Lorenzo Pieralisi
With IOMMU probe deferral, iort_iommu_configure can be called
multiple times for the same device. Hence we have a check
to see if the device's fwspec is already translated and return
the iommu_ops from that directly. But the check is wrongly
placed in iort_iommu_xlate, whi
DEFER from
of_iommu_configure.
Fixes: 7b07cbefb68d ("iommu: of: Handle IOMMU lookup failure with deferred
probing or error")
Reported-by: Geert Uytterhoeven
Tested-by: Magnus Damn
Signed-off-by: Sricharan R
---
drivers/iommu/of_iommu.c | 6 ++
drivers/of/device.c | 4 ++--
2 f
Hi Rafael,
On 5/28/2017 12:48 AM, Rafael J. Wysocki wrote:
> On Saturday, May 27, 2017 07:17:42 PM Sricharan R wrote:
>> While deferring the probe of IOMMU masters, xlate and
>> add_device callbacks called from iort_iommu_configure
>> can pass back error values like -ENODE
Hi Rob,
On 11/11/2017 2:38 AM, Rob Herring wrote:
> On Thu, Nov 09, 2017 at 08:16:14PM +0530, Sricharan R wrote:
>> IPQ8074 has an integrated Hexagon dsp core q6v5 and a wireless lan
>> (Lithium) IP. An mdt type single image format is used for the
>> firmware. So the mdt
V3:
Rebased on top of latest remoteproc next
V2:
Last time introduced this a new rproc driver, but there is lot
of code that can be shared if it is added to the q6v5-mpss pil
driver.
Sricharan R (6):
remoteproc: qcom: mdt_loader: Make the firmware authentication
optional
qcom_mdt_load function loads the mdt type firmware and
initialises the secure memory as well. Make the initialisation only
when requested by the caller, so that the function can be used
by self-authenticating remoteproc as well.
Acked-by: Bjorn Andersson
Signed-off-by: Sricharan R
---
drivers
Export rproc_elf_get_boot_addr so that it can be
used by any remoteproc to get the bootaddr of the
elf type firmware images. This is used in the
subsequent patch by the q6v5 based remoteproc
while loading its elf based mdt type image.
Signed-off-by: Sricharan R
---
drivers/remoteproc
q6v5-wcss core's start function is mostly common
with the q6v5 of msm8996. So reuse that and add
the stop function.
Signed-off-by: Sricharan R
---
drivers/remoteproc/qcom_q6v5_pil.c | 212 +
1 file changed, 212 insertions(+)
diff --git a/drivers/remot
Most of the q6v5-pil start function is same for the q6v5-wcss rproc
that will be added later. So split and move out the common pieces
so that the same code can be reused.
Signed-off-by: Sricharan R
---
drivers/remoteproc/qcom_q6v5_pil.c | 166 -
1 file
: Sricharan R
---
.../devicetree/bindings/remoteproc/qcom,q6v5.txt | 7 ++-
drivers/remoteproc/Kconfig | 1 +
drivers/remoteproc/qcom_q6v5_pil.c | 53 +-
3 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/Documentation
Instead of directly assigning reset, fw and rproc ops, put them
in to of_match data and get from that. Currently same ops
are used for all compatibles, but that will change when we add
q6v5-wcss support.
Signed-off-by: Sricharan R
---
drivers/remoteproc/qcom_q6v5_pil.c | 38
On 11/14/2017 4:23 PM, Sricharan R wrote:
> IPQ8074 has an integrated Hexagon dsp core q6v5 and a wireless lan
> (Lithium) IP. An mdt type single image format is used for the
> firmware. So the mdt_load function can be directly used to load
> the firmware. Also add the relevant res
Hi Bjorn,
On 10/12/2017 11:56 PM, Bjorn Andersson wrote:
> On Wed 30 Aug 21:45 PDT 2017, Sricharan R wrote:
>
>> qcom_mdt_load function loads the mdt type firmware and
>> initialises the secure memory as well. Make the initialisation only
>> when requested by the caller,
Hi Bjorn,
On 10/17/2017 12:28 AM, Bjorn Andersson wrote:
> On Mon 16 Oct 06:19 PDT 2017, Dwivedi, Avaneesh Kumar (avani) wrote:
>> On 10/12/2017 11:50 PM, Bjorn Andersson wrote:
> [..]
>>> Please fix this and add my Acked-by
>> Sure will do, just want to ask, when i am sending updated patches, sho
The relevant data for sdcc.
Signed-off-by: Sricharan R
---
arch/arm/boot/dts/qcom-ipq8064.dtsi | 76 +
1 file changed, 76 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index e02d588..e78618e 100644
Adding the pcie nodes and pins.
Signed-off-by: Sricharan R
---
arch/arm/boot/dts/qcom-ipq8064.dtsi | 182
1 file changed, 182 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi
b/arch/arm/boot/dts/qcom-ipq8064.dtsi
index 70790ac..e02d588 100644
Add the dt nodes for enabling the leds and gpio-buttons.
Signed-off-by: Sricharan R
---
arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 8 +
arch/arm/boot/dts/qcom-ipq8064-v1.0.dtsi | 60
arch/arm/boot/dts/qcom-ipq8064.dtsi | 19 ++
3 files changed
Adding pcie,sdcc nodes and a new board file ipq8064-ap161
Sricharan R (5):
arm: dts: qcom: Add pcie nodes for ipq8064
arm: dts: qcom: Add sdcc nodes for ipq8064
arm: dts: qcom: Move common nodes to ipq8064-v.1.0.dtsi
arm: dts: qcom: Add ipq8064-ap161.dts
arm: dts: qcom: Add led and gpio
Add a new board dts for ipq8064-ap161.
Signed-off-by: Sricharan R
---
Documentation/devicetree/bindings/arm/qcom.txt | 2 ++
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/qcom-ipq8064-ap161.dts | 7 +++
3 files changed, 10 insertions(+)
create mode 100644
The nodes in ipq8064-ap148.dts currently are common with
boards that we will add next. So move the common data to
ipq8064-v.1.0.dtsi.
Signed-off-by: Sricharan R
---
arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 83 ++--
arch/arm/boot/dts/qcom-ipq8064-v1.0.dtsi | 65
Hi Rob,
On 8/7/2018 2:05 AM, Rob Herring wrote:
> On Fri, Aug 3, 2018 at 8:10 AM Sricharan R wrote:
>>
>> Add a new board dts for ipq8064-ap161.
>>
>> Signed-off-by: Sricharan R
>> ---
>> Documentation/devicetree/bindings/arm/qcom.tx
-kernel/2015-March/332608.html
[4] https://lwn.net/Articles/740994/
[5] https://lkml.org/lkml/2017/12/19/537
Sricharan R (3):
clk: qcom: Add safe switch hook for krait mux clocks
cpufreq: qcom: Re-organise kryo cpufreq to use it for other nvmem
based qcom socs
cpufreq: qcom: Add suppor
From: Stephen Boyd
Krait CPUs have a handful of L2 cache controller registers that
live behind a cp15 based indirection register. First you program
the indirection register (l2cpselr) to point the L2 'window'
register (l2cpdr) at what you want to read/write. Then you
read/write the 'window' regi
From: Stephen Boyd
HFPLLs are the main frequency source for Krait CPU clocks. Add
support for changing the rate of these PLLs.
Signed-off-by: Stephen Boyd
---
drivers/clk/qcom/Makefile| 1 +
drivers/clk/qcom/clk-hfpll.c | 244 +++
drivers/clk/qcom/
From: Stephen Boyd
On some devices (MSM8974 for example), the HFPLLs are
instantiated within the Krait processor subsystem as separate
register regions. Add a driver for these PLLs so that we can
provide HFPLL clocks for use by the system.
Cc:
Signed-off-by: Stephen Boyd
---
drivers/clk/qcom/
From: Stephen Boyd
The ACC and GCC regions present in KPSSv1 contain registers to
control clocks and power to each Krait CPU and L2. Documenting
the bindings here.
Reviewed-by: Rob Herring
Signed-off-by: Stephen Boyd
---
.../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 19 ++
.../
From: Stephen Boyd
Describe the HFPLLs present on MSM8960 and APQ8064 devices.
Acked-by: Rob Herring (bindings)
Signed-off-by: Stephen Boyd
---
drivers/clk/qcom/gcc-msm8960.c | 172 +++
include/dt-bindings/clock/qcom,gcc-msm8960.h | 2 +
2 files changed
From: Stephen Boyd
Adds bindings document for qcom,hfpll instantiated within
the Krait processor subsystem as separate register region.
Reviewed-by: Rob Herring
Signed-off-by: Stephen Boyd
---
.../devicetree/bindings/clock/qcom,hfpll.txt | 60 ++
1 file changed, 60 i
From: Stephen Boyd
The ACC and GCC regions present in KPSSv1 contain registers to
control clocks and power to each Krait CPU and L2. For CPUfreq
purposes probe these devices and expose a mux clock that chooses
between PXO and PLL8.
Cc:
Signed-off-by: Stephen Boyd
---
drivers/clk/qcom/Kconfig
From: Stephen Boyd
The Krait clocks are made up of a series of muxes and a divider
that choose between a fixed rate clock and dedicated HFPLLs for
each CPU. Instead of using mmio accesses to remux parents, the
Krait implementation exposes the remux control via cp15
registers. Support these clocks
From: Stephen Boyd
Describe the HFPLLs present on IPQ806X devices.
Signed-off-by: Stephen Boyd
---
drivers/clk/qcom/gcc-ipq806x.c | 82 ++
1 file changed, 82 insertions(+)
diff --git a/drivers/clk/qcom/gcc-ipq806x.c b/drivers/clk/qcom/gcc-ipq806x.c
inde
From: Stephen Boyd
The Krait clock controller controls the krait CPU and the L2 clocks
consisting a primary mux and secondary mux. Add document for that.
Reviewed-by: Rob Herring
Signed-off-by: Stephen Boyd
---
.../devicetree/bindings/clock/qcom,krait-cc.txt| 34 ++
1
From: Stephen Boyd
The Krait CPU clocks are made up of a primary mux and secondary
mux for each CPU and the L2, controlled via cp15 accessors. For
Kraits within KPSSv1 each secondary mux accepts a different aux
source, but on KPSSv2 each secondary mux accepts the same aux
source.
Cc:
Signed-off
itching to the safe parent in the PRE_RATE_CHANGE notifier
and back to the original parent in the POST_RATE_CHANGE notifier.
Signed-off-by: Sricharan R
---
drivers/clk/qcom/clk-krait.c | 2 ++
drivers/clk/qcom/clk-krait.h | 3 +++
drivers/clk/qcom/krait-
adding support for krait cores here.
Signed-off-by: Sricharan R
---
.../devicetree/bindings/opp/qcom-nvmem-cpufreq.txt | 3 +-
drivers/cpufreq/Kconfig.arm| 2 +-
drivers/cpufreq/cpufreq-dt-platdev.c | 5 +
drivers/cpufreq/qcom-cpufreq-nvmem.c
.
Signed-off-by: Sricharan R
---
.../{kryo-cpufreq.txt => qcom-nvmem-cpufreq.txt} | 6 +-
drivers/cpufreq/Kconfig.arm| 4 +-
drivers/cpufreq/Makefile | 2 +-
.../{qcom-cpufreq-kryo.c => qcom-cpufreq-nvmem.c} | 124 -
4
: Sricharan R
---
drivers/clk/qcom/Kconfig | 8
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/hfpll.c | 96 +++
3 files changed, 105 insertions(+)
create mode 100644 drivers/clk/qcom/hfpll.c
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom
From: Stephen Boyd
HFPLLs are the main frequency source for Krait CPU clocks. Add
support for changing the rate of these PLLs.
Signed-off-by: Stephen Boyd
Signed-off-by: Sricharan R
---
drivers/clk/qcom/Makefile| 1 +
drivers/clk/qcom/clk-hfpll.c | 244
infradead.org/pipermail/linux-arm-kernel/2015-March/332615.html
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332608.html
[4] https://lwn.net/Articles/740994/
[5] https://lkml.org/lkml/2017/12/19/537
Sricharan R (3):
clk: qcom: Add safe switch hook for krait mux clocks
1 - 100 of 893 matches
Mail list logo
