On Thu, Mar 14, 2024 at 03:16:53PM +, Abdellatif El Khlifi wrote:
> Hi Sudeep,
>
> On Thu, Mar 14, 2024 at 02:59:20PM +0000, Sudeep Holla wrote:
> >
> > I think Robin has raised few points that need clarification. I think it was
> > done as part of DT binding pa
On Thu, Mar 14, 2024 at 01:49:28PM +, Abdellatif El Khlifi wrote:
> Hi Robin,
>
> > > + firmware-name:
> > > +description: |
> > > + Default name of the firmware to load to the remote processor.
> >
> > So... is loading the firmware image achieved by somehow bitbanging it
> >
On Thu, Mar 14, 2024 at 08:52:59AM -0600, Mathieu Poirier wrote:
> On Wed, Mar 13, 2024 at 05:17:56PM +, Abdellatif El Khlifi wrote:
> > Hi Mathieu,
> >
> > On Wed, Mar 13, 2024 at 10:25:32AM -0600, Mathieu Poirier wrote:
> > > On Tue, Mar 12, 2024 at 05:32:52PM +, Abdellatif El Khlifi
On Fri, Mar 01, 2024 at 08:30:43PM +0100, Krzysztof Kozlowski wrote:
> On 01/03/2024 17:42, abdellatif.elkhl...@arm.com wrote:
> > From: Abdellatif El Khlifi
> >
> > introduce the bindings for Arm remoteproc support.
> >
> > Signed-off-by: Abdellatif El Khlifi
> > ---
> >
On Fri, Mar 01, 2024 at 04:42:26PM +, abdellatif.elkhl...@arm.com wrote:
> From: Abdellatif El Khlifi
>
> add device tree node for the external system core in Corstone-1000
>
> Signed-off-by: Abdellatif El Khlifi
> ---
> arch/arm64/boot/dts/arm/corstone1000.dtsi | 10 +-
> 1 file
On Tue, Apr 20, 2021 at 04:12:26PM +0800, Kai-Heng Feng wrote:
> Hi Sudeep,
>
> On Tue, Apr 20, 2021 at 3:53 PM Sudeep Holla wrote:
> >
> > Gentle Ping! There is boot failure because of this issue with linux-next
> > on few arm platforms with non PCIe efifb. Pl
Gentle Ping! There is boot failure because of this issue with linux-next
on few arm platforms with non PCIe efifb. Please review and get the fix
merged ASAP so the testing on these platforms can continue with linux-next.
On Thu, Apr 15, 2021 at 11:22:24AM +0100, Sudeep Holla wrote:
> Com
Hi Stephen,
On Fri, Apr 16, 2021 at 09:03:41AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Fetching the scmi tree produces this error:
>
> fatal: couldn't find remote ref refs/heads/for-linux-next
>
Thanks for letting me know. No idea how, but I have messed up and managed
to push it as tag and
Cc: Thomas Zimmermann
Cc: Peter Jones
Signed-off-by: Sudeep Holla
---
drivers/video/fbdev/efifb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index f58a545b3bf3..8ea8f079cde2 100644
--- a/drivers/video/fbdev/e
]
https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/tang
Link: https://lore.kernel.org/r/20201116181356.804590-1-sudeep.ho...@arm.com
Cc: Rob Herring
Acked-by: Viresh Kumar
Signed-off-by: Sudeep Holla
---
Hi All,
Sorry for the delay, I thought I had sent
On Tue, 16 Mar 2021 12:48:25 +, Cristian Marussi wrote:
> The current SCMI implementation does not provide an interface to easily
> develop and include a custom vendor protocol implementation as prescribed
> by the SCMI standard, also because, there is not currently any custom
> protocol in
On Tue, Mar 30, 2021 at 08:26:43AM +0530, Viresh Kumar wrote:
> On 24-03-21, 10:07, Rob Herring wrote:
> > On Fri, Mar 12, 2021 at 07:40:35PM +0800, Hector Yuan wrote:
> > > From: "Hector.Yuan"
> > >
> > > Add devicetree bindings for MediaTek HW driver.
> > >
> > > Signed-off-by: Hector.Yuan
>
On Tue, Mar 23, 2021 at 11:44:50PM -0500, Samuel Holland wrote:
> 3) Modify the Linux PSCI client to respect PSCI_FEATURES when setting
>psci_ops.cpu_suspend. cpuidle-psci checks for this function before
>setting up idle states.
We don't call PSCI_FEATURES on mandatory functions as it may
her patches for vexpress platform or driver support.
Can you apply this directly ? Assuming that,
Acked-by: Sudeep Holla
--
Regards,
Sudeep
Hi Jonathan,
On Thu, Mar 18, 2021 at 12:12:02PM +, Sudeep Holla wrote:
> On Tue, Mar 16, 2021 at 10:38:43PM -0700, Jyoti Bhayana wrote:
> > Hi Christian,
> >
> > Thanks for the detailed explanation. Sounds good to me.
> >
>
> Can I get official Revi
Hi Stephen/Mike,
On Tue, Mar 16, 2021 at 12:48:43PM +, Cristian Marussi wrote:
> Port driver to the new SCMI Clock interface based on protocol handles
> and common devm_get_ops().
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
Please provide ack for this change so that I can take the series
On Fri, 5 Mar 2021 17:33:17 +, Robin Murphy wrote:
> The PLDA root complex on Juno relies on an address-based lookup table to
> generate AXI attributes for inbound PCI transactions, and as such will
> not pass any transaction not matching any programmed address range. The
> standard firmware
On Thu, 18 Feb 2021 22:23:23 +, Nicola Mazzucato wrote:
> In this V8 I have addressed your comments:
> - correct the goto in patch 1/3
> - improve comment in patch 2/3 for dev_pm_opp_get_opp_count()
>
> Many thanks,
> Nicola
>
> [...]
(New commit info after rebase to v5.12-rc2 for obvious
On Tue, Mar 16, 2021 at 10:38:43PM -0700, Jyoti Bhayana wrote:
> Hi Christian,
>
> Thanks for the detailed explanation. Sounds good to me.
>
Can I get official Reviewed-by or Acked-by please if you are fine with the
change ?
I definitely need one from Jonathan to merge this and one from Jyoti
On Mon, Mar 15, 2021 at 11:13:24AM -0700, Sowjanya Komatineni wrote:
> Hi Sudeep,
>
> I see you are one of the maintainer of PSCI driver. Please add any other
> right persons if you think should also agree/comment.
>
> Can you please comment on below 2 items based on your feedback?
>
> 1. Can you
On Fri, Mar 12, 2021 at 02:27:30PM -0800, Sowjanya Komatineni wrote:
> Hi Sudeep,
>
> To make our driver PSCI compliant below are few updates to be done
>
> 1. Standardize passing residency time run-time thru PSCI to ATF.
>
Yes that was my initial understanding, but your previous response was
+Lorenzo
Hi Sowjanya,
Sorry for the delayed response. I am still in vacation
On Thu, Mar 11, 2021 at 01:11:37PM -0800, Sowjanya Komatineni wrote:
>
> On 3/10/21 6:52 PM, Sudeep Holla wrote:
> > On Mon, Mar 08, 2021 at 10:32:17AM -0800, Sowjanya Komatineni wrote:
> > &
Hi Jonathan,
On Sun, Mar 14, 2021 at 03:40:33PM +, Jonathan Cameron wrote:
> On Sat, 13 Mar 2021 11:55:39 -0800
> Jyoti Bhayana wrote:
>
> > Hi Jonathan,
> >
> > I still see the old version 6 in ib-iio-scmi-5.12-rc2-take2 as well.
>
> OK. I'm completely confused as to what is going with my
Hi Cristian,
Sorry for the delay.
On Tue, Feb 02, 2021 at 10:15:55PM +, Cristian Marussi wrote:
> Having added the support for SCMI protocols as modules in order to let
> vendors extend the SCMI core with their own additions it seems odd to
> then force SCMI drivers built on top to use a
On Mon, Mar 08, 2021 at 10:32:17AM -0800, Sowjanya Komatineni wrote:
>
> On 3/7/21 8:37 PM, Sudeep Holla wrote:
> > On Wed, Mar 03, 2021 at 10:08:10PM -0800, Sowjanya Komatineni wrote:
> > > This patch adds cpu-idle-states and corresponding state nodes to
> > > Tegra
On Thu, 18 Feb 2021 22:23:23 +, Nicola Mazzucato wrote:
> In this V8 I have addressed your comments:
> - correct the goto in patch 1/3
> - improve comment in patch 2/3 for dev_pm_opp_get_opp_count()
>
> Many thanks,
> Nicola
>
> [...]
Applied the first 2 patches to sudeep.holla/linux
On Mon, Mar 08, 2021 at 07:48:41PM +, Jonathan Cameron wrote:
> On Mon, 8 Mar 2021 04:28:42 +
> Sudeep Holla wrote:
>
> > Hi Jonathan,
> >
> > On Tue, Feb 23, 2021 at 10:30:37AM -0800, Jyoti Bhayana wrote:
> > > Hi Jonathan,
> > >
>
On Tue, Feb 02, 2021 at 10:15:54PM +, Cristian Marussi wrote:
> Extend SCMI protocols accounting mechanism to address possible module
> usage and add the support to possibly define new protocols as loadable
> modules.
>
> Keep Standard protocols built into the SCMI core.
>
The changes look
On Tue, Feb 02, 2021 at 10:15:53PM +, Cristian Marussi wrote:
> Notification private data is currently accessible via handle->notify_priv;
> this data was indeed meant to be private to the notification core support
> and not to be accessible by SCMI drivers: make it private hiding it inside
>
On Tue, Feb 02, 2021 at 10:15:20PM +, Cristian Marussi wrote:
> Add basic protocol handles definitions and private data helpers support.
>
> A protocol handle identifies a protocol instance initialized against a
> specific handle; it embeds all the references to the core SCMI xfer methods
>
On Tue, Feb 02, 2021 at 10:15:19PM +, Cristian Marussi wrote:
> Extend common protocol registration routines and provide some new generic
> protocols get/put helpers that can track protocols usage and automatically
> perform the proper initialization and de-initialization on demand when
>
On Wed, Mar 03, 2021 at 10:08:10PM -0800, Sowjanya Komatineni wrote:
> This patch adds cpu-idle-states and corresponding state nodes to
> Tegra194 CPU in dt-binding document
>
I see that this platform has PSCI support. Can you care to explain why
you need additional DT bindings and driver for
Hi Jonathan,
On Tue, Feb 23, 2021 at 10:30:37AM -0800, Jyoti Bhayana wrote:
> Hi Jonathan,
>
> Thanks for the detailed and careful review of this patch. Good to hear
> that v7 is not required. Please find below answers to your
> questions. Looking forward to seeing this patch merged in the next
On Mon, Feb 22, 2021 at 10:09:04AM +0530, Viresh Kumar wrote:
> On 19-02-21, 19:16, Sudeep Holla wrote:
> > Hi Viresh,
> >
> > On Fri, Feb 19, 2021 at 09:49:44AM +0530, Viresh Kumar wrote:
> > > On 18-02-21, 22:23, Nicola Mazzucato wrote:
> > > > Hi
Hi Viresh,
On Fri, Feb 19, 2021 at 09:49:44AM +0530, Viresh Kumar wrote:
> On 18-02-21, 22:23, Nicola Mazzucato wrote:
> > Hi Viresh,
> >
> > In this V8 I have addressed your comments:
> > - correct the goto in patch 1/3
> > - improve comment in patch 2/3 for dev_pm_opp_get_opp_count()
>
>
On Mon, Feb 15, 2021 at 11:07:56AM +, Jonathan Cameron wrote:
> Hi Cristian,
>
> So this driver will also be 5.13 material now (merge window for IIO
> effectively
> closes 1-2 weeks before Linus opens the main one).
>
I guessed so.
> The way we normally handle cases like this where we
On Wed, Feb 03, 2021 at 12:10:35PM +, Cristian Marussi wrote:
> Hi Viresh
>
>
> On Wed, Feb 03, 2021 at 08:33:45AM +0530, Viresh Kumar wrote:
> > On 02-02-21, 22:15, Cristian Marussi wrote:
> > > Port driver to the new SCMI Perf interface based on protocol handles
> > > and common
On Tue, Jan 19, 2021 at 02:06:09PM +, Chen Jun wrote:
> since commit 5e89c55e4ed81d7abb1ce8828db35fa389dc0e90
> ("arm64: kernel: implement ACPI parking protocol")
>
> On arm64, IPI 6 will be wasted without setting
> CONFIG_ARM64_ACPI_PARKING_PROTOCOL.
>
> Signed-off-by: Chen Jun
> ---
>
On Tue, Jan 19, 2021 at 02:38:32AM +, Zulkifli, Muhammad Husaini wrote:
[...]
>
> I try to hook up the DT last night. Seems like the SCMI Protocol 17 is not
> implemented at ATF side.
I had guessed that.
> Double check with ATF Team, currently we don't have SCMI voltage domain
> control
On Mon, Jan 18, 2021 at 10:28:33AM +, Zulkifli, Muhammad Husaini wrote:
> Hi Sudeep and Mark,
>
> Thanks for the review. I replied inline.
>
> >-Original Message-----
> >From: Sudeep Holla
> >Sent: Saturday, January 16, 2021 2:58 AM
> >To: Mark Brow
On Thu, Jan 14, 2021 at 05:14:34PM +, Mark Brown wrote:
> On Thu, Jan 14, 2021 at 11:26:59PM +0800, Muhammad Husaini Zulkifli wrote:
>
> > Keem Bay SD regulator driver module is added to encapsulate ARM
> > Secure Monitor Call Calling Convention (SMCCC) during set voltage
> > operations to
On Thu, Jan 14, 2021 at 04:48:11PM +, Mark Brown wrote:
> On Thu, Jan 14, 2021 at 11:26:56PM +0800, Muhammad Husaini Zulkifli wrote:
> > Export inline function to encapsulate AON_CFG1 for controling the I/O Rail
> > supplied voltage levels which communicate with Trusted Firmware.
>
> Adding
On Tue, Jan 12, 2021 at 07:13:26PM +, Cristian Marussi wrote:
> Call scmi_notification_exit() only when SCMI platform driver instance has
> been really successfully removed.
>
Doesn't this deserve Fixes tag BTW ? Just send the tag if required, I can
fold it in.
--
Regards,
Sudeep
On Tue, 5 Jan 2021 15:19:45 +, Sudeep Holla wrote:
> Cristian is actively developing new features and more involved than me.
> So add Cristian as a designated reviewer. Also add the newly added scmi
> regulator driver to the list.
Applied to sudeep.holla/linux (for-next/scmi), than
On Tue, 22 Dec 2020 09:56:01 -0500, Jim Quinlan wrote:
> v4 -- s/message-serviced/a2p/ in the bindings commit message.
>-- Changed author/s-o-b/committer email address as my company is now
> appending boilerplate text to all outgoing emails.
>
> v3 -- Changed interrupt name from
On Tue, Jan 05, 2021 at 01:32:49PM -0500, Jim Quinlan wrote:
[...]
>
> I don't think that is the case; the bottom routine,
> do_wait_for_common(), decrements the x->done after a completion (which
> does an increment). Regardless, I think it is prudent to add the
> reinit patch you've provided
On Tue, Dec 22, 2020 at 07:37:22PM -0800, Florian Fainelli wrote:
>
>
> On 12/22/2020 6:56 AM, Jim Quinlan wrote:
> > The SMC/HVC SCMI transport is modified to allow the completion of an SCMI
> > message to be indicated by an interrupt rather than the return of the smc
> > call. This
Cristian is actively developing new features and more involved than me.
So add Cristian as a designated reviewer. Also add the newly added scmi
regulator driver to the list.
Cc: Cristian Marussi
Signed-off-by: Sudeep Holla
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Mon, Jan 04, 2021 at 09:57:31AM -0500, Jim Quinlan wrote:
> Hi Sudeep,
>
> Since RobH has reviewed patch 1/.2 and Florian has acked it, can you
> please accept patches 1 & 2?
>
Sure, will start queuing patches later this week, will let you know when
I apply. Thanks.
--
Regards,
Sudeep
probe functions implemented in each architecture
> (ARM and arm64), to determine the existence of this interface.
> For now this return false, but this will be overwritten by each
> architecture's support patch.
>
> Signed-off-by: Andre Przywara
> Reviewed-by: Linus Walleij
Review
; Add the definitions of the SMCCC functions as defined by the spec.
>
> Signed-off-by: Ard Biesheuvel
> Signed-off-by: Andre Przywara
> Reviewed-by: Linus Walleij
Reviewed-by: Sudeep Holla
--
Regards,
Sudeep
Desroches
Signed-off-by: Sudeep Holla
---
drivers/soc/atmel/soc.c | 12
1 file changed, 12 insertions(+)
v1->v2:
- Updated the allowed list as suggested by Alexandre
diff --git a/drivers/soc/atmel/soc.c b/drivers/soc/atmel/soc.c
index 55a1f57a4d8c..2dc86728b132 100644
On Fri, Dec 11, 2020 at 12:58:00PM +0100, Alexandre Belloni wrote:
> On 11/12/2020 11:50:55+0000, Sudeep Holla wrote:
> > On Fri, Dec 11, 2020 at 12:45:15PM +0100, Alexandre Belloni wrote:
> > > Hello,
> > >
> > > On 11/12/2020 10:31:43+, Sudeep Holl
On Fri, Dec 11, 2020 at 12:45:15PM +0100, Alexandre Belloni wrote:
> Hello,
>
> On 11/12/2020 10:31:43+0000, Sudeep Holla wrote:
> > Since at91_soc_init is called unconditionally from atmel_soc_device_init,
> > we get the following warning on all non AT91 SoCs:
> >
Desroches
Signed-off-by: Sudeep Holla
---
drivers/soc/atmel/soc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/soc/atmel/soc.c b/drivers/soc/atmel/soc.c
index c4472b68b7c2..ba9fc07cd91c 100644
--- a/drivers/soc/atmel/soc.c
+++ b/drivers/soc/atmel/soc.c
@@ -271,8 +271,19
On Thu, Dec 10, 2020 at 11:17:40AM +0530, Viresh Kumar wrote:
> The previous call to update_freq_counters_refs() has already updated the
> per-cpu variables, don't overwrite them with the same value again.
>
Good catch!
Reviewed-by: Sudeep Holla
--
Regards,
Sudeep
On Wed, Dec 09, 2020 at 11:15:02AM +0530, Viresh Kumar wrote:
> On 08-12-20, 11:20, Sudeep Holla wrote:
> > It is because of per-CPU vs per domain drama here. Imagine a system with
> > 4 CPUs which the firmware puts in individual domains while they all are
> > in the same perf
On Tue, Dec 08, 2020 at 11:34:36AM +, Lukasz Luba wrote:
>
>
> On 12/8/20 11:20 AM, Sudeep Holla wrote:
> > On Tue, Dec 08, 2020 at 12:56:11PM +0530, Viresh Kumar wrote:
> > > On 08-12-20, 07:22, Nicola Mazzucato wrote:
> > > > On 12/8/20 5:50 AM, Vires
On Tue, Dec 08, 2020 at 04:31:48PM +0530, Viresh Kumar wrote:
> On 08-12-20, 10:58, Nicola Mazzucato wrote:
> >
> >
> > On 12/8/20 7:26 AM, Viresh Kumar wrote:
> > > On 08-12-20, 07:22, Nicola Mazzucato wrote:
> > >> On 12/8/20 5:50 AM, Viresh Kumar wrote:
> > >>> On 02-12-20, 17:23, Nicola
On Tue, Dec 08, 2020 at 12:56:11PM +0530, Viresh Kumar wrote:
> On 08-12-20, 07:22, Nicola Mazzucato wrote:
> > On 12/8/20 5:50 AM, Viresh Kumar wrote:
> > > On 02-12-20, 17:23, Nicola Mazzucato wrote:
> > >> nr_opp = dev_pm_opp_get_opp_count(cpu_dev);
> > >> if (nr_opp <= 0) {
>
On Fri, Dec 04, 2020 at 12:17:46AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Wtihout CONFIG_COMMON_CLK, the scmi driver fails to link:
>
> arm-linux-gnueabi-ld: drivers/cpufreq/scmi-cpufreq.o: in function
> `scmi_cpufreq_probe':
> scmi-cpufreq.c:(.text+0x20c): undefined reference to
On Tue, Dec 01, 2020 at 04:03:46PM +, Valentin Schneider wrote:
>
> On 01/12/20 02:59, Barry Song wrote:
> > Currently the ID provided is the offset of the Processor
> > Hierarchy Nodes Structure within PPTT. Whilst this is unique
> > it is not terribly elegant so alternative suggestions
: 7002ca237b21 ("mailbox: arm_mhu: Add ARM MHU doorbell driver")
Reported-by: Cristian Marussi
Signed-off-by: Sudeep Holla
---
drivers/mailbox/arm_mhu_db.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mailbox/arm_mhu_db.c b/drivers/mailbox/arm_mhu_db.c
index 27
On Thu, Nov 26, 2020 at 03:54:17PM +, David Brazdil wrote:
> Add a handler of the CPU_ON PSCI call from host. When invoked, it looks
> up the logical CPU ID corresponding to the provided MPIDR and populates
> the state struct of the target CPU with the provided x0, pc. It then
> calls CPU_ON
On Thu, Nov 26, 2020 at 03:54:14PM +, David Brazdil wrote:
> Forward the following PSCI SMCs issued by host to EL3 as they do not
> require the hypervisor's intervention. This assumes that EL3 correctly
> implements the PSCI specification.
>
> Only function IDs implemented in Linux are
On Thu, Nov 26, 2020 at 03:54:04PM +, David Brazdil wrote:
> Add an early parameter that allows users to opt into protected KVM mode
> when using the nVHE hypervisor. In this mode, guest state will be kept
> private from the host. This will primarily involve enabling stage-2
> address
VLINK from several drivers and rely on the functions
being there.
Replicate the same for FSL_DPAA2_ETH.
Cc: Ioana Ciornei
Cc: Ioana Radulescu
Cc: David S. Miller
Cc: Jakub Kicinski
Signed-off-by: Sudeep Holla
---
drivers/net/ethernet/freescale/dpaa2/Kconfig | 1 +
1 file changed, 1 insertio
le: milli-Watts or abstract scale.
>
Looks good to me. I saw this after I sent pull request this afternoon.
In case you want to take it via PM tree:
Acked-by: Sudeep Holla
--
Regards,
Sudeep
On Mon, 23 Nov 2020 16:20:08 +, Cristian Marussi wrote:
> For sake of consistency, remove any residual naming based on _le suffixes
> in SCMI Sensors Protocol, since little endianity is already assumed across
> all of SCMI implementation and, as such, all currently existent names do
> not
On Thu, 19 Nov 2020 17:49:00 +, Cristian Marussi wrote:
> this series is meant to add support for the new SCMI Sensor Protocol
> features defined by the upcoming SCMIv3.0 specification, whose BETA
> release is available at [1].
>
> The series is currently based on for-next/scmi [2] on top of:
Hi Mark,
As discussed here is the pull request for SCMI firmware part for regulator
support. Please pull !
Regards,
Sudeep
-->8
The following changes since commit 3cea11cd5e3b00d91caf0b4730194039b45c5891:
Linux 5.10-rc2 (2020-11-01 14:43:51 -0800)
are available in the Git repository at:
On Thu, 19 Nov 2020 19:10:46 +, Cristian Marussi wrote:
> this series introduces the support for the new SCMI Voltage Domain Protocol
> defined by the upcoming SCMIv3.0 specification, whose BETA release is
> available at [1].
>
> Afterwards, a new generic SCMI Regulator driver is developed on
On Sat, Nov 21, 2020 at 08:59:03AM -0800, Guenter Roeck wrote:
> On Thu, Nov 19, 2020 at 05:49:03PM +, Cristian Marussi wrote:
> > Use an int to calculate scale values inside scmi_hwmon_scale() to match
> > the updated scale data type in struct scmi_sensor_info.
> >
> > Cc:
On Fri, Nov 20, 2020 at 08:27:38AM -0500, Jim Quinlan wrote:
> On Fri, Nov 20, 2020 at 6:14 AM Sudeep Holla wrote:
> >
> > On Thu, Nov 19, 2020 at 01:34:18PM -0500, Jim Quinlan wrote:
> > > On Fri, Nov 13, 2020 at 10:12 AM Jim Quinlan
> > > wrote:
> > >
On Thu, Nov 19, 2020 at 01:34:18PM -0500, Jim Quinlan wrote:
> On Fri, Nov 13, 2020 at 10:12 AM Jim Quinlan
> wrote:
> >
> > On Fri, Nov 13, 2020 at 9:36 AM Sudeep Holla wrote:
> > >
> > > On Fri, Nov 13, 2020 at 09:26:43AM -0500, Jim Quinlan wrote:
> &
On Fri, Nov 20, 2020 at 08:56:31AM +, Marc Zyngier wrote:
> On 2020-11-20 04:30, Neeraj Upadhyay wrote:
> > Hi,
> >
> > For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
> > AA64PFR0[47:44] field is not set, and AMU does not get enabled for
> > them.
> > Can you please provide
Hi Guenter,
On Thu, Nov 19, 2020 at 05:49:03PM +, Cristian Marussi wrote:
> Use an int to calculate scale values inside scmi_hwmon_scale() to match
> the updated scale data type in struct scmi_sensor_info.
>
You were not cc-ed in previous versions unfortunately. I plan to take this
along
On Thu, Nov 19, 2020 at 04:39:49PM +, Mark Brown wrote:
> On Thu, Nov 19, 2020 at 04:13:08PM +0000, Sudeep Holla wrote:
>
> > I was thinking about how to merge this if and when you have reviewed it
> > and happy with it. Is it OK to take via ARM SoC with dependent and othe
On Thu, Nov 19, 2020 at 03:23:20PM +, Lukasz Luba wrote:
>
>
> On 10/28/20 3:08 PM, Rob Herring wrote:
> > On Mon, Oct 26, 2020 at 04:19:08PM +0800, Hector Yuan wrote:
> > > From: "Hector.Yuan"
> > >
> > > Add devicetree documentation for 'mediatek,freq-domain' property specific
> > > to
Hi Mark,
On Tue, Nov 17, 2020 at 12:34:14PM +, Cristian Marussi wrote:
> Add a simple regulator based on SCMI Voltage Domain Protocol.
>
I was thinking about how to merge this if and when you have reviewed it
and happy with it. Is it OK to take via ARM SoC with dependent and other
SCMI
On Tue, Nov 17, 2020 at 12:34:11PM +, Cristian Marussi wrote:
> Add SCMI Voltage Domain protocol support.
>
> Signed-off-by: Cristian Marussi
> ---
> v4 --> v5
> - removed inline
> - moved segmented intervals defines
> - fixed some macros complaints by checkpatch
>
> v3 --> v4
> - avoid
On Tue, Nov 17, 2020 at 12:34:15PM +, Cristian Marussi wrote:
> Add devicetree bindings to support regulators based on SCMI Voltage
> Domain Protocol.
>
Ideally, the DT binding should be first one, rather before the binding
is used in the code. I can move the order while applying.
--
On Wed, Nov 18, 2020 at 03:20:09PM -0600, Rob Herring wrote:
> On Mon, Nov 16, 2020 at 06:13:56PM +0000, Sudeep Holla wrote:
> > The CLKSCREW attack [0] exposed security vulnerabilities in energy
> > management
> > implementations where untrusted software had d
On Thu, Nov 19, 2020 at 12:20:29PM +, Cristian Marussi wrote:
> Hi Sudeep
>
[...]
> > > + S32_EXT(SENSOR_RES_EXP(ares));
> > > + dsize += sizeof(adesc->resolution);
> > > +
> > > + scmi_parse_range_attrs(>attrs,
On Thu, Nov 19, 2020 at 12:22:49PM +, Cristian Marussi wrote:
> On Thu, Nov 19, 2020 at 11:40:29AM +0000, Sudeep Holla wrote:
> > On Wed, Nov 18, 2020 at 04:29:02PM +, Cristian Marussi wrote:
> > > Use an int to calculate scale values inside scmi_hwmon_scale() to match
On Wed, Nov 18, 2020 at 04:29:05PM +, Cristian Marussi wrote:
> Add support for new SCMIv3.0 SENSOR_UPDATE notification.
>
> Signed-off-by: Cristian Marussi
> ---
> v2 --> v3
> - removed stale unused msg payload definition
> - moved variable declaration inside switch block
Other than few
On Wed, Nov 18, 2020 at 04:29:04PM +, Cristian Marussi wrote:
> Add SCMIv3.0 Sensor support for CONFIG_GET/CONFIG_SET commands.
>
> Signed-off-by: Cristian Marussi
> ---
> drivers/firmware/arm_scmi/sensors.c | 75 +
> include/linux/scmi_protocol.h | 37
On Wed, Nov 18, 2020 at 04:29:03PM +, Cristian Marussi wrote:
> Add new .reading_get_timestamped() method to sensor_ops to support SCMIv3.0
> timestamped reads.
>
> Signed-off-by: Cristian Marussi
> ---
> V2 --> v3
> - setting rx_size to 0 in sensor_reading_get to allow fw to send
> both
On Wed, Nov 18, 2020 at 04:29:02PM +, Cristian Marussi wrote:
> Use an int to calculate scale values inside scmi_hwmon_scale() to match
> the updated scale data type in struct scmi_sensor_info.
>
> Signed-off-by: Cristian Marussi
> ---
> drivers/hwmon/scmi-hwmon.c | 2 +-
> 1 file changed,
On Wed, Nov 18, 2020 at 04:29:01PM +, Cristian Marussi wrote:
> Add support for new SCMIv3.0 Sensors extensions related to new sensors'
> features, like multiple axis and update intervals, while keeping
> compatibility with SCMIv2.0 features.
> While at that, refactor and simplify all the
]
https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/tang
Cc: Rob Herring
Signed-off-by: Sudeep Holla
---
.../bindings/dvfs/performance-domain.yaml | 76 +++
1 file changed, 76 insertions(+)
create mode 100644
Documentation/devicetree
On Mon, Nov 09, 2020 at 02:15:18PM -0600, Rob Herring wrote:
> On Thu, Nov 05, 2020 at 05:35:39PM +0000, Sudeep Holla wrote:
> > The CLKSCREW attack [0] exposed security vulnerabilities in energy
> > management
> > implementations where untrusted software had d
On Fri, Nov 13, 2020 at 09:26:43AM -0500, Jim Quinlan wrote:
> Hi, these are fast calls. Regards, Jim
>
>
> On Fri, Nov 13, 2020 at 4:47 AM Sudeep Holla wrote:
> >
> > On Thu, Nov 12, 2020 at 12:56:27PM -0500, Jim Quinlan wrote:
> > > The SMC/HVC SC
On Tue, 10 Nov 2020 15:42:21 +0800, Qinglang Miao wrote:
> destroy_workqueue seems necessary before return from
> scmi_notification_init in the error handling case when
> fails to do devm_kcalloc(). Fix this by simply moving
> devm_kcalloc to the front.
Applied to sudeep.holla/linux
return false;
> @@ -323,3 +326,64 @@ void topology_scale_freq_tick(void)
> this_cpu_write(arch_core_cycles_prev, core_cnt);
> this_cpu_write(arch_const_cycles_prev, const_cnt);
> }
> +
> +#ifdef CONFIG_ACPI_CPPC_LIB
> +#include
Not sure what arm64 maintainers prefer, but this code has nothing to do
with topolopy strictly speaking. I wonder if we can put it in separate
file conditionally compiled if CONFIG_ACPI_CPPC_LIB is enabled there
by eliminating #ifdef(main reason for raising this point).
Either way:
Reviewed-by: Sudeep Holla
--
Regards,
Sudeep
u64 max_rate, u64 ref_rate) -
>generic function that sets the normalization ratio used by
>topology_scale_freq_tick()
>
Reviewed-by: Sudeep Holla
--
Regards,
Sudeep
sult, implement update_freq_counters_refs() to replace
> init_cpu_freq_invariance_counters() and both initialise and update
> the per-cpu reference variables.
>
Reviewed-by: Sudeep Holla
--
Regards,
Sudeep
On Thu, Nov 12, 2020 at 12:56:27PM -0500, Jim Quinlan wrote:
> The SMC/HVC SCMI transport is modified to allow the completion of an SCMI
> message to be indicated by an interrupt rather than the return of the smc
> call. This accommodates the existing behavior of the BrcmSTB SCMI
> "platform"
On Mon, Oct 26, 2020 at 08:55:31PM +, Cristian Marussi wrote:
> Add an SCMI System Power control driver to handle platform's requests
> carried by SYSTEM_POWER_STATE_NOTIFIER notifications: such platform
> requested system power state transitions are handled accordingly,
> gracefully or
On Wed, Nov 11, 2020 at 05:45:46PM +, Cristian Marussi wrote:
> On Wed, Nov 11, 2020 at 11:45:24AM -0500, Jim Quinlan wrote:
> > On Wed, Nov 11, 2020 at 5:42 AM Sudeep Holla wrote:
> > >
> > > On Tue, Nov 10, 2020 at 01:38:19PM -0500, Jim Quinlan wrote:
> &g
1 - 100 of 4418 matches
Mail list logo
