* [PATCH 1/2] ARM: move flexcan1 configuration to hummingboard
From: Shawn Guo @ 2014-01-19 3:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1W3rab-00009u-5I@rmk-PC.arm.linux.org.uk>
On Thu, Jan 16, 2014 at 06:22:49PM +0000, Russell King wrote:
> Flexcan1 is not used on the cubox-i, so move it out of the microsom.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The patch will not apply against the branch/tag - imx-dt-3.14 I'm
sending to arm-soc. Please re-generate it against the tag.
Acked-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> arch/arm/boot/dts/imx6dl-hummingboard.dts | 13 +++++++++++++
> arch/arm/boot/dts/imx6qdl-microsom.dtsi | 13 -------------
> 2 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6dl-hummingboard.dts b/arch/arm/boot/dts/imx6dl-hummingboard.dts
> index 6184b0366926..e22f3d855c02 100644
> --- a/arch/arm/boot/dts/imx6dl-hummingboard.dts
> +++ b/arch/arm/boot/dts/imx6dl-hummingboard.dts
> @@ -36,6 +36,12 @@
> };
> };
>
> +&can1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hummingboard_flexcan1>;
> + status = "okay";
> +};
> +
> &i2c1 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_i2c1_1>;
> @@ -53,6 +59,13 @@
>
> &iomuxc {
> hummingboard {
> + pinctrl_hummingboard_flexcan1: hummingboard-flexcan1 {
> + fsl,pins = <
> + MX6QDL_PAD_SD3_CLK__FLEXCAN1_RX 0x80000000
> + MX6QDL_PAD_SD3_CMD__FLEXCAN1_TX 0x80000000
> + >;
> + };
> +
> pinctrl_hummingboard_gpio1_2: hummingboard-gpio1_2 {
> fsl,pins = <
> MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x80000000
> diff --git a/arch/arm/boot/dts/imx6qdl-microsom.dtsi b/arch/arm/boot/dts/imx6qdl-microsom.dtsi
> index 8aa31a842236..965ac4c1f509 100644
> --- a/arch/arm/boot/dts/imx6qdl-microsom.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-microsom.dtsi
> @@ -36,21 +36,8 @@
> };
> };
>
> -&can1 {
> - pinctrl-names = "default";
> - pinctrl-0 = <&pinctrl_microsom_flexcan1>;
> - status = "okay";
> -};
> -
> &iomuxc {
> microsom {
> - pinctrl_microsom_flexcan1: microsom-flexcan1 {
> - fsl,pins = <
> - MX6QDL_PAD_SD3_CLK__FLEXCAN1_RX 0x80000000
> - MX6QDL_PAD_SD3_CMD__FLEXCAN1_TX 0x80000000
> - >;
> - };
> -
> pinctrl_microsom_usbotg: microsom-usbotg {
> /*
> * Similar to pinctrl_usbotg_2, but we want it
> --
> 1.8.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* imx6 eSATA
From: Shawn Guo @ 2014-01-19 4:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140118184427.GJ15937@n2100.arm.linux.org.uk>
Copy Richard who might be better to clarify.
Shawn
On Sat, Jan 18, 2014 at 06:44:27PM +0000, Russell King - ARM Linux wrote:
> So, I see we have AHCI support for SATA on the iMX6. Great... but it
> doesn't work on the cubox-i, because the phy settings are wrong.
>
> The Cubox-i requires GPR13 set to 0x0593A044 - I haven't decoded what
> this means yet, but it's different from the 0x0593E4A4 which is
> currently hard-coded into the driver (and I've independently tested
> that this is indeed required.)
>
> So, there's presently no DT properties for this - given that these
> parameters would be board specific, it surprises me that this has not
> been thought about, and properties already generated, because now it
> means that we need to _add_ new properties to this driver.
>
> Also, this PDDQ mode thing, which can't be recovered except by reset.
> This is another illustration why Linux is unfriendly - the thing can
> silently go into this power down mode which is irrecoverable without
> any messages being generated nor any hints how to avoid it - maybe
> this should also be a DT property, not just a command line option.
>
> More importantly, maybe we should print a message when we discover
> that there's nothing connected and we're going to enter this mode -
> maybe something like this:
>
> diff --git a/drivers/ata/ahci_imx.c b/drivers/ata/ahci_imx.c
> index 3e23e9941dad..0a1ae7213992 100644
> --- a/drivers/ata/ahci_imx.c
> +++ b/drivers/ata/ahci_imx.c
> @@ -77,6 +77,10 @@ static void ahci_imx_error_handler(struct ata_port *ap)
> !IMX6Q_GPR13_SATA_MPLL_CLK_EN);
> clk_disable_unprepare(imxpriv->sata_ref_clk);
> imxpriv->no_device = true;
> +
> + dev_info(ap->dev, "no device, link disabled until next reset.\n");
> + dev_info(ap->dev, "pass " MODULE_PARAM_PREFIX
> + ".hotplug=1 to enable link hotplug support\n");
> }
>
> static struct ata_port_operations ahci_imx_ops = {
>
>
> --
> FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
> in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
> Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* imx6 eSATA
From: Shawn Guo @ 2014-01-19 4:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140118211119.GA6618@n2100.arm.linux.org.uk>
On Sat, Jan 18, 2014 at 09:11:19PM +0000, Russell King - ARM Linux wrote:
> Sigh. You can't get rid of the of_node there because it's needed
> for clk_get() inside ahci_platform.c. So, I think ahci_platform needs
> to become yet another library, and thereby avoid creating a child
> platform device.
Yes, you're right. This has been discussed for a while [1].
Shawn
[1] http://thread.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/4835/focus=4909
^ permalink raw reply
* [RFC v3 01/13] libahci: Allow drivers to override start_engine
From: Tejun Heo @ 2014-01-19 4:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390088935-7193-2-git-send-email-hdegoede@redhat.com>
Hello, Hans.
On Sun, Jan 19, 2014 at 12:48:43AM +0100, Hans de Goede wrote:
> void ahci_start_engine(struct ata_port *ap)
> {
> void __iomem *port_mmio = ahci_port_base(ap);
> + struct ahci_host_priv *hpriv = ap->host->private_data;
> u32 tmp;
>
> + if (hpriv->start_engine) {
> + hpriv->start_engine(ap);
> + return;
> + }
> +
I'd much prefer if the driver always calls hpriv->start_engine() which
is initialized to the default callback during common init and then
overridden if necessary.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH] arch_timer: Move delay timer to drivers clocksource
From: Antti Miettinen @ 2014-01-19 5:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D932B5.7020909@nvidia.com>
Prashant Gaikwad <pgaikwad@nvidia.com> writes:
> For some idle states it may be required to change the timer when
> entering idle state to adjust the exit latency.
Would it work to set up a separate software timer to account for the
exit latency?
--Antti
^ permalink raw reply
* [PATCH] clk: export __clk_get_hw for re-use in others
From: SeongJae Park @ 2014-01-19 5:55 UTC (permalink / raw)
To: linux-arm-kernel
Following build comes while modprobe process:
> ERROR: "__clk_get_hw" [drivers/clk/clk-max77686.ko] undefined!
> make[2]: *** [__modpost] Error 1
> make[1]: *** [modules] Error 2
Export the symbol to fix it and for other part's usecase.
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
drivers/clk/clk.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 2b38dc9..3883fba 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -575,6 +575,7 @@ struct clk_hw *__clk_get_hw(struct clk *clk)
{
return !clk ? NULL : clk->hw;
}
+EXPORT_SYMBOL_GPL(__clk_get_hw);
u8 __clk_get_num_parents(struct clk *clk)
{
--
1.8.3.2
^ permalink raw reply related
* [PATCH 00/12] ARM: dts: sbc-t3x: add support for more boards
From: Dmitry Lifshitz @ 2014-01-19 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389532975-28281-1-git-send-email-lifshitz@compulab.co.il>
This is the fixed cover letter.
The previous one was not consistent with respect to the actual path set.
Add support for CompuLab SBC-T3530 and SBC-T3517 boards:
https://compulab.co.il/products/sbcs/sbc-t3530/
https://compulab.co.il/products/sbcs/sbc-t3517/
along with respective CoMs - CM-T3530 and CM-T3517:
https://compulab.co.il/products/computer-on-modules/cm-t3530/
https://compulab.co.il/products/computer-on-modules/cm-t3517/
The device tree files have the following structure:
omap3-cm-t3x.dtsi
|
|<-- omap3-cm-t3x30.dtsi
| |
| |
| | ----- ------- ------------
| | | CoM | | Board | | Base board |
| | ----- ------- ------------
| | omap3-sb-t35.dtsi
| | |
| |<-- omap3-cm-t3730.dts <-- omap3-sbc-t3730.dts -->|
| | |
| |<-- omap3-cm-t3530.dts <-- omap3-sbc-t3530.dts -->|
| |
|<-------- omap3-cm-t3517.dts <-- omap3-sbc-t3517.dts -->|
where omap3-cm-t3730.dts, omap3-cm-t3530.dts, omap3-cm-t3517.dts
contain CoMs specific data, while omap3-sbc-t3730.dts, omap3-sbc-t3530.dts,
omap3-sbc-t3517.dts represent eval boards with respective core modules.
This series is based on Tony's omap-for-v3.14/dt branch
Dmitry Lifshitz (12):
ARM: dts: sbc-t3x: use omap specific pinctrl defines
ARM: dts: sbc-t3x: refactor DT support
ARM: dts: sbc-t3x: disable mmc3
ARM: dts: sb-t35: fix Ethernet power supply
ARM: dts: cm-t3x: add gpio-led pinmux
ARM: dts: cm-t3x30: add twl4030 gpio pullups
ARM: dts: cm-t3x30: add HS USB Host support
ARM: dts: sbc-t3730: add pinmux for usb hub reset
ARM: dts: cm-t3x30: add USB OTG support
ARM: dts: sbc-t3530: add support for sbc-t3530
ARM: dts: sbc-t3517: add support for sbc-t3517
ARM: OMAP2+: make reset pulse for sbc-t3x usb hubs
arch/arm/boot/dts/Makefile | 4 +
arch/arm/boot/dts/omap3-cm-t3517.dts | 136 +++++++++++++++++++++++++++++++++
arch/arm/boot/dts/omap3-cm-t3530.dts | 12 +++
arch/arm/boot/dts/omap3-cm-t3730.dts | 57 ++------------
arch/arm/boot/dts/omap3-cm-t3x.dtsi | 110 ++++++++++++++++++++++++++
arch/arm/boot/dts/omap3-cm-t3x30.dtsi | 74 +++++++++++++-----
arch/arm/boot/dts/omap3-sb-t35.dtsi | 29 +++++++-
arch/arm/boot/dts/omap3-sbc-t3517.dts | 43 ++++++++++
arch/arm/boot/dts/omap3-sbc-t3530.dts | 36 +++++++++
arch/arm/boot/dts/omap3-sbc-t3730.dts | 23 +++---
arch/arm/mach-omap2/pdata-quirks.c | 67 ++++++++++++++++-
11 files changed, 506 insertions(+), 85 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-cm-t3517.dts
create mode 100644 arch/arm/boot/dts/omap3-cm-t3530.dts
create mode 100644 arch/arm/boot/dts/omap3-cm-t3x.dtsi
create mode 100644 arch/arm/boot/dts/omap3-sbc-t3517.dts
create mode 100644 arch/arm/boot/dts/omap3-sbc-t3530.dts
--
1.7.5.4
^ permalink raw reply
* [PATCH] mmc: omap_hsmmc: Restrict compilation to ARM
From: Geert Uytterhoeven @ 2014-01-19 9:29 UTC (permalink / raw)
To: linux-arm-kernel
commit bcf24e1daa94f4c52ef7a3f657e43cc6bc50d46b ("mmc: omap_hsmmc: use the
generic config for omap2plus devices"), enabled the build for other
platforms for compile testing.
sh-allmodconfig now fails with:
include/linux/omap-dma.h:171:8: error: expected identifier before numeric constant
make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1
This happens because sh #defines "CCR", which is one of the enum values in
include/linux/omap-dma.h.
I expect a similar failure on blackfin, which also has #define CCR.
Restrict the build to ARM to fix this.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
http://kisskb.ellerman.id.au/kisskb/buildresult/10477672/
drivers/mmc/host/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 7fc5099e44b2..14e94fb39164 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -284,7 +284,7 @@ config MMC_OMAP
config MMC_OMAP_HS
tristate "TI OMAP High Speed Multimedia Card Interface support"
- depends on ARCH_OMAP2PLUS || COMPILE_TEST
+ depends on ARCH_OMAP2PLUS || (COMPILE_TEST && ARM)
help
This selects the TI OMAP High Speed Multimedia card Interface.
If you have an omap2plus board with a Multimedia Card slot,
--
1.7.9.5
^ permalink raw reply related
* [RFC v3 00/13] ahci: add sunxi driver and cleanup imx driver
From: Russell King - ARM Linux @ 2014-01-19 9:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390088935-7193-1-git-send-email-hdegoede@redhat.com>
On Sun, Jan 19, 2014 at 12:48:42AM +0100, Hans de Goede wrote:
> Hi All,
>
> Here is v3 of my patchset for adding ahci-sunxi support. It has grown quite
> a bit since I've been going for a more generic approach this time and I've
> also cleaned up the ahci-imx driver to use the same generic approach.
If you want to avoid getting caught in dwmw2's moderation queue, then
please use "[PATCH RFC" and not just "[RFC" for threaded patches. The
important bit is the "[PATCH" bit. Thanks.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] mmc: omap_hsmmc: Restrict compilation to ARM
From: Russell King - ARM Linux @ 2014-01-19 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390123794-26401-1-git-send-email-geert@linux-m68k.org>
On Sun, Jan 19, 2014 at 10:29:54AM +0100, Geert Uytterhoeven wrote:
> commit bcf24e1daa94f4c52ef7a3f657e43cc6bc50d46b ("mmc: omap_hsmmc: use the
> generic config for omap2plus devices"), enabled the build for other
> platforms for compile testing.
>
> sh-allmodconfig now fails with:
>
> include/linux/omap-dma.h:171:8: error: expected identifier before numeric constant
> make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1
>
> This happens because sh #defines "CCR", which is one of the enum values in
> include/linux/omap-dma.h.
>
> I expect a similar failure on blackfin, which also has #define CCR.
>
> Restrict the build to ARM to fix this.
This isn't the right fix. When this has happened on ARM in the past, we've
had a lot of pressure to change the definition since it's far too generic.
"CCR" should only be used for stuff which is restricted to (eg) one driver,
and not in some system wide header file included by lots of files.
In the case of OMAP, the unfortunate thing is that include/linux/omap-dma.h
was moved lock stock and barrel out of the ARM-private includes. It
really needs splitting up in two - one which drivers are expected to
include, and the other for shared definitions between arch/arm/*omap*/dma.c
and drivers/dma/omap-dma.c.
Even so, "CCR" will still exist - but will be localised to the compilation
units which need it. The same should happen with SH.
So, as for this patch, that's a NAK.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH v4 0/7] mtd: spi-nor: add a new framework for SPI NOR
From: Jagan Teki @ 2014-01-19 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DB3864.2040606@gmail.com>
On Sun, Jan 19, 2014 at 7:58 AM, Huang Shijie <shijie8@gmail.com> wrote:
>
> ? 2014?01?17? 16:39, Jagan Teki ??:
>
>> On Fri, Jan 17, 2014 at 12:24 PM, Huang Shijie <b32955@freescale.com>
>> wrote:
>>>
>>> On Fri, Jan 17, 2014 at 12:36:08PM +0530, Jagan Teki wrote:
>>>>>>
>>>>>> My basic question is like I have a qspi spi controller in my SOC and I
>>>>>> designed two boards B1 and B2
>>>>>
>>>>> okay.
>>>>>
>>>>>> B1 with quad spi controller connected with non-flash as a slave and B2
>>>>>> with quad spi controller connected
>>>>>> with quad flash as a slave.
>>>>>
>>>>> You can use the framework for B2. But for B1, you should not use the
>>>>> framework,
>>>>> since this framework is just for the SPI-NOR. If you do not connected
>>>>> with
>>>>> a NOR, i think it's better to code another driver for your controller.
>>>>
>>>> Means we have two separate controller drivers for same controller one
>>>> with spi-nor and
>>>> another with spi is it?
>>>
>>> Take drivers/spi/spi-imx.c for example, if you connect a NOR to it, you
>>> only
>>> need to add a NOR device node in the device tree. In the probe, it will
>>> call
>>> the m25p80.c to probe the NOR device.
>>>
>>> But if we connect other device to it. you should set another device node
>>> for it.
>>>
>>> I am not sure if your controller driver can works as the spi-imx.c
>>
>> My question here was - this new framework suggest to write a two
>> different controller
>> drivers one is for non spi-nor and spi-nor models? do you agree that?
>
>
>
> If your controller can either connects to a NOR, or can connects to other
> devices, it means your controller is a _BUS_.
> You just need to write the bus driver for your controller, such as the
> spi-imx.c and drivers/bus/imx-weim.c do.
>
> Since you have connect a device to your controller. you also need to write a
> driver for your device, such as the m25p80.c is
> for your spi nor device.
>
> Just think about that how do you code your driver for SPI NOR _without_ this
> framework:
> do your driver need to call the m25p80.c? if you do call the m25p80.c, you
> actually write your so-called "two drivers" :)
I'm still not convinced here, sorry!
Let me explain more with example, Just take your (q)spi controller as an example
B_FSL1 designed with - serial flash
B_FSL2 designed with - touch screen
With this design If we follow current we just need one controller
driver (drivers/spi/spi-fsl.c)
to serve touch screen and serial flash from upper layers.
MTD core Input core
------------- -------------------------------
m25p80.c spi touchscreen driver (drivers/input/touchscreen)
----------------------------------------------------
SPI core
----------------------------------------------------
controller driver (drivers/spi/spi-fsl.)
----------------------------------------------------
But with your new SPI-NOR
MTD core
------------
SPI-NOR Input core
----------- ------------------
fsl-quadspi.c spi touchscreen driver (drivers/input/touchscreen)
---------------- ------------------------------
SPI Core
-----------------------------
controller driver (drivers/spi/spi-fsl.c)
-----------------------------------------
Here see we have two separate drivers for the same controller as it offers two
functionalities. and also it never talk to Linux SPI subsystem which is not a
good for me as intern hw is SPI-based it must talk to subsystem to make use of
Linux SPI API's.
And also you mentioned SPI-NOR controller is not a SPI controller what does that
means because it's a NOR flash which is of SPI protocol based.
I understand that your framework doing good things in matured manner, but
seems like it's confuse to me to follow common standards - Just my
opinion, may be I'm incorrect.
One more thing question - I have 1-wire spi controller which I was
used for flash in
one board and keyboard in another board, so if I follow your framework
I need to write
a driver in drivers/mtd/spi-nor/foo-spi.c and one more in
drivers/spi/spi-foo.c - correct?
>
>
> This framework does nSPot change any logic for the current kernel, except
> adding a layer. With the new layer, we can code the
> driver for the controllers which is a SPI-NOR controller, not a SPI bus
> controller.
>
>
>
>>
>> And also one important note from your design was spi-nor mode is
>> completely bypassing
>> Linux spi core is that the good idea?
>>
> yes. I think it's a good idea.
>
> As Mark even pointed, the freescale's Quadspi controller is not a SPI
> controller, it is a SPI-NOR controller, it does _not_ need the
> LINUX SPI core.
--
Thanks,
Jagan.
^ permalink raw reply
* [RFC v3 03/13] ahci-platform: Fix clk enable/disable unbalance on suspend/resume
From: Tejun Heo @ 2014-01-19 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390088935-7193-4-git-send-email-hdegoede@redhat.com>
On Sun, Jan 19, 2014 at 12:48:45AM +0100, Hans de Goede wrote:
> For devices where ahci_platform_data provides suspend() there is an unbalance
> in clk enable/disable calls. The suspend path does not disable the clk, but
> the resume path enables it. This commit fixes it by always disabling the clk
> in the suspend path independent of there being an ahci_platform_data suspend
> method.
>
> On all drivers currently using a suspend method, the suspend method always
> succeeds, so change its return type to void, to avoid having the introduce
> somewhat complex error handling paths.
>
> The disabling of the clock on suspend is a functional change, to ensure this
> is ok I've audited all drivers using ahci_platform_data:
>
> arch/arm/mach-davinci/devices-da8xx.c: Does not use a suspend method
> arch/arm/mach-spear/spear1340.c: Does not use the clock framework
> drivers/ata/ahci_imx.c: Does have suspend and resume pdata methods, these
> disable / enable another clock, so likely it is ok to disable / enable the
> clock at of-node index 0 as well, I've ordered a wandboard to be able to
> test these changes.
This isn't your fault but similarly to the previous patch, I'd much
prefer if drivers which need custom ops just override the whole
operation and are allowed to use the default platform from their
custom implementations as they see fit. Allowing partial overrides
seems like an efficient thing to do at the beginning but if you
continue to stack them, you eventually end up with giant pile of
methods where figuring out which code paths are actually executed
takes quite a bit of effort. I'd really like to avoid that.
Thanks.
--
tejun
^ permalink raw reply
* [RFC v3 02/13] sata-highbank: Remove unnecessary ahci_platform.h include
From: Tejun Heo @ 2014-01-19 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390088935-7193-3-git-send-email-hdegoede@redhat.com>
On Sun, Jan 19, 2014 at 12:48:44AM +0100, Hans de Goede wrote:
> The sata-highbank driver is a complete standalone sata driver, which does
> not use ahci_platform.c / ahci_platform_data in any way.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Applied to libata/for-3.14.
Thanks.
--
tejun
^ permalink raw reply
* [RFC v3 04/13] ahci-platform: Undo pdata->resume on resume failure
From: Tejun Heo @ 2014-01-19 11:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390088935-7193-5-git-send-email-hdegoede@redhat.com>
Hello,
On Sun, Jan 19, 2014 at 12:48:46AM +0100, Hans de Goede wrote:
> When the ahci_resume fails the error handling code tries to undo all changes
> made, but it was not undoing the results of pdata->resume.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/ata/ahci_platform.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index dc1ef73..41720cb 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -307,7 +307,7 @@ static int ahci_resume(struct device *dev)
> if (dev->power.power_state.event == PM_EVENT_SUSPEND) {
> rc = ahci_reset_controller(host);
> if (rc)
> - goto disable_unprepare_clk;
> + goto pdata_suspend;
>
> ahci_init_controller(host);
> }
> @@ -316,6 +316,9 @@ static int ahci_resume(struct device *dev)
>
> return 0;
>
> +pdata_suspend:
> + if (pdata && pdata->suspend)
> + pdata->suspend(dev);
> disable_unprepare_clk:
> if (!IS_ERR(hpriv->clk))
> clk_disable_unprepare(hpriv->clk);
Hmmmm... resume isn't an operation you can revert without side-effect
when the whole system is waking up from sleep. e.g. think about what
should happen the driver is removed and loaded again - it should be
able to reinitialized the device, which is unlikely to work if the
device is suspended at the platform level. If resume fails, the right
state to be in is "failed with as much as resumed" instead of
"suspended".
Thanks.
--
tejun
^ permalink raw reply
* [RFC v3 05/13] ahci-platform: Pass ahci_host_priv ptr to ahci_platform_data init method
From: Tejun Heo @ 2014-01-19 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390088935-7193-6-git-send-email-hdegoede@redhat.com>
On Sun, Jan 19, 2014 at 12:48:47AM +0100, Hans de Goede wrote:
> Some ahci_platform_data->init methods need access to the ahci_host_priv data.
>
> Note:
>
> When calling ahci_platform_data->init the ata_host has not been allocated yet,
> so access to ahci_host_priv through the dev argument is not possible.
>
> The hpriv->mmio argument may seem redundant, but it is useful for drivers
> which live outside of drivers/ata and thus don't know the contents of the
> ahci_platform_data data type.
Wouldn't the right thing to do be moving them under drivers/ata?
Thanks.
--
tejun
^ permalink raw reply
* [RFC v3 08/13] ahci-platform: Allow specifying platform_data through of_device_id
From: Tejun Heo @ 2014-01-19 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390088935-7193-9-git-send-email-hdegoede@redhat.com>
On Sun, Jan 19, 2014 at 12:48:50AM +0100, Hans de Goede wrote:
> @@ -126,7 +151,7 @@ static void ahci_put_clks(struct ahci_host_priv *hpriv)
> static int ahci_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct ahci_platform_data *pdata = dev_get_platdata(dev);
> + const struct ahci_platform_data *pdata = ahci_get_pdata(dev);
Let's please not add const. For data types which are known to be
terminal, const more or less works, I suppose but for anything even
mildly complicated it ends up being more of a headache. C just
doesn't have enough language support to make const actually useful.
e.g. now if somebody wants to add an accessor to ahci_platform_data()
which is applicable to both readers and writers, we either need two
separate accessors for const and !const paths or have to cast away
const.
Thanks.
--
tejun
^ permalink raw reply
* [RFC v3 09/13] ARM: sunxi: Add support for Allwinner SUNXi SoCs sata to ahci_platform
From: Russell King - ARM Linux @ 2014-01-19 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390088935-7193-10-git-send-email-hdegoede@redhat.com>
On Sun, Jan 19, 2014 at 12:48:51AM +0100, Hans de Goede wrote:
> + timeout = 0x100000;
> + do {
> + reg_val = sunxi_getbits(reg_base + AHCI_PHYCS0R, 0x7, 28);
> + } while (--timeout && (reg_val != 0x2));
> + if (!timeout) {
> + dev_err(dev, "PHY power up failed.\n");
> + return -EIO;
> + }
This is not a good way to detect failure - there's several things wrong
here.
First, how long does sunxi_getbits() take? What does that depend on?
Therefore, how long does it take to time out?
Secondly, what if the success condition becomes true at the same time that
a timeout occurs?
So:
timeout = some_us_value;
do {
reg_val = sunxi_getbits(reg_base + AHCI_PHYCS0R, 0x7, 28);
if (reg_val == 2)
break;
timeout--;
if (timeout == 0) {
dev_err(dev, "PHY power up failed.\n");
return -EIO;
}
udelay(1);
} while (1);
is far more predictable. Same goes for the other loop in this function.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] clocksource: timer-sun5i: Switch to sched_clock_register()
From: Ingo Molnar @ 2014-01-19 12:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D9709E.4000804@linaro.org>
* Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
> On 01/17/2014 06:56 PM, Stephen Boyd wrote:
> >On 01/17/14 02:05, Daniel Lezcano wrote:
> >>On 01/17/2014 02:38 AM, Stephen Boyd wrote:
> >>>The 32 bit sched_clock interface supports 64 bits since 3.13-rc1.
> >>>Upgrade to the 64 bit function to allow us to remove the 32 bit
> >>>registration interface.
> >>>
> >>>Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
> >>>Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> >>>---
> >>>
> >>>Cc'in Ingo because this is simple enough to probably just apply to
> >>>timers/core
> >>
> >> Hi Stephen,
> >>
> >> I applied your patch in my tree for 3.15.
> >>
> >
> > I was hoping we could remove setup_sched_clock() in 3.14-rc1
> > timeline, but if we delay this until 3.15 we'll have to wait
> > another 3 months. Is there any chance we can get this in for 3.14?
>
> I am ok with that. It is up to Ingo.
Such simple patches are generally not a problem, I've applied it to
timers/core with your Acked-by.
Thanks,
Ingo
^ permalink raw reply
* [RFC v3 11/13] ahci-imx: Don't create a nested platform device from probe
From: Russell King - ARM Linux @ 2014-01-19 12:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390088935-7193-12-git-send-email-hdegoede@redhat.com>
On Sun, Jan 19, 2014 at 12:48:53AM +0100, Hans de Goede wrote:
> Instead only provide platform_data through of_device_id, like the ahci-sunxi
> driver does.
It looks like the whole of ahci_imx.c (apart from the inclues) is
enclosed in a big ifdef. You can avoid that by using this in the
Makefile:
> @@ -10,9 +10,8 @@ obj-$(CONFIG_SATA_INIC162X) += sata_inic162x.o
> obj-$(CONFIG_SATA_SIL24) += sata_sil24.o
> obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
> obj-$(CONFIG_SATA_HIGHBANK) += sata_highbank.o libahci.o
> -obj-$(CONFIG_AHCI_IMX) += ahci_imx.o
>
> -ahci_plat-objs := ahci_platform.o ahci_sunxi.o
> +ahci_plat-objs := ahci_platform.o ahci_imx.o ahci_sunxi.o
ahci_plat-y := ahci_platform.o ahci_sunxi.o
ahci_plat-$(CONFIG_AHCI_IMX) += ahci_imx.o
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [RFC v3 08/13] ahci-platform: Allow specifying platform_data through of_device_id
From: Russell King - ARM Linux @ 2014-01-19 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119113838.GE11123@htj.dyndns.org>
On Sun, Jan 19, 2014 at 06:38:38AM -0500, Tejun Heo wrote:
> On Sun, Jan 19, 2014 at 12:48:50AM +0100, Hans de Goede wrote:
> > @@ -126,7 +151,7 @@ static void ahci_put_clks(struct ahci_host_priv *hpriv)
> > static int ahci_probe(struct platform_device *pdev)
> > {
> > struct device *dev = &pdev->dev;
> > - struct ahci_platform_data *pdata = dev_get_platdata(dev);
> > + const struct ahci_platform_data *pdata = ahci_get_pdata(dev);
>
> Let's please not add const. For data types which are known to be
> terminal, const more or less works, I suppose but for anything even
> mildly complicated it ends up being more of a headache. C just
> doesn't have enough language support to make const actually useful.
> e.g. now if somebody wants to add an accessor to ahci_platform_data()
> which is applicable to both readers and writers, we either need two
> separate accessors for const and !const paths or have to cast away
> const.
I don't see anything wrong with this. Platform data should _never_ be
written to, because doing so will change the driver behaviour between
bindings. It really should be read-only to driver code.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [RFC v3 06/13] ahci-platform: Add support for devices with more then 1 clock
From: Russell King - ARM Linux @ 2014-01-19 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390088935-7193-7-git-send-email-hdegoede@redhat.com>
On Sun, Jan 19, 2014 at 12:48:48AM +0100, Hans de Goede wrote:
> +static int ahci_enable_clks(struct device *dev, struct ahci_host_priv *hpriv)
> +{
> + int c, rc;
> +
> + for (c = 0; c < AHCI_MAX_CLKS && hpriv->clks[c]; c++) {
for (c = 0; c < AHCI_MAX_CLKS && !IS_ERR(hpriv->clks[c]); c++) {
> + rc = clk_prepare_enable(hpriv->clks[c]);
> + if (rc) {
> + dev_err(dev, "clock prepare enable failed");
> + goto disable_unprepare_clk;
> + }
> + }
> + return 0;
> +
> +disable_unprepare_clk:
> + while (--c >= 0)
> + clk_disable_unprepare(hpriv->clks[c]);
> + return rc;
> +}
> +
> +static void ahci_disable_clks(struct ahci_host_priv *hpriv)
> +{
> + int c;
> +
> + for (c = AHCI_MAX_CLKS - 1; c >= 0; c--)
> + if (hpriv->clks[c])
if (!IS_ERR(hpriv->clks[c]))
> + clk_disable_unprepare(hpriv->clks[c]);
> +}
> +
> +static void ahci_put_clks(struct ahci_host_priv *hpriv)
> +{
> + int c;
> +
> + for (c = 0; c < AHCI_MAX_CLKS && hpriv->clks[c]; c++)
for (c = 0; c < AHCI_MAX_CLKS && !IS_ERR(hpriv->clks[c]); c++)
> + clk_put(hpriv->clks[c]);
> +}
Better still for this one, consider using devm_clk_get() - in which case
the above is even more important to get right. We really should have
a devm_of_clk_get() too.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [RFC v3 10/13] ahci_imx: Adjust for ahci_platform managing the clocks
From: Russell King - ARM Linux @ 2014-01-19 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390088935-7193-11-git-send-email-hdegoede@redhat.com>
On Sun, Jan 19, 2014 at 12:48:52AM +0100, Hans de Goede wrote:
> +enum {
> + CLK_SATA,
> + CLK_SATA_REF,
> + CLK_AHB
> +};
Err, so we now rely on the order that these clocks are specified in DT
rather than their name properties to provide the correct clock... that
sounds particularly fragile to me.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [RFC v3 08/13] ahci-platform: Allow specifying platform_data through of_device_id
From: Tejun Heo @ 2014-01-19 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119123055.GO15937@n2100.arm.linux.org.uk>
On Sun, Jan 19, 2014 at 12:30:55PM +0000, Russell King - ARM Linux wrote:
> I don't see anything wrong with this. Platform data should _never_ be
> written to, because doing so will change the driver behaviour between
> bindings. It really should be read-only to driver code.
Hmmm, problems usually arise when const is used to distinguish ro and
rw users. When it's simple, it seems okay but later on it often ends
up requiring dropping const in almost arbitrary places or forced casts
somewhere random. Over time, it makes const annotations in the kernel
sparse and inconsistent. For anything non-trivial, I think it's best
to ignore it.
That said, if the object is actually immutable once initialized, it
shouldn't cause any trouble. That probably is one of the few proper
use case for const on complex data types.
Thanks.
--
tejun
^ permalink raw reply
* PWM...
From: Russell King - ARM Linux @ 2014-01-19 16:49 UTC (permalink / raw)
To: linux-arm-kernel
So, having looked at what else I can add support for on the cubox-i, I
decided it would be nice and simple to add support for the front panel
LED. What could possibly go wrong with this.
Well, the hardware is wired such that the LED is connected between the
PWM output and +3.3v. So, a constant low turns the LED on full, whereas
a constant high turns the LED off.
So, the polarity of the LED is inverted - but this _can't_ be specified
in the totally and utterly fucked misdesigned crap that DT is:
pwmleds {
compatible = "pwm-leds";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_cubox_i_pwm1>;
front {
label = "imx6:red:front";
pwms = <&pwm1 0 50000>;
max-brightness = <248>;
};
};
pwm1: pwm at 02080000 {
#pwm-cells = <2>;
compatible = "fsl,imx6q-pwm", "fsl,imx27-pwm";
reg = <0x02080000 0x4000>;
interrupts = <0 83 0x04>;
clocks = <&clks 62>, <&clks 145>;
clock-names = "ipg", "per";
};
Yes, because iMX6 specifies #pwm-cells as 2, there's no flags able to
be specified in the pwms declaration in pwmleds. So that doesn't work.
There's no property to tell pwmleds that it should use inverted sense
either.
Moreover, there's no way to specify a default brightness for the LED
in the absence of any trigger, so this results in the LED being fully
on.
So, something which _should_ be nice and simple is turned into a major
fuckup because of the total and utter crappiness that DT is and the
total misdesign that this shite is.
Frankly, board support via C files was FAR BETTER than this never
ending pile of shite that I'm finding with DT. Far from making board
support easier, DT has turned it into a total disaster. I say bring
back board .c files... DT isn't worth bothering with.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] clk: export __clk_get_hw for re-use in others
From: Greg KH @ 2014-01-19 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390110907-29918-1-git-send-email-sj38.park@gmail.com>
On Sun, Jan 19, 2014 at 02:55:07PM +0900, SeongJae Park wrote:
> Following build comes while modprobe process:
> > ERROR: "__clk_get_hw" [drivers/clk/clk-max77686.ko] undefined!
> > make[2]: *** [__modpost] Error 1
> > make[1]: *** [modules] Error 2
>
> Export the symbol to fix it and for other part's usecase.
>
> Signed-off-by: SeongJae Park <sj38.park@gmail.com>
> ---
> drivers/clk/clk.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 2b38dc9..3883fba 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -575,6 +575,7 @@ struct clk_hw *__clk_get_hw(struct clk *clk)
> {
> return !clk ? NULL : clk->hw;
> }
> +EXPORT_SYMBOL_GPL(__clk_get_hw);
__ functions should usually only be for "internal" use, why does this
get exported to modules? Why not just put it in a .h file?
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox