* [RFC v3 10/13] ahci_imx: Adjust for ahci_platform managing the clocks
From: Hans de Goede @ 2014-01-19 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119193258.GT15937@n2100.arm.linux.org.uk>
Hi,
On 01/19/2014 08:32 PM, Russell King - ARM Linux wrote:
> On Sun, Jan 19, 2014 at 08:30:37PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 01/19/2014 01:41 PM, Russell King - ARM Linux wrote:
>>> 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.
>>
>> Both in the ohci- / ehci-platform case, where the idea of purely addressing
>> clocks by index comes from, as well as in the ahci-platform case, people
>> have been asking me to make things more generic, so as to avoid having
>> a gazillion almost but not quite the same ehci-foo platform drivers.
>>
>> This has already happened with ohci-foo.c drivers, and the hope is that
>> with the new generalized ohci-plaform.c many of the existing ohci-foo
>> drivers can go away over time.
>>
>> The downside of this generalized approach is that we cannot use clock-names
>> since those tend to be implementation specific.
>>
>> In the specific case of the ahci-imx driver this means that certain clocks
>> must be at a specific index, since it needs to know which one is the AHB
>> clock, as documented in the bindings documentation. I don't see how mandating
>> certain indices is different and/or more fragile then mandating certain names
>> in the bindings document. I agree that is is slightly less clear to someone
>> reading the dts, but that is the price we have to pay for this desire for
>> things to be generic.
>
> So what happens if we have the same IP block appearing, but the SATA_REF
> or SATA clock isn't present - how do we still provide an AHB clock (for
> argument sake)?
Then it will not use the same compatible string, since then clearly it is not
compatible with "fsl,imx6q-ahci"
And we can document different indices for the new compatible string (and adjust
the code to match).
Regards,
Hans
^ permalink raw reply
* [RFC v3 04/13] ahci-platform: Undo pdata->resume on resume failure
From: Tejun Heo @ 2014-01-19 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DC28DB.7070804@redhat.com>
On Sun, Jan 19, 2014 at 08:34:51PM +0100, Hans de Goede wrote:
> Well the current error handling still re-disables the clks on resume failure,
> if you want to proceed with resume as far as possible, rather then return to
Let's put it as "put it in a state where it can be reinitialized
afterwards".
Thanks.
--
tejun
^ permalink raw reply
* [RFC v3 03/13] ahci-platform: Fix clk enable/disable unbalance on suspend/resume
From: Hans de Goede @ 2014-01-19 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119191554.GB32165@mtj.dyndns.org>
Hi,
On 01/19/2014 08:15 PM, Tejun Heo wrote:
> Hey,
>
> On Sun, Jan 19, 2014 at 07:47:06PM +0100, Hans de Goede wrote:
>> As I see it either doing clks, regulator and sata-core things in a common
>> place makes sense, and then it goes for suspend and resume too, or we
>> opt for always following the complete override model, and which point
>> it becomes more sensible to just do a separate platform driver per
>> ahci implementation.
>
> It makes sense in light of those specific cases, but there are gonna
> be cases where the placement of the callback is slightly wrong and we
> end up with ->XXX_ops_pre() and then ->XXX_ops_post() and so on.
> Please make the whole op overridable and then export the default op
> and use it as library.
If we were to put a generic implementation in ahci_platform.c and export
it for use from overrides to avoid copy and pasting common bits everywhere,
then we still have the ordering problem you are talking about. How do you
envision all of this fitting together, I can imagine ie a
ahci_platform_resume_controller which has the bits of what is currently
ahci_resume stating at:
"if (dev->power.power_state.event == PM_EVENT_SUSPEND) {"
And having ahci_resume in ahci_platform.c still doing the clk and power enabling
before calling into ahci_platform_resume, and drivers overriding the resume method
need to do their own clk + regulator + whatever setup
before calling into ahci_platform_resume_controller ?
Also how do you see overriding the entire op, does that mean that pdata->suspend
will be deprecated (we will need to keep it around for now to avoid breaking
existing drivers using it), and all of:
ahci_probe
ahci_suspend
ahci_resume
Will get exported from ahci_platform.c and drivers needing to override any of them
will provide their own platform_driver struct, pointing either to their overrides,
or for driver methods they don't need to override to the exported function from
ahci_platform.c ?
This would also work nicely for the of_device_id data stuff, since if drivers
have their own platform_driver struct these bits could just go inside the
driver file instead of being in #ifdef CONFIG_FOO in ahci_platform.c
Regards,
Hans
^ permalink raw reply
* [RFC v3 04/13] ahci-platform: Undo pdata->resume on resume failure
From: Hans de Goede @ 2014-01-19 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119194226.GE32165@mtj.dyndns.org>
Hi,
On 01/19/2014 08:42 PM, Tejun Heo wrote:
> On Sun, Jan 19, 2014 at 08:34:51PM +0100, Hans de Goede wrote:
>> Well the current error handling still re-disables the clks on resume failure,
>> if you want to proceed with resume as far as possible, rather then return to
>
> Let's put it as "put it in a state where it can be reinitialized
> afterwards".
Ok, I'll drop the patch then.
Regards,
Hans
^ permalink raw reply
* [RFC v3 05/13] ahci-platform: Pass ahci_host_priv ptr to ahci_platform_data init method
From: Hans de Goede @ 2014-01-19 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119191706.GC32165@mtj.dyndns.org>
Hi,
On 01/19/2014 08:17 PM, Tejun Heo wrote:
> On Sun, Jan 19, 2014 at 07:51:48PM +0100, Hans de Goede wrote:
>> Yes, but they are part of arch/arm/mach-foo, so moving them is non trivial, and
>> I don't want to go make these kinda changes without hardware to test. Please keep
>> in mind that I'm partially cleaning up other peoples mess here (the imx bits
>> specifically). I'm willing to do that to some extend (*). But buying an imx6q board
>> and fixing that is about as far as I'm willing to go.
>
> If they can't be moved, the right thing to do is moving the header out
> to include/linux so that they can be included from those directories.
> Let's please not contort the API to fit the organizational issues.
Ok, asking the obvious here I guess, but you would accept a patch moving drivers/ata/ahci.h
to include/linux as part of this patch-set ?
Regards,
Hans
^ 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 19:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52DC2282.4040702@redhat.com>
On Sun, Jan 19, 2014 at 08:07:46PM +0100, Hans de Goede wrote:
> Hi,
>
> On 01/19/2014 01:22 PM, Russell King - ARM Linux wrote:
>> 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?
>
> You're interpreting the timeout in the above code as an actual timeout, but
> that is not what it is, it is a means to avoid looping forever if something
> is seriously amiss. The only time I've ever seen the timeout trigger is when
> I forgot to enable some clks iirc.
>
> I can rename the variable from timeout to max_tries to make this more clear.
>
>> Secondly, what if the success condition becomes true at the same time that
>> a timeout occurs?
>
> We should never get anywhere near timeout becoming 0, so if both happen at
> the same time, then something is pretty seriously broken and the returning of
> an error as the code does now is the right thing to do.
Yes... and if we look back in history, there's been lots of stuff just
like this where the loop has had to have the number of iterations
increased as CPUs have become faster and compilers become better?
So... my question stands: but let me put it a different way in two parts:
1. What is the maximum expected time for the success condition to be
satisfied?
2. How long does it actually take for the loop to time out in existing
CPUs/compilers?
--
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 09/13] ARM: sunxi: Add support for Allwinner SUNXi SoCs sata to ahci_platform
From: Hans de Goede @ 2014-01-19 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119195642.GU15937@n2100.arm.linux.org.uk>
Hi,
On 01/19/2014 08:56 PM, Russell King - ARM Linux wrote:
> On Sun, Jan 19, 2014 at 08:07:46PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 01/19/2014 01:22 PM, Russell King - ARM Linux wrote:
>>> 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?
>>
>> You're interpreting the timeout in the above code as an actual timeout, but
>> that is not what it is, it is a means to avoid looping forever if something
>> is seriously amiss. The only time I've ever seen the timeout trigger is when
>> I forgot to enable some clks iirc.
>>
>> I can rename the variable from timeout to max_tries to make this more clear.
>>
>>> Secondly, what if the success condition becomes true at the same time that
>>> a timeout occurs?
>>
>> We should never get anywhere near timeout becoming 0, so if both happen at
>> the same time, then something is pretty seriously broken and the returning of
>> an error as the code does now is the right thing to do.
>
> Yes... and if we look back in history, there's been lots of stuff just
> like this where the loop has had to have the number of iterations
> increased as CPUs have become faster and compilers become better?
>
> So... my question stands: but let me put it a different way in two parts:
>
> 1. What is the maximum expected time for the success condition to be
> satisfied?
TBH, I don't have a clue this code comes from the android driver (never an
excuse, I know) and we don't have any documentation other then the android
driver.
> 2. How long does it actually take for the loop to time out in existing
> CPUs/compilers?
I don't know either. I understand where you're coming from, and I believe
that the best way to solve this is to take your suggested implementation, start
with a way too high timeout, and add a debug print to see how much time is left
after a successfull phy_init, then do a couple of test runs to get a ballpark
figure for how long we need to wait, multiply that by 5 to be on the safe side,
and use that.
Does that sound like a plan ?
Regards,
Hans
^ permalink raw reply
* PWM...
From: Arnd Bergmann @ 2014-01-19 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119193026.GS15937@n2100.arm.linux.org.uk>
On Sunday 19 January 2014, Russell King - ARM Linux wrote:
> On Sun, Jan 19, 2014 at 11:11:41AM -0800, Olof Johansson wrote:
> > On Sun, Jan 19, 2014 at 11:08 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> > Ah, yes, if you add a cell that can be done. There'll still be the
> > "dead" first cell that will always be 0, but that's alright.
>
> Does it not mean that PWM specifications of:
>
> <&pwm1 0 n> <&pwm2 0 n>
>
> would need to be converted to:
>
> <&pwm1 0 n 0> <&pwm2 0 n 0>
>
> in every DT file referring to these PWMs - because isn't this just
> treated in DT as one single array of values? (If DT knew how many
> were in each specification, we wouldn't need the #foo-cells...)
Right: if you change an existing dts file from #pwm-cells=<2> to
#pwm-cells=<3>, that requires changing all references to the pwm
controller at the same time. If both the per-soc .dtsi files
and the per-board .dts files contain references to the same pwm
controller, that can end up in significant work. I have not checked
if this is the case for i.MX though.
Arnd
^ permalink raw reply
* How to support SDIO wifi/bt in DT
From: Arnd Bergmann @ 2014-01-19 20:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMjVpTEku+UJntewi3FXoeEPe9rJP4BBmbSesfFMtY9hnA@mail.gmail.com>
On Sunday 19 January 2014, Olof Johansson wrote:
> The "multi-slot" concept I was talking about was one host controller
> for several physical slots. Seems like at91 implements and uses this
> but nobody else. However, it seems that they allocate one mmc host per
> slot, so the same model still works.
>
IIRC dw-mci also has multiple slots, and it's a common host controller
in a number of SoCs. I don't know how many of them actually support
multiple slots rather than a simplified single-slot version of
that controller.
Arnd
^ permalink raw reply
* [PATCH 13/15] fbdev: sh-mobile-lcdcfb: Enable driver compilation with COMPILE_TEST
From: Laurent Pinchart @ 2014-01-19 21:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D8F14A.7030100@ti.com>
Hi Tomi,
On Friday 17 January 2014 11:00:58 Tomi Valkeinen wrote:
> Hi,
>
> On 2014-01-08 10:30, Tomi Valkeinen wrote:
> > On 2014-01-07 17:15, Laurent Pinchart wrote:
> >> On Wednesday 11 December 2013 13:51:18 Laurent Pinchart wrote:
> >>> Hi Jean-Christophe and Tomi,
> >>>
> >>> Could you please pick this patch up for v3.14 ?
> >>
> >> Ping ?
> >
> > Queued for 3.14.
>
> I'll drop this patch, as it causes compile break (from kbuild test robot):
>
> All error/warnings:
>
> drivers/built-in.o: In function `sh_mobile_lcdc_pan':
> >> sh_mobile_lcdcfb.c:(.text+0x77373): undefined reference to
> `sh_mobile_meram_cache_update'
> drivers/built-in.o: In function `sh_mobile_lcdc_start':
> >> sh_mobile_lcdcfb.c:(.text+0x79320): undefined reference to
> `sh_mobile_meram_cache_free'
> >> sh_mobile_lcdcfb.c:(.text+0x79394): undefined reference to
> `sh_mobile_meram_cache_alloc'
> >> sh_mobile_lcdcfb.c:(.text+0x793d4): undefined reference to
> `sh_mobile_meram_cache_update'
> drivers/built-in.o: In function `sh_mobile_lcdc_stop':
> >> sh_mobile_lcdcfb.c:(.text+0x79616): undefined reference to
> `sh_mobile_meram_cache_free'
The lcdc driver can be compiled without meram support. This is handled by
conditional compilation in include/video/sh_mobile_meram.h that defines the
meram functions as stubs when meram support isn't selected.
The problem comes from the combination of FB_SH_MOBILE_MERAM=m and
FB_SH_MOBILE_LCDC=y. The former makes the meram function non-stubs, while the
later makes the LCDC driver fail to link, as meram support is then compiled as
a module.
How do you usually handle this ?
--
Regards,
Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140119/329d9343/attachment.sig>
^ permalink raw reply
* How to support SDIO wifi/bt in DT
From: Alexandre Belloni @ 2014-01-19 23:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMjVpTEku+UJntewi3FXoeEPe9rJP4BBmbSesfFMtY9hnA@mail.gmail.com>
On Sun, Jan 19, 2014 at 11:29:55AM -0800, Olof Johansson wrote :
> The "multi-slot" concept I was talking about was one host controller
> for several physical slots. Seems like at91 implements _and_ uses this
> but nobody else. However, it seems that they allocate one mmc host per
> slot, so the same model still works.
>
I think we need to be extra careful about the DT bindings then because
adding a property in a slot is requiring handling that in the at91
driver whereas adding a common property for the various mmc hosts can be
done in the core code.
>From what I remember, it would be really good to put the DT parsing for
the slots in the core code but I only had a really quick look at that.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* How to support SDIO wifi/bt in DT
From: Olof Johansson @ 2014-01-19 23:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401192128.54413.arnd@arndb.de>
On Sun, Jan 19, 2014 at 09:28:53PM +0100, Arnd Bergmann wrote:
> On Sunday 19 January 2014, Olof Johansson wrote:
> > The "multi-slot" concept I was talking about was one host controller
> > for several physical slots. Seems like at91 implements and uses this
> > but nobody else. However, it seems that they allocate one mmc host per
> > slot, so the same model still works.
> >
>
> IIRC dw-mci also has multiple slots, and it's a common host controller
> in a number of SoCs. I don't know how many of them actually support
> multiple slots rather than a simplified single-slot version of
> that controller.
Right, that's the main one i had in mind -- the binding, and the driver, allow
for multiple slots but we've been searching high and low for an actual SoC that
implements that, and none seem to do it. So the additional overhead is just
wasted, and there's been talk of bringing the binding more in line with
a single-slot driver instead. It makes a lot of sense to do.
-Olof
^ permalink raw reply
* How to support SDIO wifi/bt in DT
From: Olof Johansson @ 2014-01-19 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119230924.GB8154@piout.net>
On Mon, Jan 20, 2014 at 12:09:25AM +0100, Alexandre Belloni wrote:
> On Sun, Jan 19, 2014 at 11:29:55AM -0800, Olof Johansson wrote :
> > The "multi-slot" concept I was talking about was one host controller
> > for several physical slots. Seems like at91 implements _and_ uses this
> > but nobody else. However, it seems that they allocate one mmc host per
> > slot, so the same model still works.
> >
>
> I think we need to be extra careful about the DT bindings then because
> adding a property in a slot is requiring handling that in the at91
> driver whereas adding a common property for the various mmc hosts can be
> done in the core code.
>
> From what I remember, it would be really good to put the DT parsing for
> the slots in the core code but I only had a really quick look at that.
The patches I have here do it all in the core per host with common
bindings. I hope to post them tonight. They should fit the at91 model
just fine as well, since they do each slot as a mmc_host, not as a separate
slot with a shared host controller.
(Some drivers don't seem to call mmc_of_parse(), which they will need to do to
take advantage of the common implementation. But that can be addressed driver
by driver as someone has a chance to test it).
-Olof
^ permalink raw reply
* PWM...
From: Olof Johansson @ 2014-01-19 23:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401192126.41543.arnd@arndb.de>
On Sun, Jan 19, 2014 at 09:26:40PM +0100, Arnd Bergmann wrote:
> On Sunday 19 January 2014, Russell King - ARM Linux wrote:
> > On Sun, Jan 19, 2014 at 11:11:41AM -0800, Olof Johansson wrote:
> > > On Sun, Jan 19, 2014 at 11:08 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > > Ah, yes, if you add a cell that can be done. There'll still be the
> > > "dead" first cell that will always be 0, but that's alright.
> >
> > Does it not mean that PWM specifications of:
> >
> > <&pwm1 0 n> <&pwm2 0 n>
> >
> > would need to be converted to:
> >
> > <&pwm1 0 n 0> <&pwm2 0 n 0>
> >
> > in every DT file referring to these PWMs - because isn't this just
> > treated in DT as one single array of values? (If DT knew how many
> > were in each specification, we wouldn't need the #foo-cells...)
>
> Right: if you change an existing dts file from #pwm-cells=<2> to
> #pwm-cells=<3>, that requires changing all references to the pwm
> controller at the same time. If both the per-soc .dtsi files
> and the per-board .dts files contain references to the same pwm
> controller, that can end up in significant work. I have not checked
> if this is the case for i.MX though.
Only imx53-tx53.dtsi and imx6qdl-sabresd.dtsi seem to reference pwm nodes from
a dtsi file, the rest are from dts.
Not all of the dts files have to be converted at the same time either;
the #pwm-cells property can be changed per dts until they've all been
converted, then the shared SoC dtsi can be converted.
-Olof
^ permalink raw reply
* linux-next: build warning after merge of the arm-soc tree
From: Stephen Rothwell @ 2014-01-19 23:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
After merging the arm-soc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/pinctrl/pinconf.c: In function 'pinconf_pins_show':
drivers/pinctrl/pinconf.c:299:28: warning: unused variable 'ops' [-Wunused-variable]
const struct pinconf_ops *ops = pctldev->desc->confops;
^
drivers/pinctrl/pinconf.c: In function 'pinconf_groups_show':
drivers/pinctrl/pinconf.c:346:28: warning: unused variable 'ops' [-Wunused-variable]
const struct pinconf_ops *ops = pctldev->desc->confops;
^
Introduced by commit c420619d5177 ("pinctrl: pinconf: remove checks on
ops->pin_config_get").
Sorry, that I did not notice this earlier.
--
Cheers,
Stephen Rothwell sfr at canb.auug.org.au
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140120/8b250078/attachment.sig>
^ permalink raw reply
* PWM...
From: Simon Horman @ 2014-01-20 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401192126.41543.arnd@arndb.de>
On Sun, Jan 19, 2014 at 09:26:40PM +0100, Arnd Bergmann wrote:
> On Sunday 19 January 2014, Russell King - ARM Linux wrote:
> > On Sun, Jan 19, 2014 at 11:11:41AM -0800, Olof Johansson wrote:
> > > On Sun, Jan 19, 2014 at 11:08 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > > Ah, yes, if you add a cell that can be done. There'll still be the
> > > "dead" first cell that will always be 0, but that's alright.
> >
> > Does it not mean that PWM specifications of:
> >
> > <&pwm1 0 n> <&pwm2 0 n>
> >
> > would need to be converted to:
> >
> > <&pwm1 0 n 0> <&pwm2 0 n 0>
> >
> > in every DT file referring to these PWMs - because isn't this just
> > treated in DT as one single array of values? (If DT knew how many
> > were in each specification, we wouldn't need the #foo-cells...)
>
> Right: if you change an existing dts file from #pwm-cells=<2> to
> #pwm-cells=<3>, that requires changing all references to the pwm
> controller at the same time. If both the per-soc .dtsi files
> and the per-board .dts files contain references to the same pwm
> controller, that can end up in significant work. I have not checked
> if this is the case for i.MX though.
Would this change imply that old dtbs would no longer work with new kernels?
^ permalink raw reply
* [PATCH 1/2] ARM: shmobile: Lager: pass Ether PHY IRQ
From: Simon Horman @ 2014-01-20 0:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoQ_qPBJUqnbU6wrrc+tmsspk_v99w-ZTdnhPivEdBzd4A@mail.gmail.com>
On Fri, Jan 17, 2014 at 03:00:29PM +0900, Magnus Damm wrote:
> On Fri, Dec 20, 2013 at 8:19 AM, Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
> > Pass Ether's PHY IRQ (which is IRQC's IRQ0) to the 'sh_eth' driver. Set the IRQ
> > trigger type to be low-level as per the Micrel PHY driver's setup.
> >
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >
> > ---
> > arch/arm/mach-shmobile/board-lager.c | 4 ++++
> > 1 file changed, 4 insertions(+)
>
> Thanks for your efforts. The code looks fine. I have now also tested
> this on my Lager board.
>
> Acked-by: Magnus Damm <damm@opensource.se>
Hi Sergei,
please repost this patch with Magnus's ack once an rc release is
available with the pre-requisites of this patch.
Thanks
^ permalink raw reply
* [PATCH 1/1] ARM: shmobile: Koelsch: pass Ether PHY IRQ
From: Simon Horman @ 2014-01-20 0:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoT1bN4jYHA2+DYRzsVjXXMXRdR_9mqx3sUUXDhJAxe5Ow@mail.gmail.com>
On Fri, Jan 17, 2014 at 03:02:20PM +0900, Magnus Damm wrote:
> On Fri, Dec 20, 2013 at 8:28 AM, Sergei Shtylyov
> <sergei.shtylyov@cogentembedded.com> wrote:
> > Pass Ether's PHY IRQ (which is IRQC's IRQ0) to the 'sh_eth' driver. Set the IRQ
> > trigger type to be low-level as per the Micrel PHY driver's setup.
> >
> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >
> > ---
> > arch/arm/mach-shmobile/board-koelsch.c | 4 ++++
> > 1 file changed, 4 insertions(+)
>
> Thanks for this. The code looks good to me. I have now tested this on
> my Koelsch board using ifconfig up/down and checking /proc/interrupts.
>
> Acked-by: Magnus Damm <damm@opensource.se>
Hi Sergei,
please repost this patch with Magnus's ack once an rc release is
available with the pre-requisites of this patch.
Thanks
^ permalink raw reply
* [PATCH 0/2] DT updates for Hummingboard and new Cubox-i
From: Russell King - ARM Linux @ 2014-01-20 0:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119185246.GB28056@quad.lixom.net>
On Sun, Jan 19, 2014 at 10:52:46AM -0800, Olof Johansson wrote:
> On Sun, Jan 19, 2014 at 11:18:18AM +0800, Shawn Guo wrote:
> > On Thu, Jan 16, 2014 at 06:22:12PM +0000, Russell King - ARM Linux wrote:
> > > Now that the Cubox-i has been released, and I have one, I've been able to
> > > update things a little. Out of the following two patches, the first one
> > > I think is critical to be merged before the microsom support hits
> > > mainline, since it drops the flexcan support from the microsom level,
> > > moving it to the Hummingboard level.
> >
> > I will be out of town for a few days, and won't be online until next
> > weekend. So please send the patch directly to arm-soc folks, so that
> > they can send it together with imx-dt-3.14 stuff.
> >
> > arm-soc folks, please take this as another ping for my imx-dt-3.14 pull
> > request :)
>
> I'm well aware that the DT branch has not been merged, and that's because
> there has been no consensus from DT maintainers on the massive rework
> you did as the base of the branch.
>
> Given the timing, it's not looking like it will be resolved in time for
> the 3.14 merge window (which might open today).
Okay, that presumably means that the Hummingboard stuff won't be going in
through this route, and it sounds like the imx DT stuff will need rework.
Is there any objection if I pushed just the Hummingboard files upstream
myself?
--
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] arm64: mm: use ubfm for dcache_line_size
From: Jingoo Han @ 2014-01-20 2:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140117111307.GE16003@mudshark.cambridge.arm.com>
> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: Friday, January 17, 2014 8:13 PM
> To: Jingoo Han
> Cc: Catalin Marinas; linux-arm-kernel at lists.infradead.org
> Subject: Re: [PATCH] arm64: mm: use ubfm for dcache_line_size
>
> On Fri, Jan 17, 2014 at 08:04:32AM +0000, Jingoo Han wrote:
> > Use 'ubfm' for the bitfield move instruction; thus, single
> > instruction can be used instead of two instructions, when
> > getting the minimum D-cache line size from CTR_EL0 register.
> >
> > Signed-off-by: Jingoo Han <jg1.han@samsung.com>
> > ---
> > arch/arm64/mm/proc-macros.S | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/mm/proc-macros.S b/arch/arm64/mm/proc-macros.S
> > index 8957b82..c31f41e 100644
> > --- a/arch/arm64/mm/proc-macros.S
> > +++ b/arch/arm64/mm/proc-macros.S
> > @@ -38,8 +38,7 @@
> > */
> > .macro dcache_line_size, reg, tmp
> > mrs \tmp, ctr_el0 // read CTR
> > - lsr \tmp, \tmp, #16
> > - and \tmp, \tmp, #0xf // cache line size encoding
> > + ubfm \tmp, \tmp, #0x16, 0x19 // cache line size encoding
>
> 0x16 and 0x19. Are you sure?
(+cc Ard Biesheuvel)
Oh, it's my mistake.
CTR_EL0[19:16] is a proper bit-field; it means 'DminLine'.
So, I will fit it as below:
ubfm \tmp, \tmp, #16, #19
>
> You can also grep for other occurences of this pattern and change
> those too (pgtable stuff in head.S, clidr in cache.S).
OK, I will change others of this pattern.
I appreciate your comments. :-)
Best regards,
Jingoo Han
^ permalink raw reply
* [PATCH v2 0/5] mmc: sdhci: a few fixes on timeout and max_discard_to
From: Dong Aisheng @ 2014-01-20 2:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA+hA=QgPvTXWbKjpd9e0H3MacGqu8=zz_PpCRAB0NGu_drVtw@mail.gmail.com>
Ping...
On Mon, Jan 13, 2014 at 6:55 PM, Dong Aisheng <dongas86@gmail.com> wrote:
> Hi Chris,
>
> On Tue, Dec 17, 2013 at 10:30 PM, Shawn Guo <shawn.guo@linaro.org> wrote:
>> On Tue, Dec 17, 2013 at 04:16:26PM +0800, Dong Aisheng wrote:
>>> Dong Aisheng (5):
>>> mmc: sdhci: add platfrom get_max_timeout_count hook
>>> mmc: sdhci-esdhc-imx: fix incorrect max_discard_to for uSDHC
>>> mmc: sdhci: add platform set_timeout hook
>>> mmc: sdhci-esdhc-imx: set the correct max timeout value for uSDHC
>>> mmc: sdhci: calculate max_discard_to dynamically for
>>> SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK
>>
>> For all,
>>
>> Reviewed-by: Shawn Guo <shawn.guo@linaro.org>
>>
>
> Can you pick this series?
>
> Regards
> Dong Aisheng
>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* imx6 eSATA
From: Hong-Xing.Zhu at freescale.com @ 2014-01-20 3:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140119041534.GF16158@S2101-09.ap.freescale.net>
Hi:
> -----Original Message-----
> From: Shawn Guo [mailto:shawn.guo at linaro.org]
> Sent: Sunday, January 19, 2014 12:16 PM
> To: Russell King - ARM Linux
> Cc: Sascha Hauer; Zhu Richard-R65037; linux-arm-kernel at lists.infradead.org
> Subject: Re: imx6 eSATA
>
> 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
[Richard] About the configurations of GPR13, first of all, this parameters are used to configure
imx6q ahci sata phy and to co-operated with board properly.
The differences between, 0x0593A044 and 0x0593E4A4 are listed below:
0x0593E4A4 enable the SATA PHY - Spread Spectrum Enable[bit 14]
0x0593A044 doesn't enable the SATA PHY - Spread Spectrum Enable[bit 14]
0x0593E4A4: SATA PHY Tx -Transmit Boost Control[bit10-7] 3.33 dB
0x0593A044: SATA PHY Tx -Transmit Boost Control[bit10-7] 0 dB
0x0593E4A4: SATA PHY - Transmit level settings[bit6-2] 1.025V
0x0593A044: SATA PHY - Transmit level settings[bit6-2] 1.104V
> > 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".
Best Regards
Richard Zhu
^ permalink raw reply
* [PATCH 0/2] DT updates for Hummingboard and new Cubox-i
From: Olof Johansson @ 2014-01-20 3:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140120004434.GV15937@n2100.arm.linux.org.uk>
On Sun, Jan 19, 2014 at 4:44 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sun, Jan 19, 2014 at 10:52:46AM -0800, Olof Johansson wrote:
>> On Sun, Jan 19, 2014 at 11:18:18AM +0800, Shawn Guo wrote:
>> > On Thu, Jan 16, 2014 at 06:22:12PM +0000, Russell King - ARM Linux wrote:
>> > > Now that the Cubox-i has been released, and I have one, I've been able to
>> > > update things a little. Out of the following two patches, the first one
>> > > I think is critical to be merged before the microsom support hits
>> > > mainline, since it drops the flexcan support from the microsom level,
>> > > moving it to the Hummingboard level.
>> >
>> > I will be out of town for a few days, and won't be online until next
>> > weekend. So please send the patch directly to arm-soc folks, so that
>> > they can send it together with imx-dt-3.14 stuff.
>> >
>> > arm-soc folks, please take this as another ping for my imx-dt-3.14 pull
>> > request :)
>>
>> I'm well aware that the DT branch has not been merged, and that's because
>> there has been no consensus from DT maintainers on the massive rework
>> you did as the base of the branch.
>>
>> Given the timing, it's not looking like it will be resolved in time for
>> the 3.14 merge window (which might open today).
>
> Okay, that presumably means that the Hummingboard stuff won't be going in
> through this route, and it sounds like the imx DT stuff will need rework.
>
> Is there any objection if I pushed just the Hummingboard files upstream
> myself?
I'm guessing this is going to mess up Shawn's cleanup patches, but
time has ran out for 3.14 for those so they will need to be respun
anyway, most likely.
We can apply them to arm-soc's dt branch. I think it's better if we
merge them since dts files tend to be one of the conflict-ridden areas
(even if this particular instance isn't). Send the series our way if
you want, or send a branch pull request, your choice.
We're generally somewhat liberal w.r.t. applying brand new dts files
-- just like Greg is liberal with applying new PCI ids in -stable: as
long as they don't break dtbs target compilation there's little reason
to sit on them a whole release if they come in early during the cycle
(pre-rc2 or so).
-Olof
^ permalink raw reply
* [PATCH 1/2] USB: at91: fix the number of endpoint parameter
From: Bo Shen @ 2014-01-20 3:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140118052059.GL9558@ns203013.ovh.net>
Hi J,
On 01/18/2014 01:20 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 10:59 Fri 17 Jan , Bo Shen wrote:
>> In sama5d3 SoC, there are 16 endpoints. As the USBA_NR_ENDPOINTS
>> is only 7. So, fix it for sama5d3 SoC using the udc->num_ep.
>>
>> Signed-off-by: Bo Shen <voice.shen@atmel.com>
>> ---
>>
>> drivers/usb/gadget/atmel_usba_udc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/atmel_usba_udc.c b/drivers/usb/gadget/atmel_usba_udc.c
>> index 2cb52e0..7e67a81 100644
>> --- a/drivers/usb/gadget/atmel_usba_udc.c
>> +++ b/drivers/usb/gadget/atmel_usba_udc.c
>> @@ -1670,7 +1670,7 @@ static irqreturn_t usba_udc_irq(int irq, void *devid)
>> if (ep_status) {
>> int i;
>>
>> - for (i = 0; i < USBA_NR_ENDPOINTS; i++)
>> + for (i = 0; i < udc->num_ep; i++)
>
> no the limit need to specified in the driver as a checkpoint by the compatible
> or platform driver id
You mean, we should not trust the data passed from dt node or platform
data? Or do you think we should do double confirm?
> Best Regards,
> J.
>> if (ep_status & (1 << i)) {
>> if (ep_is_control(&udc->usba_ep[i]))
>> usba_control_irq(udc, &udc->usba_ep[i]);
>> --
>> 1.8.5.2
>>
Best Regards,
Bo Shen
^ permalink raw reply
* [PATCH 0/3] RFC/RFT: Powering on MMC Wifi/BT modules in MMC core
From: Olof Johansson @ 2014-01-20 3:56 UTC (permalink / raw)
To: linux-arm-kernel
This is a small series enhancing the MMC core code to power on modules
before the host in cases where needed, and the corresponding DT bindings
changes.
I've got some other issues to debug on the Chromebook, i.e. the interface
doens't actually work. So far it seems unrelated to this patch set so
it's worth posting this and get things going since others need the same
functionality (i.e Cubox-i).
As mentioned in the patch in the series, I haven't implemented power-down
yet, I wanted to make sure that the power-on side will be adequate for
those who are looking to use it right away.
Comments/test reports/etc welcome.
-Olof
^ 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