On 08/12/14 22:41, Nishanth Menon wrote:
Anyways.. The following diff[1] on top of your branch makes DRA7 work - I
assume you will squash as needed and repost with linux-omap mailing list
in CC.
Brilliant. I'll squash that into my tree and repost at some point.
I increased the scope of
On 10:13-20141205, Nishanth Menon wrote:
On 12/05/2014 10:10 AM, Nishanth Menon wrote:
next-20141204 fails to boot, but next-20141203 boots fine with
omap2plus_defconfig.
Panda-ES(4460):
https://github.com/nmenon/kernel-test-logs/blob/next-20141204/omap2plus_defconfig/pandaboard-es.txt
On 09:53-20141209, Marc Zyngier wrote:
On 08/12/14 22:41, Nishanth Menon wrote:
Anyways.. The following diff[1] on top of your branch makes DRA7 work - I
assume you will squash as needed and repost with linux-omap mailing list
in CC.
Brilliant. I'll squash that into my tree and repost
On 09/12/14 18:17, Nishanth Menon wrote:
On 09:53-20141209, Marc Zyngier wrote:
On 08/12/14 22:41, Nishanth Menon wrote:
Anyways.. The following diff[1] on top of your branch makes DRA7 work - I
assume you will squash as needed and repost with linux-omap mailing list
in CC.
Brilliant. I'll
From: Lokesh Vutla lokeshvu...@ti.com
Date: Thu, 4 Dec 2014 10:24:29 +0530
CPSW is present in AM33xx, AM43xx, DRA7xx.
Updating the Kconfig to depend on ARCH_OMAP2PLUS instead of listing
all SoC's.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Applied to net-next, thanks.
--
To unsubscribe
Hi!
Major problem with Nokia H4P driver was, that it uses custom functions
instead of __hci_cmd_sync().
To recap, code was something like this: (You can see ifdefs with old
code and my new replacements).
len = sizeof(*neg_cmd) + sizeof(*neg_hdr) + H4_TYPE_SIZE;
#undef OLD
#ifdef
Hi Pavel,
Major problem with Nokia H4P driver was, that it uses custom functions
instead of __hci_cmd_sync().
the __hci_cmd_sync is for sending HCI commands and not low-level protocol
transports like H:4 or similar. So you want to separate the actual transport of
HCI from the firmware
Hi!
Major problem with Nokia H4P driver was, that it uses custom functions
instead of __hci_cmd_sync().
the __hci_cmd_sync is for sending HCI commands and not low-level
protocol transports like H:4 or similar. So you want to separate the
actual transport of HCI from the firmware loading.
Hi Pavel,
Major problem with Nokia H4P driver was, that it uses custom functions
instead of __hci_cmd_sync().
the __hci_cmd_sync is for sending HCI commands and not low-level
protocol transports like H:4 or similar. So you want to separate the
actual transport of HCI from the firmware
In order to get rid of some more hwmod data, we
introduce a few extra properties to OMAP DT
data in order to be able to pass the needed
information through DT.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Documentation/devicetree/bindings/arm/omap/omap.txt | 7 +++
1 file changed, 7
After moving sysconfig data to DT, we need to make
sure we can generate the same data we have today in C
files out of the DT provided properties.
This patch adds support for all optional properties
documented by a previous commit.
Signed-off-by: Felipe Balbi ba...@ti.com
---
This patch adds all new sysconfig DT properties
so they can later be removed from hwmod*data.c files
Signed-off-by: Felipe Balbi ba...@ti.com
---
Note here, there's still an idea of converting the flags to use
macros which would get preprocessed away, I'm yet to do that.
We will be allocating struct omap_hwmod_class for
any DT which passes sysc data. Because of that,
class-name cannot be const.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hi,
here's a more complete series showing the out of debugfs interface.
So far only AM43xx has been converted and only those HWMODs which
play well with DT and/or are not common with other OMAPs/AM33xx.
I plan to work on AM33xx tomorrow, but this RFC shows what we can
achieve WRT HWMOD static
now that this data comes from DT, we can safely
remove them from this file.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 61 --
1 file changed, 61 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
Before this patch, HWMOD requires the existence
of a struct omap_hwmod_class very early. It just
so happens that we're moving that data to DeviceTree
in a follow-up commit so we need to allow the
registration of HWMODs with a valid omap_hwmod_class
pointer.
When the device is built from DT, we
By exposing the details of hwmod structures
to debugfs we can much more easily verify
that changes to hwmod data is correct and won't
cause regressions.
The idea is that this can be used to check the
state of one hwmod, verify hwmod sysc fields, etc.
For example, this will be used to move some
On Tue, Dec 09, 2014 at 04:27:45PM -0600, Felipe Balbi wrote:
Hi,
here's a more complete series showing the out of debugfs interface.
So far only AM43xx has been converted and only those HWMODs which
play well with DT and/or are not common with other OMAPs/AM33xx.
I plan to work on
18 matches
Mail list logo
