spi: bcm2835: driver for "auxiliar" spi1/spi2

spi: bcm2835: driver for "auxiliar" spi1/spi2

[Martin Sperl]

Quick question: for the auxiliar spi1 and spi2 of the BCM2835 chipset
should I create a separate driver - say spi-bcm2835aux.c - or incorporate
it into the exising spi-bcm2835.c driver.

Note that the register set for the auxiliar spi devices is totally different
so any code-overlap with the existing spi-bcm2835.c would be minimal.

Any preferences?
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: spi: bcm2835: driver for "auxiliar" spi1/spi2

[Noralf Trønnes]

Den 18.06.2015 11:45, skrev Martin Sperl:
> Quick question: for the auxiliar spi1 and spi2 of the BCM2835 chipset
> should I create a separate driver - say spi-bcm2835aux.c - or incorporate
> it into the exising spi-bcm2835.c driver.
>
> Note that the register set for the auxiliar spi devices is totally 
> different
> so any code-overlap with the existing spi-bcm2835.c would be minimal.
>

There is also an aux mini uart that shares interrupt with spi1/2.
The AUXIRQ register determines the interrupt source. How should this
sharing be done? This uart is really only useful on the Compute Module
since it's pins overlap the pl011 uart pins on the other boards.
This is how the mini uart is used/setup downstream:
https://github.com/raspberrypi/linux/pull/1008

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: spi: bcm2835: driver for "auxiliar" spi1/spi2

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

On Thu, Jun 18, 2015 at 11:45:34AM +0200, Martin Sperl wrote:
> Quick question: for the auxiliar spi1 and spi2 of the BCM2835 chipset
> should I create a separate driver - say spi-bcm2835aux.c - or incorporate
> it into the exising spi-bcm2835.c driver.

> Note that the register set for the auxiliar spi devices is totally different
> so any code-overlap with the existing spi-bcm2835.c would be minimal.

> Any preferences?

If there's no code overlap it should be a separate driver, your proposed
name sounds good.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: spi: bcm2835: driver for "auxiliar" spi1/spi2

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

On Thu, Jun 18, 2015 at 12:19:04PM +0200, Noralf Trønnes wrote:

> There is also an aux mini uart that shares interrupt with spi1/2.
> The AUXIRQ register determines the interrupt source. How should this
> sharing be done? This uart is really only useful on the Compute Module
> since it's pins overlap the pl011 uart pins on the other boards.
> This is how the mini uart is used/setup downstream:
> https://github.com/raspberrypi/linux/pull/1008

Linux supports shared interrupts perfectly fine, though it sounds like
this is actually a cascaded interrupt (the demux is another interrupt
controller) which we also support just fine.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: spi: bcm2835: driver for "auxiliar" spi1/spi2

[Martin Sperl]

On 2015-06-18 12:58, Mark Brown wrote:
> On Thu, Jun 18, 2015 at 12:19:04PM +0200, Noralf Trønnes wrote:
> Linux supports shared interrupts perfectly fine, though it sounds like
> this is actually a cascaded interrupt (the demux is another interrupt
> controller) which we also support just fine.

So we need to move the route of using a cascaded demux interrupt handler
for interrupt separation.

The other thing is: is there a "framework" to handle access to the
the "enable" register shared by all three devices (spi1/spi2/uart1),
or do we have to create a tiny module (aux-bcm2835 or similar) to
serialize access to this register?

For the moment I will start focusing on the implementation itself while
we can figure out the interrupt-controller configuration in DT in
parallel...

We also should look into upstreaming the configuration of uart1 - even
if only available on the compute board...

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: spi: bcm2835: driver for "auxiliar" spi1/spi2

[Jakub Kiciński]

On Thu, 18 Jun 2015 11:58:48 +0100, Mark Brown wrote:
> On Thu, Jun 18, 2015 at 12:19:04PM +0200, Noralf Trønnes wrote:
> 
> > There is also an aux mini uart that shares interrupt with spi1/2.
> > The AUXIRQ register determines the interrupt source. How should this
> > sharing be done? This uart is really only useful on the Compute Module
> > since it's pins overlap the pl011 uart pins on the other boards.
> > This is how the mini uart is used/setup downstream:
> > https://github.com/raspberrypi/linux/pull/1008
> 
> Linux supports shared interrupts perfectly fine, though it sounds like
> this is actually a cascaded interrupt (the demux is another interrupt
> controller) which we also support just fine.

Mark, could you give us a hint how to best go about this shared IRQ?
I failed to find any generic interrupt controller.  I imagine there
should be some fake irqchip we can instantiate from DT giving it a
irq line and a memory address and it should provide us with 32(bit)
demuxed irqs based on status of bits in specified memory location.
Does this sound reasonable?  Does such fake irqchip driver exist?
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: spi: bcm2835: driver for "auxiliar" spi1/spi2

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On Thu, Jun 25, 2015 at 07:42:19PM +0200, Jakub Kiciński wrote:
> On Thu, 18 Jun 2015 11:58:48 +0100, Mark Brown wrote:

> > Linux supports shared interrupts perfectly fine, though it sounds like
> > this is actually a cascaded interrupt (the demux is another interrupt
> > controller) which we also support just fine.

> Mark, could you give us a hint how to best go about this shared IRQ?
> I failed to find any generic interrupt controller.  I imagine there

drivers/irqchip...

> should be some fake irqchip we can instantiate from DT giving it a
> irq line and a memory address and it should provide us with 32(bit)
> demuxed irqs based on status of bits in specified memory location.
> Does this sound reasonable?  Does such fake irqchip driver exist?

IIRC there's some basic MMIO interrupt controller but I don't know off
the top of my head where, if not it shouldn't be too hard to implement.
It does sound sensible.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]