Skip to content

Add NVIDIA Tegra FUSE driver

Thierry Reding linux-arm-kernel linux-tegra 1 version New

Get series with b4
b4 am 20140714065756.GG2081@ulmo

Versions newest first

  1. v1 Latest0 of 12 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 12 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 00/12] Add NVIDIA Tegra FUSE driver
Quoted 44 lines · Olof Johansson
Quoted 36 lines · Thierry Reding

From: Thierry Reding <[email protected]>

This series is an extension of Peter's original series to add a proper driver for the FUSE block on Tegra.

Patches 1 and 2 are preparatory work that cleans up include lists and introduces a function to query the Tegra chip ID rather than accessing a simple variable. This is used by subsequent patches to allow us to execute code when the variable is accessed to help in pin-pointing locations where it's accessed before the driver had a chance to initialize.

Patches 3 through 8 are Peter's series with a fixup patch by Stephen. I also moved the driver to drivers/soc/tegra/fuse as requested by Olof.

Patches 9 and 10 defer usages of the tegra_get_chip_id() function to a later stage (pure_initcall). This allows patch 11 to set up the early FUSE support code from an early initcall. This has the advantage of not requiring an explicit call from SoC setup code in arch/arm/mach-tegra and will allow the code to be shared on 64-bit variants of Tegra.

Patch 12 finally turns the PMC and powergate support code into a proper driver which also sets up a minimal environment from an early initcall. The driver isn't moved out of arch/arm/mach-tegra yet because people have suggested drivers/power as a good home, but that whole directory depends on the POWER_SUPPLY Kconfig symbol yet this driver doesn't have anything to do with that. Once that debate has been settled the driver can easily be moved out in a separate patch.

Some of the patches in this series introduce diagnostic WARN() messages if functions are called without setup having completed. I've booted the v3.16-rc1 kernel with these changes on top on Tegra20 (TrimSlice), Tegra30 (Beaver), Tegra114 (Dalmore) and Tegra124 (Jetson TK1) without encountering any of the diagnostic warnings and without noticing any breakage.

Quoted 6 lines

Olof, this series should address the concerns you expressed after reviewing Stephen's earlier pull request for Peter's FUSE driver series. It would be great if you could take another look to see if this is more according to your taste. I'll see if I can take this through linux-next for a little and if you have no objections will submit another pull request next week.

Quoted 6 lines

I haven't looked at all the patches in detail yet, but I do like the approach in general. I've also applied and pushed them out for build+test here, but they're queued behind a couple of other builds so I won't have it until morning (you can poll for boot logs at arm-soc.lixom.net/bootlogs/misc/v3.16-rc4-371-g2c9d948 if you want to preempt me).

Looks like Tegra boards are all fine. Thanks for testing these.

Quoted 6 lines
Quoted 2 lines

Peter De Schrijver (5):
ARM: tegra: export apb dma readl/writel

I thought I saw a patch from Peter that moved the apbio read code to the fuse driver since there are no other consumers. I think that's a reasonable thing to do.

That's a later patch in this series:

soc/tegra: fuse: move APB DMA into Tegra20 fuse driver

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140714/39e3fcd8/attachment-0001.sig>