From: Ulf Hansson <ulf.hansson@linaro.org> To: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: "Shevchenko, Andriy" <andriy.shevchenko@intel.com>, Linus Walleij <linus.walleij@linaro.org>, "Zulkifli, Muhammad Husaini" <muhammad.husaini.zulkifli@intel.com>, Adrian Hunter <adrian.hunter@intel.com>, Michal Simek <michal.simek@xilinx.com>, "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, "Raja Subramanian, Lakshmi Bai" <lakshmi.bai.raja.subramanian@intel.com>, Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>, Mark Gross <mgross@linux.intel.com> Subject: Re: [PATCH v6 0/4] mmc: sdhci-of-arasan: Enable UHS-1 support for Keem Bay SOC Date: Wed, 2 Dec 2020 15:10:04 +0100 [thread overview] Message-ID: <CAPDyKFpfadG2-JPA1PC5Sx1_eM39AQUQTVj=m26Gu_=GQmjicA@mail.gmail.com> (raw) In-Reply-To: <CAHp75VeXxPoNqJVQojDC1G3gzJUJEiJs2UOm6kob71Aqa_7v2w@mail.gmail.com> On Wed, 2 Dec 2020 at 14:09, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Wed, Dec 2, 2020 at 2:44 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > On Wed, 2 Dec 2020 at 13:24, Shevchenko, Andriy > > <andriy.shevchenko@intel.com> wrote: > > > On Wed, Dec 02, 2020 at 11:53:42AM +0100, Ulf Hansson wrote: > > > > On Wed, 2 Dec 2020 at 08:02, <muhammad.husaini.zulkifli@intel.com> wrote: > > > > > > ... > > > > > > > > Kindly help to review this patch set. > > > > > > > > This version looks a lot better to me, but I am still requesting you > > > > to model the pinctrl correctly. I don't see a reason not to, but I may > > > > have overlooked some things. > > > > > > I'm wondering why we need to mock up a pin control from something which has no > > > pin control interface. It's rather communication with firmware that does pin > > > control under the hood, but it also may be different hardware in the other / > > > future generations. Would you accept mocking up the same calls over the kernel > > > as pin control, as something else? > > > > Well, my point is that modeling this a pinctrl would keep the mmc > > driver portable. Additionally, it's very common to manage pinctrls in > > mmc drivers, so it's not like this is an entirely new thing that I > > propose. > > > > If/when it turns out that there is a new HW having a different pinctrl > > interface, it would just mean that we need a new pinctrl driver, but > > can leave the mmc driver as is. > > My point is that it may be *not* a pin control at all. Sorry, but I don't quite follow, what is *not* a pinctrl? According to the information I have received from the previous discussions [1], it's clear to me that the ARM SMC call ends up changing settings for the I/O-pads. Or did I get that wrong? > And in that case you will need to mock up (what exactly?) and update > the MMC driver. > > -- > With Best Regards, > Andy Shevchenko Kind regards Uffe [1] https://lkml.org/lkml/2020/10/8/320
WARNING: multiple messages have this Message-ID (diff)
From: Ulf Hansson <ulf.hansson@linaro.org> To: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Mark Gross <mgross@linux.intel.com>, "Shevchenko, Andriy" <andriy.shevchenko@intel.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Linus Walleij <linus.walleij@linaro.org>, "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>, Michal Simek <michal.simek@xilinx.com>, Adrian Hunter <adrian.hunter@intel.com>, Wan Ahmad Zainie <wan.ahmad.zainie.wan.mohamad@intel.com>, "Raja Subramanian, Lakshmi Bai" <lakshmi.bai.raja.subramanian@intel.com>, "Zulkifli, Muhammad Husaini" <muhammad.husaini.zulkifli@intel.com>, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v6 0/4] mmc: sdhci-of-arasan: Enable UHS-1 support for Keem Bay SOC Date: Wed, 2 Dec 2020 15:10:04 +0100 [thread overview] Message-ID: <CAPDyKFpfadG2-JPA1PC5Sx1_eM39AQUQTVj=m26Gu_=GQmjicA@mail.gmail.com> (raw) In-Reply-To: <CAHp75VeXxPoNqJVQojDC1G3gzJUJEiJs2UOm6kob71Aqa_7v2w@mail.gmail.com> On Wed, 2 Dec 2020 at 14:09, Andy Shevchenko <andy.shevchenko@gmail.com> wrote: > > On Wed, Dec 2, 2020 at 2:44 PM Ulf Hansson <ulf.hansson@linaro.org> wrote: > > On Wed, 2 Dec 2020 at 13:24, Shevchenko, Andriy > > <andriy.shevchenko@intel.com> wrote: > > > On Wed, Dec 02, 2020 at 11:53:42AM +0100, Ulf Hansson wrote: > > > > On Wed, 2 Dec 2020 at 08:02, <muhammad.husaini.zulkifli@intel.com> wrote: > > > > > > ... > > > > > > > > Kindly help to review this patch set. > > > > > > > > This version looks a lot better to me, but I am still requesting you > > > > to model the pinctrl correctly. I don't see a reason not to, but I may > > > > have overlooked some things. > > > > > > I'm wondering why we need to mock up a pin control from something which has no > > > pin control interface. It's rather communication with firmware that does pin > > > control under the hood, but it also may be different hardware in the other / > > > future generations. Would you accept mocking up the same calls over the kernel > > > as pin control, as something else? > > > > Well, my point is that modeling this a pinctrl would keep the mmc > > driver portable. Additionally, it's very common to manage pinctrls in > > mmc drivers, so it's not like this is an entirely new thing that I > > propose. > > > > If/when it turns out that there is a new HW having a different pinctrl > > interface, it would just mean that we need a new pinctrl driver, but > > can leave the mmc driver as is. > > My point is that it may be *not* a pin control at all. Sorry, but I don't quite follow, what is *not* a pinctrl? According to the information I have received from the previous discussions [1], it's clear to me that the ARM SMC call ends up changing settings for the I/O-pads. Or did I get that wrong? > And in that case you will need to mock up (what exactly?) and update > the MMC driver. > > -- > With Best Regards, > Andy Shevchenko Kind regards Uffe [1] https://lkml.org/lkml/2020/10/8/320 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-12-02 14:11 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-02 15:02 [PATCH v6 0/4] mmc: sdhci-of-arasan: Enable UHS-1 support for Keem Bay SOC muhammad.husaini.zulkifli 2020-12-02 15:02 ` muhammad.husaini.zulkifli 2020-12-02 10:53 ` Ulf Hansson 2020-12-02 10:53 ` Ulf Hansson 2020-12-02 12:25 ` Shevchenko, Andriy 2020-12-02 12:25 ` Shevchenko, Andriy 2020-12-02 12:41 ` Ulf Hansson 2020-12-02 12:41 ` Ulf Hansson 2020-12-02 13:10 ` Andy Shevchenko 2020-12-02 13:10 ` Andy Shevchenko 2020-12-02 14:10 ` Ulf Hansson [this message] 2020-12-02 14:10 ` Ulf Hansson 2020-12-02 14:34 ` Andy Shevchenko 2020-12-02 14:34 ` Andy Shevchenko 2020-12-02 14:38 ` Zulkifli, Muhammad Husaini 2020-12-02 14:38 ` Zulkifli, Muhammad Husaini 2020-12-02 15:02 ` [PATCH v6 1/4] mmc: sdhci-of-arasan: Add structure device pointer in probe func muhammad.husaini.zulkifli 2020-12-02 15:02 ` muhammad.husaini.zulkifli 2020-12-02 15:02 ` [PATCH v6 2/4] firmware: keembay: Add support for Trusted Firmware Service call muhammad.husaini.zulkifli 2020-12-02 15:02 ` muhammad.husaini.zulkifli 2020-12-02 15:02 ` [PATCH v6 3/4] dt-bindings: mmc: Add phys, vmmc and vqmmc supplies for Keem Bay SOC muhammad.husaini.zulkifli 2020-12-02 15:02 ` muhammad.husaini.zulkifli 2020-12-02 15:02 ` [PATCH v6 4/4] mmc: sdhci-of-arasan: Enable UHS-1 support " muhammad.husaini.zulkifli 2020-12-02 15:02 ` muhammad.husaini.zulkifli 2020-12-02 18:54 ` Linus Walleij 2020-12-02 18:54 ` Linus Walleij 2020-12-03 7:10 ` Zulkifli, Muhammad Husaini 2020-12-03 7:10 ` Zulkifli, Muhammad Husaini 2020-12-03 8:12 ` Shevchenko, Andriy 2020-12-03 8:12 ` Shevchenko, Andriy 2020-12-05 23:01 ` Linus Walleij 2020-12-05 23:01 ` Linus Walleij 2020-12-12 14:06 ` Zulkifli, Muhammad Husaini 2020-12-12 14:06 ` Zulkifli, Muhammad Husaini
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='CAPDyKFpfadG2-JPA1PC5Sx1_eM39AQUQTVj=m26Gu_=GQmjicA@mail.gmail.com' \ --to=ulf.hansson@linaro.org \ --cc=adrian.hunter@intel.com \ --cc=andriy.shevchenko@intel.com \ --cc=andy.shevchenko@gmail.com \ --cc=lakshmi.bai.raja.subramanian@intel.com \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mmc@vger.kernel.org \ --cc=mgross@linux.intel.com \ --cc=michal.simek@xilinx.com \ --cc=muhammad.husaini.zulkifli@intel.com \ --cc=wan.ahmad.zainie.wan.mohamad@intel.com \ /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.