| Message ID | 1515759368-16946-5-git-send-email-patrice.chotard@st.com |
|---|---|
| State | New |
| Headers | show |
| Series | Add MMCI support for STM32F SoCs family | expand |
On Fri, Jan 12, 2018 at 1:15 PM, <patrice.chotard@st.com> wrote: > From: Patrice Chotard <patrice.chotard@st.com> > > STM32F4 and STM32F7 MCUs has a SDIO controller that looks like > an ARM pl810. PL180 you mean. Ulf can fix while applying. > This patch adds the STM32 variant so that mmci driver supports it. > > Signed-off-by: Andrea Merello <andrea.merello@gmail.com> > Signed-off-by: Patrice Chotard <patrice.chotard@st.com> (...) > +static struct variant_data variant_stm32 = { > + .fifosize = 32 * 4, > + .fifohalfsize = 8 * 4, > + .clkreg = MCI_CLK_ENABLE, > + .clkreg_enable = MCI_ST_UX500_HWFCEN, If the asic designed derived this from ux500 I guess it is proper. > + .clkreg_8bit_bus_enable = MCI_ST_8BIT_BUS, > + .clkreg_neg_edge_enable = MCI_ST_UX500_NEG_EDGE, > + .datalength_bits = 24, > + .datactrl_mask_sdio = MCI_DPSM_ST_SDIOEN, > + .st_sdio = true, Did you test SDIO? I think we lack features for that. > + { > + .id = 0x00880180, > + .mask = 0x00ffffff, > + .data = &variant_stm32, > + }, Since ux500 was 480180 I wonder what variants 5,6,7 are... Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Linus On 01/15/2018 02:13 AM, Linus Walleij wrote: > On Fri, Jan 12, 2018 at 1:15 PM, <patrice.chotard@st.com> wrote: > >> From: Patrice Chotard <patrice.chotard@st.com> >> >> STM32F4 and STM32F7 MCUs has a SDIO controller that looks like >> an ARM pl810. > > PL180 you mean. Ulf can fix while applying. I need to send a v2, i will fix it. > >> This patch adds the STM32 variant so that mmci driver supports it. >> >> Signed-off-by: Andrea Merello <andrea.merello@gmail.com> >> Signed-off-by: Patrice Chotard <patrice.chotard@st.com> > > (...) >> +static struct variant_data variant_stm32 = { >> + .fifosize = 32 * 4, >> + .fifohalfsize = 8 * 4, >> + .clkreg = MCI_CLK_ENABLE, >> + .clkreg_enable = MCI_ST_UX500_HWFCEN, > > If the asic designed derived this from ux500 I guess it is proper. > >> + .clkreg_8bit_bus_enable = MCI_ST_8BIT_BUS, >> + .clkreg_neg_edge_enable = MCI_ST_UX500_NEG_EDGE, >> + .datalength_bits = 24, >> + .datactrl_mask_sdio = MCI_DPSM_ST_SDIOEN, >> + .st_sdio = true, > > Did you test SDIO? I think we lack features for that. no, the board accept only micro SD card, so only MMC mode can be tested. > >> + { >> + .id = 0x00880180, >> + .mask = 0x00ffffff, >> + .data = &variant_stm32, >> + }, > > Since ux500 was 480180 I wonder what variants 5,6,7 are... What is the rule to define the id ? for ST Micro variants we got the list below : .id = 0x00180180, u300 .id = 0x10180180, nomadik .id = 0x00280180, nomadik .id = 0x00480180, ux500 .id = 0x10480180, ux500v2 .id = 0x00880180, variant_stm32 I simply update the sixth digit for stm32 variant. Patrice > > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > > Yours, > Linus Walleij >
On Mon, Jan 15, 2018 at 6:17 PM, Patrice CHOTARD <patrice.chotard@st.com> wrote: >>> + { >>> + .id = 0x00880180, >>> + .mask = 0x00ffffff, >>> + .data = &variant_stm32, >>> + }, >> >> Since ux500 was 480180 I wonder what variants 5,6,7 are... > > What is the rule to define the id ? These four bits mean "revision". The number comes from hardware, so the ST ASIC department has some person who is responsible for revising the VHDL or Verilog code that this hardware is compiled from, and that person is bumping the version. Theoretically it is a "company function" or something bureaucratic like that updating the hardware so I guess it could be several people following procedure who have updated this number in the hardware over the years. But I bet it is a single person in Grenoble who has been doing the MMC/SD block since it appeared. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c index 38e8c20..9fb5035 100644 --- a/drivers/mmc/host/mmci.c +++ b/drivers/mmc/host/mmci.c @@ -245,6 +245,23 @@ struct variant_data { .opendrain = true, }; +static struct variant_data variant_stm32 = { + .fifosize = 32 * 4, + .fifohalfsize = 8 * 4, + .clkreg = MCI_CLK_ENABLE, + .clkreg_enable = MCI_ST_UX500_HWFCEN, + .clkreg_8bit_bus_enable = MCI_ST_8BIT_BUS, + .clkreg_neg_edge_enable = MCI_ST_UX500_NEG_EDGE, + .datalength_bits = 24, + .datactrl_mask_sdio = MCI_DPSM_ST_SDIOEN, + .st_sdio = true, + .st_clkdiv = true, + .pwrreg_powerup = MCI_PWR_ON, + .f_max = 48000000, + .pwrreg_clkgate = true, + .pwrreg_nopower = true, +}; + static struct variant_data variant_qcom = { .fifosize = 16 * 4, .fifohalfsize = 8 * 4, @@ -2019,6 +2036,11 @@ static int mmci_runtime_resume(struct device *dev) .mask = 0xf0ffffff, .data = &variant_ux500v2, }, + { + .id = 0x00880180, + .mask = 0x00ffffff, + .data = &variant_stm32, + }, /* Qualcomm variants */ { .id = 0x00051180,