Re: How to define an I2C-to-SPI bridge device ?
Grant, Anton, [snip] Doing this in parallel will speed things up significantly. Yeah; Then I would handle it as a separate cs# and map it to enabling multiple CS lines at a time. sounds reasonable - will do it that way. BTW: would drivers/misc be a proper location ? Who's supposed to pick that driver up and on what list shall I post it for review ? You should cc spi-devel-general, and feel free to cc me. drivers/misc would probably be an okay place for it to live; but if it only appears on a single machine, then it may make more sense in arch/*/board-directory. What arch or SoC is this running on? ok - currently I'm preparing bring up of a MPC8377 based system. But we have this chips on multiple boards and also on generic PCIe grabber cards running on any desktop PC. Since we could use the driver directly after registering the various I2C masters I'd prefer to go with drivers/misc. After all it's a simple I2C slave device usable by anyone ... Will send an initial patch for review after basic verification with real hardware. Thanks for your help. Cheers, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[patch] qla2xxx: locking problem in qla2x00_init_rings()
IRQs are already disabled here so we don't need to disable them again.
But more importantly, the spin_lock_irqsave() overwrites flags and
that breaks things when we want to re-enable the IRQs when we call
spin_unlock_irqrestore(ha-hardware_lock, flags);
Signed-off-by: Dan Carpenter erro...@gmail.com
---
This seems like an important bug. I don't have this hardware but could
someone from QLogic test this out and maybe queue it up for 2.6.36?
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 9c383ba..9f4ba28 100644
--- a/drivers/scsi/qla2xxx/qla_init.c
+++ b/drivers/scsi/qla2xxx/qla_init.c
@@ -1787,14 +1787,14 @@ qla2x00_init_rings(scsi_qla_host_t *vha)
qla2x00_init_response_q_entries(rsp);
}
- spin_lock_irqsave(ha-vport_slock, flags);
+ spin_lock(ha-vport_slock);
/* Clear RSCN queue. */
list_for_each_entry(vp, ha-vp_list, list) {
vp-rscn_in_ptr = 0;
vp-rscn_out_ptr = 0;
}
- spin_unlock_irqrestore(ha-vport_slock, flags);
+ spin_unlock(ha-vport_slock);
ha-isp_ops-config_rings(vha);
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: ARM machine specific DT probing
On Thu, Sep 09, 2010 at 09:07:59AM +0800, Jeremy Kerr wrote: Hi Nicolas, What Jeremy did is to add a probe_dt method in the mdesc structure, and then the core is calling them in sequence until one of them returns success. now, the compatible property is explained here: http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property From my understanding, this could allow for a kernel that doesn't yet support the specifics of a particular board to still be able to work using basic common support. But for this to work, wouldn't it be necessary for the core code to try to find the best match itself rather than letting each machine's probe_dt decide on their own? At present, the probe_dt function is a binary match/no-match indicator, so the core code just selects the first match it finds. This means that we'll need one mdesc per machine; I'm intending to keep it simple to start with. My intention in the longer-term is to allow probe_dt to indicate less-specific matches (eg, match on the SoC family), and change the core code to not break out of the loop on the first match, but continue to look for a better match. This way, we can have one mdesc to support a SoC family, but still allow that to be overridden if there's a more specific (eg, single machine) mdesc compiled in. Hrm. The trouble with this idea is that it needs some measure of specificness of match, and I'm not sure you can come up with an encoding of that which is better than just order in the match table. i.e. if you construct your match table such that more specific matches precede less specific ones, you don't need to keep scanning the table and then work out which is the best match. The reason I do this in the machine-specific code (rather than the core code checking the compatible property) is to allow the probe_dt function to check arbitrary data in the device tree. Perhaps we have two variations of a machine - both with the same compatible property, but distinguishable in some other way, and we need a separate mdesc for whatever reason. Exactly: you do need to cover this unfortunate, but inevitable case. The trouble is I don't see how you can have a specificness measure without starting to make assumptions about what the probe function is checking. Getting the probe table ordered by specificness will be fiddly in some cases, but not, I suspect more so than the hard cases would be anyway with a specificness measure. And I think it's as versatile an encoding of specificness as you're likely to get. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: How to define an I2C-to-SPI bridge device ?
On Sun, Sep 12, 2010 at 05:10:35PM +0200, André Schwarz wrote: BTW: would drivers/misc be a proper location ? Who's supposed to pick that driver up and on what list shall I post it for review ? You should cc spi-devel-general, and feel free to cc me. drivers/misc would probably be an okay place for it to live; but if it only appears on a single machine, then it may make more sense in arch/*/board-directory. What arch or SoC is this running on? ok - currently I'm preparing bring up of a MPC8377 based system. But we have this chips on multiple boards and also on generic PCIe grabber cards running on any desktop PC. Since we could use the driver directly after registering the various I2C masters I'd prefer to go with drivers/misc. After all it's a simple I2C slave device usable by anyone ... If it is a video capture device, then wouldn't drivers/video or drivers/media make sense? Search for MEDIA INPUT in the MAINTAINERS file. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[git pull] spi and OF fixes
Hi Linus, Here's a double handfull of SPI and OF (ll_temac, gpiolib, 52xx_uart). Should be nothing eyebrow raising here. g. The following changes since commit be6200aac985e0a3db56ec636763a32f3e32e7f1: Linus Torvalds (1): Merge branch 'kvm-updates/2.6.36' of git://git.kernel.org/pub/scm/virt/kvm/kvm are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 next-spi Anton Vorontsov (1): gpiolib: Add 'struct gpio_chip' forward declaration for !GPIOLIB case David Lamparter (1): spi: free children in spi_unregister_master, not siblings Feng Tang (1): spi/dw_spi: clean the cs_control code Jassi Brar (2): spi/s3c64xx: Fix compilation warning spi/s3c64xx: Fix incorrect reuse of 'val' local variable. Julia Lawall (1): powerpc/5200: mpc52xx_uart.c: Add of_node_put to avoid memory leak Linus Walleij (2): spi/pl022: fix APB pclk power regression on U300 spi/pl022: move probe call to subsys_initcall() Mark Brown (5): spi/spi_s3c64xx: Make probe more robust against missing board config spi/spi_s3c64xx: Staticise non-exported functions spi/spi_s3c64xx: Move to subsys_initcall() spi/spi_s3c64xx: Increase dead reckoning time in wait_for_xfer() spi/spi_s3c64xx: Warn if PIO transfers time out Michal Simek (1): of: Fix missing includes - ll_temac Yong Wang (1): spi/dw_spi: Allow interrupt sharing drivers/net/ll_temac_main.c |1 + drivers/net/ll_temac_mdio.c |1 + drivers/serial/mpc52xx_uart.c |1 + drivers/spi/amba-pl022.c | 16 +--- drivers/spi/dw_spi.c | 24 +++- drivers/spi/spi.c |9 +++-- drivers/spi/spi_s3c64xx.c | 37 + include/linux/gpio.h |1 + include/linux/spi/dw_spi.h|2 ++ 9 files changed, 54 insertions(+), 38 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: ARM machine specific DT probing
Hi David, Hrm. The trouble with this idea is that it needs some measure of specificness of match, I was originally thinking an enum, something to indicate that the match is for a machine or SoC or SoC-family, but that may not be flexible enough. Essentially, all we really need to indicate is that this match is more specific than that other match, which the match-table-ordering would work fine for. With the present infrastructure, we'd need to enforce this by controlling the link order. However, I don't have any good ideas about how we could do this neatly. Maybe we could get make to work out the dependencies (this mdesc needs to go before that one) for us :D Cheers, Jeremy ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
