[linux-sunxi] Re: [PATCH v7 2/3] [media] rc: add sunxi-ir driver
Hi,
On 05/19/2014 10:26 PM, David Härdeman wrote:
On Thu, May 15, 2014 at 03:56:41AM +0600, Alexander Bersenev wrote:
This patch adds driver for sunxi IR controller.
It is based on Alexsey Shestacov's work based on the original driver
supplied by Allwinner.
...
+static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
+{
+unsigned long status;
+unsigned char dt;
+unsigned int cnt, rc;
+struct sunxi_ir *ir = dev_id;
+DEFINE_IR_RAW_EVENT(rawir);
+
+spin_lock(ir-ir_lock);
+
+status = readl(ir-base + SUNXI_IR_RXSTA_REG);
+
+/* clean all pending statuses */
+writel(status | REG_RXSTA_CLEARALL, ir-base + SUNXI_IR_RXSTA_REG);
+
+if (status REG_RXINT_RAI_EN) {
+/* How many messages in fifo */
+rc = (status REG_RXSTA_RAC__SHIFT) REG_RXSTA_RAC__MASK;
+/* Sanity check */
+rc = rc SUNXI_IR_FIFO_SIZE ? SUNXI_IR_FIFO_SIZE : rc;
+/* If we have data */
+for (cnt = 0; cnt rc; cnt++) {
+/* for each bit in fifo */
+dt = readb(ir-base + SUNXI_IR_RXFIFO_REG);
+rawir.pulse = (dt 0x80) != 0;
+rawir.duration = (dt 0x7f) * SUNXI_IR_SAMPLE;
Can the hardware actually return a zero duration or should that be dt
0x7f + 1?
(Not familiar with this particular hardware but I know I've seen that
behaviour before).
Good point, I've just checked and the datasheet says the reported pulse
duration can be up to 128, so that would make the range 1-128 not 0-127,
so I believe we indeed need to add 1 to this.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [RFC PATCH 1/3] mfd: AXP22x: add support for APX221 PMIC
Hi, On 05/19/2014 07:45 PM, Boris BREZILLON wrote: Hello Lee, On 19/05/2014 19:28, Lee Jones wrote: This patch introduces preliminary support for the X-Powers AXP221 PMIC. The AXP221 is typically used on boards using Allwinner's A31 SoC. At the moment, this driver only exposes regulator devices, but other subdevices. Signed-off-by: Boris BREZILLON boris.brezil...@free-electrons.com --- drivers/mfd/Kconfig| 12 +++ drivers/mfd/Makefile | 1 + drivers/mfd/axp22x.c | 237 + include/linux/mfd/axp22x.h | 149 4 files changed, 399 insertions(+) create mode 100644 drivers/mfd/axp22x.c create mode 100644 include/linux/mfd/axp22x.h Not a chance. Fa, too much common code with axp20x.c - please merge into one file. This was one of the questions I asked in my cover letter (could you take a look at it and tell me what's your prefered solution ?) ;-). I first tried to reuse the axp20x drivers, but ended up copying almost all definitions, hence I decided to first do a different driver and ask for advices. I've just taken a good look at this (I'm planning on doing an axp152 driver myself), and it seems that using a single mfd driver for the 20x and 221 should be quite feasible: - axp20x.h would get some new register defines for registers which are different (or unique) to the 221 prefixed with aXP221 - An axp20x_writeable_ranges would need to be extended with a third range going from AXP221_BAT_CAP1 (0xe0) to AXP221_BAT_LOW_THRESH (0xe6) - axp20x_writeable_table would get .n_yes_ranges set to 2, and a new apx22x_writeable_table would be introduced with n_yes_ranges set to 3. - add a new axp221_supplies array - add a new axp221_cells array - and finally use the proper structs in axp20x_i2c_probe depending on the type Note that this means sharing ie the interrupt table, which is ok since they are the same, except that the 221 has a couple of interrupts missing, but the ones which are shared are all at the same place. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH] Add Full Duplex support to SPI (v2)
excelent news this patch is available since i am trying to connect rf24l01 sensor using spi, now i have a simple question, my as an absolute newbiehoy do i apply this patch? i am using cubieez on cb2. your help will be a bless. thanks -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Help with dtsi
Hi,
I'm attempting to connect a Microchip enc28j60 SPI Ethernet controller to an
Olimex A13 board, but I'm having trouble figuring out how to modify the dtsi
file.
This is the wiring config I'm using:
PC0 - SPI0_MOSI
PC1 - SPI0_MISO
PC2 - SPI0_CLK
PC3 - SPI0_CS0
PB3 - EINT17
The parts I'm having trouble with is figuring out how to setup the external
interrupt, and what I do to map the SPI0 device to the correct pins. I assume
it's similar to the nodes for other devices in the pinctrl section?
Sorry for the noobie questions, I normally do this kind of stuff on a Cortex M3.
Here is what I have so far:
spi0: spi@01c05000 {
compatible = allwinner,sun4i-a10-spi;
reg = 0x01c05000 0x1000;
interrupts = 10;
clocks = ahb_gates 20, spi0_clk;
clock-names = ahb, mod;
status = disabled;
#address-cells = 1;
#size-cells = 0;
ethernet: enc28j60@0 {
compatible = microchip,enc28j60;
spi-max-frequency = 2000 ;
reg = 0 ;
interrupts = ?? ;
};
};
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH v7] DMA: sun6i: Add driver for the Allwinner A31 DMA controller
Hi Maxime, El 24/04/14 11:22, Maxime Ripard escribió: The Allwinner A31 has a 16 channels DMA controller that it shares with the newer A23. Although sharing some similarities with the DMA controller of the older Allwinner SoCs, it's significantly different, I don't expect it to be possible to share the driver for these two. The A31 Controller is able to memory-to-memory or memory-to-device transfers on the 16 channels in parallel. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com Acked-by: Arnd Bergmann a...@arndb.de --- (snip) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 5c5863842de9..360a10c71388 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -361,6 +361,14 @@ config FSL_EDMA multiplexing capability for DMA request sources(slot). This module can be found on Freescale Vybrid and LS-1 SoCs. +config DMA_SUN6I + tristate Allwinner A31 SoCs DMA support + depends on ARCH_SUNXI + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS I think you also need to select DMA_OF here as you are using of_dma_controller_register + help + Support for the DMA engine for Allwinner A31 SoCs. + config DMA_ENGINE bool Cheers, Emilio -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 5/9] mtd: nand: add sunxi NAND flash controller support
On Tue, May 20, 2014 at 11:49:42AM -0700, Brian Norris wrote:
On Fri, May 09, 2014 at 06:47:22PM +0200, Boris BREZILLON wrote:
On 09/05/2014 18:03, Ezequiel Garcia wrote:
On 12 Mar 07:07 PM, Boris BREZILLON wrote:
--- /dev/null
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -0,0 +1,1276 @@
...
+static int sunxi_nand_ecc_init(struct mtd_info *mtd, struct
nand_ecc_ctrl *ecc,
+ struct device_node *np)
+{
+struct nand_chip *nand = mtd-priv;
+int ecc_step_size, ecc_strength;
+int ret;
+
+ecc_step_size = of_get_nand_ecc_step_size(np);
+ecc_strength = of_get_nand_ecc_strength(np);
+if (ecc_step_size 0 ecc_strength 0) {
+ecc-size = ecc_step_size;
+ecc-strength = ecc_strength;
+} else {
+ecc-size = nand-ecc_step_ds;
+ecc-strength = nand-ecc_strength_ds;
+}
+
Shouldn't you check the devicetree value is not weaker than the
ONFI-obtained?
I can definitely do that.
You can do that here, but take a look at the discussion Ezequiel and I
had about this:
http://thread.gmane.org/gmane.linux.drivers.devicetree/67462
We probably don't want to be doing anything drastic like overriding the
device tree configuration. Instead, we might want to stick a warning
into the core nand_base code that does the proper comparison of the
'*_ds' values with the actual values chosen in
chip-ecc-{size,strength}. The comparison is kind of subtle, actually,
so it'd be good to do it exactly once for everyone.
I forgot, Ezequiel already submitted this. I'll look at it soon:
http://patchwork.ozlabs.org/patch/348901/
Brian
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 4/9] of: mtd: add documentation for the ONFI NAND timing mode property
Hi Brian,
On 20/05/2014 20:25, Brian Norris wrote:
Hi Boris,
On Wed, Mar 12, 2014 at 07:07:39PM +0100, Boris BREZILLON wrote:
Add documentation for the ONFI NAND timing mode property.
Signed-off-by: Boris BREZILLON b.brezillon@gmail.com
---
Documentation/devicetree/bindings/mtd/nand.txt |8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/nand.txt
b/Documentation/devicetree/bindings/mtd/nand.txt
index b53f92e..2046027 100644
--- a/Documentation/devicetree/bindings/mtd/nand.txt
+++ b/Documentation/devicetree/bindings/mtd/nand.txt
@@ -19,3 +19,11 @@ errors per {size} bytes.
The interpretation of these parameters is implementation-defined, so not all
implementations must support all possible combinations. However,
implementations
are encouraged to further specify the value(s) they support.
+
+- onfi,nand-timing-mode: an integer encoding the supported ONFI timing
modes of
+ the NAND chip. Each supported mode is represented as a bit position (i.e.
:
+ mode 0 and 1 = (1 0) | (1 1) = 0x3).
+ This is only used when the chip does not support the ONFI standard.
+ The last bit set represent the closest mode fulfilling the NAND chip
timings.
+ For a full description of the different timing modes see this document:
+ www.onfi.org/~/media/ONFI/specs/onfi_3_1_spec.pdf
I'm not 100% convinced this property should go in the device tree. With
most other flash properties (device size, page size, and even minimum
ECC requirements), we try to auto-detect these parameters to some
extent. ONFI makes it easy for some class of chips, but for others, we
typically rely on an in-kernel device ID table or ID decoding heuristic
-- we don't require a DT description of every property of the flash. So
what makes this property different?
AFAICT nothing, but the same goes for the ECC requirements, and we've
recently added DT bindings to define these requirements.
I'm not telling we should drop these ECC requirements bindings (actually
I'm using them :-)), but what's different with the timings requirements ?
Moreover, we will end up with a lot of new entries in the device ID
table if we decide to put these informations in this table.
I realize that we may not include device ID entries for every flash that
you need in the ID table (although we still are able to detect the
important properties accurately, like page and block size). But would it
suffice to default these flash to a lowest common timing mode, like mode
0?
IMHO this is not a good solution: you'll end up with lower perfomances
on most of the supported NAND chips and I'm not sure this is what we want.
If no other option works well, then I am still open to describing the
supported timing modes in the DT.
BTW, this bitfield property looks kinda strange to me. Do non-ONFI flash
typically support multiple timing modes? And if so, how are we supposed
to *change* modes? AFAIK, ONFI provides the only standard for
configuring the flash's timing mode. So maybe you're really only wanting
a default timing mode property that is a single integer, not a
bitfield.
Indeed, I based it on the ONFI NAND timings mode model, but AFAIK (tell
me if I'm wrong), it should work because most of the timings are min
requirements.
This means, even if you provide slower signals transitions, the NAND
will work as expected.
But I can modify the bindings to just encode the maximum supported
timing mode.
Thanks for your feedback.
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 5/9] mtd: nand: add sunxi NAND flash controller support
On 20/05/2014 21:21, Brian Norris wrote:
On Tue, May 20, 2014 at 11:49:42AM -0700, Brian Norris wrote:
On Fri, May 09, 2014 at 06:47:22PM +0200, Boris BREZILLON wrote:
On 09/05/2014 18:03, Ezequiel Garcia wrote:
On 12 Mar 07:07 PM, Boris BREZILLON wrote:
--- /dev/null
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -0,0 +1,1276 @@
...
+static int sunxi_nand_ecc_init(struct mtd_info *mtd, struct
nand_ecc_ctrl *ecc,
+struct device_node *np)
+{
+ struct nand_chip *nand = mtd-priv;
+ int ecc_step_size, ecc_strength;
+ int ret;
+
+ ecc_step_size = of_get_nand_ecc_step_size(np);
+ ecc_strength = of_get_nand_ecc_strength(np);
+ if (ecc_step_size 0 ecc_strength 0) {
+ ecc-size = ecc_step_size;
+ ecc-strength = ecc_strength;
+ } else {
+ ecc-size = nand-ecc_step_ds;
+ ecc-strength = nand-ecc_strength_ds;
+ }
+
Shouldn't you check the devicetree value is not weaker than the
ONFI-obtained?
I can definitely do that.
You can do that here, but take a look at the discussion Ezequiel and I
had about this:
http://thread.gmane.org/gmane.linux.drivers.devicetree/67462
We probably don't want to be doing anything drastic like overriding the
device tree configuration. Instead, we might want to stick a warning
into the core nand_base code that does the proper comparison of the
'*_ds' values with the actual values chosen in
chip-ecc-{size,strength}. The comparison is kind of subtle, actually,
so it'd be good to do it exactly once for everyone.
Fair enough, I'll follow your suggestions on this specific point ;)
I forgot, Ezequiel already submitted this. I'll look at it soon:
http://patchwork.ozlabs.org/patch/348901/
Thanks for pointing this out.
Brian
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 4/9] of: mtd: add documentation for the ONFI NAND timing mode property
On Tue, May 20, 2014 at 09:30:33PM +0200, Boris BREZILLON wrote: AFAICT nothing, but the same goes for the ECC requirements, and we've recently added DT bindings to define these requirements. I'm not telling we should drop these ECC requirements bindings (actually I'm using them :-)), but what's different with the timings requirements ? ECC requirements are almost always something that has to be matched to the bootloader (since the bootloader typicaly reads the NAND to boot), so it is sensible to put that in the DT The timings are a property of the chip, and if they can be detected they should be. IMHO, the main purpose of a DT property would be to lower the speed if, for some reason, the board cannot support the device's full speed. Indeed, I based it on the ONFI NAND timings mode model, but AFAIK (tell me if I'm wrong), it should work because most of the timings are min requirements. This means, even if you provide slower signals transitions, the NAND will work as expected. IIRC for ONFI a device must always work in the mode 0 timings, without requiring a command? Jason -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v3 4/9] of: mtd: add documentation for the ONFI NAND timing mode property
On Tue, May 20, 2014 at 09:30:33PM +0200, Boris BREZILLON wrote:
Hi Brian,
On 20/05/2014 20:25, Brian Norris wrote:
Hi Boris,
On Wed, Mar 12, 2014 at 07:07:39PM +0100, Boris BREZILLON wrote:
Add documentation for the ONFI NAND timing mode property.
Signed-off-by: Boris BREZILLON b.brezillon@gmail.com
---
Documentation/devicetree/bindings/mtd/nand.txt |8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/nand.txt
b/Documentation/devicetree/bindings/mtd/nand.txt
index b53f92e..2046027 100644
--- a/Documentation/devicetree/bindings/mtd/nand.txt
+++ b/Documentation/devicetree/bindings/mtd/nand.txt
@@ -19,3 +19,11 @@ errors per {size} bytes.
The interpretation of these parameters is implementation-defined, so not
all
implementations must support all possible combinations. However,
implementations
are encouraged to further specify the value(s) they support.
+
+- onfi,nand-timing-mode: an integer encoding the supported ONFI timing
modes of
+ the NAND chip. Each supported mode is represented as a bit position
(i.e. :
+ mode 0 and 1 = (1 0) | (1 1) = 0x3).
+ This is only used when the chip does not support the ONFI standard.
+ The last bit set represent the closest mode fulfilling the NAND chip
timings.
+ For a full description of the different timing modes see this document:
+ www.onfi.org/~/media/ONFI/specs/onfi_3_1_spec.pdf
I'm not 100% convinced this property should go in the device tree. With
most other flash properties (device size, page size, and even minimum
ECC requirements), we try to auto-detect these parameters to some
extent. ONFI makes it easy for some class of chips, but for others, we
typically rely on an in-kernel device ID table or ID decoding heuristic
-- we don't require a DT description of every property of the flash. So
what makes this property different?
AFAICT nothing, but the same goes for the ECC requirements, and we've
recently added DT bindings to define these requirements.
I'm not telling we should drop these ECC requirements bindings (actually
I'm using them :-)), but what's different with the timings requirements ?
ECC selection is not quite as scientific; with ECC, there are external
factors that influence the ECC mode that you should use, since any data
read/written from Linux has to be compatible with any data read/written
with another entity (e.g., bootloader). Note that the ECC bindings do
not represent a property of the flash chip itself (i.e., they don't hold
the minimum required ECC strength), but of the entire flash system
(i.e., what ECC must I use to play nicely with the rest of the world).
With timing modes, this is purely a property of the flash chip, and we
do not have to synchronize it with the bootloader. We don't exactly care
if a bootloader and Linux use slightly different timing modes.
Moreover, we will end up with a lot of new entries in the device ID
table if we decide to put these informations in this table.
Yes, that could be a problem.
What sort of non-ONFI flash chips do you have that need this property?
And what timing mode(s) do they use? Is there, for instance, a pattern
such that all Hynix MLC of a certain generation use a particular timing
mode?
I realize that we may not include device ID entries for every flash that
you need in the ID table (although we still are able to detect the
important properties accurately, like page and block size). But would it
suffice to default these flash to a lowest common timing mode, like mode
0?
IMHO this is not a good solution: you'll end up with lower perfomances
on most of the supported NAND chips and I'm not sure this is what we want.
No, we wouldn't want to always use mode 0. But it's possible we can get
good enough heuristics for most flash, if we can integrate timing modes
into the current extended ID decoding. Not sure.
I'm also concerned here that this kind of binding will be difficult to
use properly. A user/developer/board-designer would have to read the
datasheet and compare all its values to the ONFI spec to find the
closest match, and they would have to do this for each new flash they
use. If we can help them by autodetecting this, that would be great.
If no other option works well, then I am still open to describing the
supported timing modes in the DT.
BTW, this bitfield property looks kinda strange to me. Do non-ONFI flash
typically support multiple timing modes? And if so, how are we supposed
to *change* modes? AFAIK, ONFI provides the only standard for
configuring the flash's timing mode. So maybe you're really only wanting
a default timing mode property that is a single integer, not a
bitfield.
Indeed, I based it on the ONFI NAND timings mode model, but AFAIK (tell
me if I'm wrong), it should work because most of the timings are min
requirements.
This means, even if you provide slower signals
[linux-sunxi] Re: [PATCH v3 4/9] of: mtd: add documentation for the ONFI NAND timing mode property
On 20/05/2014 21:52, Brian Norris wrote:
On Tue, May 20, 2014 at 09:30:33PM +0200, Boris BREZILLON wrote:
Hi Brian,
On 20/05/2014 20:25, Brian Norris wrote:
Hi Boris,
On Wed, Mar 12, 2014 at 07:07:39PM +0100, Boris BREZILLON wrote:
Add documentation for the ONFI NAND timing mode property.
Signed-off-by: Boris BREZILLON b.brezillon@gmail.com
---
Documentation/devicetree/bindings/mtd/nand.txt |8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/nand.txt
b/Documentation/devicetree/bindings/mtd/nand.txt
index b53f92e..2046027 100644
--- a/Documentation/devicetree/bindings/mtd/nand.txt
+++ b/Documentation/devicetree/bindings/mtd/nand.txt
@@ -19,3 +19,11 @@ errors per {size} bytes.
The interpretation of these parameters is implementation-defined, so not
all
implementations must support all possible combinations. However,
implementations
are encouraged to further specify the value(s) they support.
+
+- onfi,nand-timing-mode: an integer encoding the supported ONFI timing
modes of
+ the NAND chip. Each supported mode is represented as a bit position
(i.e. :
+ mode 0 and 1 = (1 0) | (1 1) = 0x3).
+ This is only used when the chip does not support the ONFI standard.
+ The last bit set represent the closest mode fulfilling the NAND chip
timings.
+ For a full description of the different timing modes see this document:
+ www.onfi.org/~/media/ONFI/specs/onfi_3_1_spec.pdf
I'm not 100% convinced this property should go in the device tree. With
most other flash properties (device size, page size, and even minimum
ECC requirements), we try to auto-detect these parameters to some
extent. ONFI makes it easy for some class of chips, but for others, we
typically rely on an in-kernel device ID table or ID decoding heuristic
-- we don't require a DT description of every property of the flash. So
what makes this property different?
AFAICT nothing, but the same goes for the ECC requirements, and we've
recently added DT bindings to define these requirements.
I'm not telling we should drop these ECC requirements bindings (actually
I'm using them :-)), but what's different with the timings requirements ?
ECC selection is not quite as scientific; with ECC, there are external
factors that influence the ECC mode that you should use, since any data
read/written from Linux has to be compatible with any data read/written
with another entity (e.g., bootloader). Note that the ECC bindings do
not represent a property of the flash chip itself (i.e., they don't hold
the minimum required ECC strength), but of the entire flash system
(i.e., what ECC must I use to play nicely with the rest of the world).
If the ECC bindings don't encode the minimum required ECC strength but
rather the ECC config on a specific board then I guess minimum
required ECC strength for non-ONFI chips should be defined somewhere
else (stored in the device ID table ?).
Actually, in the sunxi NAND controller driver, I'm using the DT defined
ECC config when the NAND does not support ONFI timings retrieval.
With timing modes, this is purely a property of the flash chip, and we
do not have to synchronize it with the bootloader. We don't exactly care
if a bootloader and Linux use slightly different timing modes.
Agreed.
Moreover, we will end up with a lot of new entries in the device ID
table if we decide to put these informations in this table.
Yes, that could be a problem.
What sort of non-ONFI flash chips do you have that need this property?
I only have the Hynix one defined in my patch series.
Other people tested my driver on different boards but I don't recall
exactly which NAND they had (a samsung one IIRC).
And what timing mode(s) do they use? Is there, for instance, a pattern
such that all Hynix MLC of a certain generation use a particular timing
mode?
I'll take a look.
I realize that we may not include device ID entries for every flash that
you need in the ID table (although we still are able to detect the
important properties accurately, like page and block size). But would it
suffice to default these flash to a lowest common timing mode, like mode
0?
IMHO this is not a good solution: you'll end up with lower perfomances
on most of the supported NAND chips and I'm not sure this is what we want.
No, we wouldn't want to always use mode 0. But it's possible we can get
good enough heuristics for most flash, if we can integrate timing modes
into the current extended ID decoding. Not sure.
I'm also concerned here that this kind of binding will be difficult to
use properly. A user/developer/board-designer would have to read the
datasheet and compare all its values to the ONFI spec to find the
closest match, and they would have to do this for each new flash they
use. If we can help them by autodetecting this, that would be great.
If no other option works well, then I am still open to describing the
supported
[linux-sunxi] Re: [PATCH v6 0/7] mfd: AXP20x: Add support for AXP202 and AXP209
On Mon, May 19, 2014 at 09:47:41PM +0200, Carlo Caione wrote: This set of patches introduces the core driver and support for two different subsystems: - Regulators .../ABI/testing/sysfs-driver-input-axp-pek | 11 + Documentation/devicetree/bindings/mfd/axp20x.txt | 93 +++ .../devicetree/bindings/vendor-prefixes.txt| 1 + arch/arm/configs/multi_v7_defconfig| 3 + arch/arm/configs/sunxi_defconfig | 4 + drivers/input/misc/Kconfig | 11 + drivers/input/misc/Makefile| 1 + drivers/input/misc/axp20x-pek.c| 281 + drivers/mfd/Kconfig| 12 + drivers/mfd/Makefile | 1 + drivers/mfd/axp20x.c | 258 +++ include/linux/mfd/axp20x.h | 180 + 12 files changed, 856 insertions(+) The regulator changes don't appear to be showing up in the diffstat or obviously in the series? signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v7] DMA: sun6i: Add driver for the Allwinner A31 DMA controller
On Wed, May 07, 2014 at 10:19:49PM -0500, Maxime Ripard wrote:
On Fri, May 02, 2014 at 10:04:29PM +0530, Vinod Koul wrote:
On Wed, Apr 30, 2014 at 02:53:22PM -0700, Maxime Ripard wrote:
Hi Vinod,
On Wed, Apr 30, 2014 at 12:34:08PM +0530, Vinod Koul wrote:
On Thu, Apr 24, 2014 at 04:22:44PM +0200, Maxime Ripard wrote:
+static inline void sun6i_dma_free(struct sun6i_dma_dev *sdc)
+{
+ int i;
+
+ for (i = 0; i NR_MAX_VCHANS; i++) {
+ struct sun6i_vchan *vchan = sdc-vchans[i];
+
+ list_del(vchan-vc.chan.device_node);
+ tasklet_kill(vchan-vc.task);
+ }
+
+ tasklet_kill(sdc-task);
This is again not good. see http://lwn.net/Articles/588457/
At this point HW can still generate interrupts or you can have irq
running!
I'm not sure to fully understand the issue here, but what is not good?
the first or the second tasklet_kill calls, or both?
From what I understood, the issue is only there whenever you are
calling tasklet_disable without making sure that no one will schedule
your tasklet before disabling it.
But the point is I don't actually use either _enable/_disable. I might
be wrong in not using those functions, but I don't really see how I
can be impacted.
Well that was one part of it. How do you ensure the tasklet is not scheduled
while and after you are killing it. You need to ensure irq is disabled and
pending irqs
have finished processing. I dont see that bit.
Ok. I'll change that.
Do you want me to use tasklet_enable and tasklet_disable as well?
I dont think it will help in this usage.
--
~Vinod
signature.asc
Description: Digital signature
[linux-sunxi] Re: [PATCH v7] DMA: sun6i: Add driver for the Allwinner A31 DMA controller
On Tue, May 13, 2014 at 03:42:58PM +0200, Maxime Ripard wrote:
Hi Vinod,
On Wed, Apr 30, 2014 at 12:34:08PM +0530, Vinod Koul wrote:
+
+static int sun6i_dma_terminate_all(struct sun6i_vchan *vchan)
+{
+ struct sun6i_dma_dev *sdev = to_sun6i_dma_dev(vchan-vc.chan.device);
+ struct sun6i_pchan *pchan = vchan-phy;
+ unsigned long flags;
+ LIST_HEAD(head);
+
+ spin_lock(sdev-lock);
+ list_del_init(vchan-node);
+ spin_unlock(sdev-lock);
+
+ spin_lock_irqsave(vchan-vc.lock, flags);
+
+ vchan_get_all_descriptors(vchan-vc, head);
+
+ if (pchan) {
+ writel(DMA_CHAN_ENABLE_STOP, pchan-base + DMA_CHAN_ENABLE);
+ writel(DMA_CHAN_PAUSE_RESUME, pchan-base + DMA_CHAN_PAUSE);
+
+ vchan-phy = NULL;
+ pchan-vchan = NULL;
+ pchan-desc = NULL;
+ pchan-done = NULL;
+ }
+
+ spin_unlock_irqrestore(vchan-vc.lock, flags);
+
+ vchan_dma_desc_free_list(vchan-vc, head);
shouldn't you kill the tasklet as well here?
Just to be clear, which tasklet? vchan's or the driver's?
You need to take care of both. But I suspect if we ensure irq is not triggered
and any pending ones are completed you can simply kill both of the tasklets
happily. See the fixes merged in dmaengine last cycle (hint: patchlog shows what
we need to do)
Btw just noticed, you *should* use dmaengine: as the subsytem name on the patch
series...
--
~Vinod
signature.asc
Description: Digital signature
