[GIT PULL] OMAP fbdev changes for 3.12
Hi Linus, Here are the OMAP specific fbdev changes for 3.12. I've got this pull request separate from the main fbdev pull request, as this contains a bunch of OMAP board file changes and thus could possibly be rejected in case of bad conflicts. The removal of the old display drivers depend on the board file changes, so Tony Lindgren suggested taking them together via fbdev tree. These are in linux-next, and also Tony didn't see any conflicts with any of the branches he had, so they should go in clean. Tomi The following changes since commit b36f4be3de1b123d8601de062e7dbfc904f305fb: Linux 3.11-rc6 (2013-08-18 14:36:53 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git tags/fbdev-3.12-omap-legacy-removal for you to fetch changes up to 9560dc1059222d059d494a64e5da4c54d23838da: OMAPDSS: rename omap_dss_device's 'device' field to 'dst' (2013-08-30 08:51:11 +0300) OMAP specific fbdev changes for 3.12: * Change the OMAP board files to use the new OMAP display drivers * Remove all the old drivers, and the related auxiliary code. Tomi Valkeinen (35): ARM: OMAP2+: Remove legacy DSS initialization for omap4 ARM: OMAP2+: Add selected display drivers to omap2plus_defconfig ARM: OMAP: dss-common: use new display drivers ARM: OMAP: 4430SDP: remove picodlp device data ARM: OMAP: overo: use new display drivers ARM: OMAP: rx51: use new display drivers ARM: OMAP: beagle: use new display drivers ARM: OMAP: devkit8000: use new display drivers ARM: OMAP: 2430SDP: use new display drivers ARM: OMAP: LDP: use new display drivers ARM: OMAP: omap3stalker: use new display drivers ARM: OMAP: igep0020: use new display drivers ARM: OMAP: cm-t35: use new display drivers ARM: OMAP: H4: use new display drivers ARM: OMAP: 3430SDP: use new display drivers ARM: OMAP: OMAP3EVM: use new display drivers ARM: OMAP: Pandora: use new display drivers ARM: OMAP: Zoom: use new display drivers ARM: OMAP: AM3517EVM: use new display drivers ARM: OMAP2+: Remove old display drivers from omap2plus_defconfig OMAPDSS: RFBI: Mark RFBI as broken OMAPDSS: remove omap_dss_device-channel field OMAPDSS: fix DPI and SDI device ids OMAPDSS: SDI: change regulator handling OMAPDSS: DPI: change regulator handling OMAPDSS: remove all old panel drivers OMAPDSS: DPI: remove code related to old panel model OMAPDSS: HDMI: remove code related to old panel model OMAPDSS: DSI: remove code related to old panel model OMAPDSS: SDI: remove code related to old panel model OMAPDSS: VENC: remove code related to old panel model OMAPDSS: RFBI: remove code related to old panel model OMAPDSS: DSS: remove legacy dss bus support OMAPDSS: rename omap_dss_device's 'output' to 'src' OMAPDSS: rename omap_dss_device's 'device' field to 'dst' arch/arm/configs/omap2plus_defconfig | 12 +- arch/arm/mach-omap2/board-2430sdp.c| 57 +- arch/arm/mach-omap2/board-3430sdp.c| 83 +- arch/arm/mach-omap2/board-am3517evm.c | 113 +- arch/arm/mach-omap2/board-cm-t35.c | 100 +- arch/arm/mach-omap2/board-devkit8000.c | 96 +- arch/arm/mach-omap2/board-h4.c | 48 +- arch/arm/mach-omap2/board-igep0020.c | 36 +- arch/arm/mach-omap2/board-ldp.c| 68 +- arch/arm/mach-omap2/board-omap3beagle.c| 56 +- arch/arm/mach-omap2/board-omap3evm.c | 87 +- arch/arm/mach-omap2/board-omap3pandora.c | 48 +- arch/arm/mach-omap2/board-omap3stalker.c | 61 +- arch/arm/mach-omap2/board-overo.c | 160 +- arch/arm/mach-omap2/board-rx51-peripherals.c | 12 + arch/arm/mach-omap2/board-rx51-video.c | 35 +- arch/arm/mach-omap2/board-zoom-display.c | 30 +- arch/arm/mach-omap2/display.c |4 +- arch/arm/mach-omap2/dss-common.c | 244 ++- arch/arm/mach-omap2/dss-common.h |2 - drivers/gpu/drm/omapdrm/omap_encoder.c |2 +- drivers/video/omap2/Kconfig|1 - drivers/video/omap2/Makefile |1 - drivers/video/omap2/displays-new/encoder-tfp410.c | 14 +- .../video/omap2/displays-new/encoder-tpd12s015.c | 14 +- drivers/video/omap2/displays/Kconfig | 75 - drivers/video/omap2/displays/Makefile | 11 - drivers/video/omap2/displays/panel-acx565akm.c | 798 -- drivers/video/omap2/displays/panel-generic-dpi.c | 744 -- .../omap2/displays/panel-lgphilips-lb035q02.c | 262
[PATCH v2] ARM: omap2: throw the die id into the entropy pool
Atleast eight bytes of this number are totally unique for the device
it seems, so this is a perfect candidate for feeding the entropy
pool. One byte more or less of constants does not matter so feed in
the entire OID struct.
Cc: Theodore Ts'o ty...@mit.edu
Cc: Paul Walmsley p...@pwsan.com
Reviewed-by: Kevin Hilman khil...@linaro.org
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
ChangeLog v1-v2:
- Use omap_device_initcall() to avoid calling on non-OMAPs.
---
arch/arm/mach-omap2/id.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 2dc62a2..9260d09 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -18,6 +18,7 @@
#include linux/kernel.h
#include linux/init.h
#include linux/io.h
+#include linux/random.h
#include linux/slab.h
#ifdef CONFIG_SOC_BUS
@@ -130,6 +131,17 @@ void omap_get_die_id(struct omap_die_id *odi)
odi-id_3 = read_tap_reg(OMAP_TAP_DIE_ID_3);
}
+static int __init omap_feed_randpool(void)
+{
+ struct omap_die_id odi;
+
+ /* Throw the die ID into the entropy pool at boot */
+ omap_get_die_id(odi);
+ add_device_randomness(odi, sizeof(odi));
+ return 0;
+}
+omap_device_initcall(omap_feed_randpool);
+
void __init omap2xxx_check_revision(void)
{
int i, j;
--
1.8.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 0/6] ARM: OMAP2+: AM43x/AM335x prcm reset driver
Hi Afzal,
Am Montag, den 02.09.2013, 19:41 +0530 schrieb Afzal Mohammed:
Hi,
This is an attempt to achieve reset on AM43x/AM335x based SoC's with
reset driver making use of the reset framework.
prcm node is added in device tree, which would hold reset bindings.
Initially node was made as a one that represents reset functionality
of SoC. but ended up with node for prcm (which is felt to be natural
choice) instead. I am a bit doubtful whether placement of prcm node in
root node as in this series is the right thing.
Reset driver gets probed for specific prcm node, the same defines
register details to be used for a particular SoC (using .data field
associated with .compatible in driver match table).
Another option to handle different SoC's would be to add register
details to DT and let the driver extract it from DT. I vaguely
remember seeing a thread mentioning that putting register details in
DT is not preferred. But open to putting register level details
instead in DT if that is being generally preferred. This would have
advantage that adding reset support for a new SoC would be easier, but
would have to put more thought before doing so as DT bindings should
not change.
With the approach taken here, for supporting a new SoC with new prcm
register details, driver would have to be updated much like the way a
pci based ethernet driver would have to be updated to handle a new IP
version that is not register level compatible with the existing ones.
In this series out of the three IP's (gfx, m3, pruss) that would need
reset support, here as a proof of concept only gfx is taken care.
Other's can be easily supported by adding new register data array
entries.
Two new reset API's are provided to check whether reset is ready and
to clear reset. This would be required in case IP needs to mix reset
handling procedure with power/clock managment procedure to achieve
proper reset and these procedures are sometimes IP specific that would
make it difficult to handle reset fully in pm_runtime platform support.
*--*
client IP handling s/w (DT based) should do as follows:
1. Specify reset handle in the relevant DT node, for eg.
myip@deadbeef {
:
:
/* here prcm is the handle to reset binding node */
resets = prcm 0;
};
2. In driver, that require reset to be deasserted,
(this is the sequence required for gfx on AM43x/AM335x, this would
depend on requirements of the IP)
mydriver_probe(struct platform device *pdev)
{
:
:
reset_control_get(pdev-dev, NULL);
reset_control_clear_reset();
reset_control_deassert();
pm_runtime_get_sync();
if (reset_control_is_reset() != true)
goto err;
reset_control_put();
:
:
}
*--*
if possible, I'd like to move this logic into the reset controller
driver. Can this be reordered to enable power before deasserting the
reset line (assuming it is initially asserted)? In this case, I'd
suggest to just call device_reset:
pm_runtime_get_sync(pdev-dev);
ret = device_reset(pdev-dev);
if (ret)
goto err;
The ops.reset callback in the prcm driver then can handle clearing
the reset status bit, deasserting the reset control bit, and waiting for
the reset status bit to be set (or timing out with an error).
May be removing reset handling in hwmod can be considered by making
use of reset driver.
Or as another extreme, perhaps, other logic's in the prcm can be
handled by a new prcm driver and then this reset driver can be a child
of it.
Regards
Afzal
Afzal Mohammed (6):
reset: is_reset and clear_reset api's
doc: dt: binding: omap: am43x/am335x prcm reset
reset: am43x/am335x support
ARM: OMAP2+: AM43x/AM335x: have reset controller
ARM: dts: AM335x: prcm node (for reset)
ARM: dts: AM4372: prcm node (for reset)
.../devicetree/bindings/arm/omap/prcm.txt | 13 ++
arch/arm/boot/dts/am33xx.dtsi | 6 +
arch/arm/boot/dts/am4372.dtsi | 6 +
arch/arm/mach-omap2/Kconfig| 2 +
drivers/reset/Kconfig | 14 ++
drivers/reset/Makefile | 1 +
drivers/reset/amx3_reset.c | 157
+
drivers/reset/core.c | 32 +
include/linux/reset-controller.h | 2 +
include/linux/reset.h | 2 +
10 files changed, 235 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/prcm.txt
create mode 100644 drivers/reset/amx3_reset.c
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: [PATCH RFC 0/6] ARM: OMAP2+: AM43x/AM335x prcm reset driver
Hi Philipp,
On Thursday 05 September 2013 03:37 PM, Philipp Zabel wrote:
Am Montag, den 02.09.2013, 19:41 +0530 schrieb Afzal Mohammed:
Two new reset API's are provided to check whether reset is ready and
to clear reset. This would be required in case IP needs to mix reset
handling procedure with power/clock managment procedure to achieve
proper reset and these procedures are sometimes IP specific that would
make it difficult to handle reset fully in pm_runtime platform support.
client IP handling s/w (DT based) should do as follows:
2. In driver, that require reset to be deasserted,
(this is the sequence required for gfx on AM43x/AM335x, this would
depend on requirements of the IP)
mydriver_probe(struct platform device *pdev)
{
:
:
reset_control_get(pdev-dev, NULL);
reset_control_clear_reset();
reset_control_deassert();
pm_runtime_get_sync();
if (reset_control_is_reset() != true)
goto err;
reset_control_put();
:
:
}
if possible, I'd like to move this logic into the reset controller
driver. Can this be reordered to enable power before deasserting the
reset line (assuming it is initially asserted)? In this case, I'd
suggest to just call device_reset:
pm_runtime_get_sync(pdev-dev);
ret = device_reset(pdev-dev);
if (ret)
goto err;
The ops.reset callback in the prcm driver then can handle clearing
the reset status bit, deasserting the reset control bit, and waiting for
the reset status bit to be set (or timing out with an error).
I too would have loved to have it in such a clean way and was initially
proceeding in that direction, but there is an issue specific to OMAP
family SoC's, which was required to be taken care of (even though
present use case for AM335x/AM43x would work [as it does not have
hardware supervised clockdomain mode] with a small change in platform
level power management support code - a generic one shared with other
OMAP family SoC's)
For a module to be reset, clock domain to which the module clock belongs
should be set to software supervised mode. During pm_runtime_get_sync,
in OMAP platform level handling code, it first put clockdomain into
software supervised mode, enables clock to module, and once module is
ready, module will be put to hardware supervised mode. In hardware
supervised mode, reset may not happen.
So if device_reset() is done after pm_runtime_get_sync(), reset may not
happen as by the time device_reset() is called, clockdomain would be in
hardware supervised mode. But in other case, as reset is already
deasserted when pm_runtime_get_sync() is called, module would be reset
as it first puts to software supervised mode.
And device reset would happen only upon enabling clock to module (if
reset was deasserted) by pm_runtime_get_sync(), so reset status has to
be checked after pm call, preventing us having device_reset() before
pm_runtime_get_sync(), or else in that case we have to sacrifice on
reset status checking (which may not be reliable)
Another alternative would have been to integrate this reset handling in
low level power management code thus hiding all reset handling from
driver, but as far as I know the reset sequence to be done is sometimes
IP specific, preventing it.
Regards
Afzal
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 7/8] mailbox/omap: add code to support the wkupm3 operations
Kevin, Sorry, I couldn't get back earlier due to long weekend. On 08/29/2013 11:57 AM, Kevin Hilman wrote: Suman Anna s-a...@ti.com writes: [...] Yeah, the wkupm3 mbox usage is actually odd (an unfortunate result of the way the hardware is designed) heh, design is a generous term for this hardware. ;) and doesn't quite fit into the way a regular mailbox is used. I will summarize the following into the changelog in the next version to better explain the odd usage and avoid any confusion. A typical mbox device is used for communicating both to and fro with a slave processor using two fifos, and has two internal interrupts on the MPU that needs to be handled - a rx interrupt for processing in-bound messages but there are no inbound message, so we don't care about that interrupt. and a tx-ready interrupt for handling mbox tx readiness. Yes, this is where it gets tricky. However, in the case of AM33xx, the MPU doesn't care about RX interrupts and the M3 doesn't care about TX interrupts. hmm Correct, MPU still needs to care about the Tx interrupt though. Since the WkupM3 cannot access the mailbox registers, the burden of handling the M3's Rx interrupt as well as those associated with the MPU lies with the wkupm3 mbox device code. As you can see, this usage is non-standard, and warrants that the code deal with both usr_ids since they would be different (0 for MPU and 3 for M3). Another possibility would be to allow configurability over which usr_id is used for RX and which usr_id is used for TX. IOW, have the DT binding have a usr_id_tx and and optional usr_id_rx. If usr_id_rx isn't present (for most normal users), it uses usr_id_tx. For AM33xx, we'd use usr_id_tx=0, usr_id_rx=3. That would allow you to get rid of the overrides for the IRQ functions, no? But as I think about it, this id a bit yucky too. Yet another possiblity would be to use the DT to define 2 mailboxes. One normal one for control of the MPU's view (usr_id=0) and one dummy one (usr_id=3) for control of the M3's view of the world. Since Linux needs to control both, just define them both in the DT for linux control, and drive them from the M3 driver: I like the idea of having the ability to define a omap mailbox as rx-only or tx-only or both, rather than defining two usr_ids. So far, for all the IPC communication between processors, we always needed a pair since we only had a single instance and the fifos are unidirectional. For DRA7xx, where we have multiple instances, this should allow flexibility to pick different fifos from different instances. I will redo the patches to support this feature in general. Sounds good. Does that mean you plan to define a TX only mailbox for the MPU view (usr_id=0) and an RX only mailbox for the M3 view (usr_id=3)? I will see how this pans out for the M3 view, because mainly from the API point of view, we will have one to send, and the receive is usually a callback. mbox_mpu = omap_mbox_get(normal one) mbox_m3 = omap_mbox_get(M3 one) omap_mbox_enable_irq(mbox_m3, IRQ_RX) omap_mbox_msg_send(mbox_mpu, msg) omap_mbox_disable_irq(mbox_m3, IRQ_RX) omap_mbox_fifo_readback(mbox_mpu) /* API from earlier patch */ omap_mbox_ack_irq(mbox_m3) /* this would need to be added/exported */ If you look at this sequence, there's an inherent understanding of the mailbox behavior. The enable and disable are used to suppress additional interrupts, since the mailbox IP would always trigger an interrupt as long as there is a message within the FIFO. The fifo_readback is clearing the message, but it need not be done in the response message as was done in the previous PM series. The WkupM3 driver has to primarily just trigger an interrupt. OK, I didn't fully understand the need for the readback everytime either, but was just following what was proposed in this series. Yeah, the reads are needed to take out the message, since the h/w has a fifo, and as long as messages are present (number doesn't matter) and mbox irq enabled, the interrupt keeps getting triggered. Reading the message, and acking the interrupt within the mailbox IP are the typical actions performed on an mbox interrupt. This patch essentially was doing all the above steps with the send message API, so at the end of it, an interrupt is raised within the M3's NVIC, and the firmware deals with performing the necessary steps based on the message in IPC Control registers. AFAICS, other than the new APIs to export, this wouldn't require any additional M3 quirks in the mailbox driver. The omap_mbox_fifo_readback is not a generic mailbox API and actually makes the mailbox driver complex since the driver does support tx buffering as well. I think this could be solved by just having some quirks flags or similar for each mbox device. e.g. a quirk that says read back message immediately after sending or something like that. Or maybe an IRQ only
Re: [PATCHv2] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
Op 8 jul. 2013, om 14:42 heeft Mark Jackson mpfj-l...@newflow.co.uk het volgende geschreven: On 18/01/13 05:14, Mugunthan V N wrote: On 1/18/2013 3:48 AM, Peter Korsgaard wrote: When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot mode in U-Boot), nothing updates the ethernet hwaddr specified for the CPSW slaves, causing the driver to use a random hwaddr, which is some times troublesome. The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes more sense to default to these rather than random ones. Add a fixup step which adds mac-address dt properties using the efuse addresses if the DTB didn't contain valid ones. Signed-off-by: Peter Korsgaard jac...@sunsite.dk This implementation looks fine. Acked-by: Mugunthan V N mugunthan...@ti.com Tested-by: Mark Jackson mpfj-l...@newflow.co.uk Tested-by: Koen Kooi k...@dominion.thruhere.net -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
On Mon, Jul 15, 2013 at 07:31:18AM +0200, Peter Korsgaard wrote: Mark == Mark Jackson mpfj-l...@newflow.co.uk writes: Hi, Mark On 08/07/13 13:42, Mark Jackson wrote: On 18/01/13 05:14, Mugunthan V N wrote: On 1/18/2013 3:48 AM, Peter Korsgaard wrote: When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot mode in U-Boot), nothing updates the ethernet hwaddr specified for the CPSW slaves, causing the driver to use a random hwaddr, which is some times troublesome. The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes more sense to default to these rather than random ones. Add a fixup step which adds mac-address dt properties using the efuse addresses if the DTB didn't contain valid ones. Signed-off-by: Peter Korsgaard jac...@sunsite.dk This implementation looks fine. Acked-by: Mugunthan V N mugunthan...@ti.com Tested-by: Mark Jackson mpfj-l...@newflow.co.uk Mark Is this ever going to be put into the mainline code ? Good question. Tony, could you please pick this up? It has been pending since January and has a number of acks. Do you want me to resend? Also working nicely here on 3.11. Tested-by: Matt Porter matt.por...@linaro.org Kevin or Olof: can you apply? Seems to be continuing no response after Ack back in January. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
On Thu, Sep 5, 2013 at 1:16 PM, Matt Porter matt.por...@linaro.org wrote: On Mon, Jul 15, 2013 at 07:31:18AM +0200, Peter Korsgaard wrote: Mark == Mark Jackson mpfj-l...@newflow.co.uk writes: Hi, Mark On 08/07/13 13:42, Mark Jackson wrote: On 18/01/13 05:14, Mugunthan V N wrote: On 1/18/2013 3:48 AM, Peter Korsgaard wrote: When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot mode in U-Boot), nothing updates the ethernet hwaddr specified for the CPSW slaves, causing the driver to use a random hwaddr, which is some times troublesome. The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes more sense to default to these rather than random ones. Add a fixup step which adds mac-address dt properties using the efuse addresses if the DTB didn't contain valid ones. Signed-off-by: Peter Korsgaard jac...@sunsite.dk This implementation looks fine. Acked-by: Mugunthan V N mugunthan...@ti.com Tested-by: Mark Jackson mpfj-l...@newflow.co.uk Mark Is this ever going to be put into the mainline code ? Good question. Tony, could you please pick this up? It has been pending since January and has a number of acks. Do you want me to resend? Also working nicely here on 3.11. Tested-by: Matt Porter matt.por...@linaro.org Kevin or Olof: can you apply? Seems to be continuing no response after Ack back in January. I have no idea what the patch is, it's no longer in the email. Can you resend it, please? -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
Olof == Olof Johansson o...@lixom.net writes: Tested-by: Matt Porter matt.por...@linaro.org Kevin or Olof: can you apply? Seems to be continuing no response after Ack back in January. Olof I have no idea what the patch is, it's no longer in the email. Can you Olof resend it, please? Sure, one moment. -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
mode in U-Boot), nothing updates the ethernet hwaddr specified for the
CPSW slaves, causing the driver to use a random hwaddr, which is some times
troublesome.
The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
more sense to default to these rather than random ones. Add a fixup step
which adds mac-address dt properties using the efuse addresses if the DTB
didn't contain valid ones.
Signed-off-by: Peter Korsgaard jac...@sunsite.dk
Acked-by: Mugunthan V N mugunthan...@ti.com
Tested-by: Mark Jackson mpfj-l...@newflow.co.uk
Tested-by: Koen Kooi k...@dominion.thruhere.net
Tested-by: Matt Porter matt.por...@linaro.org
---
Resent without changes.
arch/arm/mach-omap2/Makefile |3 ++
arch/arm/mach-omap2/am33xx-cpsw.c | 94 +
arch/arm/mach-omap2/control.h |4 ++
3 files changed, 101 insertions(+)
create mode 100644 arch/arm/mach-omap2/am33xx-cpsw.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index afb457c..0afee42 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -305,4 +305,7 @@ endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
+cpsw-$(CONFIG_TI_CPSW) := am33xx-cpsw.o
+obj-y += $(cpsw-m) $(cpsw-y)
+
obj-y += common-board-devices.o twl-common.o
dss-common.o
diff --git a/arch/arm/mach-omap2/am33xx-cpsw.c
b/arch/arm/mach-omap2/am33xx-cpsw.c
new file mode 100644
index 000..5a674d9
--- /dev/null
+++ b/arch/arm/mach-omap2/am33xx-cpsw.c
@@ -0,0 +1,94 @@
+/*
+ * am335x specific cpsw dt fixups
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/etherdevice.h
+#include linux/of.h
+#include linux/of_net.h
+
+#include soc.h
+#include control.h
+
+/**
+ * am33xx_dt_cpsw_set_mac_from_efuse - Add mac-address property using
+ * ethernet hwaddr from efuse
+ * @np:Pointer to the cpsw slave to set mac address of
+ * @idx: Mac address index to use from efuse
+ */
+static void am33xx_dt_cpsw_set_mac_from_efuse(struct device_node *np, int idx)
+{
+ struct property *prop;
+ u32 lo, hi;
+ u8 *mac;
+
+ switch (idx) {
+ case 0:
+ lo = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID0_LOW);
+ hi = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID0_HIGH);
+ break;
+
+ case 1:
+ lo = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID1_LOW);
+ hi = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID1_HIGH);
+ break;
+
+ default:
+ pr_err(cpsw.%d: too many slaves found\n, idx);
+ return;
+ }
+
+ prop = kzalloc(sizeof(*prop) + ETH_ALEN, GFP_KERNEL);
+ if (!prop)
+ return;
+
+ prop-value = prop + 1;
+ prop-length = ETH_ALEN;
+ prop-name = kstrdup(mac-address, GFP_KERNEL);
+ if (!prop-name) {
+ kfree(prop);
+ return;
+ }
+
+ mac = prop-value;
+
+ mac[0] = hi;
+ mac[1] = hi 8;
+ mac[2] = hi 16;
+ mac[3] = hi 24;
+ mac[4] = lo;
+ mac[5] = lo 8;
+
+ of_update_property(np, prop);
+
+ pr_info(cpsw.%d: No hwaddr in dt. Using %pM from efuse\n, idx, mac);
+}
+
+static int __init am33xx_dt_cpsw_mac_fixup(void)
+{
+ struct device_node *np, *slave;
+ int idx = 0;
+
+ if (!soc_is_am33xx())
+ return -ENODEV;
+
+ for_each_compatible_node(np, NULL, ti,cpsw)
+ for_each_node_by_name(slave, slave) {
+ if (!of_get_mac_address(slave))
+ am33xx_dt_cpsw_set_mac_from_efuse(slave, idx);
+ idx++;
+ }
+
+ return 0;
+}
+arch_initcall(am33xx_dt_cpsw_mac_fixup);
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index f7d7c2e..5d684b7 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -352,6 +352,10 @@
/* AM33XX CONTROL_STATUS register */
#define AM33XX_CONTROL_STATUS 0x040
#define AM33XX_CONTROL_SEC_CLK_CTRL0x1bc
+#define AM33XX_CONTROL_MAC_ID0_LOW 0x630
+#define AM33XX_CONTROL_MAC_ID0_HIGH0x634
+#define AM33XX_CONTROL_MAC_ID1_LOW 0x638
+#define
Re: [PATCH RESEND] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
Peter == Peter Korsgaard jac...@sunsite.dk writes: Peter When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old Peter U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot Peter mode in U-Boot), nothing updates the ethernet hwaddr specified for the Peter CPSW slaves, causing the driver to use a random hwaddr, which is some times Peter troublesome. Peter The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes Peter more sense to default to these rather than random ones. Add a fixup step Peter which adds mac-address dt properties using the efuse addresses if the DTB Peter didn't contain valid ones. Peter Signed-off-by: Peter Korsgaard jac...@sunsite.dk Peter Acked-by: Mugunthan V N mugunthan...@ti.com Peter Tested-by: Mark Jackson mpfj-l...@newflow.co.uk Peter Tested-by: Koen Kooi k...@dominion.thruhere.net Peter Tested-by: Matt Porter matt.por...@linaro.org Peter --- Peter Resent without changes. Argh, this was supposed to have been a resend of v2. Will resend that one instead. -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 RESEND] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
Hi,
On Thu, Sep 05, 2013 at 11:42:02PM +0200, Peter Korsgaard wrote:
When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
mode in U-Boot), nothing updates the ethernet hwaddr specified for the
CPSW slaves, causing the driver to use a random hwaddr, which is some times
troublesome.
The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
more sense to default to these rather than random ones. Add a fixup step
which adds mac-address dt properties using the efuse addresses if the DTB
didn't contain valid ones.
Signed-off-by: Peter Korsgaard jac...@sunsite.dk
Acked-by: Mugunthan V N mugunthan...@ti.com
Tested-by: Mark Jackson mpfj-l...@newflow.co.uk
Tested-by: Koen Kooi k...@dominion.thruhere.net
Tested-by: Matt Porter matt.por...@linaro.org
---
diff --git a/arch/arm/mach-omap2/am33xx-cpsw.c
b/arch/arm/mach-omap2/am33xx-cpsw.c
new file mode 100644
index 000..eec29a4
--- /dev/null
+++ b/arch/arm/mach-omap2/am33xx-cpsw.c
@@ -0,0 +1,94 @@
+/*
+ * am335x specific cpsw dt fixups
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/etherdevice.h
+#include linux/of.h
+#include linux/of_net.h
+
+#include soc.h
+#include control.h
+
+/**
+ * am33xx_dt_cpsw_set_mac_from_efuse - Add mac-address property using
+ * ethernet hwaddr from efuse
+ * @np: Pointer to the cpsw slave to set mac address of
+ * @idx: Mac address index to use from efuse
+ */
+static void am33xx_dt_cpsw_set_mac_from_efuse(struct device_node *np, int
idx)
+{
+ struct property *prop;
+ u32 lo, hi;
+ u8 *mac;
+
+ switch (idx) {
+ case 0:
+ lo = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID0_LOW);
+ hi = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID0_HIGH);
+ break;
+
+ case 1:
+ lo = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID1_LOW);
+ hi = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID1_HIGH);
+ break;
+
+ default:
+ pr_err(cpsw.%d: too many slaves found\n, idx);
+ return;
+ }
+
+ prop = kzalloc(sizeof(*prop) + ETH_ALEN, GFP_KERNEL);
+ if (!prop)
+ return;
+
+ prop-value = prop + 1;
+ prop-length = ETH_ALEN;
+ prop-name = kstrdup(mac-address, GFP_KERNEL);
Hmm. Do we want this to be mac-address or local-mac-address? If it's
mac-address, then this will override anything set by u-boot (by means
of priority in of_net). I don't think that's desireable. So it should
probably set local-mac-address instead.
+ if (!prop-name) {
+ kfree(prop);
+ return;
+ }
+
+ mac = prop-value;
+
+ mac[0] = hi;
+ mac[1] = hi 8;
+ mac[2] = hi 16;
+ mac[3] = hi 24;
+ mac[4] = lo;
+ mac[5] = lo 8;
+
+ of_update_property(np, prop);
mach-mxs does this too, I wonder if it's worth creating a small helper for it.
Doesn't have to be done as part of this patch but it's still worth doing.
+
+ pr_info(cpsw.%d: No hwaddr in dt. Using %pM from efuse\n, idx, mac);
+}
+
+static int __init am33xx_dt_cpsw_mac_fixup(void)
+{
+ struct device_node *np, *slave;
+ int idx = 0;
+
+ if (!soc_is_am33xx())
+ return -ENODEV;
+
+ for_each_compatible_node(np, NULL, ti,cpsw)
+ for_each_node_by_name(slave, slave) {
The binding doesn't enforce slave node names for the subnodes, so you
should probably just iterate over children. Right now they are named
slave@0 and slave@1, but lack reg properties (and a notion of what said
reg property would symbolize).
+ if (!of_get_mac_address(slave))
+ am33xx_dt_cpsw_set_mac_from_efuse(slave, idx);
+ idx++;
You're assuming that you get the children in order here, which is not
guaranteed.
Maybe best is to adjust the binding, to make reg mean something (i.e. the MAC
index for this hardware) and use the reg property of the childnode to tell
which efuse to read.
-Olof
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 RESEND] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
When booting with CONFIG_ARM_APPENDED_DTB (either because of using an old
U-Boot, not wanting the hassle of 2 files or when using Falcon fast boot
mode in U-Boot), nothing updates the ethernet hwaddr specified for the
CPSW slaves, causing the driver to use a random hwaddr, which is some times
troublesome.
The am33xx has unique ethernet hwaddrs programmed in the efuse, so it makes
more sense to default to these rather than random ones. Add a fixup step
which adds mac-address dt properties using the efuse addresses if the DTB
didn't contain valid ones.
Signed-off-by: Peter Korsgaard jac...@sunsite.dk
Acked-by: Mugunthan V N mugunthan...@ti.com
Tested-by: Mark Jackson mpfj-l...@newflow.co.uk
Tested-by: Koen Kooi k...@dominion.thruhere.net
Tested-by: Matt Porter matt.por...@linaro.org
---
Changes since v1:
- Use omap_arch_initcall as pointed out by Tony
arch/arm/mach-omap2/Makefile |3 ++
arch/arm/mach-omap2/am33xx-cpsw.c | 94 +
arch/arm/mach-omap2/control.h |4 ++
3 files changed, 101 insertions(+)
create mode 100644 arch/arm/mach-omap2/am33xx-cpsw.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index afb457c..0afee42 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -305,4 +305,7 @@ endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
+cpsw-$(CONFIG_TI_CPSW) := am33xx-cpsw.o
+obj-y += $(cpsw-m) $(cpsw-y)
+
obj-y += common-board-devices.o twl-common.o
dss-common.o
diff --git a/arch/arm/mach-omap2/am33xx-cpsw.c
b/arch/arm/mach-omap2/am33xx-cpsw.c
new file mode 100644
index 000..eec29a4
--- /dev/null
+++ b/arch/arm/mach-omap2/am33xx-cpsw.c
@@ -0,0 +1,94 @@
+/*
+ * am335x specific cpsw dt fixups
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/etherdevice.h
+#include linux/of.h
+#include linux/of_net.h
+
+#include soc.h
+#include control.h
+
+/**
+ * am33xx_dt_cpsw_set_mac_from_efuse - Add mac-address property using
+ * ethernet hwaddr from efuse
+ * @np:Pointer to the cpsw slave to set mac address of
+ * @idx: Mac address index to use from efuse
+ */
+static void am33xx_dt_cpsw_set_mac_from_efuse(struct device_node *np, int idx)
+{
+ struct property *prop;
+ u32 lo, hi;
+ u8 *mac;
+
+ switch (idx) {
+ case 0:
+ lo = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID0_LOW);
+ hi = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID0_HIGH);
+ break;
+
+ case 1:
+ lo = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID1_LOW);
+ hi = omap_ctrl_readl(AM33XX_CONTROL_MAC_ID1_HIGH);
+ break;
+
+ default:
+ pr_err(cpsw.%d: too many slaves found\n, idx);
+ return;
+ }
+
+ prop = kzalloc(sizeof(*prop) + ETH_ALEN, GFP_KERNEL);
+ if (!prop)
+ return;
+
+ prop-value = prop + 1;
+ prop-length = ETH_ALEN;
+ prop-name = kstrdup(mac-address, GFP_KERNEL);
+ if (!prop-name) {
+ kfree(prop);
+ return;
+ }
+
+ mac = prop-value;
+
+ mac[0] = hi;
+ mac[1] = hi 8;
+ mac[2] = hi 16;
+ mac[3] = hi 24;
+ mac[4] = lo;
+ mac[5] = lo 8;
+
+ of_update_property(np, prop);
+
+ pr_info(cpsw.%d: No hwaddr in dt. Using %pM from efuse\n, idx, mac);
+}
+
+static int __init am33xx_dt_cpsw_mac_fixup(void)
+{
+ struct device_node *np, *slave;
+ int idx = 0;
+
+ if (!soc_is_am33xx())
+ return -ENODEV;
+
+ for_each_compatible_node(np, NULL, ti,cpsw)
+ for_each_node_by_name(slave, slave) {
+ if (!of_get_mac_address(slave))
+ am33xx_dt_cpsw_set_mac_from_efuse(slave, idx);
+ idx++;
+ }
+
+ return 0;
+}
+omap_arch_initcall(am33xx_dt_cpsw_mac_fixup);
diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
index f7d7c2e..5d684b7 100644
--- a/arch/arm/mach-omap2/control.h
+++ b/arch/arm/mach-omap2/control.h
@@ -352,6 +352,10 @@
/* AM33XX CONTROL_STATUS register */
#define AM33XX_CONTROL_STATUS 0x040
#define AM33XX_CONTROL_SEC_CLK_CTRL0x1bc
+#define AM33XX_CONTROL_MAC_ID0_LOW 0x630
+#define AM33XX_CONTROL_MAC_ID0_HIGH0x634
+#define
Re: [PATCH v4 0/3] cleanup of gpio_pcf857x.c
Hi This patch series - removes the irq_demux_work - Uses devm_request_threaded_irq - Call the user handler iff gpio_to_irq is done. v1 -- v2 Split v1 to 3 patches v2 -- v3 Remove the unnecessary dts patches. v3 -- v4 Remove gpio-irq (in patch 2) Note: these patches were made after applying [1]. [1] - [PATCH v5] gpio: pcf857x: Add OF support - https://lkml.org/lkml/2013/8/27/70 George Cherian (3): gpio: pcf857x: change to devm_request_threaded_irq gpio: pcf857x: remove the irq_demux_work and gpio-irq gpio: pcf857x: call the gpio user handler iff gpio_to_irq is done drivers/gpio/gpio-pcf857x.c | 53 ++--- 1 file changed, 26 insertions(+), 27 deletions(-) For all patches Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
