On Tue, Jun 10, 2014 at 12:16:13AM +0200, Marcel Ziswiler wrote:
> On 06/04/2014 01:17 PM, Mark Brown wrote:
> >You're saying you're controlling it from userspace. This is a
> >particular detail of what you are doing in your system. You happen to
> >want to control the devices you are hanging of
On 06/04/2014 01:17 PM, Mark Brown wrote:
You're saying you're controlling it from userspace. This is a
particular detail of what you are doing in your system. You happen to
want to control the devices you are hanging off the system with
userspace drivers but that's just what you're doing right
On Wed, Jun 04, 2014 at 08:20:59AM +0200, Marcel Ziswiler wrote:
> On 06/03/2014 11:45 AM, Mark Brown wrote:
> >When you say "generic user space access" you are describing a specific
> >detail of how this device happens to be controlled with your software.
> No, not at all. In fact I did not even
On 06/03/2014 11:45 AM, Mark Brown wrote:
When you say "generic user space access" you are describing a specific
detail of how this device happens to be controlled with your software.
No, not at all. In fact I did not even specify neither the exact type of
device apart from it being a SPI devi
On Tue, Jun 03, 2014 at 08:02:37AM +0200, Marcel Ziswiler wrote:
> On 06/03/2014 12:16 AM, Mark Brown wrote:
> >Your DT is broken if it's got a "spidev" node in it, you should be
> >describing the hardware not the Linux implementation of the software.
> >It would be really nice if we had a good wa
On 06/03/2014 12:16 AM, Mark Brown wrote:
On Mon, Jun 02, 2014 at 06:28:37PM +0200, Marcel Ziswiler wrote:
On 06/02/2014 06:11 PM, Stephen Warren wrote:
+CONFIG_SPI_SPIDEV=y
Is this useful with DT? I thought that unlike I2C_CHARDEV, spidev needed
dummy devices to exist in DT for spidev to
On Mon, Jun 02, 2014 at 06:28:37PM +0200, Marcel Ziswiler wrote:
> On 06/02/2014 06:11 PM, Stephen Warren wrote:
> >>+CONFIG_SPI_SPIDEV=y
> >Is this useful with DT? I thought that unlike I2C_CHARDEV, spidev needed
> >dummy devices to exist in DT for spidev to work? If so, there's not much
> >poin
On 06/02/2014 06:11 PM, Stephen Warren wrote:
BTW: How about MTD_SPI_NOR,
That might only exist in linux-next.
PROC_DEVICETREE and CRYPTO_DEV_TEGRA_AES
which I haven't found any mentioning anywhere?
The TEGRA_AES driver has been removed, so the option should be removed
from defconfig too. I
On 06/01/2014 05:37 PM, Marcel Ziswiler wrote:
> The NVIDIA Tegra 3 based Apalis T30 module contains an Intel i210 resp.
> i211 gigabit Ethernet controller, an STMPE811 ADC/touch controller, I2C
> as well as SPI buses and PWM LEDs generically accessible from user
> space and an LM95245 temperature
The NVIDIA Tegra 3 based Apalis T30 module contains an Intel i210 resp.
i211 gigabit Ethernet controller, an STMPE811 ADC/touch controller, I2C
as well as SPI buses and PWM LEDs generically accessible from user
space and an LM95245 temperature sensor chip. The later five can also
be found on the Co
10 matches
Mail list logo