From: Hans de Goede <hdegoede@redhat.com> To: Mikko Perttunen <mperttunen@nvidia.com>, Tejun Heo <tj@kernel.org> Cc: "swarren@wwwdotorg.org" <swarren@wwwdotorg.org>, "thierry.reding@gmail.com" <thierry.reding@gmail.com>, Peter De Schrijver <pdeschrijver@nvidia.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>, "linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org> Subject: Re: [PATCH v2 6/7] ata: Add support for the Tegra124 SATA controller Date: Tue, 15 Jul 2014 10:55:29 +0200 [thread overview] Message-ID: <53C4EC81.1040304@redhat.com> (raw) In-Reply-To: <53C4D472.9010507@nvidia.com> Hi, On 07/15/2014 09:12 AM, Mikko Perttunen wrote: > Heh, what you are describing is the v1 of this series :) > > However, > > 17/06/14 Thierry Reding wrote: >> I would've preferred tegra_powergate_sequence_power_up() to be used >> consistently in all drivers. I'm still not convinced that using the >> platform AHCI driver this way is really the best option, since we're >> bending over backwards to fit into what this driver dictates. There >> shouldn't be a need for that. > > As you probably noticed, the issue is that on Tegra we want to use tegra_powergate_sequence_power_up to enable the SATA power rail. That function assumes that it gets a disabled clock and returns with the clock enabled. If we use ahci_platform's resource management functions, > this is not doable, since it wants to handle clocks by itself. Right, note I was not suggesting that you use ahci_platform_enable_resources / ahci_platform_disable_resources, that clearly won't work for your case. As I said "I can see there are good reasons for that though." > To be honest, I too would prefer handling the resources in the driver. The driver needs other resources than what ahci_platform currently manages (at least reset_controls and multiple regulators, later we might get more) and managing them in the driver allows the driver to do proper error handling and manage all resources consistently and in one place. Also, I don't think it is sensible to add support for loading every possible kind of DT resource to ahci_platform, since most drivers won't need them. Actually I have considered asking you to add support for reset controllers to libahci_platform too, since I see a pattern where more and more SOCs are starting to use those. I've refrained from asking that for now, but once a second ahci implementation needing those pops up we will likely go that route. So you might as well do it now :) > Other subsystems I've been in don't have this kind of helper library, so diverging here seems weird. Well the usb uhci-platform and ehci-platform drivers are doing the same, what we're trying to do here is avoid needless code duplication and if possible (for ehci and uhci it currently is) make it so that adding support for a new soc only requires adding dt stuff + a phy driver, without touching the ?hci code at all. Again I can see that this is not possible for the Tegra124. > That said, if you feel strongly about this, I can do what you described. I think you can safe a nice bit of code duplication (and if we ever find we have bugs there bug duplication) by switching to ahci_platform_get_resources, as described in my original mail. I can understand if you don't want to use any of the other ahci_platform_* functions, that makes total sense. I would not say this is something you must do, but I have a strong preference for you taking a shot at doing this. So can you please give this a try, and if it turns out to become ugly, just say so (with some explanation), and then you can keep things as is. Does that work for you? Regards, Hans > > Thanks, > Mikko > > On 14/07/14 16:36, Hans de Goede wrote: >> Hi, >> >> On 07/08/2014 03:22 PM, Tejun Heo wrote: >>> (cc'ing Hans) >>> >>> Hans, can you please review this patch? >> >> Done. >> >> Mikko, it looks like you are doing a lot of stuff >> the DIY way. I can see there are good reasons for >> that though. >> >> Still it would be nice if you could use a little bit >> more of the helper functions provided by libahci_platform.c >> >> Specifically I think it would be better if you used >> ahci_platform_get_resources, that would remove a lot of >> duplicate code from the new driver. >> >> To be specific I would like to suggest that you >> raise AHCI_MAX_CLKS to 4, and then specify an order >> in which the clks must be listed in the devicetree >> binding. Then you can put that order in an enum >> and use hpriv->clks[CLK_FOO] in your driver, where >> CLK_FOO comes from the enum. >> >> This way you should be able to use ahci_platform_get_resources >> and drop doing the iomap of the base registers, all the >> clk_gets and the phy_get yourself. >> >> You could then also use ahci_platform_disable_clks() in >> tegra_ahci_power_off >> >> Regards, >> >> Hans >>
WARNING: multiple messages have this Message-ID (diff)
From: hdegoede@redhat.com (Hans de Goede) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 6/7] ata: Add support for the Tegra124 SATA controller Date: Tue, 15 Jul 2014 10:55:29 +0200 [thread overview] Message-ID: <53C4EC81.1040304@redhat.com> (raw) In-Reply-To: <53C4D472.9010507@nvidia.com> Hi, On 07/15/2014 09:12 AM, Mikko Perttunen wrote: > Heh, what you are describing is the v1 of this series :) > > However, > > 17/06/14 Thierry Reding wrote: >> I would've preferred tegra_powergate_sequence_power_up() to be used >> consistently in all drivers. I'm still not convinced that using the >> platform AHCI driver this way is really the best option, since we're >> bending over backwards to fit into what this driver dictates. There >> shouldn't be a need for that. > > As you probably noticed, the issue is that on Tegra we want to use tegra_powergate_sequence_power_up to enable the SATA power rail. That function assumes that it gets a disabled clock and returns with the clock enabled. If we use ahci_platform's resource management functions, > this is not doable, since it wants to handle clocks by itself. Right, note I was not suggesting that you use ahci_platform_enable_resources / ahci_platform_disable_resources, that clearly won't work for your case. As I said "I can see there are good reasons for that though." > To be honest, I too would prefer handling the resources in the driver. The driver needs other resources than what ahci_platform currently manages (at least reset_controls and multiple regulators, later we might get more) and managing them in the driver allows the driver to do proper error handling and manage all resources consistently and in one place. Also, I don't think it is sensible to add support for loading every possible kind of DT resource to ahci_platform, since most drivers won't need them. Actually I have considered asking you to add support for reset controllers to libahci_platform too, since I see a pattern where more and more SOCs are starting to use those. I've refrained from asking that for now, but once a second ahci implementation needing those pops up we will likely go that route. So you might as well do it now :) > Other subsystems I've been in don't have this kind of helper library, so diverging here seems weird. Well the usb uhci-platform and ehci-platform drivers are doing the same, what we're trying to do here is avoid needless code duplication and if possible (for ehci and uhci it currently is) make it so that adding support for a new soc only requires adding dt stuff + a phy driver, without touching the ?hci code at all. Again I can see that this is not possible for the Tegra124. > That said, if you feel strongly about this, I can do what you described. I think you can safe a nice bit of code duplication (and if we ever find we have bugs there bug duplication) by switching to ahci_platform_get_resources, as described in my original mail. I can understand if you don't want to use any of the other ahci_platform_* functions, that makes total sense. I would not say this is something you must do, but I have a strong preference for you taking a shot at doing this. So can you please give this a try, and if it turns out to become ugly, just say so (with some explanation), and then you can keep things as is. Does that work for you? Regards, Hans > > Thanks, > Mikko > > On 14/07/14 16:36, Hans de Goede wrote: >> Hi, >> >> On 07/08/2014 03:22 PM, Tejun Heo wrote: >>> (cc'ing Hans) >>> >>> Hans, can you please review this patch? >> >> Done. >> >> Mikko, it looks like you are doing a lot of stuff >> the DIY way. I can see there are good reasons for >> that though. >> >> Still it would be nice if you could use a little bit >> more of the helper functions provided by libahci_platform.c >> >> Specifically I think it would be better if you used >> ahci_platform_get_resources, that would remove a lot of >> duplicate code from the new driver. >> >> To be specific I would like to suggest that you >> raise AHCI_MAX_CLKS to 4, and then specify an order >> in which the clks must be listed in the devicetree >> binding. Then you can put that order in an enum >> and use hpriv->clks[CLK_FOO] in your driver, where >> CLK_FOO comes from the enum. >> >> This way you should be able to use ahci_platform_get_resources >> and drop doing the iomap of the base registers, all the >> clk_gets and the phy_get yourself. >> >> You could then also use ahci_platform_disable_clks() in >> tegra_ahci_power_off >> >> Regards, >> >> Hans >>
next prev parent reply other threads:[~2014-07-15 8:55 UTC|newest] Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-06-18 14:23 [PATCH v2 0/7] Serial ATA support for NVIDIA Tegra124 Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen 2014-06-18 14:23 ` [PATCH v2 1/7] of: Add NVIDIA Tegra SATA controller binding Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen 2014-06-18 14:23 ` [PATCH v2 2/7] ARM: tegra: Add SATA controller to Tegra124 device tree Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen 2014-06-18 14:23 ` [PATCH v2 3/7] ARM: tegra: Add SATA and SATA power to Jetson TK1 " Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen 2014-06-18 14:23 ` [PATCH v2 4/7] clk: tegra: Enable hardware control of SATA PLL Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen 2014-07-08 1:26 ` Andrew Bresticker 2014-07-08 1:26 ` Andrew Bresticker 2014-07-08 1:26 ` Andrew Bresticker 2014-07-08 7:30 ` [PATCH] clk: tegra: Use XUSB-compatible SATA PLL sequence Mikko Perttunen 2014-07-08 7:30 ` Mikko Perttunen 2014-07-08 7:30 ` Mikko Perttunen 2014-07-08 8:16 ` Peter De Schrijver 2014-07-08 8:16 ` Peter De Schrijver 2014-07-08 8:16 ` Peter De Schrijver 2014-06-18 14:23 ` [PATCH v2 5/7] clk: tegra: Add SATA clocks to Tegra124 initialization table Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen 2014-06-24 19:32 ` Stephen Warren 2014-06-24 19:32 ` Stephen Warren 2014-06-18 14:23 ` [PATCH v2 6/7] ata: Add support for the Tegra124 SATA controller Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen [not found] ` <1403101406-15439-7-git-send-email-mperttunen-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2014-06-24 19:35 ` Stephen Warren 2014-06-24 19:35 ` Stephen Warren 2014-06-24 19:35 ` Stephen Warren 2014-06-26 11:18 ` Mikko Perttunen 2014-06-26 11:18 ` Mikko Perttunen 2014-06-26 11:18 ` Mikko Perttunen 2014-07-08 8:20 ` Mikko Perttunen 2014-07-08 8:20 ` Mikko Perttunen 2014-07-08 8:20 ` Mikko Perttunen 2014-07-09 6:49 ` Thierry Reding 2014-07-09 6:49 ` Thierry Reding 2014-07-09 6:49 ` Thierry Reding 2014-07-09 13:45 ` Mikko Perttunen 2014-07-09 13:45 ` Mikko Perttunen 2014-07-09 13:45 ` Mikko Perttunen 2014-07-08 13:22 ` Tejun Heo 2014-07-08 13:22 ` Tejun Heo 2014-07-08 13:38 ` Mikko Perttunen 2014-07-08 13:38 ` Mikko Perttunen 2014-07-08 13:38 ` Mikko Perttunen 2014-07-14 6:21 ` Mikko Perttunen 2014-07-14 6:21 ` Mikko Perttunen 2014-07-14 6:21 ` Mikko Perttunen [not found] ` <53C376FF.3060509-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2014-07-14 6:25 ` Hans de Goede 2014-07-14 6:25 ` Hans de Goede 2014-07-14 6:25 ` Hans de Goede 2014-07-14 6:28 ` Mikko Perttunen 2014-07-14 6:28 ` Mikko Perttunen 2014-07-14 6:28 ` Mikko Perttunen [not found] ` <20140708132216.GA4979-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org> 2014-07-14 13:36 ` Hans de Goede 2014-07-14 13:36 ` Hans de Goede 2014-07-14 13:36 ` Hans de Goede 2014-07-15 7:12 ` Mikko Perttunen 2014-07-15 7:12 ` Mikko Perttunen 2014-07-15 7:12 ` Mikko Perttunen 2014-07-15 8:55 ` Hans de Goede [this message] 2014-07-15 8:55 ` Hans de Goede 2014-07-15 8:55 ` Hans de Goede [not found] ` <53C4EC81.1040304-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2014-07-15 9:03 ` Mikko Perttunen 2014-07-15 9:03 ` Mikko Perttunen 2014-07-15 9:03 ` Mikko Perttunen 2014-07-15 9:31 ` Thierry Reding 2014-07-15 9:31 ` Thierry Reding 2014-07-15 9:31 ` Thierry Reding 2014-06-18 14:23 ` [PATCH v2 7/7] ARM: tegra: Add options for Tegra AHCI support to tegra_defconfig Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen 2014-06-18 14:23 ` Mikko Perttunen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=53C4EC81.1040304@redhat.com \ --to=hdegoede@redhat.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-ide@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-tegra@vger.kernel.org \ --cc=mperttunen@nvidia.com \ --cc=pdeschrijver@nvidia.com \ --cc=swarren@wwwdotorg.org \ --cc=thierry.reding@gmail.com \ --cc=tj@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.