but not used [-Werror=unused-function]
>
> Just remove the #ifdef and use __maybe_unused annotations instead,
> to make the code more robust here.
It sounds like desire to merge in the suspend/resume support as this
is in linux-next 14 hours ago.
Reviewed-by: Loc Ho
-Loc
driver. Instead, move completely to the FW by
accessing the GIC directly.
* Fix a bug with function acpi_gsi_to_irq
* Enable APEI multiple GHES source to share an single external IRQ
v2
* Make all code more generic naming
* Still waiting for comment from Linaro folks on APEI
---
Loc Ho (1
X-Gene platforms describe multiple GHES error sources with the same hardware
error notification type (external interrupt) and interrupt number.
Change the GHES interrupt request to support sharing the same IRQ.
Co-authored-by: Tuan Phan
Signed-off-by: Loc Ho
---
drivers/acpi/apei/ghes.c | 3
) X-GENE SOC EDAC
> +EDAC-XGENE-APPLIED MICRO (APM) X-GENE SOC EDAC
To be consistent with other, how about just:
EDAC-XGENE (drop the Applied micro ... line)
> M: Loc Ho
> S: Supported
> F: drivers/edac/xgene_edac.c
-Loc
the FW by
accessing the GIC directly.
* Fix a bug with function acpi_gsi_to_irq
* Enable APEI multiple GHES source to share an single external IRQ
v2
* Make all code more generic naming
* Still waiting for comment from Linaro folks on APEI
---
Loc Ho (1):
acpi: apei: Enable APEI multiple GHES
This patch allows APEI generic error source table with external
IRQ to share a single IRQ.
Co-authored-by: Tuan Phan
Signed-off-by: Loc Ho
---
drivers/acpi/apei/ghes.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
ll.
>
> AFAIR.
>
> Also, from looking at the patches, the SOB chain is wrong:
>
> Signed-off-by: Tuan Phan
> Signed-off-by: Loc Ho
>
> I don't know from that who's the author and who's the submitter.
> SubmittingPatches has more info on the whole deal.
>
. To prevent any legacy issues, the code will default to 8bit
accesses if the value is anything but 16 or 32.
Signed-off-by: Loc Ho
[Re-send as single patch set]
Signed-off-by: Jon Mason
---
drivers/acpi/spcr.c | 18 --
include/acpi/acrestyp.h | 7 +++
2 files changed, 23
v2:
* Merged Jon Mason patch with APM X-Gene patch
Loc Ho (2):
ACPI: SPCR: Use access width to determine mmio usage
ACPI: SPCR: Workaround for APM X-Gene 8250 UART 32-alignment errata
drivers/acpi/spcr.c | 40 ++--
include/acpi/acrestyp.h | 7
option.
Signed-off-by: Loc Ho
---
drivers/acpi/spcr.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c
index 2905063..4ac3e06 100644
--- a/drivers/acpi/spcr.c
+++ b/drivers/acpi/spcr.c
@@ -36,6 +36,26 @@ static bool
; >> > mmio, then the patch you link above would reset it to mmio32.
>>>> >> > Personally, I would recommend a big, fat comment on why this extra
>>>> >> > step is necessary, but it should work as desired. Alternatively, we
>>>> >
Hi,
>
> any objections?
No objection for X-Gene EDAC.
-Loc
Alternatively, we
>>> >> > could add some kind of quirk library (similar to
>>> >> > qdf2400_erratum_44_present) where the OEM/OEM Table ID is referenced
>>> >> > and workaround applied. Thoughts?
>>> >>
>>> >> That
> they are better solution as it works for more SoC's than just our. As
> >> you had suggested, we should apply your patch and
> >> https://patchwork.kernel.org/patch/9460959. The third patch -
> >> https://patchwork.kernel.org/patch/9462183/ - conflicts
Hi Wolfram,
>> This patch adds ACPI support by using PCC mailbox communication
>> interface.
>>
>> Signed-off-by: Hoan Tran
>
> Please make use checkpatch:
>
> WARNING: braces {} are not necessary for single statement blocks
> #149: FILE: drivers/i2c/busses/i2c-xgene-slimpro.c:242:
> + if (
Hi Jon,
> > From: Khuong Dinh
> >
> > This patch makes pci-xgene-msi driver ACPI-aware and provides
> > MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode.
> >
> > Signed-off-by: Khuong Dinh
> > Signed-off-by: Duc Dang
> > Acked-by: Marc Zyngier
> > ---
> > v2:
> > - Verify with
tps://lkml.org/lkml/2017/5/4/450
>> 2. Applied this one - https://patchwork.kernel.org/patch/9460959/
>>
>> -Loc
>
> What if we simply applied the following (100% untested) patch to add
> the quirk framework I was suggesting? It can be applied on top of the
> patch I
Hi Jon,
On Mon, May 8, 2017 at 1:34 PM, Jon Mason wrote:
> On Mon, May 8, 2017 at 3:57 PM, Loc Ho wrote:
>> Hi Jon,
>>
>>>>
>>>>>> The current SPCR code does not check the access width of the mmio, and
>>>>>> uses a default of 8bi
Hi Jon,
>>
The current SPCR code does not check the access width of the mmio, and
uses a default of 8bit register accesses. This prevents devices that
only do 16 or 32bit register accesses from working. By simply checking
this field and setting the mmio string appropriately,
Hi Jon,
>> The current SPCR code does not check the access width of the mmio, and
>> uses a default of 8bit register accesses. This prevents devices that
>> only do 16 or 32bit register accesses from working. By simply checking
>> this field and setting the mmio string appropriately, this issue
Hi,
>
> trivial fix to spelling mistake in dev_err message
>
> Signed-off-by: Colin Ian King
Reviewed-by: Loc Ho
> ---
> drivers/edac/xgene_edac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/edac/xgene_edac.c b/drivers/edac/x
;
> if (reg & IOBPA_M_TRANS_CORRUPT_MASK)
> - dev_err(edac_dev->dev, "Mutilple IOB PA transaction error\n");
> + dev_err(edac_dev->dev, "Multiple IOB PA transaction error\n");
> if (reg & IOBPA_REQIDRAM_CORRUPT_MASK)
> dev_err(edac_dev->dev, "IOB PA transaction ID RAM error\n");
> if (reg & IOBPA_M_REQIDRAM_CORRUPT_MASK)
Reviewed-by: Loc Ho
-Loc
t;> pclk->param.reg_csr_offset);
>>> - pr_debug("%s CSR RESET PADDR base %pa csr offset 0x%08X
>>> mask 0x%08X value 0x%08X\n",
>>> - clk_hw_get_name(hw), ®,
>>> + pr_debug("%s csr offset 0x%08X mask 0x%08X value
>>> 0x%08X\n",
>>> + clk_hw_get_name(hw),
>>> pclk->param.reg_csr_offset,
>>> pclk->param.reg_csr_mask,
>>> data);
>>> }
>>
>>
>>
>> The code looks fine to me. May be overly cautious here. Do you have a
>> board to test this out?
>>
>> -Loc
>>
>
> Yes, that was how I caught the problem. There are no errors that I
> can see with this patch applied.
Acked-by: Loc Ho
-Loc
Hi Laura,
> ioremaped addresses are not linearly mapped so the physical
> address can not be figured out via __pa. More generally, there
> is no guarantee that backing value of an ioremapped address
> is a physical address at all. The value here is only used
> for debugging so just drop the call t
Hi Ben,
>> >> --
>> >>
>> >> [ Upstream commit 1382ea631b634850a3795527db0feeff5aaf ]
>> >>
>> >> The X-Gene clock driver missed the divider shift operation when
>> >> set the divider value.
>> >&
Hi,
>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> --
>>
>> [ Upstream commit 1382ea631b634850a3795527db0feeff5aaf ]
>>
>> The X-Gene clock driver missed the divider shift operation when
>>
Hi Itaru,
On Sat, Jul 23, 2016 at 10:04 PM, Itaru Kitayama
wrote:
>
> Hi Hoan,
>
> I didn't mention in my previous post, though I think I'm using fairly recent
> version of Tianocore F/W, and I can confirm there's the PCCT table,
>
> [0.00] ACPI: PCCT 0x0047FA826000 000300 (v01 APM
Add set_mode callback")
> Signed-off-by: Kishon Vijay Abraham I
You can add my:
Reviewed-by: Loc Ho
-Loc
d-off-by: Mika Westerberg
>> Signed-off-by: Suravee Suthikulpanit
>> Tested-by: Loc Ho
>> ---
>>
>> Note: This has been tested on AMD Seattle RevB for both DT and ACPI.
>>
>> Changes from V3 (https://lkml.org/lkml/2015/12/22/596):
>> * Add i2c
d-off-by: Mika Westerberg
>> Signed-off-by: Suravee Suthikulpanit
>> Tested-by: Loc Ho
>> ---
>>
>> Note: This has been tested on AMD Seattle RevB for both DT and ACPI.
>>
>> Changes from V3 (https://lkml.org/lkml/2015/12/22/596):
>> * Add i2c_dw_p
Hi,
> The current driver uses input clock source frequency to calculate
> values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not
> currently have a good way to provide the frequency information.
> Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used
> to
Hi,
> The current driver uses input clock source frequency to calculate
> values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not
> currently have a good way to provide the frequency information.
> Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used
> to
Hi Murali,
>>
>>
>> Again, there's other SoCs out there which have serdes. Adding 2.5k of
>> lines for vendor serdes implementations does not scale - this needs to
>> be re-thought in a way which reduces the code maintanence burden.
>>
>> Other SoCs like Marvell Armada have serdes links which can
Hi Olof,,
>>
This patch set adds syscon reboot/poweroff device nodes to support reboot
and
poweroff features on X-Gene platform.
Tai Nguyen (2):
power: reset: Add syscon reboot device node for APM X-Gene platform
power: reset: Add syscon poweroff device node
Hi Olof,
>> This patch set adds syscon reboot/poweroff device nodes to support reboot and
>> poweroff features on X-Gene platform.
>>
>> Tai Nguyen (2):
>> power: reset: Add syscon reboot device node for APM X-Gene platform
>> power: reset: Add syscon poweroff device node for APM X-Gene Mustan
Hi Tejun,
>> >> Looks the commit 8a4aeec8d(libata/ahci: accommodate tag ordered
>> >> controllers) causes below sata failure[1] on APM AHCI controller.
>> >>
>> >> And the error does disappear after reverting the commit.
>> >
>> > Can you give some more details about the workload and the disk? Wh
rong wrt the dependencies for
>>>> this thing.
>>>>
>>>> It looks like the "select PHY_XGENE" came in through the libata
>>>> update, but this USB update actually brought in the "config PHY_XGENE"
>>>> and thus this error.
h the libata
>> update, but this USB update actually brought in the "config PHY_XGENE"
>> and thus this error. Which makes me wonder how this all worked. Why
>> does that "select PHY_XGENE" exist when apparently it's not needed?
>>
>> Regardless, t
This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose
PHY driver. The PHY for SATA controller 2 and 3 are enabled by default.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
arch/arm64/boot/dts/apm-storm.dtsi | 75
th more descriptive name
* Add override PHY parameter for per controller, per port, and per speed
* Patch the generic PHY frame to expose set_speed operation
v1
* Initial version
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
Loc Ho (3):
Documentation: Add APM X-Gen
This patch adds the APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding
documentation.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
.../devicetree/bindings/phy/apm-xgene-phy.txt | 79
1 files changed, 79 insertions(+), 0
This patch adds the APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding
documentation.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
.../devicetree/bindings/phy/apm-xgene-phy.txt | 79
1 files changed, 79 insertions(+), 0
This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose
PHY driver. The PHY for SATA controller 2 and 3 are enabled by default.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
arch/arm64/boot/dts/apm-storm.dtsi | 75
er port, and per speed
* Patch the generic PHY frame to expose set_speed operation
v1
* Initial version
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
Loc Ho (3):
Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
binding documentation
This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose
PHY driver. The PHY for SATA controller 2 and 3 are enabled by default.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
arch/arm64/boot/dts/apm-storm.dtsi | 75
This patch adds the APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding
documentation.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
.../devicetree/bindings/phy/apm-xgene-phy.txt | 79
1 files changed, 79 insertions(+), 0
ID completely
* Make resource requirement based on compatible type
* Rename override PHY parameters with more descriptive name
* Add override PHY parameter for per controller, per port, and per speed
* Patch the generic PHY frame to expose set_speed operation
v1
* Initial version
Signed-off-b
Hi,
>> >> This patch adds function set_speed to the generic PHY framework
>> >> operation
>> >> structure. This function can be called to instruct the PHY
>> >> underlying layer
>> >> at specified lane to configure for specified speed in hertz.
>> >
>> > why ?
Hi Felipe and Kishon,
>>> >> >> This patch adds function set_speed to the generic PHY framework
>>> >> >> operation
>>> >> >> structure. This function can be called to instruct the PHY underlying
>>> >> >> layer
>>> >> >> at specified lane to configure for specified speed in hertz.
>>> >> >
>>>
HI,
>> >> >> This patch adds function set_speed to the generic PHY framework
>> >> >> operation
>> >> >> structure. This function can be called to instruct the PHY underlying
>> >> >> layer
>> >> >> at specified lane to configure for specified speed in hertz.
>> >> >
>> >> > why ? looks like clk
Hi,
>> >> This patch adds function set_speed to the generic PHY framework operation
>> >> structure. This function can be called to instruct the PHY underlying
>> >> layer
>> >> at specified lane to configure for specified speed in hertz.
>> >
>> > why ? looks like clk_set_rate() is your friend h
Hi Balbi,
>> +/*
>> + * This function is used to configure the PHY to operation as either SATA
>> Gen1
>> + * or Gen2 speed.
>> + */
>> +static void xgene_phy_sata_force_gen(struct xgene_phy_ctx *ctx,
>> + int lane, int gen)
>
> why do you need to *force* the gene
Hi Balbi,
> On Thu, Feb 27, 2014 at 11:14:05AM -0700, Loc Ho wrote:
>> This patch adds function set_speed to the generic PHY framework operation
>> structure. This function can be called to instruct the PHY underlying layer
>> at specified lane to configure for specified sp
This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose
PHY driver. The PHY for SATA controller 2 and 3 are enabled by default.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
arch/arm64/boot/dts/apm-storm.dtsi | 75
This patch adds function set_speed to the generic PHY framework operation
structure. This function can be called to instruct the PHY underlying layer
at specified lane to configure for specified speed in hertz.
Signed-off-by: Loc Ho
---
drivers/phy/phy-core.c | 30
This patch adds APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding
documentation.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
.../devicetree/bindings/phy/apm-xgene-phy.txt | 79
1 files changed, 79 insertions(+), 0
th more descriptive name
* Add override PHY parameter for per controller, per port, and per speed
* Patch the generic PHY frame to expose set_speed operation
v1
* Initial version
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
Loc Ho (4):
PHY: Add function set_
Hi,
>> +
>> +static void sds_wr(void __iomem *csr_base, u32 indirect_cmd_reg,
>> + u32 indirect_data_reg, u32 addr, u32 data)
>> +{
>> + u32 val;
>> + u32 cmd;
>> +
>> + cmd = CFG_IND_WR_CMD_MASK | CFG_IND_CMD_DONE_MASK;
>> +
Hi,
+
+static void sds_wr(void __iomem *csr_base, u32 indirect_cmd_reg,
+ u32 indirect_data_reg, u32 addr, u32 data)
+{
+ u32 val;
+ u32 cmd;
+
+ cmd = CFG_IND_WR_CMD_MASK | CFG_IND_CMD_DONE_MASK;
+ cmd = CFG_IND
Hi,
>>
>> +config PHY_XGENE
>> + tristate "APM X-Gene 15Gbps PHY support"
>> + depends on ARM64 || COMPILE_TEST
>> + select GENERIC_PHY
>
>
> depends on HAS_IOMEM and CONFIG_OF..
I will make it depends as "HAS_IOMEM && OF && (ARM64 || COMPILE_TEST)
>>
>> +/* PLL Clock Macro Uni
This patch adds function set_speed to the generic PHY framework operation
structure. This function can be called to instruct the PHY underlying layer
at specified lane to configure for specified speed in hertz.
Signed-off-by: Loc Ho
---
drivers/phy/phy-core.c | 30
This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose
PHY driver. The PHY for SATA controller 2 and 3 are enabled by default.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
arch/arm64/boot/dts/apm-storm.dtsi | 75
v1
* Initial version
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
Loc Ho (4):
PHY: Add function set_speed to generic PHY framework
Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver
binding documentation
PHY: add APM X-Gene SoC 1
This patch adds APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding
documentation.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
.../devicetree/bindings/phy/apm-xgene-phy.txt | 79
1 files changed, 79 insertions(+), 0
This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose
PHY driver. The PHY for SATA controller 2 and 3 are enabled by default.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
arch/arm64/boot/dts/apm-storm.dtsi | 75
This patch adds function set_speed to the generic PHY framework operation
structure. This function can be called to instruct the PHY underlying layer
at specified lane to configure for specified speed in hertz.
Signed-off-by: Loc Ho
---
drivers/phy/phy-core.c | 21
ameter for per controller, per port, and per speed
* Patch the generic PHY frame to expose set_speed operation
v1
* Initial version
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
Loc Ho (4):
PHY: Add function set_speed to generic PHY framework
Documentat
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
.../devicetree/bindings/phy/apm-xgene-phy.txt | 79
1 files changed, 79 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
diff
is, as this is not
>> >> > entirely clear from the code.
>> >> >
>> >> > In particular, please describe how this differs from a dmaengine driver
>> >> > and why it is not possible to extend the dma slave API to describe qmtm
>> &g
r from the code.
>
> In particular, please describe how this differs from a dmaengine driver
> and why it is not possible to extend the dma slave API to describe qmtm
> as a dma engine.
>
[Loc Ho]
If the QM driver implements the DMA API, what about the actual DMA
engine driver which
70 matches
Mail list logo
