On 08/02/21, Jorge Ramirez-Ortiz, Foundries wrote:
> On 08/02/21, Jens Wiklander wrote:
> > Hi Jorge,
> >
> > On Wed, Jan 27, 2021 at 11:41 AM Jens Wiklander
> > wrote:
> > >
> > > Hi Arnd,
> > >
> > > On Mon, Jan 25, 2021 at 12:
On 08/02/21, Jens Wiklander wrote:
> Hi Jorge,
>
> On Wed, Jan 27, 2021 at 11:41 AM Jens Wiklander
> wrote:
> >
> > Hi Arnd,
> >
> > On Mon, Jan 25, 2021 at 12:38 PM Arnd Bergmann wrote:
> > >
> > > From: Arnd Bergmann
> > >
> > > Storing a bogus i2c_client structure on the stack adds overhead
On 26/01/21, Sai Prakash Ranjan wrote:
> As per register documentation, QCOM_WDT_ENABLE_IRQ which is BIT(1)
> of watchdog control register is wakeup interrupt enable bit and
> not related to bark interrupt at all, BIT(0) is used for that.
> So remove incorrect usage of this bit when supporting
On 25/01/21, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Storing a bogus i2c_client structure on the stack adds overhead and
> causes a compile-time warning:
>
> drivers/tee/optee/rpc.c:493:6: error: stack frame size of 1056 bytes in
> function 'optee_handle_rpc'
On 26/01/21, Arnd Bergmann wrote:
> On Tue, Jan 26, 2021 at 9:08 AM Jorge Ramirez-Ortiz, Foundries
> wrote:
> >
> > On 25/01/21, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > Storing a bogus i2c_client structure on the stack adds ove
On 23/09/20, Jens Wiklander wrote:
> On Wed, Sep 23, 2020 at 01:26:31PM +0200, Jorge Ramirez-Ortiz, Foundries
> wrote:
> > On 23/09/20, Jorge Ramirez-Ortiz, Foundries wrote:
> > > On 22/09/20, Jens Wiklander wrote:
> > > > On Wed, Sep 16, 2020 at 05:27:32PM
On 23/09/20, Jorge Ramirez-Ortiz, Foundries wrote:
> On 22/09/20, Jens Wiklander wrote:
> > On Wed, Sep 16, 2020 at 05:27:32PM +0200, Jorge Ramirez-Ortiz wrote:
> > > Allow OP-TEE to specify the number of retries in the adaptor.
> > >
> > >
On 22/09/20, Jens Wiklander wrote:
> On Wed, Sep 16, 2020 at 05:27:32PM +0200, Jorge Ramirez-Ortiz wrote:
> > Allow OP-TEE to specify the number of retries in the adaptor.
> >
> > Signed-off-by: Jorge Ramirez-Ortiz
> > ---
> > drivers/tee/optee/rpc.c |
Allow OP-TEE to specify the number of retries in the adaptor.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/tee/optee/rpc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
index 1e3614e4798f..2d46a9ecb1de 100644
--- a/drivers/tee
, optee=m
i2c=m, optee=y (not supported)
Reported-by: kernel test robot
Signed-off-by: Jorge Ramirez-Ortiz
---
v2: uses IS_REACHABLE instead of macro combination
This patch applies on top of
https://git.linaro.org/people/jens.wiklander/linux-tee.git/tag/?h=optee-i2c-for-v5.10
drivers
On 31/08/20, Randy Dunlap wrote:
> On 8/31/20 8:23 AM, Jorge Ramirez-Ortiz wrote:
> > When the optee driver is compiled into the kernel while the i2c core
> > is configured as a module, the i2c symbols are not available.
> >
> > This commit addresses the situation b
, optee=m
i2c=m, optee=y (not supported)
Reported-by: kernel test robot
Signed-off-by: Jorge Ramirez-Ortiz
---
This patch applies on top of
https://git.linaro.org/people/jens.wiklander/linux-tee.git/tag/?h=optee-i2c-for-v5.10
drivers/tee/optee/rpc.c | 2 ++
1 file changed, 2 insertions
On 21/08/20, Jens Wiklander wrote:
> On Fri, Aug 14, 2020 at 01:12:21PM +0200, Jorge Ramirez-Ortiz wrote:
> > Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> > control this type of cryptographic devices it needs coordinated access
> > to t
Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
control this type of cryptographic devices it needs coordinated access
to the bus, so collisions and RUNTIME_PM dont get in the way.
This trampoline driver allow OP-TEE to access them.
Signed-off-by: Jorge Ramirez-Ortiz
On 13/08/20, Jens Wiklander wrote:
> On Wed, Aug 12, 2020 at 02:06:52PM +0200, Jorge Ramirez-Ortiz wrote:
> > Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> > control this type of cryptographic devices it needs coordinated access
> > to t
Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
control this type of cryptographic devices it needs coordinated access
to the bus, so collisions and RUNTIME_PM dont get in the way.
This trampoline driver allow OP-TEE to access them.
Signed-off-by: Jorge Ramirez-Ortiz
On 12/08/20, Jens Wiklander wrote:
> On Tue, Aug 11, 2020 at 07:55:31PM +0200, Jorge Ramirez-Ortiz wrote:
> > Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> > control this type of cryptographic devices it needs coordinated access
> > to t
Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
control this type of cryptographic devices it needs coordinated access
to the bus, so collisions and RUNTIME_PM dont get in the way.
This trampoline driver allow OP-TEE to access them.
Signed-off-by: Jorge Ramirez-Ortiz
Data rates of MAX_UINT32 will schedule an unnecessary one jiffy
timeout on the call to msleep. Avoid this scenario by using 0 as the
unlimited data rate.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Sumit Garg
---
drivers/char/hw_random/optee-rng.c | 2 +-
1 file changed, 1 insertion(+), 1
on
the first read.
Worth noticing that since msleep(0) schedules a one jiffy timeout is
better to skip such a call.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Sumit Garg
---
drivers/char/hw_random/optee-rng.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char
on
the first read.
Worth noticing that since msleep(0) schedules a one jiffy timeout is
better to skip such a call.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Sumit Garg
---
drivers/char/hw_random/optee-rng.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char
On 06/08/20, Sumit Garg wrote:
> On Thu, 6 Aug 2020 at 12:00, Jorge Ramirez-Ortiz, Foundries
> wrote:
> >
> > On 06/08/20, Sumit Garg wrote:
> > > On Thu, 6 Aug 2020 at 02:08, Jorge Ramirez-Ortiz, Foundries
> > > wrote:
> > > >
> > > &g
On 06/08/20, Sumit Garg wrote:
> On Thu, 6 Aug 2020 at 02:08, Jorge Ramirez-Ortiz, Foundries
> wrote:
> >
> > On 05/08/20, Sumit Garg wrote:
> > > Apologies for my delayed response as I was busy with some other tasks
> > > along with holidays.
> >
On 05/08/20, Sumit Garg wrote:
> Apologies for my delayed response as I was busy with some other tasks
> along with holidays.
no pb! was just making sure this wasnt falling through some cracks.
>
> On Fri, 24 Jul 2020 at 19:53, Jorge Ramirez-Ortiz, Foundries
> wrote:
> >
&
On 05/08/20, Jens Wiklander wrote:
> On Wed, Aug 05, 2020 at 03:35:01PM +0200, Jorge Ramirez-Ortiz, Foundries
> wrote:
> > On 22/07/20, Jorge Ramirez-Ortiz wrote:
> > > Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> > > control this type of
On 23/07/20, Jorge Ramirez-Ortiz wrote:
> The current code waits for data to be available before attempting a
> second read. However the second read would not be executed as the
> while loop exits.
>
> This fix does not wait if all data has been read and reads a second
> time if
On 22/07/20, Jorge Ramirez-Ortiz wrote:
> Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> control this type of cryptographic devices it needs coordinated access
> to the bus, so collisions and RUNTIME_PM dont get in the way.
>
> This trampoline driv
On 22/07/20, Jorge Ramirez-Ortiz wrote:
> Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> control this type of cryptographic devices it needs coordinated access
> to the bus, so collisions and RUNTIME_PM dont get in the way.
>
> This trampoline driv
On 24/07/20, Jorge Ramirez-Ortiz, Foundries wrote:
> On 24/07/20, Sumit Garg wrote:
> > On Thu, 23 Jul 2020 at 14:16, Jorge Ramirez-Ortiz
> > wrote:
> > >
> > > The current code waits for data to be available before attempting a
> > > second read. How
On 24/07/20, Sumit Garg wrote:
> On Thu, 23 Jul 2020 at 14:16, Jorge Ramirez-Ortiz wrote:
> >
> > The current code waits for data to be available before attempting a
> > second read. However the second read would not be executed as the
> > while loop exits.
> >
does not attempt to read if not data is requested.
Signed-off-by: Jorge Ramirez-Ortiz
---
v2: tidy up the while loop to avoid reading when no data is requested
drivers/char/hw_random/optee-rng.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/optee
Data rates of MAX_UINT32 will schedule an unnecessary one jiffy
timeout on the call to msleep. Avoid this scenario by using 0 as the
unlimited data rate.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/char/hw_random/optee-rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
-by: Jorge Ramirez-Ortiz
---
v6: compile out if CONFIG_I2C not enabled
v5: alphabetic order of includes
v4: remove unnecessary extra line in optee_msg.h
v3: use from/to msg param to support all types of memory
modify OPTEE_MSG_RPC_CMD_I2C_TRANSFER message id
drivers/tee/optee/optee_msg.h
Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
control this type of cryptographic devices it needs coordinated access
to the bus, so collisions and RUNTIME_PM dont get in the way.
This trampoline driver allow OP-TEE to access them.
Signed-off-by: Jorge Ramirez-Ortiz
Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
control this type of cryptographic devices it needs coordinated access
to the bus, so collisions and RUNTIME_PM dont get in the way.
This trampoline driver allow OP-TEE to access them.
Signed-off-by: Jorge Ramirez-Ortiz
Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
control this type of cryptographic devices it needs coordinated access
to the bus, so collisions and RUNTIME_PM dont get in the way.
This trampoline driver allow OP-TEE to access them.
Signed-off-by: Jorge Ramirez-Ortiz
On 08/06/20, Jens Wiklander wrote:
> On Mon, Jun 01, 2020 at 09:24:46AM +0200, Jorge Ramirez-Ortiz, Foundries
> wrote:
> > On 01/06/20, Sumit Garg wrote:
> > > Hi Jorge,
> >
> > hey
> >
> > >
> > > On Mon, 1 Jun 2020 at 04:41, Jorge
On 01/06/20, Jorge Ramirez-Ortiz wrote:
> Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> control this type of cryptographic devices it needs coordinated access
> to the bus, so collisions and RUNTIME_PM dont get in the way.
>
> This trampoline driv
On 01/06/20, Sumit Garg wrote:
> Hi Jorge,
hey
>
> On Mon, 1 Jun 2020 at 04:41, Jorge Ramirez-Ortiz wrote:
> >
> > Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
> > control this type of cryptographic devices it needs coordinated access
&g
Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
control this type of cryptographic devices it needs coordinated access
to the bus, so collisions and RUNTIME_PM dont get in the way.
This trampoline driver allow OP-TEE to access them.
Signed-off-by: Jorge Ramirez-Ortiz
Some secure elements like NXP's SE050 sit on I2C buses. For OP-TEE to
control this type of cryptographic devices it needs coordinated access
to the bus, so collisions and RUNTIME_PM dont get in the way.
This trampoline driver allow OP-TEE to access them.
Signed-off-by: Jorge Ramirez-Ortiz
Support the allocation/deallocation of buffers mapped to the DSP.
When the memory mapped to the DSP at process creation is not enough,
the fastrpc library can extend it at runtime. This avoids having to do
large preallocations by default.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Srinivas
With the integration of the mmap/unmap functionality, it is no longer
necessary to allow large memory allocations upfront since they can be
handled during runtime.
Tested on QCS404 with CDSP Neural Processing test suite.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Srinivas Kandagatla
Hi Greg
These patches implement a few fixes identified while working on the
QCS404 ML integration plus we now have support for mmap/unmap of
buffers (so the process can be created with less initial memory
requirements).
Jorge Ramirez-Ortiz (4):
misc: fastrpc: add mmap/unmap support
misc
necessary, this timeout will need to be revisited.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Srinivas Kandagatla
---
drivers/misc/fastrpc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index bc03500bfe60
Buffers owned by a context that has been interrupted either by a
signal or a timeout might still be being accessed by the DSP.
delegate returning the associated memory to a later time when the
device is released.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Srinivas Kandagatla
---
drivers
Support the allocation/deallocation of buffers mapped to the DSP.
When the memory mapped to the DSP at process creation is not enough,
the fastrpc library can extend it at runtime. This avoids having to do
large preallocations by default.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Srinivas
From: Srinivas Kandagatla
Fix a memory leak in miscdev->name by using devm_variant
Orignally reported by kmemleak:
[] kmemleak_alloc+0x50/0x84
[] __kmalloc_track_caller+0xe8/0x168
[] kvasprintf+0x78/0x100
[] kasprintf+0x50/0x74
[] fastrpc_rpmsg_probe+0xd8/0x20c
[]
Make the output of the high frequency pll a clock provider.
On the QCS404 this PLL controls cpu frequency scaling.
Co-developed-by: Niklas Cassel
Signed-off-by: Niklas Cassel
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Bjorn Andersson
Acked-by: Stephen Boyd
---
drivers/clk/qcom/hfpll.c
k critical and
forcing the clock to be always enabled, addresses the above scenario
making sure the clock is not disabled but it continues to rely on the
firmware to enable the clock.
Co-developed-by: Niklas Cassel
Signed-off-by: Niklas Cassel
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Bjorn
The following clock changes are required to enable cpufreq support on
the QCS404
v2: sboyd review of v1
---
missing cover letter
reorder the patchset
use clk_parent data to speficy the parent clock
dong ignore the clock position abi
Jorge Ramirez-Ortiz (5
Signed-off-by: Niklas Cassel
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Bjorn Andersson
---
drivers/clk/qcom/apcs-msm8916.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/qcom/apcs-msm8916.c b/drivers/clk/qcom/apcs-msm8916.c
index a6c89a310b18
Extend support to platorms using different parents.
Co-developed-by: Niklas Cassel
Signed-off-by: Niklas Cassel
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/clk/qcom/hfpll.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/hfpll.c b/drivers/clk/qcom
Limit the GPLL0_AO_OUT_MAIN operating frequency as per its hardware
specifications.
Co-developed-by: Niklas Cassel
Signed-off-by: Niklas Cassel
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Bjorn Andersson
Acked-by: Stephen Boyd
---
drivers/clk/qcom/clk-alpha-pll.c | 8
drivers
On 10/09/19 11:06:55, Guenter Roeck wrote:
> On Fri, Sep 06, 2019 at 10:54:10PM +0200, Jorge Ramirez-Ortiz wrote:
> > Use the bark interrupt as the pre-timeout notifier whenever this
> > interrupt is available.
> >
> > By default, the pretimeout notification sha
On 9/10/19 11:34, Jorge Ramirez wrote:
> On 9/10/19 11:14, Stephen Boyd wrote:
>> Quoting Jorge Ramirez-Ortiz, Linaro (2019-09-09 09:54:08)
>>> On 09/09/19 09:17:03, Stephen Boyd wrote:
>>>> But now the binding is different for the same compatible. I'd prefer w
On 9/10/19 11:14, Stephen Boyd wrote:
> Quoting Jorge Ramirez-Ortiz, Linaro (2019-09-09 09:54:08)
>> On 09/09/19 09:17:03, Stephen Boyd wrote:
>>> But now the binding is different for the same compatible. I'd prefer we
>>> keep using devm_clk_get() and use a devi
On 09/09/19 09:17:03, Stephen Boyd wrote:
> Quoting Jorge Ramirez-Ortiz, Linaro (2019-09-09 07:17:40)
> > On 09/09/19 03:21:16, Stephen Boyd wrote:
> > > Quoting Jorge Ramirez-Ortiz (2019-08-26 09:45:07)
> > > > @@ -76,10 +88,11 @@ static int qcom
On 09/09/19 03:21:16, Stephen Boyd wrote:
> Quoting Jorge Ramirez-Ortiz (2019-08-26 09:45:07)
> > @@ -76,10 +88,11 @@ static int qcom_apcs_msm8916_clk_probe(struct
> > platform_device *pdev)
> > a53cc->src_shift = 8;
> > a53cc->parent_map = gpll0_a
The mailbox length is 0x1000 hence the max_register value is 0xFFC.
Fixes: c6a8b171ca8e ("mailbox: qcom: Convert APCS IPC driver to use
regmap")
Signed-off-by: Jorge Ramirez-Ortiz
---
v2: added Fixes tag
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 2 +-
1 file changed, 1 inser
The max register is 0x23004 as per the manual (the current
max_register that this commit is fixing is actually out of bounds).
Fixes: 892df0191b29 ("clk: qcom: Add QCS404 TuringCC")
Signed-off-by: Jorge Ramirez-Ortiz
---
v2: add Fixes tag
drivers/clk/qcom/turingcc-qcs404.c | 2
The mailbox length is 0x1000 hence the max_register value is 0xFFC.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c
b/drivers/mailbox/qcom-apcs-ipc
The max register is 0x23004 as per the manual (the current
max_register that this commit is fixing is actually out of bounds).
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/clk/qcom/turingcc-qcs404.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/turingcc
Use the bark interrupt as the pre-timeout notifier whenever this
interrupt is available.
By default, the pretimeout notification shall occur one second earlier
than the timeout.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/watchdog/qcom-wdt.c | 70 ++---
1
there is no need to continue keeping the clock in private storage.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/watchdog/qcom-wdt.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c
index 935c78a882a3
remove unecessary variable from the driver's private storage
v2:
register the pre-timeout notifier.
With the second patch in the set, I took the oportunity to do some
cleanup in the same code base removing an unnecesary variable from the
driver's private storage.
Jorge Ramirez-Ortiz (2
As per Documentation/process/submit-checklist.rst, when using a
facility #include the file that defines/declares that facility.
Don't depend on other header files pulling in ones that you use.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/watchdog/pm8916_wdt.c | 1 +
1 file changed, 1
When an IRQ is present in the dts, the probe function shall fail if
the interrupt can not be registered.
The probe function shall also be retried if getting the irq is being
deferred.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/watchdog/pm8916_wdt.c | 16
1 file changed, 12
On 9/6/19 19:40, Bjorn Andersson wrote:
> On Thu 05 Sep 14:00 PDT 2019, Jorge Ramirez-Ortiz wrote:
>> diff --git a/drivers/watchdog/qcom-wdt.c b/drivers/watchdog/qcom-wdt.c
> [..]
>> +static inline int qcom_get_enable(struct watchdog_device *wdd)
>> +{
>> +
>>>
static const u32 reg_offset_data_apcs_tmr[] = {
[WDT_RST] = 0x38,
[WDT_EN] = 0x40,
@@ -54,15 +58,38 @@ struct qcom_wdt *to_qcom_wdt(struct watchdog_device
*wdd)
return container_of(wdd, struct qcom_wdt, wdd);
}
+static inline int
On 9/5/19 23:19, Guenter Roeck wrote:
> On Thu, Sep 05, 2019 at 11:00:35PM +0200, Jorge Ramirez-Ortiz wrote:
>> Use the bark interrupt as the pre-timeout notifier whenever this
>> interrupt is available.
>>
>> By default, the pretimeout notification shall occur
Use the bark interrupt as the pre-timeout notifier whenever this
interrupt is available.
By default, the pretimeout notification shall occur one second earlier
than the timeout.
Signed-off-by: Jorge Ramirez-Ortiz
---
v4:
address Guenter Roeck comments as follows:
remove unnecessary
On 9/5/19 20:34, Guenter Roeck wrote:
> On Thu, Sep 05, 2019 at 08:24:19PM +0200, Jorge Ramirez-Ortiz wrote:
>> Use the bark interrupt as the pre-timeout notifier whenever this
>> interrupt is available.
>>
>> By default, the pretimeout notification shall occur
Use the bark interrupt as the pre-timeout notifier whenever this
interrupt is available.
By default, the pretimeout notification shall occur one second earlier
than the timeout.
Signed-off-by: Jorge Ramirez-Ortiz
---
v3:
remove unnecesary variable added to private.
v2:
register
Use the bark interrupt as the pre-timeout notifier whenever this
interrupt is available.
By default, the pretimeout notification shall occur one second earlier
than the timeout.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/watchdog/qcom-wdt.c | 63 ++---
1
Use the bark interrupt as the pre-timeout notifier whenever this
interrupt is available.
By default, the pretimeout notification shall occur one second earlier
than the timeout.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/watchdog/qcom-wdt.c | 63 ++---
1
On 9/5/19 18:39, Bjorn Andersson wrote:
> On Thu 05 Sep 09:21 PDT 2019, Jorge Ramirez-Ortiz wrote:
>
>> Use the bark interrupt to notify the bark event. Since the bark and bite
>> timeouts are identical, increase the bite timeout by one second so
>> that the
Use the bark interrupt to notify the bark event. Since the bark and bite
timeouts are identical, increase the bite timeout by one second so
that the bark event can be logged to the console.
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/watchdog/qcom-wdt.c | 42
On 8/26/19 18:45, Jorge Ramirez-Ortiz wrote:
> Limit the GPLL0_AO_OUT_MAIN operating frequency as per its hardware
> specifications.
>
> Co-developed-by: Niklas Cassel
> Signed-off-by: Niklas Cassel
> Signed-off-by: Jorge Ramirez-Ortiz
> Reviewed-by: Bjorn Andersson
>
On 8/26/19 18:48, Jorge Ramirez-Ortiz wrote:
> When the APCS clock is registered (platform dependent), it retrieves
> its parent names from hardcoded values in the driver.
>
> The following commit allows the DT node to provide such clock names to
> the platform data based clock d
On 9/4/19 01:34, Bjorn Andersson wrote:
> On Tue 03 Sep 14:45 PDT 2019, Stephen Boyd wrote:
>
>> Quoting Jack Pham (2019-09-03 10:39:24)
>>> On Mon, Sep 02, 2019 at 08:23:04AM +0200, Jorge Ramirez wrote:
>>>> On 8/30/19 20:28, Stephen Boyd wrote:
>>>>&
On 8/30/19 20:28, Stephen Boyd wrote:
> Quoting Bjorn Andersson (2019-08-30 09:45:20)
>> On Fri 30 Aug 09:01 PDT 2019, Stephen Boyd wrote:
>>
>>> Quoting Jorge Ramirez (2019-08-29 00:03:48)
>>>> On 2/23/19 17:52, Bjorn Andersson wrote:
>>>>> On T
Allows QCS404 based designs to enable watchdog support
Signed-off-by: Jorge Ramirez-Ortiz
---
arch/arm64/boot/dts/qcom/qcs404.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index 131d8046d3be
This fixed rate clock is required for the operation of some devices
(ie watchdog).
Signed-off-by: Jorge Ramirez-Ortiz
---
arch/arm64/boot/dts/qcom/qcs404.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
On 8/29/19 00:31, Stephen Boyd wrote:
> Quoting Jorge Ramirez-Ortiz (2019-08-26 09:46:24)
>> There is clock controller functionality in the APCS hardware block of
>> qcs404 devices similar to msm8916.
>>
>> Co-developed-by: Niklas Cassel
>> Signed-off-by: Nikla
Use the correct macro when registering the platform device.
Co-developed-by: Niklas Cassel
Signed-off-by: Niklas Cassel
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Bjorn Andersson
---
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
There is clock controller functionality in the APCS hardware block of
qcs404 devices similar to msm8916.
Co-developed-by: Niklas Cassel
Signed-off-by: Niklas Cassel
Signed-off-by: Jorge Ramirez-Ortiz
---
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 8 ++--
1 file changed, 6 insertions(+), 2
These are the mailbox changes required to enable CPU frequency scaling on
Qualcomm's QCS404.
v2: sboyd review
replace if statement with a of_match_device
dont modify platform_set_drvdata
Jorge Ramirez-Ortiz (2):
mbox: qcom: add APCS child device for QCS404
mbox: qcom: replace integer
On 2/23/19 17:52, Bjorn Andersson wrote:
> On Thu 07 Feb 03:17 PST 2019, Jorge Ramirez-Ortiz wrote:
>
>> Binding description for Qualcomm's Synopsys 1.0.0 SuperSpeed phy
>> controller embedded in QCS404.
>>
>> Based on Sriharsha Allenki's original
>> def
On 8/28/19 10:48, Srinivas Kandagatla wrote:
>
>
> On 28/08/2019 08:50, Jorge Ramirez wrote:
>> On 8/27/19 23:45, Srinivas Kandagatla wrote:
>>> On 23/08/2019 16:23, Jorge Ramirez-Ortiz wrote:
>>>> can you add me as a co-author to this patch please?
>>
On 8/27/19 23:45, Srinivas Kandagatla wrote:
>
> On 23/08/2019 16:23, Jorge Ramirez-Ortiz wrote:
>> can you add me as a co-author to this patch please?
>
> No problem I can do that if you feel so!
yes please. thanks!
>
>> since I spent about a day doing th
On 8/26/19 08:54, Jorge Ramirez wrote:
> On 7/31/19 22:29, Jorge Ramirez-Ortiz wrote:
>> The following patchset enables CPU frequency scaling support on the
>> QCS404 (with dynamic voltage scaling).
>>
>> It is important to notice that this functionality will be
The high frequency pll functionality is required to enable CPU
frequency scaling operation.
Co-developed-by: Niklas Cassel
Signed-off-by: Niklas Cassel
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs404.dtsi | 9 +
1 file changed, 9
- the following commit will need to be
reverted to enable CPUFreq support
Author: Jorge Ramirez-Ortiz
Date: Thu Jul 25 12:41:36 2019 +0200
cpufreq: Add qcs404 to cpufreq-dt-platdev blacklist
Co-developed-by: Niklas Cassel
Signed-off-by: Niklas Cassel
Signed-off-by: Jorge Ramirez-Ortiz
The high frequency pll is required on compatible Qualcomm SoCs to
support the CPU frequency scaling feature.
Co-developed-by: Niklas Cassel
Signed-off-by: Niklas Cassel
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Bjorn Andersson
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1
in the clock driver source code.
Co-developed-by: Niklas Cassel
Signed-off-by: Niklas Cassel
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Rob Herring
Reviewed-by: Bjorn Andersson
---
.../mailbox/qcom,apcs-kpss-global.txt | 24 ---
1 file changed, 21 insertions(+), 3
Specify the clocks that feed the APCS mux/divider instead of using
default hardcoded values in the source code.
Co-developed-by: Niklas Cassel
Signed-off-by: Niklas Cassel
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/qcs404.dtsi | 3 +++
1 file
node.
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Bjorn Andersson
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 5ea9fb8f2f87..96dc7a12aa94
There is clock controller functionality in the APCS hardware block of
qcs404 devices similar to msm8916.
Co-developed-by: Niklas Cassel
Signed-off-by: Niklas Cassel
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Bjorn Andersson
---
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 8 +---
1
Use the correct macro when registering the platform device.
Co-developed-by: Niklas Cassel
Signed-off-by: Niklas Cassel
Signed-off-by: Jorge Ramirez-Ortiz
Reviewed-by: Bjorn Andersson
---
drivers/mailbox/qcom-apcs-ipc-mailbox.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
1 - 100 of 322 matches
Mail list logo
