Re: [PATCH v2 5/7] samples: kdbus: disable for mn10300
On Thu, Jun 18, 2015 at 09:49:05PM +0530, Sudip Mukherjee wrote: > On Thu, Jun 18, 2015 at 07:39:58AM -0700, Greg Kroah-Hartman wrote: > > On Thu, Jun 18, 2015 at 05:47:51PM +0530, Sudip Mukherjee wrote: > > > While building it failed with: > > > In function 'prime_new': > > > error: '__NR_memfd_create' undeclared (first use in this function) > > > > > > memfd_create syscall has not yet been implemented for mn10300. > > > so disable compilation of samples/kdbus for now with mn10300. > > > > > > Signed-off-by: Sudip Mukherjee > > > --- > > > samples/Kconfig | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/samples/Kconfig b/samples/Kconfig > > > index a4c6b2f..20c55af 100644 > > > --- a/samples/Kconfig > > > +++ b/samples/Kconfig > > > @@ -57,7 +57,7 @@ config SAMPLE_KDB > > > > > > config SAMPLE_KDBUS > > > bool "Build kdbus API example" > > > - depends on KDBUS > > > + depends on KDBUS && !MN10300 > > > > Why not just add the memfd syscall to this arch? > Yes, I intend to. But for now this will fix allmodconfig. > >I thought someone had already sent such a patch in a while ago. > Then it is still not merged. :( > I will try to find that patch adding memfd syscall. And if i find it whom > shall I forward it to? The maintainers of this arch. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/7] samples: kdbus: disable for mn10300
On Thu, Jun 18, 2015 at 07:39:58AM -0700, Greg Kroah-Hartman wrote: > On Thu, Jun 18, 2015 at 05:47:51PM +0530, Sudip Mukherjee wrote: > > While building it failed with: > > In function 'prime_new': > > error: '__NR_memfd_create' undeclared (first use in this function) > > > > memfd_create syscall has not yet been implemented for mn10300. > > so disable compilation of samples/kdbus for now with mn10300. > > > > Signed-off-by: Sudip Mukherjee > > --- > > samples/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/samples/Kconfig b/samples/Kconfig > > index a4c6b2f..20c55af 100644 > > --- a/samples/Kconfig > > +++ b/samples/Kconfig > > @@ -57,7 +57,7 @@ config SAMPLE_KDB > > > > config SAMPLE_KDBUS > > bool "Build kdbus API example" > > - depends on KDBUS > > + depends on KDBUS && !MN10300 > > Why not just add the memfd syscall to this arch? Yes, I intend to. But for now this will fix allmodconfig. >I thought someone had already sent such a patch in a while ago. Then it is still not merged. :( I will try to find that patch adding memfd syscall. And if i find it whom shall I forward it to? regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] fix build failure of mn10300
On Thu, Jun 18, 2015 at 03:51:38PM +0100, Russell King - ARM Linux wrote:
> On Thu, Jun 18, 2015 at 05:47:46PM +0530, Sudip Mukherjee wrote:
> > This is an attempt to fix the build failures when building mn10300 with
> > allmodconfig. As I have never worked with arch files so I hope you will
> > point me to right direction to correct my mistakes in this attempt.
>
> Why has the linux-arm-kernel mailing list been copied for something
> which clearly has nothing to do with ARM? Am I missing something
> in this series?
get_maintainer.pl is giving linux-arm-kernel mailing list for
patch 3/7 ("mmc: mediatek: build as module").
regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linux-am33-list] [PATCH v2 0/7] fix build failure of mn10300
On Thu, Jun 18, 2015 at 10:31:07AM -0500, Jay C. Polmar wrote: > I am on this list by mistake and 5/15/2011 we requested to be removed, > can someone remove me from this list? There are six mailing lists in the Cc line. For all of the lists present there, I can't help you, but you should be able to unsubscribe yourself. Look at the footer on any message you receive from the list and it should tell you how to get more information on that subject. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH v3] mmc: sleep notification
Hi Ulf,
> -Original Message-
> From: Ulf Hansson [mailto:ulf.hans...@linaro.org]
> Sent: Monday, June 15, 2015 11:24 AM
> To: Alex Lemberg
> Cc: Avi Shchislowski; linux-mmc
> Subject: Re: [RFC PATCH v3] mmc: sleep notification
>
> On 8 June 2015 at 15:17, Alex Lemberg
> wrote:
> > Hi Ulf,
> >
> > [...]
> >
> >>
> >> One of my comments for v2, was that I think you should remove all
> >> code which was related to HPI to interrupt sleep notification from
> >> the runtime PM resume path. Instead I wanted you to add that
> >> functionality as separate patch based on top of this patch.
> >>
> >> You haven't done that in v3, why?
> >
> > The sleep_notify call was moved to suspend() per your recommendation.
> > As far as I understand, no new requests should be sent during
> > mmc_suspend() process, thus HPI support is not needed anymore.
> > Is this the correct assumption?
>
> Yes.
>
> I don't think you need mmc_card_set_sleep_notify() and the corresponding
> new MMC_STATE_SLEEP_NOTIFY , mmc_device_prg_state(), etc.
mmc_card_set_sleep_notify(), MMC_STATE_SLEEP_NOTIFY and the corresponding - We
are removing it from the current patch. Probably will add them as a separate
patch in future.
mmc_device_prg_state() - is required for waiting for Sleep_Notification
completion/timeout, although we would like to leave this function.
>
> Overall, I think this patch could be simplified yet another step.
>
> > The only case where HPI is used in this patch - is during sleep_notify
> timeout error.
>
> Why?
In case of timeout error, we would like to handle it by sending HPI - to let
device interrupt/stop the prg state.
>
> One final question, I noticed that you have removed the check for
> MMC_CAP2_FULL_PWR_CYCLE in the _mmc_suspend() function, why?
As far as we understand, this MMC_CAP2_FULL_PWR_CYCLE was used to distinguish
between PON (when the power can be cut)
and Sleep (when the power have to stay ON).
Now we have Sleep_Notification PON, which allows to cut the power also in case
of Sleep.
Hope the interpretation above is correct.
>
> Kind regards
> Uffe
N�r��yb�X��ǧv�^�){.n�+{��g"��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: [PATCH v2 0/7] fix build failure of mn10300
On Thu, Jun 18, 2015 at 05:47:46PM +0530, Sudip Mukherjee wrote: > This is an attempt to fix the build failures when building mn10300 with > allmodconfig. As I have never worked with arch files so I hope you will > point me to right direction to correct my mistakes in this attempt. Why has the linux-arm-kernel mailing list been copied for something which clearly has nothing to do with ARM? Am I missing something in this series? (Or is there a competition on to see who can add as many entries in the Cc without getting caught by any filtering? :) ) -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/7] samples: kdbus: disable for mn10300
On Thu, Jun 18, 2015 at 05:47:51PM +0530, Sudip Mukherjee wrote: > While building it failed with: > In function 'prime_new': > error: '__NR_memfd_create' undeclared (first use in this function) > > memfd_create syscall has not yet been implemented for mn10300. > so disable compilation of samples/kdbus for now with mn10300. > > Signed-off-by: Sudip Mukherjee > --- > samples/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/samples/Kconfig b/samples/Kconfig > index a4c6b2f..20c55af 100644 > --- a/samples/Kconfig > +++ b/samples/Kconfig > @@ -57,7 +57,7 @@ config SAMPLE_KDB > > config SAMPLE_KDBUS > bool "Build kdbus API example" > - depends on KDBUS > + depends on KDBUS && !MN10300 Why not just add the memfd syscall to this arch? I thought someone had already sent such a patch in a while ago. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mmc: core: Do not set mmc voltage to 1.8V when 'no-1-8-v' is present
On Thu, Jun 18, 2015 at 09:58:43AM +0200, Ulf Hansson wrote: > On 17 June 2015 at 18:25, Fabio Estevam wrote: > > Hi Ulf, > > > > On Tue, Jun 16, 2015 at 6:31 AM, Ulf Hansson wrote: > > > >> I had a closer look, should have done that before. > >> > >> I think we need to decide what "no-1-8-v" should be used for. > >> Currently the DT documentation is unclear and depending on what SDHCI > >> variant, the binding has different purpose. It's a mess! > > > > Thanks for your feedback. > > > >> > >> sdhci-pltfm + sdhci-esdhc-imx use the "no-1-8-v" DT binding to enable > >> the SDHCI_QUIRK2_NO_1_8_V. The sdhci driver uses this quirk to mask > >> the bus speed modes for SD UHS cards. > >> > >> In this regards, consider the two below options. > >> > >> 1) We have DT bindings for SD UHS speed modes, which somehow makes the > >> "no-1-8-v" binding redundant (or deprecated). > >> > >> 2) If you can model the VCCQ power supply as as a regulator, you could > >> use regulator_is_supported_voltage() API to find out similar > >> information used to set SDHCI_QUIRK2_NO_1_8_V. In fact, sdhci already > >> does that to mask MMC_CAP2_HSX00_1_2V, unless 1.2V is supported. > >> > >> In a third case, sdhci-pxav3 use the "no-1-8-v" DT binding to mask > >> SDHCI_CAN_VDD_180/SDHCI_CAN_VDD_330, which seems wrong, as it has > >> nothing to do with the power to the card (VMMC). It's also used it to > >> mask MMC_CAP_1_8V_DDR. > >> > >> The summary, is that I would rather see us to move away from using the > >> "no-1-8-v" DT binding and use the proper SD UHS bus speed modes > >> binding instead. > > > > Makes sense indeed. > > > > The challenge here is that we still need to keep the old dtb's working. > > We need to keep something that's been "broken" for ever to keep > working. Huh, it prevents us from doing the correct solution. :-( > > How hard is it to update the DTBs in these cases? > > > > > Motivation for this patch was a custom mx6sl board that works fine > > with 3.14, but after upgrading the kernel to 4.0 the eMMC no longer > > can mount the rootfs. This is a regression caused by commit > > 312449efd16bb06, which applies 1.8V to the eMMC card that can only > > operate at 3.3V. > > > > Same thing happens on imx6q-sabresd: we have 3.3V voltage being > > supplied to the eMMC, but now we are operating it at 1.8V, even though > > if we have 'no-1-8-v' property in the device tree. > > > > While I understand the need for improvement that you clearly > > described, I would also like that the old dtb's could still work > > 'as-is' with a modern kernel. > > > > The path I propose here was the minimal invasive method I could come > > up to allow the old dtb compatibility. > > No, I don't want to sprinkle the core with hacks to make host driver > works. Those hacks will have to reside in host drivers instead. > > Unless updating the DTB is out of the questions I suggest the > following instead. > > 1) > Let's add MMC_CAP_3V_DDR and a corresponding DT binding for it. Adopt > mmc_select_hs_ddr() and mmc_select_card_type() to know about this > configuration. > Yes, that's probably a quirk way to fix the issue. Host needs to consider the DDR mode support for both 3V and 1.8v way. If host does not support 1.8V VIO but it supports DDR, then we only claim 3V DDR support. It may be something like the treating way of MMC_CAP2_HSX00_1_2V in sdhci.c. > 2) > If we can assume that "no-1-8-v" for sdhci has the meaning of enabling > MMC_CAP_3V_DDR, let's do that parsing in > drivers/mmc/host/sdhci-pltfm.c. > For me, no-1-8-v may be better only reflect the host VIO capability, no DDR functionality. > 3) > Update the DT documentation to better describe the "no-1-8-v" binding. > Let's also move it to be a sdhci specific binding and not a generic > mmc binding, to limit its use. > > 4) > Update the DTB files in the kernel for imx to use new binding for > MMC_CAP_3V_DDR where applicable. Moreover convert the DTB for imx to > use the proper bindings for UHS bus speed modes. Thus imx should have > moved away from the "no-1-8-v" for future DTB updates. > Yes, i agree from a long term, we should move away from no-1-8-v since no-1-8-v is not well defined. Another issue of this way is that how about host also not support 1.2v? no-1-2-v? One different option for a long term fix may be adding VIO capability in device tree. Then each host could claim it's VIO capability in device tree. Then Host driver could select the correct DDR/UHS/HSxx mode based on VIO capability. Regards Dong Aisheng > Kind regards > Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mmc: core: Do not set mmc voltage to 1.8V when 'no-1-8-v' is present
On Tue, Jun 16, 2015 at 11:31:50AM +0200, Ulf Hansson wrote:
> On 15 June 2015 at 14:49, Fabio Estevam wrote:
> > On Mon, Jun 15, 2015 at 9:23 AM, Fabio Estevam wrote:
> >> Hi Ulf,
> >>
> >> On Mon, Jun 15, 2015 at 9:08 AM, Ulf Hansson
> >> wrote:
> >>
> >>> What card (eMMC, SD, MMC) and which host driver is being used here?
> >>
> >> It is an eMMC and the host driver is sdhci-esdhc-imx.c.
> >>
> --- a/drivers/mmc/core/host.c
> +++ b/drivers/mmc/core/host.c
> @@ -527,6 +527,8 @@ int mmc_of_parse(struct mmc_host *host)
> host->caps2 |= MMC_CAP2_HS400_1_8V |
> MMC_CAP2_HS200_1_8V_SDR;
> if (of_find_property(np, "mmc-hs400-1_2v", &len))
> host->caps2 |= MMC_CAP2_HS400_1_2V |
> MMC_CAP2_HS200_1_2V_SDR;
> + if (of_find_property(np, "no-1-8-v", &len))
> + host->caps2 |= MMC_CAP_3_3V_ONLY_DDR;
> >>>
> >>> Do you intend to use 3.3V as the I/O voltage level for an eMMCs
> >>> running in DDR mode? Isn't that violation of the eMMC spec?
> >>
> >> Yes, I would like to use 3.3V as the I/O voltage level for an eMMC in DDR
> >> mode.
> >>
> >> This was the behaviour prior to 312449efd16bb0, which I would like to
> >> keep so that our custom board based on mx6sl could work. It works fine
> >> with 3.14 kernel, but not on 4.1-rc due to the fact that the board
> >> cannot provide 1.8V level, hence 'no-1-8-v' property is passed in the
> >> device tree. With this patch applied 3.3V is applied and the eMMC can
> >> successfully operate in 3.3V DDR mode.
>
> I had a closer look, should have done that before.
>
> I think we need to decide what "no-1-8-v" should be used for.
> Currently the DT documentation is unclear and depending on what SDHCI
> variant, the binding has different purpose. It's a mess!
>
That's true!
> sdhci-pltfm + sdhci-esdhc-imx use the "no-1-8-v" DT binding to enable
> the SDHCI_QUIRK2_NO_1_8_V. The sdhci driver uses this quirk to mask
> the bus speed modes for SD UHS cards.
>
> In this regards, consider the two below options.
>
> 1) We have DT bindings for SD UHS speed modes, which somehow makes the
> "no-1-8-v" binding redundant (or deprecated).
>
> 2) If you can model the VCCQ power supply as as a regulator, you could
> use regulator_is_supported_voltage() API to find out similar
> information used to set SDHCI_QUIRK2_NO_1_8_V. In fact, sdhci already
> does that to mask MMC_CAP2_HSX00_1_2V, unless 1.2V is supported.
>
One problem of this way for IMX is that the voltage switch is controlled
by register bit. It may be not suitable to model VCCQ as regualtor.
> In a third case, sdhci-pxav3 use the "no-1-8-v" DT binding to mask
> SDHCI_CAN_VDD_180/SDHCI_CAN_VDD_330, which seems wrong, as it has
> nothing to do with the power to the card (VMMC). It's also used it to
> mask MMC_CAP_1_8V_DDR.
>
> The summary, is that I would rather see us to move away from using the
> "no-1-8-v" DT binding and use the proper SD UHS bus speed modes
> binding instead.
>
One concern of using SD UHS bus speed binding is that we may have to define
all speed mode under the node to support all different kinds of card.
e.g.
Originally it's:
&usdhc3 {
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <&pinctrl_usdhc3>;
pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
bus-width = <8>;
cd-gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
wp-gpios = <&gpio2 15 GPIO_ACTIVE_HIGH>;
keep-power-in-suspend;
enable-sdio-wakeup;
vmmc-supply = <&vcc_sd3>;
status = "okay";
};
Now:
&usdhc3 {
pinctrl-names = "default", "state_100mhz", "state_200mhz";
pinctrl-0 = <&pinctrl_usdhc3>;
pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
bus-width = <8>;
cd-gpios = <&gpio2 10 GPIO_ACTIVE_HIGH>;
wp-gpios = <&gpio2 15 GPIO_ACTIVE_HIGH>;
keep-power-in-suspend;
enable-sdio-wakeup;
vmmc-supply = <&vcc_sd3>;
cap-sd-highspeed;
cap-mmc-highspeed;
sd-uhs-sdr12;
sd-uhs-sdr25;
sd-uhs-sdr50;
sd-uhs-sdr104;
sd-uhs-ddr50;
status = "okay";
};
So the question comes:
1) it adds a lot duplicated things for different host node in device tree
and this increase dts size.
2) do we really need to claim this uhs capability from device tree?
Since it looks to me most is host controller capablity and not board
dependant.
3) those uhs mode defined in device tree may be also conflict with
common sdhci probe/detect function and maybe overwritten later.
If do that, we may need re-structure the common sdhci driver.
> >
> > Also, looked at the eMMC spec and the only restriction I saw about
> > using 3.3V voltage is with HS200 or HS400 devices:
> >
> > "VCCQ (I/O) 3.3 V range is not supported in either HS200 or HS400 devices"
>
> You are correct! We should add a MMC_CAP_3
Re: [PATCH/RFC] mmc: tmio: Fix suspend process
On 14 June 2015 at 19:22, Yoshihiro Kaneko wrote: > From: Koji Matsuoka > > The clock should be enable when SDHI registers are accessed. > > Signed-off-by: Koji Matsuoka > Signed-off-by: Yoshihiro Kaneko > --- > > This patch is based on mmc-next branch of Ulf Hansson's mmc tree. > > * Perhaps this relates to the need to enhance clock management > > drivers/mmc/host/tmio_mmc_pio.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c > index e3dcf31..ec10bcd 100644 > --- a/drivers/mmc/host/tmio_mmc_pio.c > +++ b/drivers/mmc/host/tmio_mmc_pio.c > @@ -1240,7 +1240,9 @@ int tmio_mmc_host_runtime_suspend(struct device *dev) > struct mmc_host *mmc = dev_get_drvdata(dev); > struct tmio_mmc_host *host = mmc_priv(mmc); > > + pm_runtime_get_sync(dev); I don't recommend doing a pm_runtime_get_sync() from your ->runtime_suspend() callback. There a often cases where this can deadlock. Anyway, isn't the clock already enabled here? > tmio_mmc_disable_mmc_irqs(host, TMIO_MASK_ALL); > + pm_runtime_put(dev); > > if (host->clk_cache) > tmio_mmc_clk_stop(host); > -- > 1.9.1 > Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] mmc: mediatek: build as module
On 18 June 2015 at 14:17, Sudip Mukherjee wrote: > while building as module with mn10300 it failed with: > > warning: data definition has no type or storage class > module_init(__driver##_init); > > Signed-off-by: Sudip Mukherjee Thanks for the patch. It's although already been fixed on my next branch. Kind regards Uffe > --- > drivers/mmc/host/mtk-sd.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c > index 7c20f28..ea6ae36 100644 > --- a/drivers/mmc/host/mtk-sd.c > +++ b/drivers/mmc/host/mtk-sd.c > @@ -33,6 +33,7 @@ > #include > #include > #include > +#include > > #define MAX_BD_NUM 1024 > > -- > 1.8.1.2 > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/7] mn10300: Provide dummy dma_alloc_attrs() and dma_free_attrs()
allmodconfig fails to build with following errors.
drivers/media/platform/sti/bdisp/bdisp-hw.c:
In function 'bdisp_hw_free_nodes':
drivers/media/platform/sti/bdisp/bdisp-hw.c:132:3: error:
implicit declaration of function 'dma_free_attrs'
drivers/media/platform/sti/bdisp/bdisp-hw.c:
In function 'bdisp_hw_alloc_nodes':
drivers/media/platform/sti/bdisp/bdisp-hw.c:157:2: error:
implicit declaration of function 'dma_alloc_attrs'
mn10300 does not provide those functions at this time.
Provide dummy implementations to avoid build errors.
Signed-off-by: Sudip Mukherjee
---
copied from https://lkml.org/lkml/2015/4/22/346
arch/mn10300/include/asm/dma-mapping.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/mn10300/include/asm/dma-mapping.h
b/arch/mn10300/include/asm/dma-mapping.h
index a18abfc..d589c5e 100644
--- a/arch/mn10300/include/asm/dma-mapping.h
+++ b/arch/mn10300/include/asm/dma-mapping.h
@@ -183,4 +183,17 @@ static inline int dma_get_sgtable(struct device *dev,
struct sg_table *sgt,
return -EINVAL;
}
+static inline void *dma_alloc_attrs(struct device *dev, size_t size,
+ dma_addr_t *dma_handle, gfp_t flag,
+ struct dma_attrs *attrs)
+{
+ return NULL;
+}
+
+static inline void dma_free_attrs(struct device *dev, size_t size,
+ void *vaddr, dma_addr_t dma_handle,
+ struct dma_attrs *attrs)
+{
+}
+
#endif
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/7] mn10300: kgdb_arch_set_pc
While building it failed with:
undefined reference to `kgdb_arch_set_pc'
Signed-off-by: Sudip Mukherjee
---
arch/mn10300/kernel/kgdb.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/mn10300/kernel/kgdb.c b/arch/mn10300/kernel/kgdb.c
index 9977082..8a0ae2b 100644
--- a/arch/mn10300/kernel/kgdb.c
+++ b/arch/mn10300/kernel/kgdb.c
@@ -499,3 +499,8 @@ void kgdb_roundup_cpus(unsigned long flags)
smp_jump_to_debugger();
}
#endif
+
+void kgdb_arch_set_pc(struct pt_regs *regs, unsigned long ip)
+{
+ regs->pc = ip;
+}
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/7] USB: mos7720: rename DCR
While building with mn10300 it failed with:
error: expected identifier before '(' token
#define __SYSREG(ADDR, TYPE) (*(volatile TYPE *)(ADDR))
note: in expansion of macro '__SYSREG'
#define DCR __SYSREG(0xc030, u16) /* Debug control register */
mn10300 has a register named as DCR, so when this driver used an enum
named as DCR, build failed.
Just rename the DCR in the driver to parport_DCR.
Signed-off-by: Sudip Mukherjee
---
drivers/usb/serial/mos7720.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c
index 4f70df3..3263125 100644
--- a/drivers/usb/serial/mos7720.c
+++ b/drivers/usb/serial/mos7720.c
@@ -135,7 +135,7 @@ enum mos_regs {
DLM,
DPR, /* parallel port regs */
DSR,
- DCR,
+ parport_DCR,
ECR,
SP1_REG, /* device control regs */
SP2_REG, /* serial port 2 (7720 only) */
@@ -164,7 +164,7 @@ static inline __u16 get_reg_index(enum mos_regs reg)
0x01, /* DLM */
0x00, /* DPR */
0x01, /* DSR */
- 0x02, /* DCR */
+ 0x02, /* parport_DCR */
0x0a, /* ECR */
0x01, /* SP1_REG */
0x02, /* SP2_REG (7720 only) */
@@ -510,7 +510,7 @@ static void parport_mos7715_write_control(struct parport
*pp, unsigned char d)
if (parport_prologue(pp) < 0)
return;
data = ((__u8)d & 0x0f) | (mos_parport->shadowDCR & 0xf0);
- write_mos_reg(mos_parport->serial, dummy, DCR, data);
+ write_mos_reg(mos_parport->serial, dummy, parport_DCR, data);
mos_parport->shadowDCR = data;
parport_epilogue(pp);
}
@@ -543,7 +543,7 @@ static unsigned char parport_mos7715_frob_control(struct
parport *pp,
if (parport_prologue(pp) < 0)
return 0;
mos_parport->shadowDCR = (mos_parport->shadowDCR & (~mask)) ^ val;
- write_mos_reg(mos_parport->serial, dummy, DCR, mos_parport->shadowDCR);
+ write_mos_reg(mos_parport->serial, dummy, parport_DCR,
mos_parport->shadowDCR);
dcr = mos_parport->shadowDCR & 0x0f;
parport_epilogue(pp);
return dcr;
@@ -581,7 +581,7 @@ static void parport_mos7715_data_forward(struct parport *pp)
return;
mos7715_change_mode(mos_parport, PS2);
mos_parport->shadowDCR &= ~0x20;
- write_mos_reg(mos_parport->serial, dummy, DCR, mos_parport->shadowDCR);
+ write_mos_reg(mos_parport->serial, dummy, parport_DCR,
mos_parport->shadowDCR);
parport_epilogue(pp);
}
@@ -593,7 +593,7 @@ static void parport_mos7715_data_reverse(struct parport *pp)
return;
mos7715_change_mode(mos_parport, PS2);
mos_parport->shadowDCR |= 0x20;
- write_mos_reg(mos_parport->serial, dummy, DCR, mos_parport->shadowDCR);
+ write_mos_reg(mos_parport->serial, dummy, parport_DCR,
mos_parport->shadowDCR);
parport_epilogue(pp);
}
@@ -633,7 +633,7 @@ static void parport_mos7715_restore_state(struct parport
*pp,
spin_unlock(&release_lock);
return;
}
- write_parport_reg_nonblock(mos_parport, DCR, mos_parport->shadowDCR);
+ write_parport_reg_nonblock(mos_parport, parport_DCR,
mos_parport->shadowDCR);
write_parport_reg_nonblock(mos_parport, ECR, mos_parport->shadowECR);
spin_unlock(&release_lock);
}
@@ -719,7 +719,7 @@ static int mos7715_parport_init(struct usb_serial *serial)
/* initialize device registers */
mos_parport->shadowDCR = DCR_INIT_VAL;
- write_mos_reg(mos_parport->serial, dummy, DCR, mos_parport->shadowDCR);
+ write_mos_reg(mos_parport->serial, dummy, parport_DCR,
mos_parport->shadowDCR);
mos_parport->shadowECR = ECR_INIT_VAL;
write_mos_reg(mos_parport->serial, dummy, ECR, mos_parport->shadowECR);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/7] mn10300: fix build failure
allmodconfig build fails with the error:
invalid use of undefined type 'struct kprobe_ctlblk'
just declared the two basic structures after checking the struct in other
architectures.
Signed-off-by: Sudip Mukherjee
---
arch/mn10300/include/asm/kprobes.h | 12
1 file changed, 12 insertions(+)
diff --git a/arch/mn10300/include/asm/kprobes.h
b/arch/mn10300/include/asm/kprobes.h
index c800b59..c90d2b1 100644
--- a/arch/mn10300/include/asm/kprobes.h
+++ b/arch/mn10300/include/asm/kprobes.h
@@ -47,4 +47,16 @@ extern int kprobe_exceptions_notify(struct notifier_block
*self,
extern void arch_remove_kprobe(struct kprobe *p);
+struct prev_kprobe {
+ struct kprobe *kp;
+ unsigned long status;
+};
+
+struct kprobe_ctlblk {
+ unsigned int kprobe_status;
+ struct pt_regs jprobe_saved_regs;
+ char jprobes_stack[MAX_STACK_SIZE];
+ struct prev_kprobe prev_kprobe;
+};
+
#endif /* _ASM_KPROBES_H */
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/7] mn10300: add early_init_dt_*
While building it failed with:
undefined reference to `early_init_dt_alloc_memory_arch'
undefined reference to `early_init_dt_add_memory_arch'
Added the function after seeing them in x86.
Signed-off-by: Sudip Mukherjee
---
arch/mn10300/kernel/setup.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/mn10300/kernel/setup.c b/arch/mn10300/kernel/setup.c
index 2ad7f32..f0e08b0 100644
--- a/arch/mn10300/kernel/setup.c
+++ b/arch/mn10300/kernel/setup.c
@@ -87,6 +87,21 @@ static int __init early_mem(char *p)
early_param("mem", early_mem);
/*
+ * early_init_dt_add_memory_arch() and early_init_dt_alloc_memory_arch()
+ * borrowed from arch/x86/kernel/devicetree.c
+ */
+
+void __init early_init_dt_add_memory_arch(u64 base, u64 size)
+{
+ BUG();
+}
+
+void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
+{
+ return __alloc_bootmem(size, align, 0);
+}
+
+/*
* architecture specific setup
*/
void __init setup_arch(char **cmdline_p)
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/7] mmc: mediatek: build as module
while building as module with mn10300 it failed with: warning: data definition has no type or storage class module_init(__driver##_init); Signed-off-by: Sudip Mukherjee --- drivers/mmc/host/mtk-sd.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c index 7c20f28..ea6ae36 100644 --- a/drivers/mmc/host/mtk-sd.c +++ b/drivers/mmc/host/mtk-sd.c @@ -33,6 +33,7 @@ #include #include #include +#include #define MAX_BD_NUM 1024 -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/7] samples: kdbus: disable for mn10300
While building it failed with: In function 'prime_new': error: '__NR_memfd_create' undeclared (first use in this function) memfd_create syscall has not yet been implemented for mn10300. so disable compilation of samples/kdbus for now with mn10300. Signed-off-by: Sudip Mukherjee --- samples/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/samples/Kconfig b/samples/Kconfig index a4c6b2f..20c55af 100644 --- a/samples/Kconfig +++ b/samples/Kconfig @@ -57,7 +57,7 @@ config SAMPLE_KDB config SAMPLE_KDBUS bool "Build kdbus API example" - depends on KDBUS + depends on KDBUS && !MN10300 help Build an example of how the kdbus API can be used from userspace. -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] fix build failure of mn10300
Hi, This is an attempt to fix the build failures when building mn10300 with allmodconfig. As I have never worked with arch files so I hope you will point me to right direction to correct my mistakes in this attempt. regards sudip Sudip Mukherjee (7): mn10300: fix build failure mn10300: Provide dummy dma_alloc_attrs() and dma_free_attrs() mmc: mediatek: build as module USB: mos7720: rename DCR samples: kdbus: disable for mn10300 mn10300: kgdb_arch_set_pc mn10300: add early_init_dt_* arch/mn10300/include/asm/dma-mapping.h | 13 + arch/mn10300/include/asm/kprobes.h | 12 arch/mn10300/kernel/kgdb.c | 5 + arch/mn10300/kernel/setup.c| 15 +++ drivers/mmc/host/mtk-sd.c | 1 + drivers/usb/serial/mos7720.c | 16 samples/Kconfig| 2 +- 7 files changed, 55 insertions(+), 9 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mmc: core: Do not set mmc voltage to 1.8V when 'no-1-8-v' is present
On 17 June 2015 at 18:25, Fabio Estevam wrote: > Hi Ulf, > > On Tue, Jun 16, 2015 at 6:31 AM, Ulf Hansson wrote: > >> I had a closer look, should have done that before. >> >> I think we need to decide what "no-1-8-v" should be used for. >> Currently the DT documentation is unclear and depending on what SDHCI >> variant, the binding has different purpose. It's a mess! > > Thanks for your feedback. > >> >> sdhci-pltfm + sdhci-esdhc-imx use the "no-1-8-v" DT binding to enable >> the SDHCI_QUIRK2_NO_1_8_V. The sdhci driver uses this quirk to mask >> the bus speed modes for SD UHS cards. >> >> In this regards, consider the two below options. >> >> 1) We have DT bindings for SD UHS speed modes, which somehow makes the >> "no-1-8-v" binding redundant (or deprecated). >> >> 2) If you can model the VCCQ power supply as as a regulator, you could >> use regulator_is_supported_voltage() API to find out similar >> information used to set SDHCI_QUIRK2_NO_1_8_V. In fact, sdhci already >> does that to mask MMC_CAP2_HSX00_1_2V, unless 1.2V is supported. >> >> In a third case, sdhci-pxav3 use the "no-1-8-v" DT binding to mask >> SDHCI_CAN_VDD_180/SDHCI_CAN_VDD_330, which seems wrong, as it has >> nothing to do with the power to the card (VMMC). It's also used it to >> mask MMC_CAP_1_8V_DDR. >> >> The summary, is that I would rather see us to move away from using the >> "no-1-8-v" DT binding and use the proper SD UHS bus speed modes >> binding instead. > > Makes sense indeed. > > The challenge here is that we still need to keep the old dtb's working. We need to keep something that's been "broken" for ever to keep working. Huh, it prevents us from doing the correct solution. :-( How hard is it to update the DTBs in these cases? > > Motivation for this patch was a custom mx6sl board that works fine > with 3.14, but after upgrading the kernel to 4.0 the eMMC no longer > can mount the rootfs. This is a regression caused by commit > 312449efd16bb06, which applies 1.8V to the eMMC card that can only > operate at 3.3V. > > Same thing happens on imx6q-sabresd: we have 3.3V voltage being > supplied to the eMMC, but now we are operating it at 1.8V, even though > if we have 'no-1-8-v' property in the device tree. > > While I understand the need for improvement that you clearly > described, I would also like that the old dtb's could still work > 'as-is' with a modern kernel. > > The path I propose here was the minimal invasive method I could come > up to allow the old dtb compatibility. No, I don't want to sprinkle the core with hacks to make host driver works. Those hacks will have to reside in host drivers instead. Unless updating the DTB is out of the questions I suggest the following instead. 1) Let's add MMC_CAP_3V_DDR and a corresponding DT binding for it. Adopt mmc_select_hs_ddr() and mmc_select_card_type() to know about this configuration. 2) If we can assume that "no-1-8-v" for sdhci has the meaning of enabling MMC_CAP_3V_DDR, let's do that parsing in drivers/mmc/host/sdhci-pltfm.c. 3) Update the DT documentation to better describe the "no-1-8-v" binding. Let's also move it to be a sdhci specific binding and not a generic mmc binding, to limit its use. 4) Update the DTB files in the kernel for imx to use new binding for MMC_CAP_3V_DDR where applicable. Moreover convert the DTB for imx to use the proper bindings for UHS bus speed modes. Thus imx should have moved away from the "no-1-8-v" for future DTB updates. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: mmc: sdhci: update max frequency only if undefined
Hi,
On Thu, Jun 18, 2015 at 12:59 PM, Dong Aisheng wrote:
> On Thu, Jun 18, 2015 at 12:57:07PM +0530, Suneel Garapati wrote:
>> f_max parameter of mmc structure is updated unconditionally.
>> If dt property max-frequency is assigned, this update is
>> overwriting the dt property value which is undesired.
>>
>> Signed-off-by: Suneel Garapati
>> ---
>> drivers/mmc/host/sdhci.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index bc14452..c2917d5 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -3047,7 +3047,10 @@ int sdhci_add_host(struct sdhci_host *host)
>>* Set host parameters.
>>*/
>> mmc->ops = &sdhci_ops;
>> - mmc->f_max = host->max_clk;
>> +
>> + if(!mmc->f_max)
>> + mmc->f_max = host->max_clk;
>> +
>
> This is probably not going to work properly.
> mmc->f_max will be overwritten again if host->clk_mul enabled.
> And you did not do sanity check if f_max from device tree is valid.
>
> Please see:
> http://www.spinics.net/lists/arm-kernel/msg426167.html
> I already sent a proper fix.
Ok, I missed your series.
My platform doesn't have clk_mul enabled hence couldn't check on that.
Agree on the sanity check.
Regards,
Suneel
>
> Regards
> Dong Aisheng
>
>> if (host->ops->get_min_clock)
>> mmc->f_min = host->ops->get_min_clock(host);
>> else if (host->version >= SDHCI_SPEC_300) {
>> --
>> 2.1.2
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers: mmc: sdhci: update max frequency only if undefined
f_max parameter of mmc structure is updated unconditionally.
If dt property max-frequency is assigned, this update is
overwriting the dt property value which is undesired.
Signed-off-by: Suneel Garapati
---
drivers/mmc/host/sdhci.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index bc14452..c2917d5 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -3047,7 +3047,10 @@ int sdhci_add_host(struct sdhci_host *host)
* Set host parameters.
*/
mmc->ops = &sdhci_ops;
- mmc->f_max = host->max_clk;
+
+ if(!mmc->f_max)
+ mmc->f_max = host->max_clk;
+
if (host->ops->get_min_clock)
mmc->f_min = host->ops->get_min_clock(host);
else if (host->version >= SDHCI_SPEC_300) {
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: mmc: sdhci: update max frequency only if undefined
On Thu, Jun 18, 2015 at 12:57:07PM +0530, Suneel Garapati wrote:
> f_max parameter of mmc structure is updated unconditionally.
> If dt property max-frequency is assigned, this update is
> overwriting the dt property value which is undesired.
>
> Signed-off-by: Suneel Garapati
> ---
> drivers/mmc/host/sdhci.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index bc14452..c2917d5 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -3047,7 +3047,10 @@ int sdhci_add_host(struct sdhci_host *host)
>* Set host parameters.
>*/
> mmc->ops = &sdhci_ops;
> - mmc->f_max = host->max_clk;
> +
> + if(!mmc->f_max)
> + mmc->f_max = host->max_clk;
> +
This is probably not going to work properly.
mmc->f_max will be overwritten again if host->clk_mul enabled.
And you did not do sanity check if f_max from device tree is valid.
Please see:
http://www.spinics.net/lists/arm-kernel/msg426167.html
I already sent a proper fix.
Regards
Dong Aisheng
> if (host->ops->get_min_clock)
> mmc->f_min = host->ops->get_min_clock(host);
> else if (host->version >= SDHCI_SPEC_300) {
> --
> 2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/7] Add Mediatek MMC driver
On 17 June 2015 at 23:01, Paul Gortmaker wrote: > On Tue, Jun 16, 2015 at 4:03 AM, Ulf Hansson wrote: >> On 15 June 2015 at 13:20, Chaotian Jing wrote: >>> This series enables MMC support on the MT8135/MT8173 platform. >>> MT8135 has 5 MMC controllers and MT8173 has 4 MMC controllers. >>> >>> Changes base on Ulf's comments >>> Make hclk mandatory in the driver code >>> Change host->hclk to host->src_clk_freq >>> Add linux/pm.h >>> >>> Chaotian Jing (3): >>> mmc: dt-bindings: add Mediatek MMC bindings >>> mmc: mediatek: Add Mediatek MMC driver. > > This commit breaks when merged to linux-next since it gets > exposed as an implicit module.h user that does not include > that header: > >drivers/mmc/host/mtk-sd.c:1459:1: note: in expansion of macro > 'module_platform_driver' > module_platform_driver(mt_msdc_driver); > ^ >include/linux/device.h:1296:1: error: type defaults to 'int' in > declaration of 'module_init' [-Werror=implicit-int] > module_init(__driver##_init); \ > ^ > > Since the code doesn't exist in mainline, I can't fix it from > within my header cleanup series, so can you please add > an appropriate include of module.h to the above? > > Also, I noticed the Makefile addition from this commit > is whitespace mangled; might as well fix that too if > rebasing to fix the include problem. > > Thanks, > Paul. Paul, appreciate your feedback! I have re-based my next branch and updated the commit according to your suggestions. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
