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
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
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
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 off the
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
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
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
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 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
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 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 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 way of
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
>
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.
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
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
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.
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
point adding
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
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
20 matches
Mail list logo
