linux-toradex.git/drivers/base/Makefile, branch tegra

drivers/base: add bus for System-on-Chip devices

2017-03-31T08:24:52+00:00

Traditionally, any System-on-Chip based platform creates a flat list
of platform_devices directly under /sys/devices/platform.

In order to give these some better structure, this introduces a new
bus type for soc_devices that are registered with the new
soc_device_register() function.  All devices that are on the same
chip should then be registered as child devices of the soc device.

The soc bus also exports a few standardised device attributes which
allow user space to query the specific type of soc.

Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman 
(cherry picked from commit 74d1d82cdaaec727f5072eb1c9f49b7e920e076f)

dma-buf: Introduce dma buffer sharing mechanism

2012-02-03T13:20:29+00:00

This is the first step in defining a dma buffer sharing mechanism.

A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.

The framework allows:
- creation of a buffer object, its association with a file pointer, and
   associated allocator-defined operations on that buffer. This operation is
   called the 'export' operation.
- different devices to 'attach' themselves to this exported buffer object, to
  facilitate backing storage negotiation, using dma_buf_attach() API.
- the exported buffer object to be shared with the other entity by asking for
   its 'file-descriptor (fd)', and sharing the fd across.
- a received fd to get the buffer object back, where it can be accessed using
   the associated exporter-defined operations.
- the exporter and user to share the scatterlist associated with this buffer
   object using map_dma_buf and unmap_dma_buf operations.

Atleast one 'attach()' call is required to be made prior to calling the
map_dma_buf() operation.

Couple of building blocks in map_dma_buf() are added to ease introduction
of sync'ing across exporter and users, and late allocation by the exporter.

For this first version, this framework will work with certain conditions:
- *ONLY* exporter will be allowed to mmap to userspace (outside of this
   framework - mmap is not a buffer object operation),
- currently, *ONLY* users that do not need CPU access to the buffer are
   allowed.

More details are there in the documentation patch.

This is based on design suggestions from many people at the mini-summits[1],
most notably from Arnd Bergmann , Rob Clark  and
Daniel Vetter .

The implementation is inspired from proof-of-concept patch-set from
Tomasz Stanislawski , who demonstrated buffer sharing
between two v4l2 devices. [2]

[1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
[2]: http://lwn.net/Articles/454389

Change-Id: I8ebd858ad86242ee7b02d5f42bb25c3edbd64fca
Signed-off-by: Sumit Semwal 
Signed-off-by: Sumit Semwal 
Reviewed-by: Daniel Vetter 
Reviewed-by: Dave Airlie 
Reviewed-and-Tested-by: Rob Clark 
Signed-off-by: Dave Airlie 
Signed-off-by: Hiroshi DOYU 
[Hiroshi DOYU: Backported from v3.3-rc1]
Reviewed-on: http://git-master/r/78384
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Varun Wadekar 
Reviewed-by: Ken Adams

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap

2011-07-23T18:14:47+00:00

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regulator: Convert tps65023 to use regmap API
  regmap: Add SPI bus support
  regmap: Add I2C bus support
  regmap: Add generic non-memory mapped register access API

regmap: Add generic non-memory mapped register access API

2011-07-23T06:56:03+00:00

There are many places in the tree where we implement register access for
devices on non-memory mapped buses, especially I2C and SPI. Since hardware
designers seem to have settled on a relatively consistent set of register
interfaces this can be effectively factored out into shared code.  There
are a standard set of formats for marshalling data for exchange with the
device, with the actual I/O mechanisms generally being simple byte
streams.

We create an abstraction for marshaling data into formats which can be
sent on the control interfaces, and create a standard method for
plugging in actual transport underneath that.

This is mostly a refactoring and renaming of the bottom level of the
existing code for sharing register I/O which we have in ASoC. A
subsequent patch in this series converts ASoC to use this.  The main
difference in interface is that reads return values by writing to a
location provided by a pointer rather than in the return value, ensuring
we can use the full range of the type for register data.  We also use
unsigned types rather than ints for the same reason.

As some of the devices can have very large register maps the existing
ASoC code also contains infrastructure for managing register caches.
This cache work will be moved over in a future stage to allow for
separate review, the current patch only deals with the physical I/O.

Signed-off-by: Mark Brown 
Acked-by: Liam Girdwood 
Acked-by: Greg Kroah-Hartman 
Acked-by: Wolfram Sang 
Acked-by: Grant Likely

drivers: iommu: move to a dedicated folder

2011-06-14T12:47:41+00:00

Create a dedicated folder for iommu drivers, and move the base
iommu implementation over there.

Grouping the various iommu drivers in a single location will help
finding similar problems shared by different platforms, so they
could be solved once, in the iommu framework, instead of solved
differently (or duplicated) in each driver.

Signed-off-by: Ohad Ben-Cohen 
Signed-off-by: Joerg Roedel

PM / Core: Introduce struct syscore_ops for core subsystems PM

2011-03-14T23:43:46+00:00

Some subsystems need to carry out suspend/resume and shutdown
operations with one CPU on-line and interrupts disabled.  The only
way to register such operations is to define a sysdev class and
a sysdev specifically for this purpose which is cumbersome and
inefficient.  Moreover, the arguments taken by sysdev suspend,
resume and shutdown callbacks are practically never necessary.

For this reason, introduce a simpler interface allowing subsystems
to register operations to be executed very late during system suspend
and shutdown and very early during resume in the form of
strcut syscore_ops objects.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Greg Kroah-Hartman

driver-core: base: change to new flag variable

2010-10-22T17:16:44+00:00

Replace EXTRA_CFLAGS with ccflags-y.

Signed-off-by: matt mooney 
Acked-by: WANG Cong 
Signed-off-by: Greg Kroah-Hartman

Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev

2009-09-15T16:50:49+00:00

Devtmpfs lets the kernel create a tmpfs instance called devtmpfs
very early at kernel initialization, before any driver-core device
is registered. Every device with a major/minor will provide a
device node in devtmpfs.

Devtmpfs can be changed and altered by userspace at any time,
and in any way needed - just like today's udev-mounted tmpfs.
Unmodified udev versions will run just fine on top of it, and will
recognize an already existing kernel-created device node and use it.
The default node permissions are root:root 0600. Proper permissions
and user/group ownership, meaningful symlinks, all other policy still
needs to be applied by userspace.

If a node is created by devtmps, devtmpfs will remove the device node
when the device goes away. If the device node was created by
userspace, or the devtmpfs created node was replaced by userspace, it
will no longer be removed by devtmpfs.

If it is requested to auto-mount it, it makes init=/bin/sh work
without any further userspace support. /dev will be fully populated
and dynamic, and always reflect the current device state of the kernel.
With the commonly used dynamic device numbers, it solves the problem
where static devices nodes may point to the wrong devices.

It is intended to make the initial bootup logic simpler and more robust,
by de-coupling the creation of the inital environment, to reliably run
userspace processes, from a complex userspace bootstrap logic to provide
a working /dev.

Signed-off-by: Kay Sievers 
Signed-off-by: Jan Blunck 
Tested-By: Harald Hoyer 
Tested-By: Scott James Remnant 
Signed-off-by: Greg Kroah-Hartman

driver-core: move dma-coherent.c from kernel to driver/base

2009-09-15T16:50:47+00:00

Placing dma-coherent.c in driver/base is better than in kernel,
since it contains code to do per-device coherent dma memory
handling.

Signed-off-by: Ming Lei 
Signed-off-by: Greg Kroah-Hartman

select IOMMU_API when DMAR and/or AMD_IOMMU is selected

2009-01-03T13:10:09+00:00

These two IOMMUs can implement the current version of this API. So
select the API if one or both of these IOMMU drivers is selected.

Signed-off-by: Joerg Roedel