On 9/6/23 16:54, Niklas Cassel wrote: > Hello Damien, > > On Wed, Sep 06, 2023 at 03:48:02PM +0900, Damien Le Moal wrote: >> On 9/5/23 21:49, Niklas Cassel wrote: >>> From: Niklas Cassel <niklas.cassel@xxxxxxx> >>> >>> The target LPM policy can be set using either a Kconfig or a kernel module >>> parameter. >>> >>> However, if the board type is set to anything but board_ahci_low_power, >>> then the LPM policy will overridden and set to ATA_LPM_UNKNOWN. >>> >>> Additionally, if the default suspend is suspend to idle, depending on the >>> hardware capabilities of the HBA, ahci_update_initial_lpm_policy() might >>> override the LPM policy to either ATA_LPM_MIN_POWER_WITH_PARTIAL or >>> ATA_LPM_MIN_POWER. >>> >>> All this means that it is very hard to know which LPM policy a user will >>> actually be using on a given system. >>> >>> In order to make it easier to debug LPM related issues, print the LPM >>> policy on boot. >>> >>> One common LPM related issue is that the device fails to link up. >>> Because of that, we cannot add this print to ata_dev_configure(), as that >>> function is only called after a successful link up. Instead, add the info >>> using ata_port_desc(). The port description is printed once during boot. >>> >>> Before changes: >>> ata1: SATA max UDMA/133 abar m524288@0xa5780000 port 0xa5780100 irq 170 >>> ata2: SATA max UDMA/133 abar m524288@0xa5780000 port 0xa5780180 irq 170 >>> >>> After changes: >>> ata1: SATA max UDMA/133 abar m524288@0xa5780000 port 0xa5780100 lpm-pol 4 irq 170 >>> ata2: SATA max UDMA/133 abar m524288@0xa5780000 port 0xa5780180 lpm-pol 4 irq 170 >> >> Looks good, but maybe print the lpm-pol value at the end, after the IRQ number, >> to preserve the beginning of the message as it was before. >> >> Or even better: why not print the LPM modes supported by the port and the target >> lpm policy (lpm-pol) as a new ata_port_info() message right after the port desc >> message ? > > This print already exists: > [ 1.515960] ahci 10000:e0:17.0: AHCI 0001.0301 32 slots 1 ports 6 Gbps 0x1 impl SATA mode > [ 1.515963] ahci 10000:e0:17.0: flags: 64bit ncq sntf pm clo only pio slum part deso sadm sds > > Which prints the capabilities of the HBA. Right. > > The only LPM capability per port, that seems to be able to differ from the > global HBA capability, is PxDEVSLP.DSP: > > " > Device Sleep Present (DSP): If set to ‘1’, the platform supports Device Sleep > on this port. If cleared to ‘0’, the platform does not support Device Sleep on > this port. This bit may only be set to ‘1’ if CAP2.SDS is set to ‘1’. > " > > E.g. on my machine, the HBA has support for DevSleep (supported features print > includes "sds"), but none of the ports seem to have support for DevSleep. > > Would you like PxDEVSLP.DSP printed? We could. > What would be interesting is to be able to know which features the connected > device supports, as e.g. DevSleep needs support both in HBA and the device, > but as the problem is that we usually don't get link up, this is information > is still unknown at this time. Yes. And if the link up is OK, devsleep capability is reported if supported by the device. OK. So let's just keep the lpm-pol message addition, but maybe move it at the end of the message, after the IRQ info. > > > Kind regards, > Niklas > >> >>> >>> Signed-off-by: Niklas Cassel <niklas.cassel@xxxxxxx> >>> --- >>> drivers/ata/ahci.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c >>> index abb5911c9d09..541f6ec7f395 100644 >>> --- a/drivers/ata/ahci.c >>> +++ b/drivers/ata/ahci.c >>> @@ -1898,6 +1898,7 @@ static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) >>> ap->em_message_type = hpriv->em_msg_type; >>> >>> ahci_update_initial_lpm_policy(ap, hpriv); >>> + ata_port_desc(ap, "lpm-pol %d", ap->target_lpm_policy); >>> >>> /* disabled/not-implemented port */ >>> if (!(hpriv->port_map & (1 << i))) >> >> -- >> Damien Le Moal >> Western Digital Research -- Damien Le Moal Western Digital Research
