On 1 July 2016 at 20:56, Michal Suchanek wrote:
> On 1 July 2016 at 18:22, Mark Brown wrote:
>> On Fri, Jul 01, 2016 at 05:37:53PM +0200, Michal Suchanek wrote:
>>
>>> Can you, please, specify what problems this patch creates for other users
>>> and maintainability?
>>
>> To repeat yet again a ma
On 1 July 2016 at 18:22, Mark Brown wrote:
> On Fri, Jul 01, 2016 at 05:37:53PM +0200, Michal Suchanek wrote:
>
>> Can you, please, specify what problems this patch creates for other users
>> and maintainability?
>
> To repeat yet again a major design goal for DT is to describe the
> hardware rath
On Fri, Jul 01, 2016 at 05:37:53PM +0200, Michal Suchanek wrote:
> Can you, please, specify what problems this patch creates for other users
> and maintainability?
To repeat yet again a major design goal for DT is to describe the
hardware rather than implementation details of the software you pla
On 1 July 2016 at 17:00, Mark Brown wrote:
> On Fri, Jul 01, 2016 at 10:58:34AM +0200, Michal Suchanek wrote:
>> On 1 July 2016 at 10:25, Mark Brown wrote:
>
>> > It's been repeatedly suggested to you that the tooling for this stuff
>> > could use some work. Please go and put some effort into th
On Fri, Jul 01, 2016 at 10:58:34AM +0200, Michal Suchanek wrote:
> On 1 July 2016 at 10:25, Mark Brown wrote:
> > It's been repeatedly suggested to you that the tooling for this stuff
> > could use some work. Please go and put some effort into that rather
> > than continuing this thread which is
On 1 July 2016 at 11:36, Mark Brown wrote:
> On Thu, Jun 30, 2016 at 10:03:57AM +0100, Dan O'Donovan wrote:
>
> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80 columns. Doing this makes your messages much
> easier to read and reply to.
Sorry a
On Thu, Jun 30, 2016 at 10:03:57AM +0100, Dan O'Donovan wrote:
Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns. Doing this makes your messages much
easier to read and reply to.
> In case its relevant, I'd like add to this point by emphas
On 1 July 2016 at 10:25, Mark Brown wrote:
> On Thu, Jun 30, 2016 at 09:47:32AM +0200, Michal Suchanek wrote:
>
>> So to write such tutorial you have to give some steps to follow which
>> are reasonably likely to succeed on wide variety of boards and require
>> smallest possible changes to the boa
On Thu, Jun 30, 2016 at 09:47:32AM +0200, Michal Suchanek wrote:
> So to write such tutorial you have to give some steps to follow which
> are reasonably likely to succeed on wide variety of boards and require
> smallest possible changes to the board software.
> For mainline this would currently
On 06/30/2016 08:47 AM, Michal Suchanek wrote:
> On 29 June 2016 at 20:02, Mark Brown wrote:
>> On Wed, Jun 29, 2016 at 05:32:48AM +0200, Michal Suchanek wrote:
>>
>>> The other is to get a generic expansion board and jumper wires. Of
>>> course, you will not use all pins of your expansion connect
On 29 June 2016 at 20:02, Mark Brown wrote:
> On Wed, Jun 29, 2016 at 05:32:48AM +0200, Michal Suchanek wrote:
>
>> The other is to get a generic expansion board and jumper wires. Of
>> course, you will not use all pins of your expansion connector this
>> way. On the other hand using the remaining
On Wed, Jun 29, 2016 at 05:32:48AM +0200, Michal Suchanek wrote:
> The other is to get a generic expansion board and jumper wires. Of
> course, you will not use all pins of your expansion connector this
> way. On the other hand using the remaining pins becomes challenging
> because of the jumper w
On 28 June 2016 at 22:57, Mark Brown wrote:
> On Tue, Jun 28, 2016 at 10:02:59PM +0200, Michal Suchanek wrote:
>
>> Of course I could add "my-shiny-new-board" compatible to the device
>> tree and spidev. Then when I build my-shiny-new-board2 and it happens
>> to also use userspace driver I will no
On Tue, Jun 28, 2016 at 10:02:59PM +0200, Michal Suchanek wrote:
> Of course I could add "my-shiny-new-board" compatible to the device
> tree and spidev. Then when I build my-shiny-new-board2 and it happens
> to also use userspace driver I will not bother to update the
> compatible nor will anyone
On 28 June 2016 at 20:38, Mark Brown wrote:
> On Tue, Jun 28, 2016 at 06:24:58PM +0200, Michal Suchanek wrote:
>
>> No, no, no!
>
>> This is NOT about loading an overlay. This is about talking on the bus
>> without loading an overlay.
>
> This is the solution you want to adopt because you've decid
On Tue, Jun 28, 2016 at 06:24:58PM +0200, Michal Suchanek wrote:
> No, no, no!
> This is NOT about loading an overlay. This is about talking on the bus
> without loading an overlay.
This is the solution you want to adopt because you've decided that it's
what you want. You've said this quite a n
On 28 June 2016 at 17:51, Mark Brown wrote:
> On Tue, Jun 28, 2016 at 02:40:41PM +0200, Michal Suchanek wrote:
>
>> There is no hardware other than pin header. You are preparing a
>> factory image for a devboard with a pin header that can be used for
>> connecting SPI devices. Some devices have fi
On Tue, Jun 28, 2016 at 02:40:41PM +0200, Michal Suchanek wrote:
> There is no hardware other than pin header. You are preparing a
> factory image for a devboard with a pin header that can be used for
> connecting SPI devices. Some devices have fine kernel drivers and for
> these you prepare fine
On 27 June 2016 at 22:32, Mark Brown wrote:
> On Mon, Jun 27, 2016 at 09:40:38PM +0200, Michal Suchanek wrote:
>
>> No. It's for buses that have some inherent identification. It's not for
>
>> 1) generate random compatible and stick it in device tree
>
> Don't generate a random compatible, generat
On Mon, Jun 27, 2016 at 09:40:38PM +0200, Michal Suchanek wrote:
> On 27 June 2016 at 21:09, Greg Kroah-Hartman
> wrote:
> > On Mon, Jun 27, 2016 at 09:02:32PM +0200, Michal Suchanek wrote:
> >> The spi bus has no autodetection whatsoever. The 'detection' of the
> >> device that's suposed to be o
On Mon, Jun 27, 2016 at 09:40:38PM +0200, Michal Suchanek wrote:
> No. It's for buses that have some inherent identification. It's not for
> 1) generate random compatible and stick it in device tree
Don't generate a random compatible, generate one that accurately
describes your hardware.
> also
On 27 June 2016 at 21:09, Greg Kroah-Hartman wrote:
> On Mon, Jun 27, 2016 at 09:02:32PM +0200, Michal Suchanek wrote:
>> The spi bus has no autodetection whatsoever. The 'detection' of the
>> device that's suposed to be on the other side completely relies on user
>> supplied information coming fr
On Mon, Jun 27, 2016 at 09:02:32PM +0200, Michal Suchanek wrote:
> The spi bus has no autodetection whatsoever. The 'detection' of the
> device that's suposed to be on the other side completely relies on user
> supplied information coming from devicetree on many platforms. It is
> completely reason
The spi bus has no autodetection whatsoever. The 'detection' of the
device that's suposed to be on the other side completely relies on user
supplied information coming from devicetree on many platforms. It is
completely reasonable then to allow the user to supply the information
at runtime by doing
24 matches
Mail list logo
