<feed xmlns='http://www.w3.org/2005/Atom'>
<title>litmus-rt.git/arch/arm/mach-omap2/Kconfig, branch test</title>
<subtitle>The LITMUS^RT kernel.</subtitle>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/'/>
<entry>
<title>Merge tag 'armsoc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc</title>
<updated>2015-04-22T16:24:55+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2015-04-22T16:24:55+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=8b3c8ba3d8c2680dab5363a80c024965cac08b1e'/>
<id>8b3c8ba3d8c2680dab5363a80c024965cac08b1e</id>
<content type='text'>
Pull ARM SoC late changes from Olof Johansson:
 "We were expecting to sit on this branch through most of the merge
  window since the contents was merged into our tree late, but we ended
  up sitting on all of our contents so it can go in with the rest.

  The contents here is:

   - a large branch of cleanups of the CM/PRM blocks on OMAP.

   - a couple of patches plumbing up CM/PRM on OMAP5 and DRA7.

   - a branch with DT updates for Freescale i.MX.  including some
     shuffling from .dts to .dtsi (include) files that causes a little
     churn"

* tag 'armsoc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (78 commits)
  ARM: OMAP2+: Fix booting with configs that don't have MFD_SYSCON
  ARM: OMAP4+: control: add support for initializing control module via DT
  ARM: dts: dra7: add minimal l4 bus layout with control module support
  ARM: dts: omap5: add minimal l4 bus layout with control module support
  ARM: OMAP4+: control: remove support for legacy pad read/write
  ARM: OMAP4: display: convert display to use syscon for dsi muxing
  ARM: dts: omap4: add minimal l4 bus layout with control module support
  ARM: dts: am4372: add minimal l4 bus layout with control module support
  ARM: dts: am43xx-epos-evm: fix pinmux node layout
  ARM: dts: am33xx: add minimal l4 bus layout with control module support
  ARM: dts: omap3: add minimal l4 bus layout with control module support
  ARM: dts: omap24xx: add minimal l4 bus layout with control module support
  ARM: OMAP2+: control: add syscon support for register accesses
  ARM: OMAP2+: id: cache omap_type value
  ARM: OMAP2+: control: remove API for getting control module base address
  ARM: OMAP2+: clock: add low-level support for regmap
  ARM: OMAP4+: PRM: get rid of cpu_is_omap44xx calls from interrupt init
  ARM: OMAP4+: PRM: setup prm_features from the PRM init time flags
  ARM: OMAP2+: CM: move SoC specific init calls within a generic API
  ARM: OMAP4+: PRM: determine prm_device_inst based on DT compatibility
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull ARM SoC late changes from Olof Johansson:
 "We were expecting to sit on this branch through most of the merge
  window since the contents was merged into our tree late, but we ended
  up sitting on all of our contents so it can go in with the rest.

  The contents here is:

   - a large branch of cleanups of the CM/PRM blocks on OMAP.

   - a couple of patches plumbing up CM/PRM on OMAP5 and DRA7.

   - a branch with DT updates for Freescale i.MX.  including some
     shuffling from .dts to .dtsi (include) files that causes a little
     churn"

* tag 'armsoc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (78 commits)
  ARM: OMAP2+: Fix booting with configs that don't have MFD_SYSCON
  ARM: OMAP4+: control: add support for initializing control module via DT
  ARM: dts: dra7: add minimal l4 bus layout with control module support
  ARM: dts: omap5: add minimal l4 bus layout with control module support
  ARM: OMAP4+: control: remove support for legacy pad read/write
  ARM: OMAP4: display: convert display to use syscon for dsi muxing
  ARM: dts: omap4: add minimal l4 bus layout with control module support
  ARM: dts: am4372: add minimal l4 bus layout with control module support
  ARM: dts: am43xx-epos-evm: fix pinmux node layout
  ARM: dts: am33xx: add minimal l4 bus layout with control module support
  ARM: dts: omap3: add minimal l4 bus layout with control module support
  ARM: dts: omap24xx: add minimal l4 bus layout with control module support
  ARM: OMAP2+: control: add syscon support for register accesses
  ARM: OMAP2+: id: cache omap_type value
  ARM: OMAP2+: control: remove API for getting control module base address
  ARM: OMAP2+: clock: add low-level support for regmap
  ARM: OMAP4+: PRM: get rid of cpu_is_omap44xx calls from interrupt init
  ARM: OMAP4+: PRM: setup prm_features from the PRM init time flags
  ARM: OMAP2+: CM: move SoC specific init calls within a generic API
  ARM: OMAP4+: PRM: determine prm_device_inst based on DT compatibility
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'armsoc-cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc</title>
<updated>2015-04-22T16:04:39+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2015-04-22T16:04:39+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=d0440c59f52d31aa7f74ba8e35cc22ee96acea84'/>
<id>d0440c59f52d31aa7f74ba8e35cc22ee96acea84</id>
<content type='text'>
Pull ARM SoC cleanups from Olof Johansson:
 "We've got a fairly large cleanup branch this time.  The bulk of this
  is removal of non-DT platforms of several flavors:

   - Atmel at91 platforms go full-DT, with removal of remaining
     board-file based support

   - OMAP removes legacy board files for three more platforms

   - removal of non-DT mach-msm, newer Qualcomm platforms now live in
     mach-qcom

   - Freescale i.MX25 also removes non-DT platform support"

Most of the rest of the changes here are fallout from the above, i.e. for
example removal of drivers that now lack platforms, etc.

* tag 'armsoc-cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (58 commits)
  mmc: Remove msm_sdcc driver
  gpio: Remove gpio-msm-v1 driver
  ARM: Remove mach-msm and associated ARM architecture code
  ARM: shmobile: cpuidle: Remove the pointless default driver
  ARM: davinci: dm646x: Add interrupt resource for McASPs
  ARM: davinci: irqs: Correct McASP1 TX interrupt definition for DM646x
  ARM: davinci: dm646x: Clean up the McASP DMA resources
  ARM: davinci: devices-da8xx: Add support for McASP2 on da830
  ARM: davinci: devices-da8xx: Clean up and correct the McASP device creation
  ARM: davinci: devices-da8xx: Add interrupt resource to McASP structs
  ARM: davinci: devices-da8xx: Add resource name for the McASP DMA request
  ARM: OMAP2+: Remove legacy support for omap3 TouchBook
  ARM: OMAP3: Remove legacy support for devkit8000
  ARM: OMAP3: Remove legacy support for EMA-Tech Stalker board
  ARM: shmobile: Consolidate the pm code for R-Car Gen2
  ARM: shmobile: r8a7791: Correct SYSCIER value
  ARM: shmobile: r8a7790: Correct SYSCIER value
  ARM: at91: remove old setup
  ARM: at91: sama5d4: remove useless map_io
  ARM: at91: sama5 use SoC detection infrastructure
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull ARM SoC cleanups from Olof Johansson:
 "We've got a fairly large cleanup branch this time.  The bulk of this
  is removal of non-DT platforms of several flavors:

   - Atmel at91 platforms go full-DT, with removal of remaining
     board-file based support

   - OMAP removes legacy board files for three more platforms

   - removal of non-DT mach-msm, newer Qualcomm platforms now live in
     mach-qcom

   - Freescale i.MX25 also removes non-DT platform support"

Most of the rest of the changes here are fallout from the above, i.e. for
example removal of drivers that now lack platforms, etc.

* tag 'armsoc-cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (58 commits)
  mmc: Remove msm_sdcc driver
  gpio: Remove gpio-msm-v1 driver
  ARM: Remove mach-msm and associated ARM architecture code
  ARM: shmobile: cpuidle: Remove the pointless default driver
  ARM: davinci: dm646x: Add interrupt resource for McASPs
  ARM: davinci: irqs: Correct McASP1 TX interrupt definition for DM646x
  ARM: davinci: dm646x: Clean up the McASP DMA resources
  ARM: davinci: devices-da8xx: Add support for McASP2 on da830
  ARM: davinci: devices-da8xx: Clean up and correct the McASP device creation
  ARM: davinci: devices-da8xx: Add interrupt resource to McASP structs
  ARM: davinci: devices-da8xx: Add resource name for the McASP DMA request
  ARM: OMAP2+: Remove legacy support for omap3 TouchBook
  ARM: OMAP3: Remove legacy support for devkit8000
  ARM: OMAP3: Remove legacy support for EMA-Tech Stalker board
  ARM: shmobile: Consolidate the pm code for R-Car Gen2
  ARM: shmobile: r8a7791: Correct SYSCIER value
  ARM: shmobile: r8a7790: Correct SYSCIER value
  ARM: at91: remove old setup
  ARM: at91: sama5d4: remove useless map_io
  ARM: at91: sama5 use SoC detection infrastructure
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'omap-for-v4.1/prcm-dts-mfd-syscon-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/late</title>
<updated>2015-04-22T04:45:15+00:00</updated>
<author>
<name>Olof Johansson</name>
<email>olof@lixom.net</email>
</author>
<published>2015-04-22T04:45:15+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=48c1078509b47b38802329028ccfd77783bcff99'/>
<id>48c1078509b47b38802329028ccfd77783bcff99</id>
<content type='text'>
Merge "urgent omap boot fix for v4.1 if MFD_SYSCON is not set" from Tony
Lindgren:

Urgent pull request for v4.1 to booting for custom kernel
.config files that do not have MFD_SYSCON set.

Omaps now have a dependency to MFD_SYSCON for system control
module generic register area and some clocks with the changes
done in omap-for-v4.1/prcm-dts branch.

This can be pulled on top of omap-for-v4.1/prcm-dts, or into
fixes for v4.1.

We already do have a slight MFD_SYSCON dependency for
REGULATOR_PBIAS for dual voltage MMC cards on the first MMC
bus for many devices, so from that point of view this can
also be merged separately from omap-for-v4.1/prcm-dts.

* tag 'omap-for-v4.1/prcm-dts-mfd-syscon-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP2+: Fix booting with configs that don't have MFD_SYSCON

Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Merge "urgent omap boot fix for v4.1 if MFD_SYSCON is not set" from Tony
Lindgren:

Urgent pull request for v4.1 to booting for custom kernel
.config files that do not have MFD_SYSCON set.

Omaps now have a dependency to MFD_SYSCON for system control
module generic register area and some clocks with the changes
done in omap-for-v4.1/prcm-dts branch.

This can be pulled on top of omap-for-v4.1/prcm-dts, or into
fixes for v4.1.

We already do have a slight MFD_SYSCON dependency for
REGULATOR_PBIAS for dual voltage MMC cards on the first MMC
bus for many devices, so from that point of view this can
also be merged separately from omap-for-v4.1/prcm-dts.

* tag 'omap-for-v4.1/prcm-dts-mfd-syscon-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP2+: Fix booting with configs that don't have MFD_SYSCON

Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: OMAP2+: Fix booting with configs that don't have MFD_SYSCON</title>
<updated>2015-04-20T17:36:31+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2015-04-20T17:36:31+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=da4d81453cf1eedfcd8b2cd1e7bfab230084bd87'/>
<id>da4d81453cf1eedfcd8b2cd1e7bfab230084bd87</id>
<content type='text'>
With the recent changes omaps have developed a dependency to MFD_SYSCON.
This is used for system control module generic register area and some
clocks.

We do have it selected in omap2plus_defconfig, but targeted config
files may not have it selected. Let's make sure it's selected like
few other ARM platforms are already doing.

Reported-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With the recent changes omaps have developed a dependency to MFD_SYSCON.
This is used for system control module generic register area and some
clocks.

We do have it selected in omap2plus_defconfig, but targeted config
files may not have it selected. Let's make sure it's selected like
few other ARM platforms are already doing.

Reported-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: DRA7: Enable Cortex A15 errata 798181</title>
<updated>2015-03-27T21:38:03+00:00</updated>
<author>
<name>Praneeth Bajjuri</name>
<email>praneeth@ti.com</email>
</author>
<published>2015-03-25T23:25:09+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=209431eff8afb928d72200c79153165c7d860ca0'/>
<id>209431eff8afb928d72200c79153165c7d860ca0</id>
<content type='text'>
ARM errata 798181 is applicable for OMAP5/DRA7 based devices. So enable
the same in the build.

DRA7xx is based on Cortex-A15 r2p2 revision.

ARM Errata extract and workaround information is as below.

On Cortex-A15 (r0p0..r3p2) the TLBI*IS/DSB operations are not
adequately shooting down all use of the old entries. The
ARM_ERRATA_798181 option enables the Linux kernel workaround
for this erratum which sends an IPI to the CPUs that are running
the same ASID as the one being invalidated.

Signed-off-by: Praneeth Bajjuri &lt;praneeth@ti.com&gt;
Acked-by: Nishanth Menon &lt;nm@ti.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ARM errata 798181 is applicable for OMAP5/DRA7 based devices. So enable
the same in the build.

DRA7xx is based on Cortex-A15 r2p2 revision.

ARM Errata extract and workaround information is as below.

On Cortex-A15 (r0p0..r3p2) the TLBI*IS/DSB operations are not
adequately shooting down all use of the old entries. The
ARM_ERRATA_798181 option enables the Linux kernel workaround
for this erratum which sends an IPI to the CPUs that are running
the same ASID as the one being invalidated.

Signed-off-by: Praneeth Bajjuri &lt;praneeth@ti.com&gt;
Acked-by: Nishanth Menon &lt;nm@ti.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: OMAP2+: Remove legacy support for omap3 TouchBook</title>
<updated>2015-03-17T00:07:26+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2015-03-17T00:07:26+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=01ea0d4247bb3a224a66007e0a1291232c15d61a'/>
<id>01ea0d4247bb3a224a66007e0a1291232c15d61a</id>
<content type='text'>
We've been moving all omap2+ based systems to boot in device tree only
mode for a few years now. Only omap3 has legacy booting support
remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
files for booting with device tree.

As it seems this board only has minimal support upstreamed for the
legacy booting and has not seen activity for on the mailing lists
for a few years, let's attempt to remove the related legacy board-*.c
file.

I do not have this board, but it seems getting the same level of
support with device tree based booting is mostly just configuring
the .dts file. And there is no need to upgrade the boot loader as
we can boot with appended DTB too. And most of the omap3 boards
seem to be related to omap3-evm, and omap3beagleboard that are
supported with device tree based booting.

If somebody is using this board actively with the mainline kernel,
please communicate this to the linux-omap mailing list so we can
get the board booting with device tree based support. I can help
some too getting the minimal device tree based booting going if
help is needed.

The reason for attempting to remove this board now is that I'd
rather get the remaining omap3 legacy booting support into a known
state where we at least have a .dts file being written for the
remaining legacy boards. That is because for the next few merge
cycles we can still revert this patch if absolutely necessary,
but I'd rather not get suprised by missing .dts files at the point
where we are ready to drop all remaining omap3 legacy booting
support later on.

Cc: Gregoire Gentil &lt;gregoire@gentil.com&gt;
Cc: Radek Pilar &lt;mrkva@mrkva.eu&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We've been moving all omap2+ based systems to boot in device tree only
mode for a few years now. Only omap3 has legacy booting support
remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
files for booting with device tree.

As it seems this board only has minimal support upstreamed for the
legacy booting and has not seen activity for on the mailing lists
for a few years, let's attempt to remove the related legacy board-*.c
file.

I do not have this board, but it seems getting the same level of
support with device tree based booting is mostly just configuring
the .dts file. And there is no need to upgrade the boot loader as
we can boot with appended DTB too. And most of the omap3 boards
seem to be related to omap3-evm, and omap3beagleboard that are
supported with device tree based booting.

If somebody is using this board actively with the mainline kernel,
please communicate this to the linux-omap mailing list so we can
get the board booting with device tree based support. I can help
some too getting the minimal device tree based booting going if
help is needed.

The reason for attempting to remove this board now is that I'd
rather get the remaining omap3 legacy booting support into a known
state where we at least have a .dts file being written for the
remaining legacy boards. That is because for the next few merge
cycles we can still revert this patch if absolutely necessary,
but I'd rather not get suprised by missing .dts files at the point
where we are ready to drop all remaining omap3 legacy booting
support later on.

Cc: Gregoire Gentil &lt;gregoire@gentil.com&gt;
Cc: Radek Pilar &lt;mrkva@mrkva.eu&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: OMAP3: Remove legacy support for devkit8000</title>
<updated>2015-03-17T00:05:37+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2015-03-16T23:56:58+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=f56a1b24f54e7d1f70b5dbcc32e702bf9a1f7e97'/>
<id>f56a1b24f54e7d1f70b5dbcc32e702bf9a1f7e97</id>
<content type='text'>
We've been moving all omap2+ based systems to boot in device tree only
mode for a few years now. Only omap3 has legacy booting support
remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
files for booting with device tree.

As it seems this board only has minimal support upstreamed for the
legacy booting and has not seen activity for on the mailing lists
for a few years, let's attempt to remove the related legacy board-*.c
file.

I do not have this board, but it seems getting the same level of
support with device tree based booting is mostly just configuring
the .dts file. And there is no need to upgrade the boot loader as
we can boot with appended DTB too. And most of the omap3 boards
seem to be related to omap3-evm, and omap3beagleboard that are
supported with device tree based booting.

If somebody is using this board actively with the mainline kernel,
please communicate this to the linux-omap mailing list so we can
get the board booting with device tree based support. I can help
some too getting the minimal device tree based booting going if
help is needed.

The reason for attempting to remove this board now is that I'd
rather get the remaining omap3 legacy booting support into a known
state where we at least have a .dts file being written for the
remaining legacy boards. That is because for the next few merge
cycles we can still revert this patch if absolutely necessary,
but I'd rather not get suprised by missing .dts files at the point
where we are ready to drop all remaining omap3 legacy booting
support later on.

http://www.embest-tech.com/product/single-board-computers/index.html

Cc: Thomas Weber &lt;thomas@tomweber.eu&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We've been moving all omap2+ based systems to boot in device tree only
mode for a few years now. Only omap3 has legacy booting support
remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
files for booting with device tree.

As it seems this board only has minimal support upstreamed for the
legacy booting and has not seen activity for on the mailing lists
for a few years, let's attempt to remove the related legacy board-*.c
file.

I do not have this board, but it seems getting the same level of
support with device tree based booting is mostly just configuring
the .dts file. And there is no need to upgrade the boot loader as
we can boot with appended DTB too. And most of the omap3 boards
seem to be related to omap3-evm, and omap3beagleboard that are
supported with device tree based booting.

If somebody is using this board actively with the mainline kernel,
please communicate this to the linux-omap mailing list so we can
get the board booting with device tree based support. I can help
some too getting the minimal device tree based booting going if
help is needed.

The reason for attempting to remove this board now is that I'd
rather get the remaining omap3 legacy booting support into a known
state where we at least have a .dts file being written for the
remaining legacy boards. That is because for the next few merge
cycles we can still revert this patch if absolutely necessary,
but I'd rather not get suprised by missing .dts files at the point
where we are ready to drop all remaining omap3 legacy booting
support later on.

http://www.embest-tech.com/product/single-board-computers/index.html

Cc: Thomas Weber &lt;thomas@tomweber.eu&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: OMAP3: Remove legacy support for EMA-Tech Stalker board</title>
<updated>2015-03-16T23:56:58+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2015-03-16T23:56:58+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=35cc73dae6374919affa64ba3092b6a1801c0943'/>
<id>35cc73dae6374919affa64ba3092b6a1801c0943</id>
<content type='text'>
We've been moving all omap2+ based systems to boot in device tree only
mode for a few years now. Only omap3 has legacy booting support
remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
files for booting with device tree.

As it seems this board only has minimal support upstreamed for the
legacy booting and has not seen activity for on the mailing lists
for a few years, let's attempt to remove the related legacy board-*.c
file.

I do not have this board, but it seems getting the same level of
support with device tree based booting is mostly just configuring
the .dts file. And there is no need to upgrade the boot loader as
we can boot with appended DTB too. And most of the omap3 boards
seem to be related to omap3-evm, and omap3beagleboard that are
supported with device tree based booting.

If somebody is using this board actively with the mainline kernel,
please communicate this to the linux-omap mailing list so we can
get the board booting with device tree based support. I can help
some too getting the minimal device tree based booting going if
help is needed.

The reason for attempting to remove this board now is that I'd
rather get the remaining omap3 legacy booting support into a known
state where we at least have a .dts file being written for the
remaining legacy boards. That is because for the next few merge
cycles we can still revert this patch if absolutely necessary,
but I'd rather not get suprised by missing .dts files at the point
where we are ready to drop all remaining omap3 legacy booting
support later on.

Also looks like this board is no longer listed on ema-tech.com
product page at:

http://ema-tech.com/en/categories.html

Cc: Jason Lam &lt;lzg@ema-tech.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We've been moving all omap2+ based systems to boot in device tree only
mode for a few years now. Only omap3 has legacy booting support
remaining. Most omap3 boards already have related arch/arm/boot/*.dts*
files for booting with device tree.

As it seems this board only has minimal support upstreamed for the
legacy booting and has not seen activity for on the mailing lists
for a few years, let's attempt to remove the related legacy board-*.c
file.

I do not have this board, but it seems getting the same level of
support with device tree based booting is mostly just configuring
the .dts file. And there is no need to upgrade the boot loader as
we can boot with appended DTB too. And most of the omap3 boards
seem to be related to omap3-evm, and omap3beagleboard that are
supported with device tree based booting.

If somebody is using this board actively with the mainline kernel,
please communicate this to the linux-omap mailing list so we can
get the board booting with device tree based support. I can help
some too getting the minimal device tree based booting going if
help is needed.

The reason for attempting to remove this board now is that I'd
rather get the remaining omap3 legacy booting support into a known
state where we at least have a .dts file being written for the
remaining legacy boards. That is because for the next few merge
cycles we can still revert this patch if absolutely necessary,
but I'd rather not get suprised by missing .dts files at the point
where we are ready to drop all remaining omap3 legacy booting
support later on.

Also looks like this board is no longer listed on ema-tech.com
product page at:

http://ema-tech.com/en/categories.html

Cc: Jason Lam &lt;lzg@ema-tech.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: OMAP4: remove dead kconfig option OMAP4_ERRATA_I688</title>
<updated>2015-03-16T23:23:28+00:00</updated>
<author>
<name>Stefan Hengelein</name>
<email>stefan.hengelein@fau.de</email>
</author>
<published>2015-02-25T18:44:27+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=606da4826b89b044b51e3a84958b802204cfe4c7'/>
<id>606da4826b89b044b51e3a84958b802204cfe4c7</id>
<content type='text'>
The Kconfig-Option OMAP4_ERRATA_I688 is never visible due to a
contradiction in it's dependencies.
The option requires ARCH_MULTIPLATFORM to be 'disabled'. However, an
enclosing menu requires either ARCH_MULTI_V6 or ARCH_MULTI_V7 to be
enabled. These options inherit a dependency from an enclosing menu,
that requires ARCH_MULTIPLATFORM to be 'enabled'.
This is a contradiction and made this option also unavailable for
non-multiplatform configurations.

Since there are no selects on OMAP4_ERRATA_I688, which would ignore
dependencies, the code related to that option is dead and can be
removed.

This (logical) defect has been found with the undertaker tool.
(https://undertaker.cs.fau.de)

Signed-off-by: Stefan Hengelein &lt;stefan.hengelein@fau.de&gt;
Acked-by: Santosh Shilimkar &lt;ssantosh@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The Kconfig-Option OMAP4_ERRATA_I688 is never visible due to a
contradiction in it's dependencies.
The option requires ARCH_MULTIPLATFORM to be 'disabled'. However, an
enclosing menu requires either ARCH_MULTI_V6 or ARCH_MULTI_V7 to be
enabled. These options inherit a dependency from an enclosing menu,
that requires ARCH_MULTIPLATFORM to be 'enabled'.
This is a contradiction and made this option also unavailable for
non-multiplatform configurations.

Since there are no selects on OMAP4_ERRATA_I688, which would ignore
dependencies, the code related to that option is dead and can be
removed.

This (logical) defect has been found with the undertaker tool.
(https://undertaker.cs.fau.de)

Signed-off-by: Stefan Hengelein &lt;stefan.hengelein@fau.de&gt;
Acked-by: Santosh Shilimkar &lt;ssantosh@kernel.org&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: OMAP3: Add back Kconfig option MACH_OMAP3517EVM for ASoC</title>
<updated>2015-01-20T16:49:08+00:00</updated>
<author>
<name>Tony Lindgren</name>
<email>tony@atomide.com</email>
</author>
<published>2015-01-20T16:49:08+00:00</published>
<link rel='alternate' type='text/html' href='http://rtsrv.cs.unc.edu/cgit/cgit.cgi/litmus-rt.git/commit/?id=549f95ed20168daa06901054a028e185ebb905ab'/>
<id>549f95ed20168daa06901054a028e185ebb905ab</id>
<content type='text'>
We still have SND_OMAP_SOC_AM3517EVM depending on MACH_OMAP3517EVM,
so let's keep MACH_OMAP3517EVM Kconfig option around for a little
bit longer.

This removes the dependency between ARM SoC changes and the ASoC
changes, and allows the following three options for the driver:

1. Update the driver for device tree based booting

2. Initialize the driver with legacy platform data, then update
   the driver for device tree based booting

3. Just remove the driver if there are no audio users for
   3517-evm board

Reported-by: Paul Bolle &lt;pebolle@tiscali.nl&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We still have SND_OMAP_SOC_AM3517EVM depending on MACH_OMAP3517EVM,
so let's keep MACH_OMAP3517EVM Kconfig option around for a little
bit longer.

This removes the dependency between ARM SoC changes and the ASoC
changes, and allows the following three options for the driver:

1. Update the driver for device tree based booting

2. Initialize the driver with legacy platform data, then update
   the driver for device tree based booting

3. Just remove the driver if there are no audio users for
   3517-evm board

Reported-by: Paul Bolle &lt;pebolle@tiscali.nl&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
