On 7 August 2013 17:34, Mark Brown broo...@kernel.org wrote:
On Tue, Aug 06, 2013 at 10:35:52PM -0300, Fabio Estevam wrote:
On Tue, Aug 6, 2013 at 12:49 PM, Mark Brown broo...@kernel.org wrote:
From: Andy Green andy.gr...@linaro.org
You might have CONFIG_PM, but you might not have
On 06/12/12 00:42, the mail apparently from Alan Stern included:
On Wed, 5 Dec 2012, Andy Green wrote:
The details of this aren't clear yet. For instance, should the device
core try to match the port with the asset info, or should this be done
by the USB code when the port is created
On 05/12/12 01:10, the mail apparently from Alan Stern included:
[CC: list trimmed; the people who were on it should be subscribed to at
least one of the lists anyway.]
On Tue, 4 Dec 2012, Andy Green wrote:
I think associating ULPI PHY reset and SMSC power and reset with the hub
port power
On 05/12/12 02:14, the mail apparently from Sarah Sharp included:
On Tue, Dec 04, 2012 at 11:40:05AM +0800, Andy Green wrote:
On 04/12/12 01:09, the mail apparently from Alan Stern included:
On Mon, 3 Dec 2012, Andy Green wrote:
Unless someone NAKs it for sure already (if you're already sure
On 04/12/12 01:09, the mail apparently from Alan Stern included:
On Mon, 3 Dec 2012, Andy Green wrote:
Unless someone NAKs it for sure already (if you're already sure you're
going to, please do so to avoid wasting time), I'll issue a try#2 of my
code later which demonstrates what I mean
On 04/12/12 10:39, the mail apparently from Ming Lei included:
On Mon, Dec 3, 2012 at 12:52 PM, Andy Green andy.gr...@linaro.org wrote:
+static void ehci_hub_power_off(struct power_controller *pc, struct
device
*dev)
+{
+ gpio_set_value(GPIO_HUB_NRESET, 0);
+ gpio_set_value
: Andy Green andy.gr...@linaro.org
Cc: Roger Quadros rog...@ti.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Ming Lei tom.leim...@gmail.com
---
drivers/base/power/Makefile |1 +
drivers/base/power/power_controller.c | 110
notifier.
Cc: Andy Green andy.gr...@linaro.org
Cc: Roger Quadros rog...@ti.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Ming Lei tom.leim...@gmail.com
---
drivers/base/core.c| 21 +
include/linux/device.h | 13
: Andy Green andy.gr...@linaro.org
Cc: Roger Quadros rog...@ti.com
Cc: Alan Stern st...@rowland.harvard.edu
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Ming Lei tom.leim...@gmail.com
---
arch/arm/mach-omap2/board-omap4panda.c | 99 +++-
1 file changed, 96 insertions
On 03/12/12 12:11, the mail apparently from Ming Lei included:
On Mon, Dec 3, 2012 at 12:37 AM, Andy Green andy.gr...@linaro.org wrote:
On 02/12/12 23:01, the mail apparently from Ming Lei included:
Hi -
This patch defines power controller for powering on/off LAN95xx
USB hub and USB
as well as
device_asset - external clock will stay permanently up and the forest of
mux code - it's code, not tables - in mach-omap2 will stay as a _init
one-off.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com
On 11/30/2012 01:57 AM, the mail apparently from Alan Stern included:
On Thu, 29 Nov 2012, Andy Green wrote:
However I think what you're saying about binding to hub power is good.
The hub ports are not devices, but it would be possible to bind an asset
array to them and make the pre- and post
On 11/30/2012 04:58 AM, the mail apparently from Andy Green included:
On 11/30/2012 01:57 AM, the mail apparently from Alan Stern included:
On Thu, 29 Nov 2012, Andy Green wrote:
However I think what you're saying about binding to hub power is good.
The hub ports are not devices, but it would
On 11/28/2012 07:13 PM, the mail apparently from Roger Quadros included:
On 11/27/2012 09:22 PM, Andy Green wrote:
On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
Greg's advice was simply not to rely on pathnames in sysfs because
and clock to the HUB+PHY (smsc95xx chip)
remains off until ehci-hcd module is inserted, and both are
disabled again when the module is removed.
---
Andy Green (7):
drivers: base: introduce device assets
regulator: core: add default device asset handlers
clk: add default device
-off-by: Andy Green andy.gr...@linaro.org
---
drivers/base/dd.c | 36
include/linux/device.h | 25 +
2 files changed, 61 insertions(+)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index e3bbed8..d37210a 100644
--- a/drivers
duplication at the usages
is nipped in the bud.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
drivers/regulator/core.c | 34 ++
include/linux/regulator/machine.h | 30 ++
2 files changed, 64 insertions(+)
diff --git a/drivers
duplication at the usages
is nipped in the bud.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
drivers/clk/clkdev.c | 39 +++
include/linux/clk.h | 33 -
2 files changed, 71 insertions(+), 1 deletion(-)
diff --git
This series migrates it to be assets of the logical ehci-omap.0
device object.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/usb-host.c|1 -
arch/arm/plat-omap/include/plat/usb.h |7 --
drivers/usb/host/ehci-omap.c | 37
is around the same as the idle power of the SoC and
rest of the board.
This allows us to start off with it depowered, and only power it if the
ehci-hcd module is inserted. When the module is removed, it's depowered
again.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2
measurements there.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/board-omap4panda.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 52add03
omap2plus seems to have rotted a bit, this is the delta that appears
if we enable modular build for ehci-hcd and smsc95xx.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/configs/omap2plus_defconfig | 42 ++
1 file changed, 17 insertions(+), 25
On 11/28/2012 11:06 PM, the mail apparently from Roger Quadros included:
Hi Roger -
On 11/28/2012 02:59 PM, Andy Green wrote:
This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.
The regulators are made a device_asset of the EHCI logical
On 11/28/2012 12:37 AM, the mail apparently from Alan Stern included:
On Tue, 27 Nov 2012, Andy Green wrote:
I don't know if such an approach would be sufficiently general for
future requirements, but it would solve the problem at hand.
We can get a notification about device creation and do
platform dependent(even for same LAN95xx
USB devices on different platforms(omap, tegra, ..)) , so I am wondering
why we don't enable it directly in probe() of ehci-omap.0 platform device?
I didn't get this point, ehci-omap doesn't help if it's non-omap platform.
-Andy
--
Andy Green | TI
On 11/28/2012 02:09 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
Greg's advice was simply not to rely on pathnames in sysfs because they
aren't fixed in stone. That leaves plenty of other ways to approach
this problem.
It's sage advice
On 11/28/2012 04:10 AM, the mail apparently from Alan Stern included:
On Wed, 28 Nov 2012, Andy Green wrote:
OK. So I try to sketch it out iteractively to try to get in sync:
device.h:
enum asset_event {
AE_PROBED,
AE_REMOVED
, and
is powered cleanly for the lifecycle of the ehci-hcd root hub object.
Comments welcome, this is my first attempt at turning the discussion of the
last few days into an implementation, it is working here well on Panda ES.
-Andy
---
Andy Green (5):
drivers : introduce device_path api
usb
*
providing the same literal string for ehci-omap.0 hub no matter how many\
usb buses have been registered before.
This wildcard string can then be matched to regulators or other string-
searchable assets intended for the device on that hardware path.
Signed-off-by: Andy Green andy.gr
This series migrates it to the hub driver as suggested by
Felipe Balbi.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
drivers/usb/host/ehci-omap.c | 33 -
1 file changed, 33 deletions(-)
diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci
This adds the config option to associate a regulator with each hub,
when the hub on a specific, interesting device path appears, then
the regular is powered while the logical hub exists.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
drivers/usb/core/Kconfig | 10 ++
drivers/usb
off with it depowered, and only power it if the
ehci-hcd module is inserted. When the module is removed, it's depowered
again.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/Kconfig|1
arch/arm/mach-omap2/board-omap4panda.c | 90
omap2plus seems to have rotted a bit, this is the delta that appears
if we enable modular build for ehci-hcd and smsc95xx.
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/configs/omap2plus_defconfig | 42 ++
1 file changed, 17 insertions(+), 25
On 11/27/2012 03:12 AM, the mail apparently from Alan Stern included:
On Mon, 26 Nov 2012, Andy Green wrote:
This adds a small optional API into drivers/base which deals with generating,
matching and registration of wildcard device paths.
From a struct device * you can generate a string like
On 11/27/2012 03:16 AM, the mail apparently from Greg KH included:
On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
+struct device_path list;
+DEFINE_MUTEX(lock);
Those are some very descriptive global variables you just created :(
I guess I can add the static if that will heal
On 11/27/2012 03:22 AM, the mail apparently from Greg KH included:
On Mon, Nov 26, 2012 at 12:45:34PM +, Andy Green wrote:
This adds a small optional API into drivers/base which deals with generating,
matching and registration of wildcard device paths.
From a struct device * you can
to quite
identify, I fear we are moving deckchairs on the titanic.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
On 11/27/2012 12:20 AM, the mail apparently from Roger Quadros included:
Hi Andy,
On 11/26/2012 02:45 PM, Andy Green wrote:
This adds regulators which are controlled by the OMAP4 PandaBoard (ES)'s
EHCI logical root hub existing.
Without power control, the ULPI PHY + SMSC9614 on the Panda eats
On 11/24/12 23:38, the mail apparently from Alan Stern included:
On Sat, 24 Nov 2012, Andy Green wrote:
If we're just looking at fixing the current magic regulator name
scheme of hsusb0 so that it can work with abstract devices like any
hub / port, we could invert what my original device path
else, which should be pretty small.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
To unsubscribe from this list
On 11/22/12 20:21, the mail apparently from Felipe Balbi included:
Hi,
On Thu, Nov 22, 2012 at 09:13:16AM +0800, Andy Green wrote:
On 11/22/12 03:54, the mail apparently from Felipe Balbi included:
Hi,
On Wed, Nov 21, 2012 at 06:07:57PM +0200, Roger Quadros wrote:
On 11/21/2012 05:32 PM
Balbi wrote:
On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote:
From: Andy Green andy.gr...@linaro.org
This patch changes the management of the two GPIO for
hub reset (actually controls enable of ULPI PHY and hub reset) and
hub power (controls power to hub + eth).
looks like
index of that driver we targeted, but that's
easy enough.
Anyway as a generic thing I think its ship has sailed (on a river of
flames), but since you bring up attaching kernel objects to
asynchronously probed devices: there's one way to do it for hardwired
platform devices.
-Andy
--
Andy
On 10/07/12 20:37, the mail apparently from Florian Fainelli included:
Hi -
Le jeudi 05 juillet 2012 04:44:33, Andy Green a écrit :
The following series adds some code to generate legal, locally administered
MAC addresses from OMAP4 CPU Die ID fuse data, and then adds a helper at
net/ethernet
From: Andy Green a...@warmcat.com
This introduces a small helper in net/ethernet, which registers a network
notifier at core_initcall time, and accepts registrations mapping expected
asynchronously-probed network device paths (like, usb1/1-1/1-1.1/1-1.1:1.0)
and the MAC that is needed
From: Andy Green a...@warmcat.com
This provides the board-specific device paths needed to get
the panda boardfile working with the eth-mac-platform api.
On Pandaboard / ES, neither the onboard Ethernet or onboard WLAN
module have onboard arrangements for MAC storage, without this
series yielding
patch on omap2plus_defconfig
that will get Ethernet and WLAN up on Pandaboard.
The patches are against today's linux-omap.
Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the
helper in net/ethernet.
---
Andy Green (4):
OMAP: add cpu id register to MAC address helper
From: Andy Green a...@warmcat.com
Introduce a generic helper function that can generate a valid MAC
address using data from the OMAP unique CPU ID register.
For comparison purposes this produces a MAC address of
2e:20:3c:ea:46:01
for the ethernet device on my PandaBoard ES.
The MAC address
From: Andy Green a...@warmcat.com
This introduces a small helper in net/ethernet, which registers a network
notifier at core_initcall time, and accepts registrations mapping expected
asynchronously-probed network device paths (like, usb1/1-1/1-1.1/1-1.1:1.0)
and the MAC that is needed
From: Andy Green a...@warmcat.com
This provides the board-specific device paths needed to get
the panda boardfile working with the mac-platform api.
On Pandaboard / ES, neither the onboard Ethernet or onboard WLAN
module have onboard arrangements for MAC storage, without this
series yielding
From: Andy Green a...@warmcat.com
This is just provided for testing convenience, it has enough config
options to get Ethernet and WL12xx driver on PandaBoard / ES up
You should be able to reproduce something like this, with different
MAC addresses.
# ifconfig -a
eth0 Link encap:Ethernet
for the review.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
To unsubscribe from this list: send the line
patch on omap2plus_defconfig
that will get Ethernet and WLAN up on Pandaboard.
The patches are against today's linux-omap.
Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the
helper in net/ethernet.
---
Andy Green (4):
OMAP: add cpu id register to MAC address helper
From: Andy Green a...@warmcat.com
Introduce a generic helper function that can generate a valid MAC
address using data from the OMAP unique CPU ID register.
For comparison purposes this produces a MAC address of
2e:20:3c:ea:46:01
for the ethernet device on my PandaBoard ES.
The MAC address
From: Andy Green a...@warmcat.com
This introduces a small helper in net/ethernet, which registers a network
notifier at core_initcall time, and accepts registrations mapping expected
asynchronously-probed network device paths (like, usb1/1-1/1-1.1/1-1.1:1.0)
and the MAC that is needed
From: Andy Green a...@warmcat.com
This provides the board-specific device paths needed to get
the panda boardfile working with the mac-platform api.
On Pandaboard / ES, neither the onboard Ethernet or onboard WLAN
module have onboard arrangements for MAC storage, without this
series yielding
From: Andy Green a...@warmcat.com
This is just provided for testing convenience, it has enough config
options to get Ethernet and WL12xx driver on PandaBoard / ES up
You should be able to reproduce something like this, with different
MAC addresses.
# ifconfig -a
eth0 Link encap:Ethernet
On 07/03/12 00:12, the mail apparently from Arnd Bergmann included:
On Monday 02 July 2012, Andy Green wrote:
From: Andy Green a...@warmcat.com
This introduces a small helper in net/ethernet, which registers a
network notifier on init, and accepts registrations of expected asynchronously
patch on omap2plus_defconfig
that will get Ethernet and WLAN up on Pandaboard.
The patches are against today's linux-omap.
Thanks to Tony Lindgren and Arnd Bergmann for comments leading to the
helper in net/ethernet.
---
Andy Green (4):
OMAP2+: add cpu id register to MAC address helper
From: Andy Green a...@warmcat.com
Introduce a generic helper function that can generate a valid MAC
address using data from the OMAP unique CPU ID register.
For comparison purposes this produces a MAC address of
2e:20:3c:ea:46:01
for the ethernet device on my PandaBoard ES.
The MAC address
From: Andy Green a...@warmcat.com
This introduces a small helper in net/ethernet, which registers a
network notifier on init, and accepts registrations of expected asynchronously-
probed network device paths (like, usb1/1-1/1-1.1/1-1.1:1.0) and the MAC
that is needed to be assigned to the device
From: Andy Green a...@warmcat.com
This provides the board-specific device paths needed to get
the panda boardfile working with the mac-la-ap api.
On Pandaboard / ES, neither the onboard Ethernet or onboard WLAN
module have onboard arrangements for MAC storage, without this
series yielding
From: Andy Green a...@warmcat.com
This is just provided for testing convenience, it has enough config
options to get Ethernet and WL12xx driver on PandaBoard / ES up
You should be able to reproduce something like this, with different
MAC addresses.
# ifconfig -a
eth0 Link encap:Ethernet
On 06/29/12 16:51, the mail apparently from Arnd Bergmann included:
On Friday 29 June 2012, Andy Green wrote:
+static int omap_panda_netdev_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ struct net_device *dev = ptr
On 06/29/12 17:05, the mail apparently from Tony Lindgren included:
* Andy Green andy.gr...@linaro.org [120628 22:59]:
Introduce a generic helper function that can generate a valid MAC
address using data from the OMAP unique CPU ID register.
...
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm
On 06/29/12 17:40, the mail apparently from Tony Lindgren included:
* Andy Green andy.gr...@linaro.org [120628 22:59]:
From: Andy Green a...@warmcat.com
This exposes a new API in devices.c that lets a board register
a list of device paths representing network devices that have
no arrangements
On 06/29/12 21:55, the mail apparently from Tony Lindgren included:
* Arnd Bergmann a...@arndb.de [120629 06:50]:
On Friday 29 June 2012, Tony Lindgren wrote:
* Andy Green andy.gr...@linaro.org [120629 03:12]:
2. Is this really how we want to pass the board generated mac addresses
On 06/29/12 21:45, the mail apparently from Arnd Bergmann included:
On Friday 29 June 2012, Tony Lindgren wrote:
* Andy Green andy.gr...@linaro.org [120629 03:12]:
2. Is this really how we want to pass the board generated mac addresses
and other dynamically generated data to the drivers
alright with it we might have a go at implementing this, but
can you define a bit more about how we logically tell DSS that we want
to, eg, disable HDMI totally?
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages
not enabling and disabling stuff like
SoC HDMI PHY willy nilly can maybe be something else targeted by this
proposed 4-state power scheme.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http
On 06/28/12 22:45, the mail apparently from Steven Rostedt included:
On Thu, 2012-06-28 at 14:18 +, Arnd Bergmann wrote:
It's been a while since we discussed these patches, but Steven Rostedt
just tripped over the same problem and the patches work for
him, so he says Tested-by: Steven
MAC either assigned by
the manufacturer or stored on the board, the last patch in the series adds
these device paths and gets them set when the network device is registered.
The patches are against today's linux-omap.
---
Andy Green (3):
OMAP2+: add cpu id register to MAC address helper
From: Andy Green a...@warmcat.com
Introduce a generic helper function that can generate a valid MAC
address using data from the OMAP unique CPU ID register.
For comparison purposes this produces a MAC address of
2e:40:70:f0:12:06
for the ethernet device on my Panda.
The MAC address space
From: Andy Green a...@warmcat.com
This exposes a new API in devices.c that lets a board register
a list of device paths representing network devices that have
no arrangements for their MAC address to be set by the board.
It watches network device registrations via a notifier and
gives
From: Andy Green a...@warmcat.com
This provides the board-specific device paths needed to get
the panda boardfile working with the MAC address fixup api.
On Pandaboard / ES, neither the onboard Ethernet or onboard WLAN
module have onboard arrangements for MAC storage, without this
series
permanently enabling the external HDMI PHY
chip section that performs level-conversion for hpd, and the existing
work to use irq management of hpd, seems to have really solved detecting
that TV for the first time.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software
On 07/29/2011 01:07 PM, Somebody in the thread at some point said:
Hi -
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev-westate);
+ if (dev-rev OMAP_I2C_REV_ON_3530_4430)
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
+
On 05/16/2011 09:56 AM, Somebody in the thread at some point said:
Am Donnerstag, den 21.04.2011, 13:13 +0100 schrieb Andy Green:
On 04/21/2011 12:47 PM, Somebody in the thread at some point said:
Without OMAP_I2C_FLAG_RESET_REGS_POSTIDLE I got i2c controller
timeouts on each accsess after
On 04/21/2011 12:47 PM, Somebody in the thread at some point said:
Without OMAP_I2C_FLAG_RESET_REGS_POSTIDLE I got i2c controller
timeouts on each accsess after an NACK message.
Taking this flag fix it.
Ahhh that will explain why if you accidentally configure LM75 system
monitor support,
On 03/25/2011 11:49 AM, Somebody in the thread at some point said:
On Thursday 24 March 2011, Andy Green wrote:
Introduce a generic helper function that can set a MAC address using
data from the OMAP unique CPU ID register.
For comparison purposes this produces a MAC address of
2e:40:70:f0
On 03/25/2011 01:24 PM, Somebody in the thread at some point said:
On Friday 25 March 2011, Andy Green wrote:
Having a proper MAC from IEEE assigned for each interface is of course
ideal.
But even if that happened today though, on Panda there is no board
identity storage to put the reserved
On 03/25/2011 02:50 PM, Somebody in the thread at some point said:
On Friday 25 March 2011, Andy Green wrote:
I see. It would work OK then. They probably wouldn't want to blow
their $1750 just on Panda though, so maybe they set 4 bits or whatever
and let 20 be computed.
Well
On 03/25/2011 08:13 PM, Somebody in the thread at some point said:
Hi -
I very much like this approach. I believed the ability to use the die
ID to get a unique code was reasonable approach and that is why I
didn't get an EEPROM put onto the BeagleBoard, though Gerald is
looking at adding one
more closely mapped to what the unique factory areas are advice
is welcome.
The patches are against linux-omap which already has a prerequisite
patch that fixes a problem with device ID capture on OMAP4.
---
Andy Green (2):
OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0
;h=b235e007831dbf57710e59cd4a120e2f374eecb9
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/mach-omap2/id.c | 39 +
arch/arm/mach-omap2/include/mach/id.h |1 +
2 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm
the MAC addresses even if the
drivers are in modules loaded in an order that changes their interface
name from usual (eg, the onboard module might be wlan1 if there is a
USB wireless stick plugged in and its module is inserted first.)
Cc: Alan Cox a...@lxorguk.ukuu.org.uk
Signed-off-by: Andy Green
On 03/18/2011 08:34 AM, Somebody in the thread at some point said:
+void omap2_die_id_to_mac(u8 *mac, int length)
+{
+ struct omap_die_id odi;
+
+ omap_get_die_id(odi);
+ memcpy(mac,odi.id_0, length);
+
+ /* mark it as not multicast and outside official 80211 MAC
On 03/18/2011 08:52 AM, Somebody in the thread at some point said:
+ /* mark it as not multicast and outside official 80211 MAC namespace */
+
+ mac[0] = (mac[0] ~1) | 2;
so here lies the answer to my question From where do you get the MAC :)
Is there a guarantee that this MAC
On 03/18/2011 02:37 PM, Somebody in the thread at some point said:
Hi -
[sp] This 'trick' has been tried earlier in u-boot. See:
http://www.mail-archive.com/u-boot@lists.denx.de/msg19915.html
I am also not sure whether DIE_ID would really be unique.
It doesn't actually need all
On 03/15/2011 10:28 PM, Somebody in the thread at some point said:
Hi,
* Andy Greena...@warmcat.com [110315 12:53]:
The following series removes cpu_...() usage completely from the
omap-i2c driver by having decisions about functional implementation
choices in the SoC held in cpu-specific
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
Acked-by: Benoit Cousson b-cous...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |2 ++
arch/arm/mach-omap2
non-existent I2C register at times on that
platform.
The patch series is quite extended from the first try thanks to
comments from Benoit Cousson.
This 3rd try is based on 2.6.38-rc8 as requested.
---
Andy Green (18):
I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version shown
accordingly to help show up errors in usage.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
drivers/i2c/busses/i2c-omap.c | 23 ---
1 files changed, 12 insertions(+), 11
These represent the two kinds of (incompatible) OMAP I2C
peripheral unit in use so far.
The constants are in linux/i2c-omap.h so the omap i2c driver can have
them too.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
include/linux/i2c-omap.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/linux/i2c-omap.h b/include/linux/i2c-omap.h
index 701886d..b321211 100644
--- a/include/linux
-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/plat-omap/i2c.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c
index a4f8003..0a1b5af 100644
--- a/arch/arm/plat-omap/i2c.c
+++ b/arch/arm/plat-omap/i2c.c
@@ -108,6
Mark each OMAP I2C bus with the hwmod's knowledge of which I2C
IP version is in the chip we're running on.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
arch/arm/plat-omap/i2c.c
peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
drivers/i2c/busses/i2c-omap.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 2826c13..eee0bb8 100644
--- a/drivers/i2c
in the platform_data.
Cc: patc...@linaro.org
Cc: Ben Dooks ben-li...@fluff.org
Reported-by: Peter Maydell peter.mayd...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses
...@linaro.org
Signed-off-by: Andy Green andy.gr...@linaro.org
---
drivers/i2c/busses/i2c-omap.c | 19 ++-
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 14f5b50..ecb48c7 100644
--- a/drivers/i2c
1 - 100 of 141 matches
Mail list logo
