Re: [linux-sunxi] tv-in documentation from allwinner?
Hi Euge, On Tue, May 26, 2015 at 3:24 AM, euge sobrino wrote: > I need to decode a analog signal, but i cannot see any reference nor > documentation of the 4 TVIN pins of A20. I Even see cubietruck has the > connector attached but no references. Am I missing anything or is another > undocumented stuff from allwinner. It's almost completely undocumented and there is no upstream driver for it. This seems to be one of the few references of people working on it: http://www.cubieforums.com/index.php?topic=1064.0 I must point out that the "TVIN" subsystem consists of two parts, one which (apparently) decodes analogue (composite?) signals and one which decodes DVB (Transport Stream) digital TV. As far as I'm aware, no viable driver exists for either part, no documentation exists and nobody is working on either of them at the moment. If you must have TV input now, I recommend getting a USB TV decoder. Otherwise you might be able to get something working from the hints on the link above. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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] Re: [RFC 7/7] ARM: dts: sun9i: Add secure SRAM node used for MCPM SMP hotplug
On Sun, May 24, 2015 at 11:55:22PM +0800, Chen-Yu Tsai wrote:
> On Wed, May 20, 2015 at 6:08 PM, Maxime Ripard
> wrote:
> > On Thu, May 14, 2015 at 02:10:11PM +0800, Chen-Yu Tsai wrote:
> >> The A80 stores some magic flags in a portion of the secure SRAM. The
> >> BROM jumps directly to the software entry point set by the SMP code
> >> if the flags are set. This is required for CPU0 hotplugging.
> >>
> >> Signed-off-by: Chen-Yu Tsai
> >> ---
> >> arch/arm/boot/dts/sun9i-a80.dtsi | 20
> >> 1 file changed, 20 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi
> >> b/arch/arm/boot/dts/sun9i-a80.dtsi
> >> index 1507bd2a88f0..0695215634d4 100644
> >> --- a/arch/arm/boot/dts/sun9i-a80.dtsi
> >> +++ b/arch/arm/boot/dts/sun9i-a80.dtsi
> >> @@ -366,6 +366,26 @@
> >>*/
> >> ranges = <0 0 0 0x2000>;
> >>
> >> + sram_b: sram@0002 {
> >> + /* 256 KiB secure SRAM at 0x2 */
> >> + compatible = "mmio-sram";
> >> + reg = <0x0002 0x4>;
> >> +
> >
> > We should probably add a property to that SRAM to tell the driver not
> > to access it if we're not booted in secure mode.
>
> (CC-ing Heiko...)
>
> That kind of puts architecture (ARM) dependent code into a platform
> driver. Furthermore, AFAIK there isn't a safe way to check if we're
> in secure mode or not. Checking SCR raises an undefined instruction
> exception in non-secure mode. Can the kernel handle that? I really
> don't understand this bit well.
That's a very good question. I'm pretty sure the kernel can know that,
since it actually prints the execution mode, and must be able to know
whether it can use the virtualization extensions or not I assume.
> > Otherwise, bad things might happen.
>
> The kernel (or rather the bootloader) boots in secure mode by default,
> and we don't have any bootloader support to boot into non-secure mode
> ATM.
That's not really true. We do have some U-Boot patches, and U-Boot
might very well be setup to boot into HYP, even though it doesn't do
anything else.
And even so, the fact that we have no implementation yet doesn't mean
that we won't have one in a few month. So just sweeping it under the
carpet doesn't seem to be a very good solution.
> Couldn't we have the bootloader mark the SRAM as disabled when
> booting into non-secure when we add that support?
It actually changes the kernel requirements to be able to
boot. Changing that is not an option, especially since it's something
that: 1) isn't dynamic in any way, 2) will possibly break the kernel
if not done, 3) require synchronisation between the bootloader and the
kernel when a new secure SRAM is added to the DT, and require an
upgrade of the bootloader, 4) we might not be able to replace the
bootloader in the first place.
All of these issues make it look like a rather bad solution :/
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android 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.
signature.asc
Description: Digital signature
[linux-sunxi] Re: tv-in documentation from allwinner?
This is AW at its best! Selling H/W and not providing the proper documentation or even source code showing how the H/W block works! It is no coincidence that many people simply gave up on all this totally lost company called All Winner. R On Monday, May 25, 2015 at 12:45:47 PM UTC-5, euge sobrino wrote: > > I need to decode a analog signal, but i cannot see any reference nor > documentation of the 4 TVIN pins of A20. I Even see cubietruck has the > connector attached but no references. Am I missing anything or is another > undocumented stuff from allwinner. > > 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] Re: [PATCH 1/2] mmc: sunxi: fix timeout in sunxi_mmc_oclk_onoff
Hi Michal,
The patch itself looks good, but there's a few style issues.
On Sun, May 24, 2015 at 08:07:32PM +0200, Michal Suchanek wrote:
> The 250ms timeout is too short.
>
> On my system enabling the oclk takes under 50ms and disabling slightly
> over 100ms when idle. Under load disabling the clock can take over
> 350ms.
>
> This does not make mmc clock gating look like good option to have on
> sunxi but the system should not crash with mmc clock gating enabled
> nonetheless.
>
> This patch sets the timeout to 750ms and adds debug prints which show
> how long enabling/disabling the clock took so more data can be collected
> from other systems.
>
> Signed-off-by: Michal Suchanek
> ---
> drivers/mmc/host/sunxi-mmc.c | 22 +++---
> 1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 4d3e1ff..7cdeecd 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -595,7 +595,7 @@ static irqreturn_t sunxi_mmc_handle_manual_stop(int irq,
> void *dev_id)
>
> static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
> {
> - unsigned long expire = jiffies + msecs_to_jiffies(250);
> + unsigned long start, end;
> u32 rval;
>
> rval = mmc_readl(host, REG_CLKCR);
> @@ -604,6 +604,8 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host
> *host, u32 oclk_en)
> if (oclk_en)
> rval |= SDXC_CARD_CLOCK_ON;
>
> + start = jiffies;
> + end = start + msecs_to_jiffies(750);
> mmc_writel(host, REG_CLKCR, rval);
>
> rval = SDXC_START | SDXC_UPCLK_ONLY | SDXC_WAIT_PRE_OVER;
> @@ -611,15 +613,29 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host
> *host, u32 oclk_en)
>
> do {
> rval = mmc_readl(host, REG_CMDR);
> - } while (time_before(jiffies, expire) && (rval & SDXC_START));
> + } while (time_before(jiffies, end) && (rval & SDXC_START));
> + end = jiffies;
>
> /* clear irq status bits set by the command */
> mmc_writel(host, REG_RINTR,
> mmc_readl(host, REG_RINTR) & ~SDXC_SDIO_INTERRUPT);
>
> if (rval & SDXC_START) {
> - dev_err(mmc_dev(host->mmc), "fatal err update clk timeout\n");
> + dev_err(mmc_dev(host->mmc),
> + "fatal err update oclk timeout. Could not %s in
> %ims.\n",
> + oclk_en ? "enable" : "disable",
> + jiffies_to_msecs(end-start));
You should have spaces around that operator.
> return -EIO;
> + } else {
> + int msecs = jiffies_to_msecs(end-start);
Ditto.
> + const char *ing = oclk_en ? "enabling" : "disabling";
> +
> + if ((msecs > 150) || (oclk_en && (msecs > 50)))
> + dev_warn(mmc_dev(host->mmc),
> + "%s oclk took %ims", ing, msecs);
> + else
> + dev_dbg(mmc_dev(host->mmc),
> + "%s oclk took %ims", ing, msecs);
And this should be aligned with the opening parenthesis.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android 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.
signature.asc
Description: Digital signature
[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL
Hi, On 25-05-15 20:35, Hans de Goede wrote: Hi, On 22-05-15 09:04, Roy Spliet wrote: Hello, For my set-up I made use of Boris Brezillon's sunxi-nand tree[1], or actually I rebased his patches on top of 4.0rc7. This basically adds support for NAND-chip partitioning, ECC and randomisation. Docs for the DT specification in Documentation/devicetree/bindings/mtd/sunxi-nand.txt , and an example can be found in arch/arm/boot/dts/sun7i-a20-cubietruck.dts . [2] lists the acceptable configuration options for the boot and boot_rescue partitions, make sure to pick one of these (which should be no problem for MLC-type nand). The ECC mode for these boot partitions is called hw_syndrome. Assuming you now have a Linux set-up kernel based on this tree with NAND support on an MMC, for U-boot what you should currently do is: 1) in include/configs/sunxi-common.h, adjust the parameters PAGE_SIZE, ECC_STEP, ECC_STRENGTH to match your NAND chip and DT configuration. 2) Build 3) Use your MMC to flash u-boot-sunxi-with-spl.bin onto NAND: # flash_erase /dev/mtd0 # nandwrite -p /dev/mtd0 u-boot-sunxi-with-spl.bin 4) Reboot without the MMC card and see U-boot load Ok, it took me way longer then I wanted (see below) but I've this working now. It is cool to see u-boot load from nand :) That should be all. @Alex: To answer your question specifically: It's likely that the parameters in sunxi-common.h mentioned above might not match your NAND-chip configuration in the Linux kernel. I can't tell you precisely how to fetch these details from the 3.4 kernel, sorry. I recall Daniel using 24-bit strength ECC with otherwise equal parameters, but perhaps he can help you with this better than I can. Alex, could it be that you are writing the nand using a (rebased) version of bbrezillon's sunxi-nand-next branch ? I started with that too because it is much newer and contains various bug fixes, but it seems that it also contains a new bug causing it to write the NAND in such a way that the BROM and u-boot SPL code will not read it. I've just pushed a rebased version of the sunxi-nand branch of Boris here: https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment And that works for me, where as before I got the exact same errors trying to fel load a nand enabled spl. I'm working on merging over all the changes from the sunxi-nand-next branch onto my working sunxi-nand-experiment branch 1 by 1 until I find the one which causes the breakage... Ok, so quick update the breakage was caused by this commit: https://github.com/bbrezillon/linux-sunxi/commit/7f7324bc6170a45742352070fb45170779a3611c When it was rebased someone (Boris I guess) forgot to remove the "chip->read_buf(mtd, NULL, ecc->size);" line at line 1075 (after the patch) and likewise the "chip->write_buf(mtd, buf + (i * ecc->size), ecc->size);" line at line 1161. With these 2 lines removed the sunxi-nand-next branch from Boris, rebased on 4.1-rc1 can write the nand boot parts and the brom / spl can load the spl / resp. u-boot.bin from there (on a cubieboard2). I've also tried to get this code running on a cubieboard (non 2 so A10 rather then A20), the SPL loads fine there (indicating that the kernel bits work), but then I get: U-Boot SPL 2015.07-rc1-00287-g050de86-dirty (May 25 2015 - 22:28:19) DRAM: 1024 MiB CPU: 100800Hz, AXI/AHB/APB: 3/2/2 Nand initialised NAND timeout reading data NAND timeout reading data NAND timeout reading data NAND timeout reading data NAND timeout reading data NAND timeout reading data ... Which seems to indicate a problem with the SPL nand code on the A10. I'll investigate this further tomorrow evening. A cleaned up version of my kernel work on this is available in my sunxi-wip branch. 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: Proposal to add NAND-boot support for Sunxi SPL
Hi, On 22-05-15 09:04, Roy Spliet wrote: Hello, For my set-up I made use of Boris Brezillon's sunxi-nand tree[1], or actually I rebased his patches on top of 4.0rc7. This basically adds support for NAND-chip partitioning, ECC and randomisation. Docs for the DT specification in Documentation/devicetree/bindings/mtd/sunxi-nand.txt , and an example can be found in arch/arm/boot/dts/sun7i-a20-cubietruck.dts . [2] lists the acceptable configuration options for the boot and boot_rescue partitions, make sure to pick one of these (which should be no problem for MLC-type nand). The ECC mode for these boot partitions is called hw_syndrome. Assuming you now have a Linux set-up kernel based on this tree with NAND support on an MMC, for U-boot what you should currently do is: 1) in include/configs/sunxi-common.h, adjust the parameters PAGE_SIZE, ECC_STEP, ECC_STRENGTH to match your NAND chip and DT configuration. 2) Build 3) Use your MMC to flash u-boot-sunxi-with-spl.bin onto NAND: # flash_erase /dev/mtd0 # nandwrite -p /dev/mtd0 u-boot-sunxi-with-spl.bin 4) Reboot without the MMC card and see U-boot load Ok, it took me way longer then I wanted (see below) but I've this working now. It is cool to see u-boot load from nand :) That should be all. @Alex: To answer your question specifically: It's likely that the parameters in sunxi-common.h mentioned above might not match your NAND-chip configuration in the Linux kernel. I can't tell you precisely how to fetch these details from the 3.4 kernel, sorry. I recall Daniel using 24-bit strength ECC with otherwise equal parameters, but perhaps he can help you with this better than I can. Alex, could it be that you are writing the nand using a (rebased) version of bbrezillon's sunxi-nand-next branch ? I started with that too because it is much newer and contains various bug fixes, but it seems that it also contains a new bug causing it to write the NAND in such a way that the BROM and u-boot SPL code will not read it. I've just pushed a rebased version of the sunxi-nand branch of Boris here: https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-nand-experiment And that works for me, where as before I got the exact same errors trying to fel load a nand enabled spl. I'm working on merging over all the changes from the sunxi-nand-next branch onto my working sunxi-nand-experiment branch 1 by 1 until I find the one which causes the breakage... Regards, Hans Cheers, Roy [1] https://github.com/bbrezillon/linux-sunxi/commits/sunxi-nand [2] https://linux-sunxi.org/NAND#More_information_on_BROM_NAND Op 22-05-15 om 04:23 schreef kaplan2...@gmail.com: Hi Roy, I could definitely use such a howto. I have applied the patches to the current mainline u-boot head and try to boot my A13-OlinXino Wifi board in FEL mode. I can compile and boot into u-boot via FEL. However, I get these errors when I have CONFIG_SPL_NAND_SUPPORT defined: U-Boot SPL 2015.07-rc1-00276-g77792f9-dirty (May 21 2015 - 19:15:54) DRAM: 512 MiB Failed to set core voltage! Can't set CPU frequency sunxi board_nand_init() Nand initialised Error: 1 ECC failures detected Error: 512 ECC failures detected This is my configs/A13-OLinuXino_defconfig looks like this: CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=2,AXP209_POWER,USB_EHCI,SYS_MAX_NAND_DEVICE=1,SYS_NAND_BASE=0x00" CONFIG_NAND=y CONFIG_SUNXI_NAND=y CONFIG_SUNXI_DMA=y CONFIG_CMD_NAND=y CONFIG_SPL_NAND_SUPPORT=y CONFIG_SPL=y CONFIG_FDTFILE="sun5i-a13-olinuxino.dtb" CONFIG_USB1_VBUS_PIN="PG11" CONFIG_VIDEO_HDMI=n CONFIG_VIDEO_VGA_VIA_LCD=y CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y # For use with the Olimex 7" LCD module, adjust timings for other displays # Set video-mode=sunxi:800x600-24@60,monitor=lcd in the env. to enable CONFIG_VIDEO_LCD_MODE="x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0" CONFIG_VIDEO_LCD_POWER="AXP0-0" CONFIG_VIDEO_LCD_BL_PWM="PB2" CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN5I=y CONFIG_DRAM_CLK=408 CONFIG_DRAM_ZQ=123 CONFIG_DRAM_EMR1=0 CONFIG_DEFAULT_DEVICE_TREE="sun5i-a13-olinuxino" I just found out in the sun5i-a13-olinuxino.dts file are no nand settings. I guess I can find the information in the linux-sunxi 3.4 kernels fex file for the olinuxio and need to convert to dts, correct? I am happy about any hints / comments. Thanks Alex On Thursday, May 21, 2015 at 11:08:24 AM UTC-7, Hans de Goede wrote: Hi Roy, On 21-05-15 15:59, Roy Spliet wrote: > The following patches take the work by Daniel Kochmánski, and make some > heavy modifications for readability and functionality, based on Boris > Brezillon's Linux driver. Tested on an Olimex Lime w/ A20. > Patches are sent as RFC. Open questions: > - Config options added are partially NAND-chip specific. Some options can > be autodetected based on the NAND ID, others require either brute-forcing > or config options like these. Do they belong in sunxi-common?
[linux-sunxi] tv-in documentation from allwinner?
I need to decode a analog signal, but i cannot see any reference nor documentation of the 4 TVIN pins of A20. I Even see cubietruck has the connector attached but no references. Am I missing anything or is another undocumented stuff from allwinner. 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] Re: [PATCH v6] dma: sun4i: Add support for the DMA engine on sun[457]i SoCs
On Thu, May 21, 2015 at 01:45:27PM -0300, Emilio López wrote:
> Hi Maxime, Vinod,
>
> El 20/05/15 a las 18:17, Maxime Ripard escibió:
> >>>+static struct dma_async_tx_descriptor *
> >>>+sun4i_dma_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf, size_t
> >>>len,
> >>>+size_t period_len, enum dma_transfer_direction dir,
> >>>+unsigned long flags)
> >>>+{
> >>>+ struct sun4i_dma_vchan *vchan = to_sun4i_dma_vchan(chan);
> >>>+ struct dma_slave_config *sconfig = &vchan->cfg;
> >>>+ struct sun4i_dma_promise *promise;
> >>>+ struct sun4i_dma_contract *contract;
> >>>+ dma_addr_t src, dest;
> >>>+ u32 endpoints;
> >>>+ int nr_periods, offset, plength, i;
> >>>+
> >>>+ if (!is_slave_direction(dir)) {
> >>>+ dev_err(chan2dev(chan), "Invalid DMA direction\n");
> >>>+ return NULL;
> >>>+ }
> >>>+
> >>>+ if (vchan->is_dedicated) {
> >>>+ /*
> >>>+ * As we are using this just for audio data, we need to use
> >>>+ * normal DMA. There is nothing stopping us from supporting
> >>>+ * dedicated DMA here as well, so if a client comes up and
> >>>+ * requires it, it will be simple to implement it.
> >>>+ */
> >>>+ dev_err(chan2dev(chan),
> >>>+ "Cyclic transfers are only supported on Normal DMA\n");
> >>>+ return NULL;
> >>>+ }
> >>>+
> >>>+ contract = generate_dma_contract();
> >>>+ if (!contract)
> >>>+ return NULL;
> >>>+
> >>>+ contract->is_cyclic = 1;
> >>>+
> >>>+ /* Figure out the endpoints and the address we need */
> >>>+ if (dir == DMA_MEM_TO_DEV) {
> >>>+ src = buf;
> >>>+ dest = sconfig->dst_addr;
> >>>+ endpoints = NDMA_CFG_SRC_DRQ_TYPE(NDMA_DRQ_TYPE_SDRAM) |
> >>>+ NDMA_CFG_DEST_DRQ_TYPE(vchan->endpoint) |
> >>>+ NDMA_CFG_DEST_FIXED_ADDR;
> >>>+ } else {
> >>>+ src = sconfig->src_addr;
> >>>+ dest = buf;
> >>>+ endpoints = NDMA_CFG_SRC_DRQ_TYPE(vchan->endpoint) |
> >>>+ NDMA_CFG_SRC_FIXED_ADDR |
> >>>+ NDMA_CFG_DEST_DRQ_TYPE(NDMA_DRQ_TYPE_SDRAM);
> >>>+ }
> >>>+
> >>>+ /*
> >>>+ * We will be using half done interrupts to make two periods
> >>>+ * out of a promise, so we need to program the DMA engine less
> >>>+ * often
> >>>+ */
> >>>+ nr_periods = DIV_ROUND_UP(len / period_len, 2);
> >>
> >>and why is that.. why don't you use actual period count here?
> >
> >I must admit I don't really know on this one.
> >
> >Emilio?
>
> You mean why is it that I chose to divide "len / period_len" (is
> there some other way to get period count that I'm missing?) by 2 and
> use half done interrupts? The engine can interrupt on half-transfer,
> so we can use this feature to program the engine half as often as if
> we didn't use it (keep in mind the hardware doesn't support linked
> lists).
>
> Say you have a set of periods (| marks the start/end, I for
> interrupt, P for programming the engine to do a new transfer), the
> easy but slow way would be to do
>
> |---|---|---|---| (periods / promises)
> P I,P I,P I,P I
>
> Using half transfer interrupts you can do
>
> |---|---| (promises as configured on hw)
> |---|---|---|---| (periods)
> P I I,P I I
>
> Which requires half the engine programming for the same functionality.
>
> Feel free to include these drawings on the comment if you think
> they'll help.
That explains it then, please do add this bit to driver documentation
>
> >>>+static struct dma_async_tx_descriptor *
> >>>+sun4i_dma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
> >>>+ unsigned int sg_len, enum dma_transfer_direction dir,
> >>>+ unsigned long flags, void *context)
> >>>+{
> >>>+ struct sun4i_dma_vchan *vchan = to_sun4i_dma_vchan(chan);
> >>>+ struct dma_slave_config *sconfig = &vchan->cfg;
> >>>+ struct sun4i_dma_promise *promise;
> >>>+ struct sun4i_dma_contract *contract;
> >>>+ struct scatterlist *sg;
> >>>+ dma_addr_t srcaddr, dstaddr;
> >>>+ u32 endpoints, para;
> >>>+ int i;
> >>>+
> >>>+ if (!sgl)
> >>>+ return NULL;
> >>>+
> >>>+ if (!is_slave_direction(dir)) {
> >>>+ dev_err(chan2dev(chan), "Invalid DMA direction\n");
> >>>+ return NULL;
> >>>+ }
> >>>+
> >>>+ contract = generate_dma_contract();
> >>>+ if (!contract)
> >>>+ return NULL;
> >>>+
> >>>+ /* Figure out endpoints */
> >>>+ if (vchan->is_dedicated && dir == DMA_MEM_TO_DEV) {
> >>>+ endpoints = DDMA_CFG_SRC_DRQ_TYPE(DDMA_DRQ_TYPE_SDRAM) |
> >>>+ DDMA_CFG_SRC_ADDR_MODE(DDMA_ADDR_MODE_LINEAR) |
> >>>+ DDMA_CFG_DEST_DRQ_TYPE(vchan->endpoint) |
> >>>+ DDMA_CFG_DEST_ADDR_MODE(DDMA_ADDR_MODE_IO);
> >>>+ } else if (!vchan->is_dedicated && dir == DMA_MEM_TO_DEV) {
> >>>+ endpoints = NDMA_CFG_SRC_DRQ_TYPE(NDMA_DRQ_T
[linux-sunxi] Re: Firmware extractor for GSL168x chips
On Sunday, May 24, 2015 at 7:43:33 AM UTC-4, Sergio Costas wrote: > > Hi all: > > I created a firmware extractor for these chips. Hope it is useful. > > Some notes: > > * Sometimes it fails in the first launch, but launching again with > exactly the same parameters works fine. > * Try to unload the touch module before running it, to avoid > interferences between both codes. > * Try first with a chunk size of 4 bytes, and change only to 2 or 1 if > it fails. > > -- > Nos leemos > RASTER(Linux user #228804) > ras...@rastersoft.com http://www.rastersoft.com > > Thanks !! That did the trick, it read just fine and the output is in a form I am pretty sure I can work with and finally be able to make a driver for this tab that will run with a Kernel Other than the iNet Provided ones. Your work on this is Truly appreciated. If I do manage to get an Android driver that accepts files similar to the output of your extractor as loadable firmware I will be happy to share the sources. It will most certainly end up on my Github account, but if there is any interest in it let me know. Thanks Again ! :-) -- 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: Firmware extractor for GSL168x chips
Hi: An example: extract /dev/i2c-1 firmware.txt 4 This will try to dump the firmware to a file called firmware.txt, reading 4 bytes each time, and searching for the GSL chip in the first i2c bus. On 25/05/15 16:10, David Bentley wrote: > > > On Sunday, May 24, 2015 at 7:43:33 AM UTC-4, Sergio Costas wrote: > > Hi all: > > I created a firmware extractor for these chips. Hope it is useful. > > Some notes: > > * Sometimes it fails in the first launch, but launching again with > exactly the same parameters works fine. > * Try to unload the touch module before running it, to avoid > interferences between both codes. > * Try first with a chunk size of 4 bytes, and change only to 2 > or 1 if > it fails. > > -- > Nos leemos > RASTER(Linux user #228804) > ras...@rastersoft.com > http://www.rastersoft.com > > > It is great to see someone is still working on the gslx680 I had > thought the driver porting efforts had died out. > > I have compiled and tried the tool but am having a bit of difficulty > getting any output. I am not sure I am entering the > parameter for the Device correctly... exactly what is it looking for > here ? the i2c device name ? I get "Cant open device error" > on all that I have attempted thus far. > > I am attempting to make an android driver for my Touchscreen on an > A31s Q711C_2M_PG iNet board. This seems to be a bit of > an out of the ordinary driver and I have been completely unable to > obtain any source code for it, although I have a Large number > of sources that I have downloaded from many places. In any case I > would like to make something similar to the sunxi-gslx680 and > Rastersoft drivers for Android ie ability to load firmwares from a > file. I have not yet tried to compile the Rastersoft version and my > attempts > to alter the driver included with the A31SDK's have been unfruitful > for this Tablet so far. I used the firmware extractor from sunxi-gslx680 > however i have not been able to do much of anything with the resulting > file due mainly to my Lack of any recent experience in C > programming and the differences in sunxi and sdk kernel code. > > Thanks I hope you can help :-) > -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.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. signature.asc Description: OpenPGP digital signature
[linux-sunxi] Re: Firmware extractor for GSL168x chips
On Sunday, May 24, 2015 at 7:43:33 AM UTC-4, Sergio Costas wrote: > > Hi all: > > I created a firmware extractor for these chips. Hope it is useful. > > Some notes: > > * Sometimes it fails in the first launch, but launching again with > exactly the same parameters works fine. > * Try to unload the touch module before running it, to avoid > interferences between both codes. > * Try first with a chunk size of 4 bytes, and change only to 2 or 1 if > it fails. > > -- > Nos leemos > RASTER(Linux user #228804) > ras...@rastersoft.com http://www.rastersoft.com > > It is great to see someone is still working on the gslx680 I had thought the driver porting efforts had died out. I have compiled and tried the tool but am having a bit of difficulty getting any output. I am not sure I am entering the parameter for the Device correctly... exactly what is it looking for here ? the i2c device name ? I get "Cant open device error" on all that I have attempted thus far. I am attempting to make an android driver for my Touchscreen on an A31s Q711C_2M_PG iNet board. This seems to be a bit of an out of the ordinary driver and I have been completely unable to obtain any source code for it, although I have a Large number of sources that I have downloaded from many places. In any case I would like to make something similar to the sunxi-gslx680 and Rastersoft drivers for Android ie ability to load firmwares from a file. I have not yet tried to compile the Rastersoft version and my attempts to alter the driver included with the A31SDK's have been unfruitful for this Tablet so far. I used the firmware extractor from sunxi-gslx680 however i have not been able to do much of anything with the resulting file due mainly to my Lack of any recent experience in C programming and the differences in sunxi and sdk kernel code. Thanks I hope you can help :-) -- 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: Proposal to add NAND-boot support for Sunxi SPL
Hello, sorry for delay. Comments inline. Hans de Goede writes: > Hi Roy, > > It seems you've accidentally dropped the mailinglist > from the Cc (I don't see anything private in here), > so I've readded it. > > On 24-05-15 15:30, Roy Spliet wrote: >> Hello Hans, >> >> Comments inline. >> >> Op 22-05-15 om 15:51 schreef Hans de Goede: >>> Hello Roy, >>> >>> On 22-05-15 12:12, Roy Spliet wrote: Hello Hans, Sorry for ignoring the second half of your question so far. Here's what's on my mind. Op 21-05-15 om 20:08 schreef Hans de Goede: > Hi Roy, > > 2) What is the plan to add support for loading files from nand in u-boot > proper, > so that we can get (e.g.) extlinux.conf + kernel +dtb from a /boot on > nand ? For the full U-boot I agree we want both MMC and NAND support, regardless of where it was loaded from. From what I can tell U-boot already has UBI support. It sounds like a logical step to try and construct a proper NAND driver for U-boot that either co-exists with this SPL driver or, even better, shares code. That way, I only assume that the UBI and UBIFS layers will take care of all the rest. >>> >>> Ack. >>> The NAND framework in u-boot resembles Linux in many ways. I'm currently in doubt whether we should take Boris' driver as a starting point, or rather use something heavily reduced that re-uses this SPL code. Either way, in U-boot we can perform a clean NAND-chip detection, preferably based on DT definitions as we also use on Linux, and take care of everything proper like PLL settings and a bunch of parameters which are now hard-coded or a configuration option in sunxi-common.h. >>> >>> Have you seen Yassin Jaffer's work porting Boris' code to u-boot ? >>> >>> https://github.com/yassinjaffer/u-boot/commits/sunxi-nand >>> >>> Last time I mailed with Yassin (added to the Cc) he was ok with someone >>> else picking this up and continuing with it as the does not have time >>> to work on it. >> I have seen the pointer to it, but I have the "nasty" habit of preferring to >> look at simple work rather than complex. Hence I ended up with leveraging >> Daniel's patches. Considering space limitations, perhaps it would be best if >> this SPL driver co-exists with a full NAND driver. > > Yes I think that given the space limitations that will be the way to go. > >> Even if that means sacrificing code-sharing...? > > Yes, as much as I dislike that I think dragging the entire mtd work into > the SPL simply is not going to fly. > >> I might have to get back to you on this once I understand the level of code >> sharing between the NAND framework for SPL and for U-boot. > > Ok. > >> If I were to pick up from Yassin's tree: are there strong reasons why this >> work hasn't been merged already? > > Not that I can remember, the main problem was lack of time from both the > reviewer and submitter side IIRC. ATM I'm quite interested in getting > nand working, so the reviewer side should be covered and I've the > feeling the same goes for the submitter side, so we should be able > to make good progress here. > >>> SPL is a different story. I don't know the exact size restriction, but for A10 I've heard it might be as little as 30KB. >>> > Current SPL with my patches and without MMC is already 23KiB. >>> >>> The BROM loads the SPL to a 32K sram and the stack sits in that same SRAM. >>> Note >>> I've some patches which switch the SPL from using a fill blown malloc to >>> using >>> simple-malloc.c which saves a significant amount of space, and the mmc code >>> is not really that big, so I think we should be able to cram this all into >>> the SPL. >> That sounds like a good plan, it's good enough for SPL. >>> I personally think we can reduce it slightly by taking out support for reading everything other than the bootloader partition from SPL (so remove non-syndrome mode, remove the random seeds table...), >>> >>> I agree that removing (#if 0 it for now?) non boot partition support makes >>> sense as a space saving measure. That would disable possibility of preloading multiimage with packed boot script, kernel and devicetree, right? I think code which adds support for all partitions isn't that big. Or maybe rather loading anything else then u-boot from u-boot is undesirable? >>> but it certainly doesn't leave any room for the full NAND framework to do ID-based NAND chip detection. >>> >>> What info do we need when we're only reading ? If the BROM can get away >>> with a fixed >>> way of reading the nand for booting, we should be able to make the SPL get >>> away with it too ... I do really believe that we should be able to deal >>> with different nand chips from a single binaries, with cheap chinese >>> devices like the mk802 the chances are simply to big that the nand >>> will differ from one revision to the next. >> If we look solely at function
Re: [linux-sunxi] Re: Firmware extractor for GSL168x chips
"You can also try patching the firmware with the correct resolution. " How do you imagine to do this? PS: Actually when I was 1st extract fw without this tool I was UNsure that possible I do something wrong or incomplete. Even now I am not at all sure that all you need just grab firmware. May be inside firmware there are some parameters and in some weird way you should initialize it. Actually it looks strange to have different resolution between touch screen and display. Actualy I am only guessing "why" but do not exactly know why and if everything was done in correct way. Unfortunately Chuwi and Silead keep silence and are not open manufacturers that ready to provide any info about their devices even for customers that bought their products. Regards, Serge. On Monday, May 25, 2015 at 11:17:06 AM UTC+3, Michal Suchanek wrote: > > hello, > > On 24 May 2015 at 23:22, > wrote: > > > 2nd: It is unbelievable but on Chuwi vi8 looks that "idiots" put touch > > screen with more resolution than display resolution. After dumping I've > got > > the same story from which I was started - resolution of something like > > x=1145 y=1725 - this is the same I have extracted from elf .ko file, > this is > > the same I've got with loading Silead.fw taken from Win 8.1. > > > > On Chuwi Vi8 I dis this so: rmod gslx680_ts (be ready to connect > external > > keyboard because touch will not work or use linux scripting\piping to > get > > result) then I run twice!!! (only 2nd attempt was working) > > Kind regards, > > As you have already fixed this there is no real problem with the > resolution mismatch. > > You can also try patching the firmware with the correct resolution. > > Thanks > > Michal > -- 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: Proposal to add NAND-boot support for Sunxi SPL
Hi, On 25-05-15 11:29, Daniel Kochmański wrote: Hello, sorry for delay. Comments inline. Hans de Goede writes: Hi Roy, It seems you've accidentally dropped the mailinglist from the Cc (I don't see anything private in here), so I've readded it. On 24-05-15 15:30, Roy Spliet wrote: Hello Hans, Comments inline. Op 22-05-15 om 15:51 schreef Hans de Goede: Hello Roy, On 22-05-15 12:12, Roy Spliet wrote: Hello Hans, Sorry for ignoring the second half of your question so far. Here's what's on my mind. Op 21-05-15 om 20:08 schreef Hans de Goede: Hi Roy, 2) What is the plan to add support for loading files from nand in u-boot proper, so that we can get (e.g.) extlinux.conf + kernel +dtb from a /boot on nand ? For the full U-boot I agree we want both MMC and NAND support, regardless of where it was loaded from. From what I can tell U-boot already has UBI support. It sounds like a logical step to try and construct a proper NAND driver for U-boot that either co-exists with this SPL driver or, even better, shares code. That way, I only assume that the UBI and UBIFS layers will take care of all the rest. Ack. The NAND framework in u-boot resembles Linux in many ways. I'm currently in doubt whether we should take Boris' driver as a starting point, or rather use something heavily reduced that re-uses this SPL code. Either way, in U-boot we can perform a clean NAND-chip detection, preferably based on DT definitions as we also use on Linux, and take care of everything proper like PLL settings and a bunch of parameters which are now hard-coded or a configuration option in sunxi-common.h. Have you seen Yassin Jaffer's work porting Boris' code to u-boot ? https://github.com/yassinjaffer/u-boot/commits/sunxi-nand Last time I mailed with Yassin (added to the Cc) he was ok with someone else picking this up and continuing with it as the does not have time to work on it. I have seen the pointer to it, but I have the "nasty" habit of preferring to look at simple work rather than complex. Hence I ended up with leveraging Daniel's patches. Considering space limitations, perhaps it would be best if this SPL driver co-exists with a full NAND driver. Yes I think that given the space limitations that will be the way to go. Even if that means sacrificing code-sharing...? Yes, as much as I dislike that I think dragging the entire mtd work into the SPL simply is not going to fly. I might have to get back to you on this once I understand the level of code sharing between the NAND framework for SPL and for U-boot. Ok. If I were to pick up from Yassin's tree: are there strong reasons why this work hasn't been merged already? Not that I can remember, the main problem was lack of time from both the reviewer and submitter side IIRC. ATM I'm quite interested in getting nand working, so the reviewer side should be covered and I've the feeling the same goes for the submitter side, so we should be able to make good progress here. SPL is a different story. I don't know the exact size restriction, but for A10 I've heard it might be as little as 30KB. Current SPL with my patches and without MMC is already 23KiB. The BROM loads the SPL to a 32K sram and the stack sits in that same SRAM. Note I've some patches which switch the SPL from using a fill blown malloc to using simple-malloc.c which saves a significant amount of space, and the mmc code is not really that big, so I think we should be able to cram this all into the SPL. That sounds like a good plan, it's good enough for SPL. I personally think we can reduce it slightly by taking out support for reading everything other than the bootloader partition from SPL (so remove non-syndrome mode, remove the random seeds table...), I agree that removing (#if 0 it for now?) non boot partition support makes sense as a space saving measure. That would disable possibility of preloading multiimage with packed boot script, kernel and devicetree, right? I think code which adds support for all partitions isn't that big. Or maybe rather loading anything else then u-boot from u-boot is undesirable? I guess you mean "loading anything else then u-boot from the spl is undesirable?" So what you're talking about using a multi-image directly from the SPL, is basically what is falcon mode, and given the restrictions we've in the SPL I do not think that supporting something like that for nand is a good idea, in order to access the non boot partitions we need to know some more nand parameters, and as said I would really like to avoid coding things like ecc size into Kconfig since different production runs of the same board (e.g. the famous mk802 boards) may very well use different nand chips, and I do not want users to need know which production run they exactly have ... This means we need to get info like this from the nand id, and I'm not sure that that is doable from the spl. So for starters I suggest we simply #if 0 the code, with a comment th
[linux-sunxi] Re: Firmware extractor for GSL168x chips
Yes, there are a lot of unneeded includes. Feel free to remove them. I just took the original driver and modified the code "in-place", and forgot to remove that. On 24/05/15 23:22, sergk.ad...@gmail.com wrote: > Thank you very much! This tool is one that what is missed in complete > set of make it working GSL1680. > > Have ported your code to baytrail. > > 1st - these lines I think is rudшmental in section include (it is > important for porting! ) and came from user space driver where was > used uinput device. > > #include > #include > > > 2nd: It is unbelievable but on Chuwi vi8 looks that "idiots" put touch > screen with more resolution than display resolution. After dumping > I've got the same story from which I was started - resolution of > something like x=1145 y=1725 - this is the same I have extracted from > elf .ko file, this is the same I've got with loading Silead.fw taken > from Win 8.1. > > On Chuwi Vi8 I dis this so: rmod gslx680_ts (be ready to connect > external keyboard because touch will not work or use linux > scripting\piping to get result) then I run twice!!! (only 2nd attempt > was working) > Kind regards, > > Serge Kolotylo. -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.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. signature.asc Description: OpenPGP digital signature
Re: [linux-sunxi] Re: Firmware extractor for GSL168x chips
hello, On 24 May 2015 at 23:22, wrote: > 2nd: It is unbelievable but on Chuwi vi8 looks that "idiots" put touch > screen with more resolution than display resolution. After dumping I've got > the same story from which I was started - resolution of something like > x=1145 y=1725 - this is the same I have extracted from elf .ko file, this is > the same I've got with loading Silead.fw taken from Win 8.1. > > On Chuwi Vi8 I dis this so: rmod gslx680_ts (be ready to connect external > keyboard because touch will not work or use linux scripting\piping to get > result) then I run twice!!! (only 2nd attempt was working) > Kind regards, As you have already fixed this there is no real problem with the resolution mismatch. You can also try patching the firmware with the correct resolution. Thanks Michal -- 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] openwrt finally released for sunxi
Openwrt is finally released for sunxi: https://downloads.openwrt.org/chaos_calmer/15.05-rc1/sunxi/generic/ We had to wait because otherwise there were only daily builds available. If you use it, feel free to report bugs. This is based on a 3.18 lts kernel. -- Benjamin Henrion FFII Brussels - +32-484-566109 - +32-2-4148403 "In July 2005, after several failed attempts to legalise software patents in Europe, the patent establishment changed its strategy. Instead of explicitly seeking to sanction the patentability of software, they are now seeking to create a central European patent court, which would establish and enforce patentability rules in their favor, without any possibility of correction by competing courts or democratically elected legislators." -- 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: Proposal to add NAND-boot support for Sunxi SPL
Hi Roy, It seems you've accidentally dropped the mailinglist from the Cc (I don't see anything private in here), so I've readded it. On 24-05-15 15:30, Roy Spliet wrote: Hello Hans, Comments inline. Op 22-05-15 om 15:51 schreef Hans de Goede: Hello Roy, On 22-05-15 12:12, Roy Spliet wrote: Hello Hans, Sorry for ignoring the second half of your question so far. Here's what's on my mind. Op 21-05-15 om 20:08 schreef Hans de Goede: Hi Roy, 2) What is the plan to add support for loading files from nand in u-boot proper, so that we can get (e.g.) extlinux.conf + kernel +dtb from a /boot on nand ? For the full U-boot I agree we want both MMC and NAND support, regardless of where it was loaded from. From what I can tell U-boot already has UBI support. It sounds like a logical step to try and construct a proper NAND driver for U-boot that either co-exists with this SPL driver or, even better, shares code. That way, I only assume that the UBI and UBIFS layers will take care of all the rest. Ack. The NAND framework in u-boot resembles Linux in many ways. I'm currently in doubt whether we should take Boris' driver as a starting point, or rather use something heavily reduced that re-uses this SPL code. Either way, in U-boot we can perform a clean NAND-chip detection, preferably based on DT definitions as we also use on Linux, and take care of everything proper like PLL settings and a bunch of parameters which are now hard-coded or a configuration option in sunxi-common.h. Have you seen Yassin Jaffer's work porting Boris' code to u-boot ? https://github.com/yassinjaffer/u-boot/commits/sunxi-nand Last time I mailed with Yassin (added to the Cc) he was ok with someone else picking this up and continuing with it as the does not have time to work on it. I have seen the pointer to it, but I have the "nasty" habit of preferring to look at simple work rather than complex. Hence I ended up with leveraging Daniel's patches. Considering space limitations, perhaps it would be best if this SPL driver co-exists with a full NAND driver. Yes I think that given the space limitations that will be the way to go. Even if that means sacrificing code-sharing...? Yes, as much as I dislike that I think dragging the entire mtd work into the SPL simply is not going to fly. I might have to get back to you on this once I understand the level of code sharing between the NAND framework for SPL and for U-boot. Ok. If I were to pick up from Yassin's tree: are there strong reasons why this work hasn't been merged already? Not that I can remember, the main problem was lack of time from both the reviewer and submitter side IIRC. ATM I'm quite interested in getting nand working, so the reviewer side should be covered and I've the feeling the same goes for the submitter side, so we should be able to make good progress here. SPL is a different story. I don't know the exact size restriction, but for A10 I've heard it might be as little as 30KB. > Current SPL with my patches and without MMC is already 23KiB. The BROM loads the SPL to a 32K sram and the stack sits in that same SRAM. Note I've some patches which switch the SPL from using a fill blown malloc to using simple-malloc.c which saves a significant amount of space, and the mmc code is not really that big, so I think we should be able to cram this all into the SPL. That sounds like a good plan, it's good enough for SPL. I personally think we can reduce it slightly by taking out support for reading everything other than the bootloader partition from SPL (so remove non-syndrome mode, remove the random seeds table...), I agree that removing (#if 0 it for now?) non boot partition support makes sense as a space saving measure. but it certainly doesn't leave any room for the full NAND framework to do ID-based NAND chip detection. What info do we need when we're only reading ? If the BROM can get away with a fixed way of reading the nand for booting, we should be able to make the SPL get away with it too ... I do really believe that we should be able to deal with different nand chips from a single binaries, with cheap chinese devices like the mk802 the chances are simply to big that the nand will differ from one revision to the next. If we look solely at functionality I agree. It doesn't even make sense giving SPL broader support than BROM. The technical half of me is complaining about their approach though, because as it stands it does not allow booting from <4GB SLC NAND chips. The parameters they try simply don't match what these chips have to offer in terms of page size and OOB area. I do not think that support things which the BROM does not support makes sense for the FEL code. OTOH no need to cripple it explicitly if the same code can support more. For the full u-boot.bin nand driver supporting more then the BROM does is fine. Maybe I should try and add an ID read function to at least obtain the page size and access
[linux-sunxi] Re: [PATCH 2/2] mmc: sunxi: Also set SDXC_LOW_POWER_ON
Hi, On 24-05-15 20:04, Michal Suchanek wrote: The function sunxi_mmc_oclk_onoff filters out the SDXC_LOW_POWER_ON flag but never sets it. Set SDXC_LOW_POWER_ON when oclk is disabled. Nack, looking at the datasheet I do not thing this patch actually does anything, according to the datasheet setting this bit to 1 results in: "Turn off card clock when FSM in IDLE state", iow this does mmc clock gating on idle automatically in hardware, since we completely disable the clock on clock-off by clearing SDXC_CARD_CLOCK_ON setting this bit on clock-off is a nop. We could consider actually setting this to safe power when setting the clock on, for doing that it would be good to look at the android code and see if it ever sets this bit and if so when. WRT CONFIG_MMC_CLKGATE we are probably better off using SDXC_LOW_POWER_ON then that when it is enabled. So maybe we should set SDXC_LOW_POWER_ON based on #ifdef WRT CONFIG_MMC_CLKGATE, and have some way to tell the mmc core to not do clock gating on this host ? Regards, Hans Signed-off-by: Michal Suchanek --- drivers/mmc/host/sunxi-mmc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c index 7cdeecd..e957888 100644 --- a/drivers/mmc/host/sunxi-mmc.c +++ b/drivers/mmc/host/sunxi-mmc.c @@ -603,6 +603,8 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en) if (oclk_en) rval |= SDXC_CARD_CLOCK_ON; + else + rval |= SDXC_LOW_POWER_ON; start = jiffies; end = start + msecs_to_jiffies(750); -- 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.
