* [PATCH] net: fec: Add support for multiple phys on mdiobus
From: Florian Fainelli @ 2013-01-22 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FEAA28.1070003@grandegger.com>
On 01/22/2013 04:03 PM, Wolfgang Grandegger wrote:
> On 01/22/2013 03:47 PM, Florian Fainelli wrote:
>> On 01/22/2013 08:22 AM, Wolfgang Grandegger wrote:
>>>> Well this could be done when the fixed phy driver could be registered
>>>> with the devicetree, maybe like this:
>>>>
>>>> fixed-phy: mdiophy {
>>>> compatible = "mdio-fixed-phy";
>>>> link = "100FD";
>>>> };
>>> I find that confusing. There is *no* phy but just a fixed link to the
>>> switch...
>>>
>>>> The good thing about this would be that every ethernet driver could just
>>>> use such a fixed phy, any external mdio phy (like on Marvell Armada) or
>>>> just a phy connected to the internal mdio interface provided by the
>>>> ethernet
>>>> core.
>>> What is wrong with the existing "fixed-link" property of the *ethernet*
>>> node. The fixed-link handling should/could be done in the phy layer, and
>>> not in the driver as it currently is implemented. Maybe that's the
>>> reason why the current code is regarded as hack!
>> As far as I have used it with the CPMAC driver, the fixed PHY is a
>> specific PHY device and there is no specific handling to be done by the
>> Ethernet MAC driver but eventually changing its MII bus id so that it is
>> named "fixed-0" to allow the fixed PHY driver to bind. Put differently,
> There is special handling for the fixed link, e.g. here:
>
> http://lxr.linux.no/#linux+v3.7.4/drivers/net/ethernet/freescale/gianfar.c#L1462
>
> This could be hidden in the PHY layer allowing all ethernet drivers
> using the "fixed-link" property.
Ok, so in the end you could have potentially an ethernet PHY node
containing the following properties:
- fixed-link
- fixed-speed
- fixed-duplex
and treat it as a fixed-phy. If so, this would be pretty handy.
>
>> using the fixed PHY driver is a kind of "last" resort thing to cope with
>> situations like:
>>
>> - switch not providing a consistent PHY-like interface on the MDC/MDIO bus
>> - switches not connected to the MDC/MDIO bus of the Ethernet MAC they
>> forward to
>>
>> What exactly do you mean by "as it currently is implemented"? that you
>> do not like?
> As Sascha pointed out, the implementation is labeled as "hack", which
> should be fixed sooner than later. It's just not clear why ;).
>
> Wolfgang.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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
* [PATCH 13/15] USB: ehci: make orion and mxc bus glues coexist
From: Alan Stern @ 2013-01-22 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJFYCKFb8F1k5Y6+Q4x5WgTsLO_xh1AFB1mgyRc0xK5m1ABbwA@mail.gmail.com>
On Tue, 22 Jan 2013, Manjunath Goudar wrote:
> > > I think we can actually
> > > get the same results by turning the Kconfig logic around and making
> > > the platform glue drivers 'select USB_EHCI_HCD' than depending on
> > > it.
> >
> > That's a good idea. The Kconfig changes would have to be done
> > carefully to make sure that the dependency on USB_ARCH_HAS_EHCI still
> > applies to all the platform drivers.
> >
> > Manjunath, would you like to send a patch to do this?
> >
> > Alan Stern
> >
> > Ya sure,could you explain little bit briefly about the Kconfig changes.
Suppose you do exactly what Arnd proposed: add "select USB_EHCI_HCD" to
the Kconfig entries for each of the platform glue drivers. Then
consider what would happen in a build where USB_ARCH_HAS_EHCI is "n"
but one of those glue drivers is enabled. There would be conflicting
requirements on USB_EHCI_HCD: The new "select" would force it to be on,
but the existing "depends on USB && USB_ARCH_HAS_EHCI" would force it
to be off. The build would fail.
In order to prevent this, you have to make sure that each glue driver
depends on USB_ARCH_HAS_EHCI. A simple way to do this is to surround
the Kconfig entries for those drivers with "if USB &&
USB_ARCH_HAS_EHCI" ... "endif".
Come to think of it, the "if USB" part really should protect the entire
file.
Alan Stern
^ permalink raw reply
* Mirabox tree
From: Ezequiel Garcia @ 2013-01-22 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130120160347.03553c4e@skate>
Hi Michael,
> On Sat, 19 Jan 2013 19:21:12 +0100, Michael Lawson wrote:
>
> > What I found was that the sd card reader is a pretty standard device,
> > root at mirabox-debian:~# lsusb
> > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 001 Device 003: ID 05e3:0723 Genesys Logic, Inc. GL827L SD/MMC/MS Flash
> > Card Reader
> > Bus 001 Device 004: ID 05e3:0723 Genesys Logic, Inc. GL827L SD/MMC/MS Flash
> > Card Reader
> > Bus 001 Device 002: ID 1a40:0101 TERMINUS TECHNOLOGY INC. USB-2.0 4-Port HUB
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> >
Indeed GL827L controller is USB storage class compliant
(datasheet is publicly avaiable).
This means there's no need for an ad-hoc driver.
All you need to do is pick CONFIG_USB_STORAGE=y.
[snip]
>
> You need the Armada 370 datasheet, which for now, is only available
> under NDA to selected companies and developers, if I'm correct.
> However, as far as USB support on Armada 370 is concerned, the patch
> series for Ezequiel Garcia that I mentioned earlier is sufficient.
> Then, it is a matter of finding or writing a device driver for the
> Genesys Logic USB device.
>
As Thomas says, using my posted USB patches is enough to make USB
host controller work. You need these series:
http://www.spinics.net/lists/arm-kernel/msg217028.html
Now, to access your SD card you only need to select CONFIG_USB_STORAGE.
If you need some more assistance, don't hesitate in asking.
Good luck,
--
Ezequiel Garc?a, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: Santosh Shilimkar @ 2013-01-22 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122145113.GK23505@n2100.arm.linux.org.uk>
On Tuesday 22 January 2013 08:21 PM, Russell King - ARM Linux wrote:
> On Tue, Jan 22, 2013 at 03:44:03PM +0530, Santosh Shilimkar wrote:
>> Sorry for not being clear enough. On OMAP, 32KHz is the only clock which
>> is always running(even during low power states) and hence the clock
>> source and clock event have been clocked using 32KHz clock. As mentioned
>> by RMK, with 32768 Hz clock and HZ = 100, there will be always an
>> error of 0.1 %. This accuracy also impacts the timer tick interval.
>> This was the reason, OMAP has been using the HZ = 128.
>
> Ok. Let's look at this. As far as time-of-day is concerned, this
> shouldn't really matter with the clocksource/clockevent based system
> that we now have (where *important point* platforms have been converted
> over.)
>
> Any platform providing a clocksource will override the jiffy-based
> clocksource. The measurement of time-of-day passing is now based on
> the difference in values read from the clocksource, not from the actual
> tick rate.
>
> Anything _not_ providing a clock source will be reliant on jiffies
> incrementing, which in turn _requires_ one timer interrupt per jiffies
> at a known rate (which is HZ).
>
> Now, that's the time of day, what about jiffies? Well, jiffies is
> incremented based on a certain number of nsec having passed since the
> last jiffy update. That means the code copes with dropped ticks and
> the like.
>
> However, if your actual interrupt rate is close to the desired HZ, then
> it can lead to some interesting effects (and noise):
>
> - if the interrupt rate is slightly faster than HZ, then you can end up
> with updates being delayed by 2x interrupt rate.
> - if the interrupt rate is slightly slower than HZ, you can occasionally
> end up with jiffies incrementing by two.
> - if your interrupt rate is dead on HZ, then other system noise can come
> into effect and you may get maybe zero, one or two jiffy increments per
> interrupt.
>
> (You have to think about time passing in NS, where jiffy updates should
> be vs where the timer interrupts happen.) See tick_do_update_jiffies64()
> for the details.
>
> The timer infrastructure is jiffy based - which includes scheduling where
> the scheduler does not use hrtimers. That means a slight discrepency
> between HZ and the actual interrupt rate can cause around 1/HZ jitter.
> That's a matter of fact due to how the code works.
>
> So, actually, I think the accuracy of HZ has much overall effect _provided_
> a platform provides a clocksource to the accuracy of jiffy based timers
> nor timekeeping. For those which don't, the accuracy of the timer
> interrupt to HZ is very important.
>
> (This is just based on reading some code and not on practical
> experiments - I'd suggest some research of this is done, trying HZ=100
> on OMAP's 32kHz timers, checking whether there's any drift, checking
> how accurately a single task can be woken from various select/poll/epoll
> delays, and checking whether NTP works.)
>
Thanks for expanding it. It is really helpful.
> And I think further discussion is pointless until such research has been
> done (or someone who _really_ knows the time keeping/timer/sched code
> inside out comments.)
>
Fully agree about experimentation to re-asses the drift.
From what I recollect from past, few OMAP customers did
report the time drift issue and that is how the switch
from 100 --> 128 happened.
Anyway I have added the suggested task to my long todo list.
Regards,
Santosh
^ permalink raw reply
* [PATCH] net: fec: Add support for multiple phys on mdiobus
From: Wolfgang Grandegger @ 2013-01-22 15:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FEA691.4050904@openwrt.org>
On 01/22/2013 03:47 PM, Florian Fainelli wrote:
> On 01/22/2013 08:22 AM, Wolfgang Grandegger wrote:
>>> Well this could be done when the fixed phy driver could be registered
>>> with the devicetree, maybe like this:
>>>
>>> fixed-phy: mdiophy {
>>> compatible = "mdio-fixed-phy";
>>> link = "100FD";
>>> };
>>
>> I find that confusing. There is *no* phy but just a fixed link to the
>> switch...
>>
>>> The good thing about this would be that every ethernet driver could just
>>> use such a fixed phy, any external mdio phy (like on Marvell Armada) or
>>> just a phy connected to the internal mdio interface provided by the
>>> ethernet
>>> core.
>>
>> What is wrong with the existing "fixed-link" property of the *ethernet*
>> node. The fixed-link handling should/could be done in the phy layer, and
>> not in the driver as it currently is implemented. Maybe that's the
>> reason why the current code is regarded as hack!
>
> As far as I have used it with the CPMAC driver, the fixed PHY is a
> specific PHY device and there is no specific handling to be done by the
> Ethernet MAC driver but eventually changing its MII bus id so that it is
> named "fixed-0" to allow the fixed PHY driver to bind. Put differently,
There is special handling for the fixed link, e.g. here:
http://lxr.linux.no/#linux+v3.7.4/drivers/net/ethernet/freescale/gianfar.c#L1462
This could be hidden in the PHY layer allowing all ethernet drivers
using the "fixed-link" property.
> using the fixed PHY driver is a kind of "last" resort thing to cope with
> situations like:
>
> - switch not providing a consistent PHY-like interface on the MDC/MDIO bus
> - switches not connected to the MDC/MDIO bus of the Ethernet MAC they
> forward to
>
> What exactly do you mean by "as it currently is implemented"? that you
> do not like?
As Sascha pointed out, the implementation is labeled as "hack", which
should be fixed sooner than later. It's just not clear why ;).
Wolfgang.
^ permalink raw reply
* One of these things (CONFIG_HZ) is not like the others..
From: Russell King - ARM Linux @ 2013-01-22 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FE666B.10902@ti.com>
On Tue, Jan 22, 2013 at 03:44:03PM +0530, Santosh Shilimkar wrote:
> Sorry for not being clear enough. On OMAP, 32KHz is the only clock which
> is always running(even during low power states) and hence the clock
> source and clock event have been clocked using 32KHz clock. As mentioned
> by RMK, with 32768 Hz clock and HZ = 100, there will be always an
> error of 0.1 %. This accuracy also impacts the timer tick interval.
> This was the reason, OMAP has been using the HZ = 128.
Ok. Let's look at this. As far as time-of-day is concerned, this
shouldn't really matter with the clocksource/clockevent based system
that we now have (where *important point* platforms have been converted
over.)
Any platform providing a clocksource will override the jiffy-based
clocksource. The measurement of time-of-day passing is now based on
the difference in values read from the clocksource, not from the actual
tick rate.
Anything _not_ providing a clock source will be reliant on jiffies
incrementing, which in turn _requires_ one timer interrupt per jiffies
at a known rate (which is HZ).
Now, that's the time of day, what about jiffies? Well, jiffies is
incremented based on a certain number of nsec having passed since the
last jiffy update. That means the code copes with dropped ticks and
the like.
However, if your actual interrupt rate is close to the desired HZ, then
it can lead to some interesting effects (and noise):
- if the interrupt rate is slightly faster than HZ, then you can end up
with updates being delayed by 2x interrupt rate.
- if the interrupt rate is slightly slower than HZ, you can occasionally
end up with jiffies incrementing by two.
- if your interrupt rate is dead on HZ, then other system noise can come
into effect and you may get maybe zero, one or two jiffy increments per
interrupt.
(You have to think about time passing in NS, where jiffy updates should
be vs where the timer interrupts happen.) See tick_do_update_jiffies64()
for the details.
The timer infrastructure is jiffy based - which includes scheduling where
the scheduler does not use hrtimers. That means a slight discrepency
between HZ and the actual interrupt rate can cause around 1/HZ jitter.
That's a matter of fact due to how the code works.
So, actually, I think the accuracy of HZ has much overall effect _provided_
a platform provides a clocksource to the accuracy of jiffy based timers
nor timekeeping. For those which don't, the accuracy of the timer
interrupt to HZ is very important.
(This is just based on reading some code and not on practical
experiments - I'd suggest some research of this is done, trying HZ=100
on OMAP's 32kHz timers, checking whether there's any drift, checking
how accurately a single task can be woken from various select/poll/epoll
delays, and checking whether NTP works.)
And I think further discussion is pointless until such research has been
done (or someone who _really_ knows the time keeping/timer/sched code
inside out comments.)
^ permalink raw reply
* [GIT PULL] imx cleanup for 3.9
From: Shawn Guo @ 2013-01-22 14:48 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit a49f0d1ea3ec94fc7cf33a7c36a16343b74bd565:
Linux 3.8-rc1 (2012-12-21 17:19:00 -0800)
are available in the git repository at:
git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-cleanup-3.9
for you to fetch changes up to 6faa0b731160d2b0e49796191ad124f564b021f0:
ARM: imx: Remove mx508 support (2013-01-22 22:26:44 +0800)
----------------------------------------------------------------
IMX cleanup for 3.9:
* Board level dts shuffling to use node label
* Remove lluart.c by using debug_ll_io_init()
* Remove mach-mx51_3ds board support
* Remove imx50 support which has been BROKEN for cycles
* Other trival cleanups
----------------------------------------------------------------
Fabio Estevam (5):
ARM: mach-imx: Kconfig: Do not select Babbage for MACH_IMX51_DT
ARM: dts: imx27-3ds: Rename it to imx27-pdk
ARM: boot: dts: Add an entry for imx27-pdk.dtb
ARM: imx: Remove mach-mx51_3ds board
ARM: imx: Remove mx508 support
Shawn Guo (4):
ARM: dts: add missing imx dtb targets
ARM: dts: imx: use nodes label in board dts
ARM: imx: remove unused imx6q_clock_map_io()
ARM: imx: use debug_ll_io_init() for imx6q
Documentation/devicetree/bindings/arm/fsl.txt | 4 +
arch/arm/Kconfig.debug | 10 +-
arch/arm/boot/dts/Makefile | 7 +-
arch/arm/boot/dts/imx25-karo-tx25.dts | 30 +-
arch/arm/boot/dts/imx25.dtsi | 2 +-
arch/arm/boot/dts/imx27-apf27.dts | 82 +-
arch/arm/boot/dts/{imx27-3ds.dts => imx27-pdk.dts} | 24 +-
arch/arm/boot/dts/imx31-bug.dts | 12 +-
arch/arm/boot/dts/imx51-babbage.dts | 456 +++++----
arch/arm/boot/dts/imx53-ard.dts | 126 ++-
arch/arm/boot/dts/imx53-evk.dts | 194 ++--
arch/arm/boot/dts/imx53-qsb.dts | 380 ++++----
arch/arm/boot/dts/imx53-smd.dts | 294 +++---
arch/arm/boot/dts/imx6q-arm2.dts | 124 ++-
arch/arm/boot/dts/imx6q-sabreauto.dts | 64 +-
arch/arm/boot/dts/imx6q-sabrelite.dts | 216 +++--
arch/arm/boot/dts/imx6q-sabresd.dts | 102 +-
arch/arm/boot/dts/imx6q.dtsi | 2 +-
arch/arm/configs/imx_v6_v7_defconfig | 1 -
arch/arm/include/debug/imx.S | 2 +-
arch/arm/mach-imx/Kconfig | 36 -
arch/arm/mach-imx/Makefile | 3 -
arch/arm/mach-imx/Makefile.boot | 4 -
arch/arm/mach-imx/clk-imx6q.c | 2 -
arch/arm/mach-imx/common.h | 11 -
arch/arm/mach-imx/cpu-imx5.c | 39 -
arch/arm/mach-imx/devices-imx50.h | 33 -
arch/arm/mach-imx/devices/Kconfig | 2 +-
arch/arm/mach-imx/devices/platform-fec.c | 6 -
arch/arm/mach-imx/devices/platform-imx-i2c.c | 10 -
arch/arm/mach-imx/devices/platform-imx-uart.c | 12 -
arch/arm/mach-imx/hardware.h | 6 -
arch/arm/mach-imx/iomux-mx50.h | 977 --------------------
arch/arm/mach-imx/lluart.c | 47 -
arch/arm/mach-imx/mach-imx6q.c | 4 +-
arch/arm/mach-imx/mach-mx50_rdp.c | 225 -----
arch/arm/mach-imx/mach-mx51_3ds.c | 178 ----
arch/arm/mach-imx/mm-imx5.c | 48 -
arch/arm/mach-imx/mx50.h | 290 ------
arch/arm/mach-imx/mxc.h | 13 -
arch/arm/mach-imx/pm-imx5.c | 7 +-
41 files changed, 1031 insertions(+), 3054 deletions(-)
rename arch/arm/boot/dts/{imx27-3ds.dts => imx27-pdk.dts} (59%)
delete mode 100644 arch/arm/mach-imx/devices-imx50.h
delete mode 100644 arch/arm/mach-imx/iomux-mx50.h
delete mode 100644 arch/arm/mach-imx/lluart.c
delete mode 100644 arch/arm/mach-imx/mach-mx50_rdp.c
delete mode 100644 arch/arm/mach-imx/mach-mx51_3ds.c
delete mode 100644 arch/arm/mach-imx/mx50.h
^ permalink raw reply
* [PATCH v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
From: Roger Quadros @ 2013-01-22 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FEA447.1090701@ti.com>
On 01/22/2013 04:37 PM, kishon wrote:
> On Tuesday 22 January 2013 07:47 PM, Roger Quadros wrote:
>> On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
>>> The OMAP glue has been modified to get PHY by phandle for dt boot.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>> ---
>>> drivers/usb/musb/omap2430.c | 7 ++++++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>>> index 1a8cf6d..e43faeb 100644
>>> --- a/drivers/usb/musb/omap2430.c
>>> +++ b/drivers/usb/musb/omap2430.c
>>> @@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
>>> * up through ULPI. TWL4030-family PMICs include one,
>>> * which needs a driver, drivers aren't always needed.
>>> */
>>> - musb->xceiv = devm_usb_get_phy_dev(dev, 0);
>>> + if (dev->parent->of_node)
>>> + musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
>>> + "usb_phy", 0);
>>> + else
>>> + musb->xceiv = devm_usb_get_phy_dev(dev, 0);
>>> +
>>> if (IS_ERR_OR_NULL(musb->xceiv)) {
>>> pr_err("HS USB OTG: no transceiver configured\n");
>>> return -ENODEV;
>>
>> This will not work with PHY driver as a module. You need to use deferred probing mechanism here
>> after you have addressed my comment in patch 2 and also devm_usb_get_phy_by_phandle()
>
> IIUC, even using -EPROBE_DEFER might not help if we are making the PHY driver as module, since the kernel will try to probe only till the prompt comes.
>
Oh really? I thought deferred probing takes place whenever a new driver is bound to a device. What does "prompt comes" have to do with it?
> And having -EPROBE_DEFER instead of -ENODEV might also not help since, the gadget driver wont be able to bind to UDC (usb_gadget_probe_driver will fail).
>
> A lot of things need to be changed before we change to -EPROBE_DEFER IMO.
OK.
--
cheers,
-roger
^ permalink raw reply
* [PATCH] net: fec: Add support for multiple phys on mdiobus
From: Florian Fainelli @ 2013-01-22 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FE3E37.4010004@grandegger.com>
On 01/22/2013 08:22 AM, Wolfgang Grandegger wrote:
>> Well this could be done when the fixed phy driver could be registered
>> with the devicetree, maybe like this:
>>
>> fixed-phy: mdiophy {
>> compatible = "mdio-fixed-phy";
>> link = "100FD";
>> };
>
> I find that confusing. There is *no* phy but just a fixed link to the
> switch...
>
>> The good thing about this would be that every ethernet driver could just
>> use such a fixed phy, any external mdio phy (like on Marvell Armada) or
>> just a phy connected to the internal mdio interface provided by the ethernet
>> core.
>
> What is wrong with the existing "fixed-link" property of the *ethernet*
> node. The fixed-link handling should/could be done in the phy layer, and
> not in the driver as it currently is implemented. Maybe that's the
> reason why the current code is regarded as hack!
As far as I have used it with the CPMAC driver, the fixed PHY is a
specific PHY device and there is no specific handling to be done by the
Ethernet MAC driver but eventually changing its MII bus id so that it is
named "fixed-0" to allow the fixed PHY driver to bind. Put differently,
using the fixed PHY driver is a kind of "last" resort thing to cope with
situations like:
- switch not providing a consistent PHY-like interface on the MDC/MDIO bus
- switches not connected to the MDC/MDIO bus of the Ethernet MAC they
forward to
What exactly do you mean by "as it currently is implemented"? that you
do not like?
--
Florian
^ permalink raw reply
* [GIT PULL] imx fixes for 3.8, take 3
From: Shawn Guo @ 2013-01-22 14:44 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 83ae20981ae924c37d02a42c829155fc3851260c:
ARM: imx: correct low-power mode setting (2013-01-14 22:19:48 +0800)
are available in the git repository at:
git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-fixes-3.8-3
for you to fetch changes up to e6b267ce14f61d9da0151b97ee26ab4d38055567:
video: imxfb: Do not crash on reboot (2013-01-17 16:14:29 +0800)
----------------------------------------------------------------
This is yet another critical imxfb fixes held off by absence of FB
maintainer for some time.
----------------------------------------------------------------
Fabio Estevam (1):
video: imxfb: Do not crash on reboot
drivers/video/imxfb.c | 10 ++++++++++
1 file changed, 10 insertions(+)
^ permalink raw reply
* [PATCH v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
From: kishon @ 2013-01-22 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FE9F5C.2010501@ti.com>
On Tuesday 22 January 2013 07:47 PM, Roger Quadros wrote:
> On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
>> The OMAP glue has been modified to get PHY by phandle for dt boot.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>> drivers/usb/musb/omap2430.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
>> index 1a8cf6d..e43faeb 100644
>> --- a/drivers/usb/musb/omap2430.c
>> +++ b/drivers/usb/musb/omap2430.c
>> @@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
>> * up through ULPI. TWL4030-family PMICs include one,
>> * which needs a driver, drivers aren't always needed.
>> */
>> - musb->xceiv = devm_usb_get_phy_dev(dev, 0);
>> + if (dev->parent->of_node)
>> + musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
>> + "usb_phy", 0);
>> + else
>> + musb->xceiv = devm_usb_get_phy_dev(dev, 0);
>> +
>> if (IS_ERR_OR_NULL(musb->xceiv)) {
>> pr_err("HS USB OTG: no transceiver configured\n");
>> return -ENODEV;
>
> This will not work with PHY driver as a module. You need to use deferred probing mechanism here
> after you have addressed my comment in patch 2 and also devm_usb_get_phy_by_phandle()
IIUC, even using -EPROBE_DEFER might not help if we are making the PHY
driver as module, since the kernel will try to probe only till the
prompt comes.
And having -EPROBE_DEFER instead of -ENODEV might also not help since,
the gadget driver wont be able to bind to UDC (usb_gadget_probe_driver
will fail).
A lot of things need to be changed before we change to -EPROBE_DEFER IMO.
Thanks
Kishon
^ permalink raw reply
* [PATCH V2 0/5] W1: Support onewire master on i.MX53
From: Mark Rutland @ 2013-01-22 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FEA1B0.7060600@parkeon.com>
On Tue, Jan 22, 2013 at 02:26:56PM +0000, Martin Fuzzey wrote:
> On 22/01/13 15:09, Shawn Guo wrote:
> > On Tue, Jan 22, 2013 at 09:27:12AM +0100, Sascha Hauer wrote:
> >> On Wed, Jan 16, 2013 at 03:57:49PM +0100, Martin Fuzzey wrote:
> >>> W1: Support onewire master on i.MX53
> >>> * Add device tree and pinctrl support to the MXC master driver
> >>> * Convert to use devm_
> >>> * Add i.MX53 clocks
> >>> * Add i.MX53 device tree entries
> >>>
> >>> Changes since V1
> >>> * Applied comments from Sascha Hauer:
> >>> * Move patch converting driver to devm_ before the one adding devm_ based pinctrl
> >>> * Fix existing unbalanced clk_prepare_enable/clk_disable_unprepare
> >>> in probe error path
> >>>
> >>> * Place DT patch last since it includes pinctrls for driver.
> >> This looks good now.
> >>
> >> Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
> >>
> >> You might have to send this again in two series, one for the w1
> >> maintainer and one for arm-soc. Both series should be sufficiently
> >> orthogonal.
> >>
> > Evgeniy has already ACK-ed the v1 series, so maybe he does not see any
> > problem with the whole series going through one tree. In that case,
> > we may just have it go via arm-soc tree? Otherwise, please let us
> > know, Evgeniy.
> >
> > Shawn
> >
> There was also the question raised by Mark Rutland on the DT compatible
> string.
> Currently this is "fsl,imx21-owire" but Mark thought "fsl,imx21-w1" to
> be better.
Your reasoning that "fsl,imx21-owire" better matched the hardware name is
convincing -- bindings don't have to match the Linux view of things. I'm happy
either way, as long as the binding is documented.
Apologies for any inconvenience I've caused.
> Do I take your Acks to mean "fsl,imx21-owire" is OK?
> I should add a Documentation file for the DT binding too but I was
> waiting for consensus
> on the compatible string first.
>
> Martin
>
>
Thanks,
Mark.
^ permalink raw reply
* [PATCH V2 0/5] W1: Support onewire master on i.MX53
From: Martin Fuzzey @ 2013-01-22 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122140941.GA4920@S2101-09.ap.freescale.net>
On 22/01/13 15:09, Shawn Guo wrote:
> On Tue, Jan 22, 2013 at 09:27:12AM +0100, Sascha Hauer wrote:
>> On Wed, Jan 16, 2013 at 03:57:49PM +0100, Martin Fuzzey wrote:
>>> W1: Support onewire master on i.MX53
>>> * Add device tree and pinctrl support to the MXC master driver
>>> * Convert to use devm_
>>> * Add i.MX53 clocks
>>> * Add i.MX53 device tree entries
>>>
>>> Changes since V1
>>> * Applied comments from Sascha Hauer:
>>> * Move patch converting driver to devm_ before the one adding devm_ based pinctrl
>>> * Fix existing unbalanced clk_prepare_enable/clk_disable_unprepare
>>> in probe error path
>>>
>>> * Place DT patch last since it includes pinctrls for driver.
>> This looks good now.
>>
>> Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
>>
>> You might have to send this again in two series, one for the w1
>> maintainer and one for arm-soc. Both series should be sufficiently
>> orthogonal.
>>
> Evgeniy has already ACK-ed the v1 series, so maybe he does not see any
> problem with the whole series going through one tree. In that case,
> we may just have it go via arm-soc tree? Otherwise, please let us
> know, Evgeniy.
>
> Shawn
>
There was also the question raised by Mark Rutland on the DT compatible
string.
Currently this is "fsl,imx21-owire" but Mark thought "fsl,imx21-w1" to
be better.
Do I take your Acks to mean "fsl,imx21-owire" is OK?
I should add a Documentation file for the DT binding too but I was
waiting for consensus
on the compatible string first.
Martin
^ permalink raw reply
* [PATCH] ARM: imx: Remove mx508 support
From: Shawn Guo @ 2013-01-22 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358858455-9600-1-git-send-email-fabio.estevam@freescale.com>
On Tue, Jan 22, 2013 at 10:40:55AM -0200, Fabio Estevam wrote:
> Only mx508 based board is mach-mx50_rdp and it has been marked as BROKEN
> for several releases.
>
> mx508 currently lacks clock support.
>
> In case someone needs to add mx508 support back, then the recommended approach
> is to use device tree.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Applied, thanks.
^ permalink raw reply
* [PATCH v1 6/6] USB: MUSB: OMAP: get PHY by phandle for dt boot
From: Roger Quadros @ 2013-01-22 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358848694-20145-7-git-send-email-kishon@ti.com>
On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
> The OMAP glue has been modified to get PHY by phandle for dt boot.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/usb/musb/omap2430.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index 1a8cf6d..e43faeb 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -345,7 +345,12 @@ static int omap2430_musb_init(struct musb *musb)
> * up through ULPI. TWL4030-family PMICs include one,
> * which needs a driver, drivers aren't always needed.
> */
> - musb->xceiv = devm_usb_get_phy_dev(dev, 0);
> + if (dev->parent->of_node)
> + musb->xceiv = devm_usb_get_phy_by_phandle(dev->parent,
> + "usb_phy", 0);
> + else
> + musb->xceiv = devm_usb_get_phy_dev(dev, 0);
> +
> if (IS_ERR_OR_NULL(musb->xceiv)) {
> pr_err("HS USB OTG: no transceiver configured\n");
> return -ENODEV;
This will not work with PHY driver as a module. You need to use deferred probing mechanism here
after you have addressed my comment in patch 2 and also devm_usb_get_phy_by_phandle()
e.g.
if (IS_ERR(musb->xceiv)) {
int ret = PTR_ERR(musb->xveiv);
if (ret == -ENODEV)
pr_err("HS USB OTG: no transceiver configured\n");
return ret;
}
--
cheers,
-roger
^ permalink raw reply
* [PATCH v1 2/6] usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type
From: kishon @ 2013-01-22 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FE9D1E.3010800@ti.com>
Hi,
On Tuesday 22 January 2013 07:37 PM, Roger Quadros wrote:
> On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
>> In order to add support for multipe PHY's of the same type, new API's
>> for adding PHY and getting PHY has been added. Now the binding
>> information for the PHY and controller should be done in platform file
>> using usb_bind_phy API. And for getting a PHY, the device pointer of the
>> USB controller and an index should be passed. Based on the binding
>> information that is added in the platform file, usb_get_phy_dev will return the
>> appropriate PHY.
>> Already existing API's to add and get phy by type is not removed. These
>> API's are deprecated and will be removed once all the platforms start to
>> use the new API.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>> drivers/usb/otg/otg.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++-
>> include/linux/usb/phy.h | 13 ++++++
>> 2 files changed, 126 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
>> index 492ba2f..1f30b22 100644
>> --- a/drivers/usb/otg/otg.c
>> +++ b/drivers/usb/otg/otg.c
>> @@ -36,6 +36,20 @@ static struct usb_phy *__usb_find_phy(struct list_head *list,
>> return ERR_PTR(-ENODEV);
>> }
>>
>> +static struct usb_phy *__usb_find_phy_dev(struct device *dev,
>> + struct list_head *list, u8 index)
>> +{
>> + struct usb_phy_bind *phy_bind = NULL;
>> +
>> + list_for_each_entry(phy_bind, list, list) {
>> + if (!(strcmp(phy_bind->dev_name, dev_name(dev))) &&
>> + phy_bind->index == index)
>> + return phy_bind->phy;
>
> If the PHY driver has not yet called usb_add_phy_dev() (e.g. driver not yet loaeded)
> then this will return NULL.
>
>> + }
>> +
>> + return ERR_PTR(-ENODEV);
>> +}
>> +
>> static void devm_usb_phy_release(struct device *dev, void *res)
>> {
>> struct usb_phy *phy = *(struct usb_phy **)res;
>> @@ -112,6 +126,69 @@ err0:
>> EXPORT_SYMBOL(usb_get_phy);
>>
>> /**
>> + * usb_get_phy_dev - find the USB PHY
>> + * @dev - device that requests this phy
>> + * @index - the index of the phy
>> + *
>> + * Returns the phy driver, after getting a refcount to it; or
>> + * -ENODEV if there is no such phy. The caller is responsible for
>> + * calling usb_put_phy() to release that count.
>> + *
>> + * For use by USB host and peripheral drivers.
>> + */
>> +struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index)
>> +{
>> + struct usb_phy *phy = NULL;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&phy_lock, flags);
>> +
>> + phy = __usb_find_phy_dev(dev, &phy_bind_list, index);
>> + if (IS_ERR(phy)) {
>> + pr_err("unable to find transceiver\n");
>> + goto err0;
>> + }
>
> Since NULL is not IS_ERR(), you will do a NULL pointer reference below.
>
> In such cases we would want to use the deferred probe mechanism. So should we return
> -EPROBE_DEFER?
Good catch. I'll update the patch.
Thanks
Kishon
^ permalink raw reply
* [PATCH V2 0/5] W1: Support onewire master on i.MX53
From: Shawn Guo @ 2013-01-22 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122082712.GJ1906@pengutronix.de>
On Tue, Jan 22, 2013 at 09:27:12AM +0100, Sascha Hauer wrote:
> On Wed, Jan 16, 2013 at 03:57:49PM +0100, Martin Fuzzey wrote:
> > W1: Support onewire master on i.MX53
> > * Add device tree and pinctrl support to the MXC master driver
> > * Convert to use devm_
> > * Add i.MX53 clocks
> > * Add i.MX53 device tree entries
> >
> > Changes since V1
> > * Applied comments from Sascha Hauer:
> > * Move patch converting driver to devm_ before the one adding devm_ based pinctrl
> > * Fix existing unbalanced clk_prepare_enable/clk_disable_unprepare
> > in probe error path
> >
> > * Place DT patch last since it includes pinctrls for driver.
>
> This looks good now.
>
> Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> You might have to send this again in two series, one for the w1
> maintainer and one for arm-soc. Both series should be sufficiently
> orthogonal.
>
Evgeniy has already ACK-ed the v1 series, so maybe he does not see any
problem with the whole series going through one tree. In that case,
we may just have it go via arm-soc tree? Otherwise, please let us
know, Evgeniy.
Shawn
^ permalink raw reply
* [PATCH v1 4/6] drivers: usb: musb: omap: make use of the new PHY lib APIs
From: Roger Quadros @ 2013-01-22 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358848694-20145-5-git-send-email-kishon@ti.com>
On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
> New PHY lib APIs like usb_add_phy_dev() and devm_usb_get_phy_dev() are
> used in MUSB (OMAP), in order to make use of the binding information
> provided in the board file (of OMAP platforms).
> All the platforms should be modified similar to this to add and get the
> PHY.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/usb/musb/omap2430.c | 2 +-
> drivers/usb/otg/twl4030-usb.c | 3 ++-
> drivers/usb/phy/omap-usb2.c | 3 ++-
> 3 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index bf6cfe0..1a8cf6d 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -345,7 +345,7 @@ static int omap2430_musb_init(struct musb *musb)
> * up through ULPI. TWL4030-family PMICs include one,
> * which needs a driver, drivers aren't always needed.
> */
> - musb->xceiv = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> + musb->xceiv = devm_usb_get_phy_dev(dev, 0);
> if (IS_ERR_OR_NULL(musb->xceiv)) {
> pr_err("HS USB OTG: no transceiver configured\n");
> return -ENODEV;
> diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
> index 0a70193..a994715 100644
> --- a/drivers/usb/otg/twl4030-usb.c
> +++ b/drivers/usb/otg/twl4030-usb.c
> @@ -610,6 +610,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
> twl->phy.dev = twl->dev;
> twl->phy.label = "twl4030";
> twl->phy.otg = otg;
> + twl->phy.type = USB_PHY_TYPE_USB2;
What is the need to set phy.type? I think this should be deprecated along with the old API.
> twl->phy.set_suspend = twl4030_set_suspend;
>
> otg->phy = &twl->phy;
> @@ -624,7 +625,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
> dev_err(&pdev->dev, "ldo init failed\n");
> return err;
> }
> - usb_add_phy(&twl->phy, USB_PHY_TYPE_USB2);
> + usb_add_phy_dev(&twl->phy);
>
> platform_set_drvdata(pdev, twl);
> if (device_create_file(&pdev->dev, &dev_attr_vbus))
> diff --git a/drivers/usb/phy/omap-usb2.c b/drivers/usb/phy/omap-usb2.c
> index 4b59b39..b5c759c 100644
> --- a/drivers/usb/phy/omap-usb2.c
> +++ b/drivers/usb/phy/omap-usb2.c
> @@ -143,6 +143,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
> phy->phy.label = "omap-usb2";
> phy->phy.set_suspend = omap_usb2_suspend;
> phy->phy.otg = otg;
> + phy->phy.type = USB_PHY_TYPE_USB2;
same here.
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>
> @@ -168,7 +169,7 @@ static int omap_usb2_probe(struct platform_device *pdev)
> }
> clk_prepare(phy->wkupclk);
>
> - usb_add_phy(&phy->phy, USB_PHY_TYPE_USB2);
> + usb_add_phy_dev(&phy->phy);
>
> platform_set_drvdata(pdev, phy);
>
>
--
cheers,
-roger
^ permalink raw reply
* [PATCH v1 2/6] usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type
From: Roger Quadros @ 2013-01-22 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358848694-20145-3-git-send-email-kishon@ti.com>
On 01/22/2013 11:58 AM, Kishon Vijay Abraham I wrote:
> In order to add support for multipe PHY's of the same type, new API's
> for adding PHY and getting PHY has been added. Now the binding
> information for the PHY and controller should be done in platform file
> using usb_bind_phy API. And for getting a PHY, the device pointer of the
> USB controller and an index should be passed. Based on the binding
> information that is added in the platform file, usb_get_phy_dev will return the
> appropriate PHY.
> Already existing API's to add and get phy by type is not removed. These
> API's are deprecated and will be removed once all the platforms start to
> use the new API.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
> ---
> drivers/usb/otg/otg.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++-
> include/linux/usb/phy.h | 13 ++++++
> 2 files changed, 126 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
> index 492ba2f..1f30b22 100644
> --- a/drivers/usb/otg/otg.c
> +++ b/drivers/usb/otg/otg.c
> @@ -36,6 +36,20 @@ static struct usb_phy *__usb_find_phy(struct list_head *list,
> return ERR_PTR(-ENODEV);
> }
>
> +static struct usb_phy *__usb_find_phy_dev(struct device *dev,
> + struct list_head *list, u8 index)
> +{
> + struct usb_phy_bind *phy_bind = NULL;
> +
> + list_for_each_entry(phy_bind, list, list) {
> + if (!(strcmp(phy_bind->dev_name, dev_name(dev))) &&
> + phy_bind->index == index)
> + return phy_bind->phy;
If the PHY driver has not yet called usb_add_phy_dev() (e.g. driver not yet loaeded)
then this will return NULL.
> + }
> +
> + return ERR_PTR(-ENODEV);
> +}
> +
> static void devm_usb_phy_release(struct device *dev, void *res)
> {
> struct usb_phy *phy = *(struct usb_phy **)res;
> @@ -112,6 +126,69 @@ err0:
> EXPORT_SYMBOL(usb_get_phy);
>
> /**
> + * usb_get_phy_dev - find the USB PHY
> + * @dev - device that requests this phy
> + * @index - the index of the phy
> + *
> + * Returns the phy driver, after getting a refcount to it; or
> + * -ENODEV if there is no such phy. The caller is responsible for
> + * calling usb_put_phy() to release that count.
> + *
> + * For use by USB host and peripheral drivers.
> + */
> +struct usb_phy *usb_get_phy_dev(struct device *dev, u8 index)
> +{
> + struct usb_phy *phy = NULL;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&phy_lock, flags);
> +
> + phy = __usb_find_phy_dev(dev, &phy_bind_list, index);
> + if (IS_ERR(phy)) {
> + pr_err("unable to find transceiver\n");
> + goto err0;
> + }
Since NULL is not IS_ERR(), you will do a NULL pointer reference below.
In such cases we would want to use the deferred probe mechanism. So should we return
-EPROBE_DEFER?
> +
> + get_device(phy->dev);
> +
> +err0:
> + spin_unlock_irqrestore(&phy_lock, flags);
> +
> + return phy;
> +}
> +EXPORT_SYMBOL(usb_get_phy_dev);
> +
--
cheers,
-roger
^ permalink raw reply
* [GIT PULL] U300-related COH901318 cleanup
From: Linus Walleij @ 2013-01-22 13:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi ARM SoC guys,
This pushes the platform data for the COH901318 DMA controller down
into the driver so it is self-contained as a cleanup for the U300 machine.
Since roughly 50% of this patch affects arch/arm/mach* and we may want
to build additional cleanups on top, we need to take this into the ARM
SoC tree.
All patches are ACKed by the DMA subsystem maintainer.
Please pull it into ARM SoC!
Yours,
Linus Walleij
The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:
Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)
are available in the git repository at:
http://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
tags/coh901318-for-arm-soc
for you to fetch changes up to 73b31eaee7f02946dbb0bfabbee72ab6f0117bfb:
dma: coh901318: cut down on platform data abstraction (2013-01-07
17:36:41 +0100)
----------------------------------------------------------------
This pushes the platform data for the U300 COH901318
DMA controller down into the driver and cleans up in
the <mach/*> namespace for the U300 platform.
----------------------------------------------------------------
Linus Walleij (8):
dma: coh901318: create a proper platform data file
dma: coh901318: push platform data into driver
dma: coh901318: remove hardcoded target addresses
dma: coh901318: skip hard-coded addresses
dma: coh901318: push header down into the DMA subsystem
dma: coh901318: push definitions into driver
dma: coh901318: merge header files
dma: coh901318: cut down on platform data abstraction
arch/arm/mach-u300/core.c | 1087 +--------------------
arch/arm/mach-u300/dma_channels.h | 60 --
arch/arm/mach-u300/include/mach/coh901318.h | 267 ------
arch/arm/mach-u300/spi.c | 3 +-
drivers/dma/coh901318.c | 1302 +++++++++++++++++++++++++-
drivers/dma/{coh901318_lli.h => coh901318.h} | 35 +-
drivers/dma/coh901318_lli.c | 4 +-
include/linux/platform_data/dma-coh901318.h | 72 ++
8 files changed, 1354 insertions(+), 1476 deletions(-)
delete mode 100644 arch/arm/mach-u300/dma_channels.h
delete mode 100644 arch/arm/mach-u300/include/mach/coh901318.h
rename drivers/dma/{coh901318_lli.h => coh901318.h} (81%)
create mode 100644 include/linux/platform_data/dma-coh901318.h
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Mark Jackson @ 2013-01-22 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874ni95ry6.fsf@dell.be.48ers.dk>
On 22/01/13 12:21, Peter Korsgaard wrote:
>>>>>> "Mark" == Mark Jackson <mpfj-list@mimc.co.uk> writes:
>
> Hi,
>
> Mark> Bytes transferred = 3963919 (3c7c0f hex)
> Mark> ## Booting kernel from Legacy Image at 80000000 ...
> Mark> Image Name: Linux
> Mark> Image Type: ARM Linux Kernel Image (uncompressed)
> Mark> Data Size: 3963855 Bytes = 3.8 MiB
> Mark> Load Address: 80008000
> Mark> Entry Point: 80008000
> Mark> Verifying Checksum ... OK
> Mark> Loading Kernel Image ... OK
> Mark> OK
>
> I haven't tried a recent -next build, but what is your kernel command
> line and did you try without EARLY_PRINTK?
>
Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2
rootwait
I understand that MMC is not in the mainline.
Aha ... I tried without EARLY_PRINTK and it now boots up to the point of rootfs access.
Cheers
Mark J.
^ permalink raw reply
* [PATCH 2/2] ARM: dts: exynos5: Set up power domain for MFC and G-scaler
From: Prasanna Kumar @ 2013-01-22 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357733733-18769-3-git-send-email-prasanna.ps@samsung.com>
Hi Kukjin,
Kindly review this patch.
On Wed, Jan 9, 2013 at 5:45 PM, Prasanna Kumar <prasanna.ps@samsung.com> wrote:
> This patch adds device tree nodes for MFC and G-scaler power domains
> of exynos5.It binds these power-domain nodes to repsective device tree nodes.
>
> Signed-off-by: Prasanna Kumar <prasanna.ps@samsung.com>
> ---
> arch/arm/boot/dts/exynos5250.dtsi | 15 +++++++++++++++
> 1 files changed, 15 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
> index 30485de..6d0e87c 100644
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -85,6 +85,7 @@
> compatible = "samsung,mfc-v6";
> reg = <0x11000000 0x10000>;
> interrupts = <0 96 0>;
> + samsung,power-domain = <&pd_mfc>;
> };
>
> rtc {
> @@ -554,28 +555,42 @@
> };
> };
>
> + pd_gsc: gsc-power-domain at 0x10044000 {
> + compatible = "samsung,exynos4210-pd";
> + reg = <0x10044000 0x20>;
> + };
> +
> + pd_mfc: mfc-power-domain at 0x10044040 {
> + compatible = "samsung,exynos4210-pd";
> + reg = <0x10044040 0x20>;
> + };
> +
> gsc_0: gsc at 0x13e00000 {
> compatible = "samsung,exynos5-gsc";
> reg = <0x13e00000 0x1000>;
> interrupts = <0 85 0>;
> + samsung,power-domain = <&pd_gsc>;
> };
>
> gsc_1: gsc at 0x13e10000 {
> compatible = "samsung,exynos5-gsc";
> reg = <0x13e10000 0x1000>;
> interrupts = <0 86 0>;
> + samsung,power-domain = <&pd_gsc>;
> };
>
> gsc_2: gsc at 0x13e20000 {
> compatible = "samsung,exynos5-gsc";
> reg = <0x13e20000 0x1000>;
> interrupts = <0 87 0>;
> + samsung,power-domain = <&pd_gsc>;
> };
>
> gsc_3: gsc at 0x13e30000 {
> compatible = "samsung,exynos5-gsc";
> reg = <0x13e30000 0x1000>;
> interrupts = <0 88 0>;
> + samsung,power-domain = <&pd_gsc>;
> };
>
> hdmi {
> --
> 1.7.5.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks
Prasanna Kumar
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Mark Jackson @ 2013-01-22 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433ECF3DD3@DBDE01.ent.ti.com>
On 22/01/13 13:32, Bedia, Vaibhav wrote:
<snip>
> Following works for me:
>
> Kernel
> ===
> git checkout next-20130122
> make distclean
> make omap2plus_defconfig
> <Enable the appended DTB related options via menuconfig>
> make -j7
> cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone
> mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone
>
> U-Boot
> ===
> Built from v2013.01
<snip>
> A dumb question... in your case what's the bootargs set? Note that the mainline
> kernel for AM335x doesn't have MMC support yet and the default bootargs is set to
> rootfs on MMC.
Yes ... I'm trying to boot from a rootfs on MMC:-
Kernel command line: console=ttyO0,115200n8 earlyprintk debug root=/dev/mmcblk0p2 ro rootfstype=ext2
rootwait
But I should get *something* from the kernel before it starts trying to access the rootfs ?
Regards
Mark J.
^ permalink raw reply
* OMAP baseline test results for v3.8-rc4
From: Bedia, Vaibhav @ 2013-01-22 13:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50FE66AC.2090306@mimc.co.uk>
On Tue, Jan 22, 2013 at 15:45:08, Mark Jackson wrote:
> On 22/01/13 02:24, Paul Walmsley wrote:
> >
> > Hi guys,
> >
> > Regarding the AM33xx test failures with appended DTBs, it would be very
> > helpful if especially the TI people could try reproducing the problem.
>
> My non-working setup (I'm using a recent U-Boot) is as follows ...
>
> [Note that the DTB patch mentioned elsewhere in this thread seems to be *already* applied to -next]
>
> $ git describe
> next-20130121
> $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- omap2plus_defconfig
> $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux- menuconfig
> CONFIG_ARM_APPENDED_DTB=y
> CONFIG_ARM_ATAG_DTB_COMPAT=y
> CONFIG_EARLY_PRINTK=y
> $ make -j 8 ARCH=arm CROSS_COMPILE=arm-linux-
> $ cat arch/arm/boot/zImage arch/arm/boot/dtb/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone
> $ scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0?80008000 -e 0?80008000 -n ?Linux? -d
> arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone
> $ cp arch/arm/boot/uImage-dtb.am335x-bone /tftpboot/nanobone/uImage-dtb
>
> And when I boot:-
>
> U-Boot SPL 2013.01 (Jan 16 2013 - 15:20:58)
> OMAP SD/MMC: 0
> reading u-boot.img
> reading u-boot.img
>
>
> U-Boot 2013.01 (Jan 16 2013 - 15:20:58)
>
> I2C: ready
> DRAM: 256 MiB
> WARNING: Caches not enabled
> NAND: No NAND device found!!!
> 0 MiB
> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> *** Warning - readenv() failed, using default environment
>
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Host mode controller at 47401800 using PIO, IRQ 0
> Net: cpsw, usb_ether
> Hit any key to stop autoboot: 0
> mmc0 is current device
> SD/MMC found on device 0
> reading uEnv.txt
> 167 bytes read in 3 ms (53.7 KiB/s)
> Loaded environment from uEnv.txt
> Importing environment from mmc ...
> Running uenvcmd ...
> cpsw Waiting for PHY auto negotiation to complete. done
> link up on port 0, speed 100, full duplex
> BOOTP broadcast 1
> BOOTP broadcast 2
> *** Unhandled DHCP Option in OFFER/ACK: 44
> *** Unhandled DHCP Option in OFFER/ACK: 46
> *** Unhandled DHCP Option in OFFER/ACK: 44
> *** Unhandled DHCP Option in OFFER/ACK: 46
> DHCP client bound to address 10.0.0.112
> Using cpsw device
> TFTP from server 10.0.0.100; our IP address is 10.0.0.112
> Filename '/nanobone/uImage-dtb'.
> Load address: 0x80000000
> Loading: #################################################################
> #################################################################
> #################################################################
> #################################################################
> ###########
> 627.9 KiB/s
> done
> Bytes transferred = 3963919 (3c7c0f hex)
> ## Booting kernel from Legacy Image at 80000000 ...
> Image Name: Linux
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 3963855 Bytes = 3.8 MiB
> Load Address: 80008000
> Entry Point: 80008000
> Verifying Checksum ... OK
> Loading Kernel Image ... OK
> OK
>
> Starting kernel ...
>
>
Following works for me:
Kernel
===
git checkout next-20130122
make distclean
make omap2plus_defconfig
<Enable the appended DTB related options via menuconfig>
make -j7
cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-bone.dtb > arch/arm/boot/zImage-dtb.am335x-bone
mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n 'Linux' -d arch/arm/boot/zImage-dtb.am335x-bone arch/arm/boot/uImage-dtb.am335x-bone
U-Boot
===
Built from v2013.01
Bootlog
===
U-Boot SPL 2013.01 (Jan 22 2013 - 18:47:57)
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img
U-Boot 2013.01 (Jan 22 2013 - 18:47:57)
I2C: ready
DRAM: 256 MiB
WARNING: Caches not enabled
NAND: No NAND device found!!!
0 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net: cpsw, usb_ether
Hit any key to stop autoboot: 0
U-Boot# setenv serverip 172.24.133.119
U-Boot# setenv bootfile uImage-dtb.am335x-bone
U-Boot# dhcp 80200000
link up on port 0, speed 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 172.24.190.59
Using cpsw device
TFTP from server 172.24.133.119; our IP address is 172.24.190.59; sending through gateway 172.24.188.1
Filename 'uImage-dtb.am335x-bone'.
Load address: 0x80200000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##T ###############################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##########################################################
183.6 KiB/s
done
Bytes transferred = 3956239 (3c5e0f hex)
U-Boot# setenv bootargs console=ttyO0,115200n8 debug ignore_loglevel earlyprintk=serial init=/bin/sh mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536
U-Boot# mmc rescan 0
U-Boot# fatload mmc 0 82000000 ramdisk-pm.gz
reading ramdisk-pm.gz
2022580 bytes read in 252 ms (7.7 MiB/s)
U-Boot# bootm 0x80200000
## Booting kernel from Legacy Image at 80200000 ...
Image Name: Linux
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3956175 Bytes = 3.8 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 3.8.0-rc4-next-20130122 (a0393953 at psplinux063) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1 SMP Tue Jan 22 18:43:06 IST 2013
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
[ 0.000000] debug: ignoring loglevel setting.
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] On node 0 totalpages: 32512
[ 0.000000] free_area_init_node: node 0, pgdat c07d3ec0, node_mem_map c0d35000
[ 0.000000] Normal zone: 256 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 32512 pages, LIFO batch:7
[ 0.000000] AM335X ES1.0 (neon )
[ 0.000000] PERCPU: Embedded 9 pages/cpu @c0e3d000 s13056 r8192 d15616 u36864
[ 0.000000] pcpu-alloc: s13056 r8192 d15616 u36864 alloc=9*4096
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256
[ 0.000000] Kernel command line: console=ttyO0,115200n8 debug ignore_loglevel earlyprintk=serial init=/bin/sh mem=128M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=65536
[ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] __ex_table already sorted, skipping sort
[ 0.000000] Memory: 127MB = 127MB total
[ 0.000000] Memory: 98944k/98944k available, 32128k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] vmalloc : 0xc8800000 - 0xff000000 ( 872 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
[ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000] .text : 0xc0008000 - 0xc06e9880 (7047 kB)
[ 0.000000] .init : 0xc06ea000 - 0xc073e300 ( 337 kB)
[ 0.000000] .data : 0xc0740000 - 0xc07d6860 ( 603 kB)
[ 0.000000] .bss : 0xc07d6860 - 0xc0d317b0 (5484 kB)
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
[ 0.000000] Total of 128 interrupts on 1 active controller
[ 0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz
[ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[ 0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
[ 0.000000] Console: colour dummy device 80x30
[ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 0.000000] ... MAX_LOCK_DEPTH: 48
[ 0.000000] ... MAX_LOCKDEP_KEYS: 8191
[ 0.000000] ... CLASSHASH_SIZE: 4096
[ 0.000000] ... MAX_LOCKDEP_ENTRIES: 16384
[ 0.000000] ... MAX_LOCKDEP_CHAINS: 32768
[ 0.000000] ... CHAINHASH_SIZE: 16384
[ 0.000000] memory used by lock dependency info: 3695 kB
[ 0.000000] per task-struct memory footprint: 1152 bytes
[ 0.001254] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408)
[ 0.109085] pid_max: default: 32768 minimum: 301
[ 0.109681] Security Framework initialized
[ 0.109882] Mount-cache hash table entries: 512
[ 0.121969] CPU: Testing write buffer coherency: ok
[ 0.123774] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[ 0.123868] Setting up static identity map for 0x804ecd48 - 0x804ecdb8
[ 0.127107] Brought up 1 CPUs
[ 0.127140] SMP: Total of 1 processors activated (364.48 BogoMIPS).
[ 0.130829] devtmpfs: initialized
[ 0.146231] ttyO0 used as console in debug mode: uart0 clocks will not be gated
[ 0.209016] pinctrl core: initialized pinctrl subsystem
[ 0.216451] regulator-dummy: no parameters
[ 0.219522] NET: Registered protocol family 16
[ 0.220528] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.222118] omap-gpmc omap-gpmc: GPMC revision 6.0
[ 0.251333] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[ 0.251927] OMAP GPIO hardware version 0.1
[ 0.255800] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[ 0.259807] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[ 0.263355] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[ 0.278062] No ATAGs?
[ 0.278097] hw-breakpoint: debug architecture 0x4 unsupported.
[ 0.282814] Serial: AMBA PL011 UART driver
[ 0.361131] bio: create slab <bio-0> at 0
[ 0.465566] omap-dma-engine omap-dma-engine: OMAP DMA engine driver
[ 0.476999] SCSI subsystem initialized
[ 0.480100] usbcore: registered new interface driver usbfs
[ 0.480733] usbcore: registered new interface driver hub
[ 0.481725] usbcore: registered new device driver usb
[ 0.484797] omap_i2c 44e0b000.i2c: did not get pins for i2c error: -19
[ 0.487289] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[ 0.494498] DCDC1: at 1800 mV
[ 0.497346] vdd_mpu: 925 <--> 1325 mV at 1275 mV
[ 0.500720] vdd_core: 925 <--> 1150 mV at 1100 mV
[ 0.503612] LDO1: at 1800 mV
[ 0.506134] LDO2: at 3300 mV
[ 0.509103] LDO3: at 3300 mV
[ 0.511612] LDO4: at 3300 mV
[ 0.513852] tps65217 0-0024: TPS65217 ID 0xf version 1.1
[ 0.523930] Switching to clocksource gp_timer
[ 0.692430] NET: Registered protocol family 2
[ 0.694878] TCP established hash table entries: 1024 (order: 1, 8192 bytes)
[ 0.695123] TCP bind hash table entries: 1024 (order: 3, 36864 bytes)
[ 0.695757] TCP: Hash tables configured (established 1024 bind 1024)
[ 0.696026] TCP: reno registered
[ 0.696069] UDP hash table entries: 256 (order: 2, 20480 bytes)
[ 0.696653] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[ 0.697852] NET: Registered protocol family 1
[ 0.699530] RPC: Registered named UNIX socket transport module.
[ 0.699559] RPC: Registered udp transport module.
[ 0.699576] RPC: Registered tcp transport module.
[ 0.699592] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.700848] Trying to unpack rootfs image as initramfs...
[ 0.703450] rootfs image is not initramfs (no cpio magic); looks like an initrd
[ 0.841357] Freeing initrd memory: 16384K
[ 0.841625] NetWinder Floating Point Emulator V0.97 (double precision)
[ 0.842474] CPU PMU: probing PMU on CPU 0
[ 0.842520] hw perfevents: enabled with ARMv7 Cortex-A8 PMU driver, 5 counters available
[ 1.054500] VFS: Disk quotas dquot_6.5.2
[ 1.054811] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 1.058444] NFS: Registering the id_resolver key type
[ 1.059059] Key type id_resolver registered
[ 1.059089] Key type id_legacy registered
[ 1.059272] jffs2: version 2.2. (NAND) (SUMMARY) ?? 2001-2006 Red Hat, Inc.
[ 1.059967] msgmni has been set to 225
[ 1.064654] io scheduler noop registered
[ 1.064688] io scheduler deadline registered
[ 1.064811] io scheduler cfq registered (default)
[ 1.066454] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[ 1.072242] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 1.081518] omap_uart 44e09000.serial: did not get pins for uart0 error: -19
[ 1.082185] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0
[ 1.810770] console [ttyO0] enabled
[ 1.857842] brd: module loaded
[ 1.888668] loop: module loaded
[ 1.898978] mtdoops: mtd device (mtddev=name/number) must be supplied
[ 1.907161] OneNAND driver initializing
[ 1.919778] usbcore: registered new interface driver asix
[ 1.926317] usbcore: registered new interface driver cdc_ether
[ 1.933710] usbcore: registered new interface driver smsc95xx
[ 1.940554] usbcore: registered new interface driver net1080
[ 1.947405] usbcore: registered new interface driver cdc_subset
[ 1.954393] usbcore: registered new interface driver zaurus
[ 1.960925] usbcore: registered new interface driver cdc_ncm
[ 1.970109] usbcore: registered new interface driver cdc_wdm
[ 1.976072] Initializing USB Mass Storage driver...
[ 1.982138] usbcore: registered new interface driver usb-storage
[ 1.988616] USB Mass Storage support registered.
[ 1.994334] usbcore: registered new interface driver usbtest
[ 2.003751] mousedev: PS/2 mouse device common for all mice
[ 2.014783] i2c /dev entries driver
[ 2.021637] Driver for 1-wire Dallas network protocol.
[ 2.033754] omap_wdt: OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[ 2.048194] usbcore: registered new interface driver usbhid
[ 2.054080] usbhid: USB HID core driver
[ 2.059877] oprofile: using arm/armv7
[ 2.065057] TCP: cubic registered
[ 2.068566] Initializing XFRM netlink socket
[ 2.073446] NET: Registered protocol family 17
[ 2.078271] NET: Registered protocol family 15
[ 2.083554] Key type dns_resolver registered
[ 2.088379] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
[ 2.096622] ThumbEE CPU extension supported.
[ 2.173009] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
[ 2.179436] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
[ 2.189615] libphy: 4a101000.mdio: probed
[ 2.193878] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
[ 2.204140] Random MACID = ca:fe:8a:07:ba:03
[ 2.214820] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
[ 2.226373] RAMDISK: gzip image found at block 0
[ 2.691956] VFS: Mounted root (ext2 filesystem) on device 1:0.
[ 2.699599] devtmpfs: mounted
[ 2.703581] Freeing init memory: 336K
/bin/sh: can't access????oR?????????????.????VH? ??
/ #
A dumb question... in your case what's the bootargs set? Note that the mainline
kernel for AM335x doesn't have MMC support yet and the default bootargs is set to
rootfs on MMC.
Regards,
Vaibhav
^ permalink raw reply
* [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
From: Rajendra Nayak @ 2013-01-22 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130121180113.GA22517@atomide.com>
Hi Tony,
>> So I looked at this one with help of Rajendra. We can get rid of the
>> IRQ and DMA data(needs DMA biding updates) easily. The address
>> space though is needed since hwmod code uses it to setup the
>> sysconfig registers.
>
> OK great. The address space tinkering in hwmod code should be
> moved to be done in the drivers.
>
> As discussed earlier, there should be a driver specific reset
> function driver_xyz_reset() in the driver header file so the
> hwmod code can call it too in a late_initcall if no driver is
> loaded.
I am a little confused with what you are saying. The hwmod doing
reset of modules (and not relying on drivers doing it) was
mainly for modules which do not have drivers built in (and hence
run a risk of gating system sleep in case the bootloaders left
them in a bad state).
But if the drivers aren't built in (or are built as modules) *then*
hwmod still needs to be able to do reset (maybe in a late_initcall) of
these modules on its own (because there is no driver code to do it).
The other big reason why hwmod would need the address space
tinkering is because it also controls the various OCP master/slave
modes of these modules. Quite often these modes are broken and
need tinkering every time the module is enable/idled and also
need to be restored back to sane values (smart_idle/smart_standby)
post reset. All of this is today handled as part of hwmod and
would defeat the whole purpose of the framework if all this is
moved into drivers.
So completely getting rid of all address space tinkering in hwmod
looks really difficult.
regards,
Rajendra
>
>> Extracting that from DT code seems to be really expensive and
>> ugly [1]. I am yet to try out DMA lines removal but that seems
>> to be doable by pulling Vinod'd DMA engine branch and updating
>> DT file.
>
> The overhead here does not matter as it should only happen in a
> late_initcall and only for some of the drivers. For that to
> happen we just need to go through the list of modules not yet
> probed. We also need to have some locking in the driver specific
> reset function to avoid races with the loadable modules.
>
>> Whats your suggestion on address space part ?
>
> Let's add the code to hwmod to extract it from DT so hwmod code
> can call the driver specific reset function defined in the driver
> header. That way we can start moving the driver code out of hwmod
> one driver at a time.
>
> Note that the ioremapping should be done in the driver specific
> reset function, not in hwmod code. We just need to pass the
> iorange in a struct resource to the driver specific reset function.
>
> Regards,
>
> Tony
>
^ 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