>> Ankit Agrawal (3):
>> vfio/pci: rename and export do_io_rw()
>> vfio/pci: rename and export range_intersect_range
>> vfio/nvgrace-gpu: Add vfio pci variant module for grace hopper
>>
>> MAINTAINERS | 16 +-
>> d
>> diff --git a/drivers/vfio/pci/nvgrace-gpu/main.c
>> b/drivers/vfio/pci/nvgrace-gpu/main.c new file mode 100644
>> index ..5a251a6a782e
>> --- /dev/null
>> +++ b/drivers/vfio/pci/nvgrace-gpu/main.c
>> @@ -0,0 +1,888 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyrig
>> +
>> +/**
>> + * vfio_pci_core_range_intersect_range() - Determine overlap between a
>> buffer
>> + * and register offset ranges.
>> + * @buf_start: start offset of the buffer
>> + * @buf_cnt: number of buffer bytes.
>
> You could drop
t and make
>> + * use of the value for its calculation to determine USEMEM size.
>> + */
>> + nvdev->usemem.memlength = round_down(nvdev->usemem.memlength,
>> + MEMBLK_SIZE);
>> + if ((check_add_overflo
>> >
>> > IMO, this seems like adding too much code to reduce the call length for a
>> > very specific case. If there aren't any strong opinion on this, I'm
>> > planning to
>> > leave this code as it is.
>>
>> a slight difference. if mem_count==0 the result should always succeed
>> no matter nvgr
Thanks Kevin for the review. Comments inline.
>>
>> Note that the usemem memory is added by the VM Nvidia device driver [5]
>> to the VM kernel as memblocks. Hence make the usable memory size
>> memblock
>> aligned.
>
> Is memblock size defined in spec or purely a guest implementation choice?
The
>> >>
>> >> If mem_count == 0, going through nvgrace_gpu_map_and_read() is not
>> >> necessary.
>> >
>> > Harmless, other than the possibly unnecessary call through to
>> > nvgrace_gpu_map_device_mem(). Maybe both
>> nvgrace_gpu_map_and_read()
>> > and nvgrace_gpu_map_and_write() could conditional
>> > +/* Memory size expected as non cached and reserved by the VM driver
>> > */ +#define RESMEM_SIZE 0x4000
>> > +#define MEMBLK_SIZE 0x2000
>> > +
>>
>> Maybe use SZ_* definitions in linux/size.h
>
> Good suggestion.
Ack.
>>
>> Better move this part to the place between vfio_pci_core_e
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 8999497011a2..529ec8966f58 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -23103,6 +23103,12 @@ L: k...@vger.kernel.org
>> S: Maintained
>> F: drivers/vfio/platform/
>>
>> +VFIO
Thanks Kevin.
>> range_intesect_range determines an overlap between two ranges. If an
>
> s/intesect/intersect/
Will fix the typo.
>> + * vfio_pci_core_range_intersect_range() - Determine overlap between a
>> buffer
>> + * and register offset ranges.
>> + * @
Borislav Petkov writes:
> On Mon, Dec 14, 2020 at 10:27:09PM +0900, Punit Agrawal wrote:
>> IIUC, this suggests that Linux booting on anything prior to Zen3 is down
>> to pure luck - I hope that wasn't the case.
>
> WTF does this have to do with linux booting?!
I
Borislav Petkov writes:
> On Sat, Dec 12, 2020 at 08:36:48AM +0900, Punit Agrawal wrote:
>> To me it suggests, that there are likely more systems from the family
>> that show the characteristic described below.
>
> Until we find a *single* system with a broken BIOS whic
Borislav Petkov writes:
> On Wed, Dec 09, 2020 at 08:21:48AM +0900, Punit Agrawal wrote:
>> According to the commit log, acd316248205 seems to be only targeted at
>> powernow-K8 -
>
> No, it is not targeted at powernow-k8 - acpi-cpufreq.c is what is used
> on AMD h
Borislav Petkov writes:
> On Fri, Dec 11, 2020 at 07:56:40AM +0900, Punit Agrawal wrote:
>> Booting Linux on a Zen2 based processor (family: 0x17, model: 0x60,
>> stepping: 0x1) shows the following message in the logs -
>>
>> acpi_cpufreq: overriding BIOS provide
verride is not required for Zen3
onwards, it seems that domain information can be trusted even on
certain earlier systems. Update the check, to skip the override for
Zen2 processors known to work without the override.
Signed-off-by: Punit Agrawal
Cc: Wei Huang
---
drivers/cpufreq/acpi-cpu
eturn value of the function to bool
Punit Agrawal (2):
cpufreq: acpi-cpufreq: Re-factor overriding ACPI PSD
cpufreq: acpi-cpufreq: Add processor to the ignore PSD override list
drivers/cpufreq/acpi-cpufreq.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
--
2.29.2
Re-factor the code to override the firmware provided frequency domain
information (via PSD) to localise the checks in one function.
No functional change intended.
Signed-off-by: Punit Agrawal
Cc: Wei Huang
---
drivers/cpufreq/acpi-cpufreq.c | 17 +++--
1 file changed, 15
interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ,
> + ;
> +};
> + };
> +...
FWIW,
Reviewed-by: Punit Agrawal
Thanks,
Punit
Rob Herring writes:
[...]
>> > + gpio-ranges: true
>>
>> I am not sure I have a good handle on the yaml schema definitions but
>> "gpio-ranges" feels like it should be a list of ranges not a boolean.
>>
>> Something like -
>>
>> gpio-ranges:
>> maxItems: 1
>>
>> feels more appropr
Hi Wei,
Wei Huang writes:
> On 11/25/20 8:48 AM, Punit Agrawal wrote:
>> Re-factor the code to override the firmware provided frequency domain
>> information (via PSD) to localise the checks in one function.
>>
>> No functional change intended.
>>
>> S
Hi Rafael,
"Rafael J. Wysocki" writes:
> On Fri, Dec 4, 2020 at 11:45 PM Punit Agrawal wrote:
>>
>> Hi Rafael,
>>
>> Punit Agrawal writes:
>>
>> > Hi,
>> >
>> > While looking into Giovanni's patches to enable freque
Borislav Petkov writes:
> On Mon, Dec 07, 2020 at 04:07:52PM -0600, Wei Huang wrote:
>> I think we shouldn't override zen2 if _PSD is correct. In my opinion,
>> there are two approaches:
>>
>> * Keep override_acpi_psd()
>> Let us keep the original quirk and override_acpi_psd() function. Over
>>
Hi Rafael,
Punit Agrawal writes:
> Hi,
>
> While looking into Giovanni's patches to enable frequency invariance
> on AMD systems[0], I noticed an issue with initialising frequency
> domain information on a recent AMD APU.
>
> Patch 1 refactors the test to ignore f
> #address-cells = <2>;
> #size-cells = <2>;
> @@ -384,6 +390,12 @@ spi6: spi@28146000 {
> #size-cells = <0>;
> status = "disabled";
> };
> +
> + wdt:
,
> + ,
> + ,
> + ,
> + ,
> + ;
> + };
> +
> uart0: serial@2820 {
> compatible = "arm,pl011", "arm,primecell";
> reg = <0 0x2820 0 0x1000>;
FWIW,
Reviewed-by: Punit Agrawal
Thanks,
Punit
*irq_chip;
> + struct irq_desc *desc;
> + struct gpio_irq_chip *girq;
> + const char *name = dev_name(dev);
> + int i, ret, num_irq;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
>
Iwamatsu-san,
Nobuhiro Iwamatsu writes:
> Add bindings for the Toshiba Visconti GPIO Controller.
>
> Signed-off-by: Nobuhiro Iwamatsu
> ---
> .../bindings/gpio/toshiba,gpio-visconti.yaml | 85 +++
> 1 file changed, 85 insertions(+)
> create mode 100644
> Documentation/device
Borislav Petkov writes:
> On Wed, Nov 25, 2020 at 11:48:47PM +0900, Punit Agrawal wrote:
>> Replace the raw values for AMD processor family with recently
>> introduced identifier macros to improve code readability and
>> maintainability.
>>
>> Signed-off-by:
Hi Boris,
Borislav Petkov writes:
> On Wed, Nov 25, 2020 at 11:48:46PM +0900, Punit Agrawal wrote:
>> So far, the AMD processor identifier (family, models, stepping) are
>> referred to by raw values making it easy to make mistakes. It is also
>> harder to read and maintain
the processor identifiers.
As a first step towards improving the status quo, add macros for the
AMD processor families and propagate them through the existing
cpu_device_id.h header used for this purpose.
Signed-off-by: Punit Agrawal
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: x
verride is not required for Zen3
onwards, it seems that domain information can be trusted even on
certain earlier systems. Update the check, to skip the override for
Zen2 processors known to work without the override.
Signed-off-by: Punit Agrawal
Cc: Wei Huang
---
drivers/cpufreq/acpi-cpu
Replace the raw values for AMD processor family with recently
introduced identifier macros to improve code readability and
maintainability.
Signed-off-by: Punit Agrawal
---
drivers/cpufreq/acpi-cpufreq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq
4 are somewhat independent and a first step towards
improving the situation with regards to the use of raw identifiers for
AMD processors throughout the kernel.
All feedback welcome.
Thanks,
Punit
[0]
https://lore.kernel.org/linux-acpi/20201112182614.10700-1-ggherdov...@suse.cz/
Punit Agrawal
Re-factor the code to override the firmware provided frequency domain
information (via PSD) to localise the checks in one function.
No functional change intended.
Signed-off-by: Punit Agrawal
Cc: Wei Huang
---
drivers/cpufreq/acpi-cpufreq.c | 17 +++--
1 file changed, 15
performance domains and again when matching cpus
belonging to the same domain.
Drop the unnecessary initialisation.
Signed-off-by: Punit Agrawal
---
drivers/acpi/processor_perflib.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/proce
Smita Koralahalli Channabasappa writes:
> Punit,
>
> On 11/9/20 1:05 PM, Smita Koralahalli Channabasappa wrote:
>
>> On 11/8/20 7:18 PM, Punit Agrawal wrote:
>>> Borislav Petkov writes:
>>>> On Fri, Nov 06, 2020 at 02:36:46PM +0900, Punit Agrawal wrote:
&
Borislav Petkov writes:
> On Fri, Nov 06, 2020 at 02:36:46PM +0900, Punit Agrawal wrote:
>> > diff --git a/drivers/firmware/efi/cper-x86.c
>> > b/drivers/firmware/efi/cper-x86.c
>> > index 2531de49f56c..438ed9eff6d0 100644
>> > --- a/drivers/firmware/efi
print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16,
> +groupsize, (ctx_info + 1),
> + ctx_info->reg_arr_size, 0);
> + }
>
> ctx_info = (struct cper_ia_proc_ctx *)((long)ctx_info + size);
> }
With that addressed,
FWIW,
Reviewed-by: Punit Agrawal
Thanks,
Punit
Yazen Ghannam writes:
> On Fri, Sep 25, 2020 at 09:54:06AM +0900, Punit Agrawal wrote:
>> Borislav Petkov writes:
>>
>> > On Thu, Sep 24, 2020 at 12:23:27PM -0500, Smita Koralahalli Channabasappa
>> > wrote:
>> >> > Even though it&#
Borislav Petkov writes:
> On Thu, Sep 24, 2020 at 12:23:27PM -0500, Smita Koralahalli Channabasappa
> wrote:
>> > Even though it's not defined in the UEFI spec, it doesn't mean a
>> > structure definition cannot be created.
>
> Created for what? That structure better have a big fat comment above
Sep 2020 14:49:12
> +
> ^^
>
> On Wed, Sep 23, 2020 at 07:07:17PM +0900, Punit Agrawal wrote:
>> I know Boris asked you to add the reason for the Reported-by, but
>> usually we don't track version differences in the committed patch.
>>
Hi Smita,
A few comments below.
Smita Koralahalli writes:
> Linux Kernel uses ACPI Boot Error Record Table (BERT) to report fatal
> errors that occurred in a previous boot. The MCA errors in the BERT are
> reported using the x86 Processor Error Common Platform Error Record (CPER)
> format. Curr
Ben Levinsky writes:
> Hi All,
>
>> -Original Message-
>> From: Wendy Liang
>> Sent: Friday, September 18, 2020 6:53 PM
>> To: Michael Auchter
>> Cc: Ben Levinsky ; punit1.agra...@toshiba.co.jp;
>> devicet...@vger.kernel.org; linux-remotep...@vger.kernel.org; linux-
>> ker...@vger.kerne
Hi Ben,
One query below -
Ben Levinsky writes:
> Add binding for ZynqMP R5 OpenAMP.
>
> Represent the RPU domain resources in one device node. Each RPU
> processor is a subnode of the top RPU domain node.
>
> Signed-off-by: Jason Wu
> Signed-off-by: Wendy Liang
> Signed-off-by: Michal Simek
Hi Amit,
Amit Sunil Dhamne writes:
> From: Tejas Patel
>
> Validate IOCTL ID for ZynqMP and Versal before calling
> zynqmp_pm_invoke_fn().
>
> Signed-off-by: Tejas Patel
> Signed-off-by: Amit Sunil Dhamne
> ---
> drivers/firmware/xilinx/zynqmp.c | 117
> +++--
Hi Ben,
Thanks for fixing the commit ordering issue. Some additional comments
below.
Ben Levinsky writes:
> R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> remotproc driver, we can boot the R5 sub-system in different 2
> configurations: split or lock-step.
Suggest following
When adding parent clk(mclk) to wclk, this adds fallback option
for the case where global clk name is used.
Signed-off-by: Akshu Agrawal
---
sound/soc/codecs/rt5682.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/rt5682.c b/sound/soc/codecs/rt5682.c
index 93ebf0279b62
Hi Ben,
Thanks for addressing the comments on the previous version. One comment
below.
Ben Levinsky writes:
> This patch adds APIs to access to configure RPU and its
> processor-specific memory.
>
> That is query the run-time mode of RPU as either split or lockstep as well
> as API to set this
Ben Levinsky writes:
> R5 is included in Xilinx Zynq UltraScale MPSoC so by adding this
> remotproc driver, we can boot the R5 sub-system in different 2
> configurations: split or lock-step.
>
> The Xilinx R5 Remoteproc Driver boots the R5's via calls to the Xilinx
> Platform Management Unit that
Hi Ben,
Noticed some issues while going through the code. A couple of queries
below.
Ben Levinsky writes:
> This patch adds APIs to access to configure RPU and its
> processor-specific memory.
>
> That is query the run-time mode of RPU as either split or lockstep as well
> as API to set this mo
Hi Smita,
Smita Koralahalli Channabasappa writes:
> On 8/31/20 12:05 AM, Punit Agrawal wrote:
>
>> Hi Smita,
>>
>> A couple of comments below -
>>
>> Smita Koralahalli writes:
>>
>> [...]
>>
>>
>>> diff --git a/drivers/fir
Hi Smita,
A couple of comments below -
Smita Koralahalli writes:
> Linux Kernel uses ACPI Boot Error Record Table (BERT) to report fatal
> errors that occurred in a previous boot. The MCA errors in the BERT are
> reported using the x86 Processor Error Common Platform Error Record (CPER)
> forma
While the driver waits for DAIs to be probed and retries probing,
have the error messages at debug level instead of error.
Signed-off-by: Akshu Agrawal
---
v2: Add a debug level message for -EPROBE_DEFER
sound/soc/amd/acp3x-rt5682-max9836.c | 11 ---
1 file changed, 8 insertions(+), 3
On 8/26/2020 4:54 PM, Mark Brown wrote:
On Wed, Aug 26, 2020 at 04:48:05PM +0530, Akshu Agrawal wrote:
While the driver waits for DAIs to be probed and retries probing,
avoid printing error messages.
This means that if there is a problem with deferred probe no diagnostics
will be available
While the driver waits for DAIs to be probed and retries probing,
avoid printing error messages.
Signed-off-by: Akshu Agrawal
---
sound/soc/amd/acp3x-rt5682-max9836.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/sound/soc/amd/acp3x-rt5682-max9836.c
b/sound/soc/amd
Since there is slight difference in AMD RV based soc in misc
clk architecture. The fmw property will help in differentiating
the SoCs.
Signed-off-by: Akshu Agrawal
---
drivers/acpi/acpi_apd.c | 4
include/linux/platform_data/clk-fch.h | 1 +
2 files changed, 5 insertions
There is minor difference between previous family of SoC and
the current one. Which is the there is only 48Mh fixed clk.
There is no mux and no option to select another freq as there in previous.
Signed-off-by: Akshu Agrawal
Reviewed-by: Stephen Boyd
---
v2: Consolidated the loops in remove.
v3
AMD SoC general pupose clk is present in new platforms with
minor differences. We can reuse the same clk driver for other
platforms. Hence, changing name from ST(SoC) to FCH(IP)
Signed-off-by: Akshu Agrawal
Reviewed-by: Stephen Boyd
---
v2: Moved some changes to acp:apd patch so that individual
Hi,
This series of patch does the following:
1. Changes the name of the AMD SoC general purpose clk
from ST(a version of SoC) to FCH (name of the IP).
2. Then make the drivers support both older and newer versions of
SoC.
Thanks,
Akshu
Akshu Agrawal (4):
ACPI: APD: Change name from ST to FCH
AMD SoC general pupose clk is present in new platforms with
same MMIO mappings. We can reuse the same clk handler support
for other platforms. Hence, changing name from ST(SoC) to FCH(IP)
Signed-off-by: Akshu Agrawal
Acked-by: Stephen Boyd
---
v2: pulled in clk changes so that patch compiles
On 7/31/2020 4:44 PM, Rafael J. Wysocki wrote:
On Fri, Jul 31, 2020 at 2:44 AM Agrawal, Akshu wrote:
On 7/29/2020 6:56 AM, Stephen Boyd wrote:
Quoting Akshu Agrawal (2020-07-28 01:28:53)
AMD SoC general pupose clk is present in new platforms with
same MMIO mappings. We can reuse the same
On 7/29/2020 6:56 AM, Stephen Boyd wrote:
Quoting Akshu Agrawal (2020-07-28 01:28:53)
AMD SoC general pupose clk is present in new platforms with
same MMIO mappings. We can reuse the same clk handler support
for other platforms. Hence, changing name from ST(SoC) to FCH(IP)
Signed-off-by
Since there is slight difference in AMD RV based soc in misc
clk architecture. The fmw property will help in differentiating
the SoCs.
Signed-off-by: Akshu Agrawal
---
drivers/acpi/acpi_apd.c | 4
include/linux/platform_data/clk-fch.h | 1 +
2 files changed, 5 insertions
There is minor difference between previous family of SoC and
the current one. Which is the there is only 48Mh fixed clk.
There is no mux and no option to select another freq as there in previous.
Signed-off-by: Akshu Agrawal
---
v2: Consolidated the loops in remove.
v3: Removed negation in
Since there is slight difference in AMD RV based soc in misc
clk architecture. The fmw property will help in differentiating
the SoCs.
Signed-off-by: Akshu Agrawal
---
drivers/acpi/acpi_apd.c | 4
include/linux/platform_data/clk-fch.h | 1 +
2 files changed, 5 insertions
AMD SoC general pupose clk is present in new platforms with
minor differences. We can reuse the same clk driver for other
platforms. Hence, changing name from ST(SoC) to FCH(IP)
Signed-off-by: Akshu Agrawal
---
v2: Moved some changes to acp:apd patch so that individual patches
compile
drivers
AMD SoC general pupose clk is present in new platforms with
same MMIO mappings. We can reuse the same clk handler support
for other platforms. Hence, changing name from ST(SoC) to FCH(IP)
Signed-off-by: Akshu Agrawal
---
v2: pulled in clk changes so that patch compiles individually
drivers
On 7/21/2020 1:36 PM, Stephen Boyd wrote:
Quoting Akshu Agrawal (2020-07-19 22:04:57)
diff --git a/drivers/clk/x86/clk-st.c b/drivers/clk/x86/clk-fch.c
similarity index 73%
rename from drivers/clk/x86/clk-st.c
rename to drivers/clk/x86/clk-fch.c
index 25d4b97aff9b..b252f0cf0628 100644
--- a
On 7/21/2020 1:35 PM, Stephen Boyd wrote:
Quoting Akshu Agrawal (2020-07-19 22:04:59)
diff --git a/drivers/clk/x86/clk-fch.c b/drivers/clk/x86/clk-fch.c
index b252f0cf0628..d68bca7b213f 100644
--- a/drivers/clk/x86/clk-fch.c
+++ b/drivers/clk/x86/clk-fch.c
[...]
static int
On 7/27/2020 6:58 PM, Rafael J. Wysocki wrote:
On Mon, Jul 20, 2020 at 7:06 AM Akshu Agrawal wrote:
AMD SoC general pupose clk is present in new platforms with
same MMIO mappings. We can reuse the same clk handler support
for other platforms. Hence, changing name from ST(SoC) to FCH(IP
the
state should be maintained after ACP Power On.
Signed-off-by: Akshu Agrawal
---
sound/soc/amd/raven/pci-acp3x.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/sound/soc/amd/raven/pci-acp3x.c b/sound/soc/amd/raven/pci-acp3x.c
index ebf4388b6262
Since there is slight difference in AMD RV based soc in misc
clk architecture. The fmw property will help in differentiating
the SoCs.
Signed-off-by: Akshu Agrawal
---
drivers/acpi/acpi_apd.c | 4
include/linux/platform_data/clk-fch.h | 1 +
2 files changed, 5 insertions
AMD SoC general pupose clk is present in new platforms with
same MMIO mappings. We can reuse the same clk handler support
for other platforms. Hence, changing name from ST(SoC) to FCH(IP)
Signed-off-by: Akshu Agrawal
---
drivers/acpi/acpi_apd.c| 14
There is minor difference between previous family of SoC and
the current one. Which is the there is only 48Mh fixed clk.
There is no mux and no option to select another freq as there in previous.
Signed-off-by: Akshu Agrawal
---
v2: Consolidated the loops in remove.
drivers/clk/x86/clk-fch.c
AMD SoC general pupose clk is present in new platforms with
minor differences. We can reuse the same clk driver for other
platforms. Hence, changing name from ST(SoC) to FCH(IP)
Signed-off-by: Akshu Agrawal
---
drivers/clk/x86/Makefile| 2 +-
drivers/clk/x86/{clk-st.c =>
On 7/16/2020 6:12 AM, Stephen Boyd wrote:
Quoting Akshu Agrawal (2020-07-12 17:59:50)
diff --git a/drivers/clk/x86/clk-st.c b/drivers/clk/x86/clk-fch.c
similarity index 73%
rename from drivers/clk/x86/clk-st.c
rename to drivers/clk/x86/clk-fch.c
index 25d4b97aff9b..b252f0cf0628 100644
--- a
On 7/16/2020 6:33 AM, Stephen Boyd wrote:
Quoting Akshu Agrawal (2020-07-12 17:59:52)
There is minor difference between previous family of SoC and
the current one. Which is the there is only 48Mh fixed clk.
There is no mux and no option to select another freq as there in previous.
Signed-off
On 7/7/2020 4:00 PM, Mark Brown wrote:
On Tue, Jul 07, 2020 at 03:38:25PM +0530, Akshu Agrawal wrote:
Non-dts based systems can use ACPI DSDT to pass on the mclk.
Thus add fmw property mclk-name to get the name of the system clk
and link it to rt5682 mclk.
ACPI doesn't support clocks a
There is minor difference between previous family of SoC and
the current one. Which is the there is only 48Mh fixed clk.
There is no mux and no option to select another freq as there in previous.
Signed-off-by: Akshu Agrawal
---
drivers/clk/x86/clk-fch.c | 55
AMD SoC general pupose clk is present in new platforms with
minor differences. We can reuse the same clk driver for other
platforms. Hence, changing name from ST(SoC) to FCH(IP)
Signed-off-by: Akshu Agrawal
---
drivers/clk/x86/Makefile| 2 +-
drivers/clk/x86/{clk-st.c =>
AMD SoC general pupose clk is present in new platforms with
same MMIO mappings. We can reuse the same clk handler support
for other platforms. Hence, changing name from ST(SoC) to FCH(IP)
Signed-off-by: Akshu Agrawal
---
drivers/acpi/acpi_apd.c| 14
Since there is slight difference in AMD RV based soc in misc
clk architecture. The fmw property will help in differentiating
the SoCs.
Signed-off-by: Akshu Agrawal
---
drivers/acpi/acpi_apd.c | 4
include/linux/platform_data/clk-fch.h | 1 +
2 files changed, 5 insertions
Non-dts based systems can use ACPI DSDT to pass on the mclk.
Thus add fmw property mclk-name to get the name of the system clk
and link it to rt5682 mclk.
Signed-off-by: Akshu Agrawal
---
include/sound/rt5682.h| 1 +
sound/soc/codecs/rt5682.c | 7 ++-
2 files changed, 7 insertions(+), 1
AMD SoC general pupose clk is present in new platforms with
minor differences. We can reuse the same clk driver for other
platforms. Hence, changing name from ST(SoC) to FCH(IP)
Signed-off-by: Akshu Agrawal
---
This patch is dependant on https://patchwork.kernel.org/patch/11648129/
drivers/clk
There is minor difference between previous family of SoC and
the current one. Which is the there is only 48Mh fixed clk.
There is no mux and no option to select another freq as there in previous.
Signed-off-by: Akshu Agrawal
---
This patch is dependant on https://patchwork.kernel.org/patch
AMD SoC general pupose clk is present in new platforms with
same MMIO mappings. We can reuse the same clk handler support
for other platforms. Hence, changing name from ST(SoC) to FCH(IP)
Signed-off-by: Akshu Agrawal
---
drivers/acpi/acpi_apd.c| 14
Since there is slight difference in AMD RV based soc in misc
clk architecture. The fmw property will help in differentiating
the SoCs.
Signed-off-by: Akshu Agrawal
---
drivers/acpi/acpi_apd.c | 4
include/linux/platform_data/clk-fch.h | 1 +
2 files changed, 5 insertions
Fixes interrupt enable condition check with which now
interrupt gets enabled in dma_open.
Prior to this patch it was getting enabled in runtime_resume only.
Signed-off-by: Akshu Agrawal
---
sound/soc/amd/raven/acp3x-pcm-dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Akshu Agrawal
---
drivers/mmc/host/sdhci-acpi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index d8b76cb8698a..48ecbd0b180d 100644
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -542,6 +542,7 @@ stati
On 6/12/2020 10:04 PM, Mark Brown wrote:
On Fri, Jun 12, 2020 at 10:01:11PM +0530, Akshu Agrawal wrote:
Fixes kernel crash on platforms which do not have mclk exposed
in CCF framework. For these platforms have mclk as NULL and
continue to register clocks.
Derek already submitted this
Fixes kernel crash on platforms which do not have mclk exposed
in CCF framework. For these platforms have mclk as NULL and
continue to register clocks.
Signed-off-by: Akshu Agrawal
---
sound/soc/codecs/rt5682.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/sound
Having mixer control to switch between DMICs prevents user to
initiate capture simultaneously on both the DMIcs.
Earlier 2 separate devices, one for each DMIC, gave an option of
using them simultaneously, which is not supported.
Signed-off-by: Akshu Agrawal
---
v2: Modified "Front Mic"
Having mixer control to switch between DMICs prevents user to
initiate capture simultaneously on both the DMIcs.
Earlier 2 separate devices, one for each DMIC, gave an option of
using them simultaneously, which is not supported.
Signed-off-by: Akshu Agrawal
---
v2: Modified "Front Mic"
On 5/27/2020 4:57 PM, Mark Brown wrote:
On Wed, May 27, 2020 at 07:10:16AM +0530, Akshu Agrawal wrote:
+ SOC_SINGLE_BOOL_EXT("Front Mic", 0, front_mic_get, front_mic_set),
This should probably be a mux with two labelled options, or if it's a
boolean control it should en
Having mixer control to switch between DMICs prevents user to
initiate capture simultaneously on both the DMIcs.
Earlier 2 separate devices, one for each DMIC, gave an option of
using them simultaneously, which is not supported.
Signed-off-by: Akshu Agrawal
---
sound/soc/amd/acp3x-rt5682
The following commit has been merged into the efi/urgent branch of tip:
Commit-ID: 3d8c11efd528d56972d44ed0de51c4e11a9a4fa9
Gitweb:
https://git.kernel.org/tip/3d8c11efd528d56972d44ed0de51c4e11a9a4fa9
Author:Punit Agrawal
AuthorDate:Tue, 12 May 2020 13:55:02 +09:00
Hi Aaron,
"Brown, Aaron F" writes:
>> From: netdev-ow...@vger.kernel.org On
>> Behalf Of Punit Agrawal
>> Sent: Thursday, May 14, 2020 9:31 PM
>> To: Kirsher, Jeffrey T
>> Cc: daniel.sangor...@toshiba.co.jp; Punit Agrawal
>> ; Alexand
-by: Akshu Agrawal
---
Resending the patch https://patchwork.kernel.org/patch/11355713/
sound/soc/amd/raven/acp3x-i2s.c | 6 +++---
sound/soc/amd/raven/acp3x-pcm-dma.c | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/sound/soc/amd/raven/acp3x-i2s.c b/sound/soc/amd/raven
. The extra condition can lead to inconsistency between the
state of hardware as expected by the driver.
Fix this by dropping the check for number of delay iterations.
While at it, also make __ew32_prepare() static as it's not used
anywhere else.
Signed-off-by: Punit Agrawal
Reviewed-by: Alexa
Alexander Duyck writes:
> On Mon, May 11, 2020 at 9:45 PM Punit Agrawal
> wrote:
>>
>> It's an error if the value of the RX/TX tail descriptor does not match
>> what was written. The error condition is true regardless the duration
>> of the interference from
1 - 100 of 683 matches
Mail list logo
