Skip to content

spi: Migrate bcm2708 to generic queueing #978

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

spi: Migrate bcm2708 to generic queueing #978

wants to merge 1 commit into from

Conversation

hkallweit
Copy link
Contributor

The bcm2708 spi driver still uses an own queueing what is considered
deprecated. The generic spi code therefore prints a warning
"master is unqueued, this is deprecated"
This patch migrates the driver to using the generic queueing.

Signed-off-by: Heiner Kallweit [email protected]

The bcm2708 spi driver still uses an own queueing what is considered
deprecated. The generic spi code therefore prints a warning
"master is unqueued, this is deprecated"
This patch migrates the driver to using the generic queueing.

Signed-off-by: Heiner Kallweit <[email protected]>
@popcornmix
Copy link
Collaborator

Ping @msperl

@msperl
Copy link
Contributor

msperl commented May 24, 2015

I recommend using spi-bcm2835 instead - it comes with the foundation kernel already and there exists an overlay to use that driver instead of the spi-bcm2708.

On top of that spi-bcm2835 contains a lot of other optimizations and features that are not found in spi-bcm2708 (less interrupts, 3 wire mode, more distinct clock frequencies,...)

There is a patch to that driver that already uses DMA for longer spi-transfers (3ecd37e, 7e52be0 and 29ad1a7) - which has been merged into spi/for-next and that means that as soon as the merge window for 4.2 opens (and it has been accepted by Linux) we can create a request to merge that into the foundation kernels as well.

Finally the patch only implements the transfer_one_message interface and not the transfer_one interface which is the new interface that people should be use to code drivers (and which will also get depreciated eventually).

@hkallweit
Copy link
Contributor Author

OK. Meanwhile I switched to bcm-2835 by activating the overlay.
Not sure why it's not the default. Thanks for the additional insight.

@msperl
Copy link
Contributor

msperl commented May 24, 2015

If you look at the original ticket for the overlay then the idea was for a gradual move.
First just enable it as an overlay and if there are no issues then make it the default with the fallback to the old.

The question is when we want to make this change...
@popcornmix when should we change it?

@popcornmix
Copy link
Collaborator

If you say that switching to spi-bcm2835 is unlikely to break things for existing spi users and is a better driver, then I've no objections.
@pelwell okay with you?

@msperl
Copy link
Contributor

msperl commented May 25, 2015

For reference see these for the original discussion:
#864
#866

In principle we have spi-bcm2708 as a fallback for issues not seen.

I am only using spi-bcm2835 now with 4 different devices (2 mcp2515, enc28j60, mmc_spi, fbtft) and all are active at the same time without any issues...

@pelwell
Copy link
Contributor

pelwell commented May 25, 2015

I'm not really an SPI user so I'm going to have to take it on trust that the new driver is good, but providing we have an overlay to revert to the old driver should people have problems then I think we should make the switch.

@msperl
Copy link
Contributor

msperl commented May 25, 2015

Shall I create an overlay for spi-bcm2708 and change the default in the device-tree to spi-bcm2835?
As there are people using the spi-bcm2835-overlay I guess we will need to keep that one...

@msperl
Copy link
Contributor

msperl commented May 27, 2015

created #987 to activate spi-bcm2835 by default.
I have only created a merge request for 4.0.y as I assume this is the most likley candidate for release...

@pelwell
Copy link
Contributor

pelwell commented Jun 8, 2015

@hkallweit Now that #987 has been merged for a while and in a few firmware updates, are you happy to close this?

@hkallweit
Copy link
Contributor Author

Yes, can be closed.

@hkallweit hkallweit closed this Jun 13, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants