Skip to contentSkip to conversation

tidspbridge compilation broken

DISCUSSION Ionut Nicu 3 participants 3 messages Oct 9, 2010 – Oct 11, 2010

lore
Share & tools
lore

Ionut Nicu

author
#0 lore raw

Hi,

I'm trying to compile the tidspbridge driver from the dspbridge branch of the linux-omap git tree and I stumbled upon a few compilation problems:

1. First is related to the missing header plat/dsp.h added by the following patch which was not applied to this branch:

http://marc.info/?l=linux-omap&m=128620861805925&w=2

2. The second one is related to the missing header plat/control.h which was moved by a recent commit (81bb9b6) from plat to mach-omap2. The dspbridge driver requires a few defines from that header but as far as I understand, that header file is no longer supposed to be accessible by drivers. Any suggestion on how to fix that in dspbridge?

3. There's a link error triggered by the new iommu dependency. It's fairly trivial to fix. I will submit a patch for this.

Thanks,
Ionut.

#1 lore raw
Quoted 19 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ionut Nicu
Sent: Saturday, October 09, 2010 5:50 AM
To: [email protected]
Subject: tidspbridge compilation broken

Hi,

I'm trying to compile the tidspbridge driver from the dspbridge branch of the linux-omap git tree and I stumbled upon a few compilation
problems:

1. First is related to the missing header plat/dsp.h added by the following patch which was not applied to this branch:

Quoted 8 lines

http://marc.info/?l=linux-omap&m=128620861805925&w=2

2. The second one is related to the missing header plat/control.h which was moved by a recent commit (81bb9b6) from plat to mach-omap2. The dspbridge driver requires a few defines from that header but as far as I understand, that header file is no longer supposed to be accessible by drivers. Any suggestion on how to fix that in dspbridge?

This will be fixed soon, we are looking for the best solution.

Regards,
Fernando Guzman.

Quoted 14 lines

3. There's a link error triggered by the new iommu dependency. It's fairly trivial to fix. I will submit a patch for this.

Thanks,
Ionut.

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at
http://vger.kernel.org/majordomo-info.html

#2 lore raw
Quoted 5 lines · Fernando
Quoted 5 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ionut Nicu
Sent: Saturday, October 09, 2010 5:50 AM

Quoted 8 lines
Quoted 6 lines

2. The second one is related to the missing header plat/control.h which was moved by a recent commit (81bb9b6) from plat to mach-omap2. The dspbridge driver requires a few defines from that header but as far as I understand, that header file is no longer supposed to be accessible by drivers. Any suggestion on how to fix that in dspbridge?

This will be fixed soon, we are looking for the best solution.

Tony mentioned that you all needed some help with this. I would have converted DSPBridge as part of the original SCM patch, but since DSPBridge used __raw_writel() to write to the SCM rather than omap_ctrl_writel(), it didn't show up on my original grep.

Anyway, following is a patch series to help you deal with this problem in the short term. It is unlikely to work as-is, since there doesn't appear to be any code in arch/arm/mach-omap2/* to populate the function pointers. You guys need to fix this - this is a defect in the original code. I suggest that you move your OMAP3430 hardware adaptation layer out of your core/tiomap3430.c into arch/arm/mach-omap2/, after rewriting it appropriately. For example, there shouldn't be any need to do any CM or PRM accesses. That should all be doable with clock/clockdomain/powerdomain/omap_device/omap_hwmod functions.

Also, I hope you all are planning to do whatever it takes to move that driver out of staging as soon as possible. If further resources aren't invested on this driver to get it mainline-ready, then it's likely that someone will kick it out of staging at some point. Staging isn't really mainline.

- Paul

Paul Walmsley (3):
OMAP: control: add functions for DSP boot address/mode control
OMAP3: PM: update DSP reset code to use new SCM DSP boot control
functions
DSPBridge: convert OMAP3430 adaptation layer to use new SCM DSP boot
control fns

 arch/arm/mach-omap2/control.c                      |   51 ++++++++++++++++++
 arch/arm/mach-omap2/control.h                      |   16 +++---
 arch/arm/mach-omap2/pm34xx.c                       |    6 +-
 arch/arm/plat-omap/include/plat/iva2_dsp.h         |   56 ++++++++++++++++++++
 drivers/staging/tidspbridge/core/tiomap3430.c      |   13 ++---
 .../tidspbridge/include/dspbridge/host_os.h        |    4 ++
 6 files changed, 129 insertions(+), 17 deletions(-)
 create mode 100644 arch/arm/plat-omap/include/plat/iva2_dsp.h