Re: [linux-sunxi] Dual channel LVDS panel with A10/A20

[Michal Suchanek]

Hello,

On 11 September 2017 at 18:46, Priit Laes <pl...@plaes.org> wrote:
> On Mon, Sep 11, 2017 at 06:26:36PM +0200, Michal Suchanek wrote:
>> Hello,
>>
>> anyone used a dual channel LVDS panel with a Cubieboard?
>>
>> I have a LVDS board that has 4+4 LVDS pair inputs and only one clock input.
>>
>> Presumably I can switch both LVDS clocks to the same source so they
>> are effectively the same but I have no idea about splitting the panel
>> data between the two channels. Did anybody manage to set it up?
>
> See 
> https://github.com/plaes/u-boot/commit/d688d1b9c97dd4dfc0ddf3835aeb91d00d1e2c12
>
> I don't yet have hardware, but it should work.
>

this looks like the stuff I was looking for.

I do have what is presumably a 1080p 8bit (probably only the
interface) dual channel LVDS panel but I do not have enough power
converters and 2mm IDC cables to wire it up. I have 30pin 2mm pitch
*socket* on the device end of the LVDS cabling and the cubieboard has
48pin 2mm pitch header with completely different layout. I found some
2mm cabling parts from Molex and some other manufacturer but still
need to research practical availability.

I may need to look for a smaller panel to test the single channel
connectivity first.

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.

Re: [linux-sunxi] AXP209 question

[Michal Suchanek]

Hello,

On 10 September 2017 at 18:23,   wrote:
> Hi all,
>
> I use AXP209 and A20. Is there way that A20 not power on upon DC voltage
> connection to AXP209. I mean if board is off and I plug DC voltage that
> AXP209 only continue to charge battery without power ON board? Thanks.
>
> Best regards,
> Darko
>

The AXP209 datasheet 1.0 states this is programmable but I did not
find any explicit information on how to achieve that in it. Perhaps
this is somewhat implicitly programmable only by disabling the ACIN
and VBUS power sources before shutdown. It will probably not charge
the battery in that case either but I have not tested this at all.

You can also try reading the original sunxi 3.4 kernel sources - maybe
there are some constants defined which give some hint.

HTH

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] Dual channel LVDS panel with A10/A20

[Michal Suchanek]

Hello,

anyone used a dual channel LVDS panel with a Cubieboard?

I have a LVDS board that has 4+4 LVDS pair inputs and only one clock input.

Presumably I can switch both LVDS clocks to the same source so they
are effectively the same but I have no idea about splitting the panel
data between the two channels. Did anybody manage to set it up?

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.

Re: [linux-sunxi] A23 Labeled as A33 !!

[Michal Suchanek]

Hello,

On 29 March 2017 at 13:19, Eyad Majali  wrote:
> Hi,
> I have a Q8 Tablet with the Soc clearly labeled A33 Quad core , when I
> compiled u-boot for A33 it didnt work and showed error initializing dram,
> but when compiled for A23 it worked correctly , and gave an ID of 0x1661,of
> course kernel shows the soc as A23 (two cpus),
> on the stock android the kernel shows two cpus with only one active !
>
> my question is : does allwinner make fake soc ? A23 labeled as A33? or i'm
> missing something here ?

A23 tablets marketed as A33 are the norm when dealing with Chinese sellers.

Did you look at the actual chip or only at the box labels?

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.

Re: [linux-sunxi] Re: [PATCH RESEND v5] ARM: sun4i: spi: Allow transfers larger than FIFO size

[Michal Suchanek]

On 17 October 2016 at 10:26, Alex Gagniuc <mr.nuke...@gmail.com> wrote:
> On Thu, Aug 20, 2015 at 6:48 AM, Michal Suchanek <hramr...@gmail.com> wrote:
>> Hello,
>>
>> On 14 August 2015 at 01:08, Alex G. <mr.nuke...@gmail.com> wrote:
>>> On 08/10/2015 07:54 AM, Michal Suchanek wrote:
>>>> On 10 August 2015 at 15:44, Olliver Schinagl <oliver+l...@schinagl.nl> 
>>>> wrote:
>>>>> Hey Michal,
>>>>>
>>>>> As without this patch, we cannot use something like mmc-spi due to the
>>>>> restriction of packet size iirc.
>>>>
>>>> With DMA we can. And since DMA will be enabled most of the time the
>>>> non-DMA code will receive little or no testing.
>>>>
>>> That was also an objection over a year ago, when this patch was first
>>> ready, and still, no DMA support is implemented. It would be amazing to
>>> have a way to run larger transfers _today_ :) .
>>
>> The dmaengine patch should get into 4.3 probably.
>>
>
> And here we are again, over one year later, up to 4.9, and still
> limited to 63 byte transfers.
>
> A very smart person just brought this up to me today:
>
> " cool, to bad spi does not work properly on allwinner..."
>

The patches are out there - eg here

https://github.com/hramrach/linux-sunxi/tree/sunxi-spi-dma-merged


I don't have time to haggle with maintainers which variant is
acceptable atm but you are free to use the thing and/or pick it up and
submit to linux.


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: [PATCH v3 00/13] sunxi spi fixes

[Michal Suchanek]

On 29 July 2016 at 22:22, Maxime Ripard
<maxime.rip...@free-electrons.com> wrote:
> On Mon, Jul 25, 2016 at 10:03:14AM +0200, Michal Suchanek wrote:
>> Hello,
>>
>> On 25 July 2016 at 09:32, Maxime Ripard
>> <maxime.rip...@free-electrons.com> wrote:
>> > On Fri, Jun 17, 2016 at 12:34:44PM +0200, Michal Suchanek wrote:
>> >> Hello,
>> >>
>> >> On 13 June 2016 at 21:57, Maxime Ripard
>> >> <maxime.rip...@free-electrons.com> wrote:
>> >> > On Mon, Jun 13, 2016 at 05:46:48PM -, Michal Suchanek wrote:
>> >> >> Hello,
>> >> >>
>> >> >> This is update of the sunxi spi patches that should give full-featured 
>> >> >> SPI
>> >> >> driver.
>> >> >>
>> >> >> First three patches fix issues with the current driver and can be of 
>> >> >> use for
>> >> >> stable kernels so adding cc for those.
>> >> >>
>> >> >> I merged the sun4i and sun6i driver because there several issues that 
>> >> >> need to
>> >> >> be fixed in both separately and they are even out of sync wrt some 
>> >> >> fixes.
>> >> >> I guess some of the merge patches can be squashed.
>> >> >>
>> >> >> I tested this with A10s Olinuxino Micro. I have no sun6i device so I 
>> >> >> cannot
>> >> >> tell if that side was broken by this patchset - especially the last 
>> >> >> patch that
>> >> >> adds DMA was afaik never tested on sun6i.
>> >> >
>> >> >
>> >> > For the record, I'm still very much opposed to such a merge.
>> >>
>> >> What is the reason against the merge? I did not find the original
>> >> discussion.
>> >
>> > I really prefer some code that is concise and clear but a little
>> > duplicated over some code that shares every possible lines of code but
>> > is a giant mess impossible to understand.
>>
>> Yes, it's been tried. In the case of this driver there is more duplication
>> than differences. Also bitrot due to different variants receiving different
>> updates and fixes crept in already.
>>
>> Adding the remap layer certainly does not make the driver easier to
>> understand but it's not becoming giant mess either.
>
> Well, when you say that you're not quite fond of using your structure
> all over the place because "it makes your eyes bleed", I wouldn't call
> that a good sales pitch.

That's why put dereferencing it inside the read function. It reduces the noise
throughout the code and make it easier to add checks or change the remap
implementation.

>
> But again, reg_field seems like a good solution for that.

I will look at reg_field.

I saw some drivers using remap layers that are way more heavyweight than
looking up an integer in a table so I wanted to avoid that.

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: [PATCH v3 00/13] sunxi spi fixes

[Michal Suchanek]

Hello,

On 25 July 2016 at 09:32, Maxime Ripard
<maxime.rip...@free-electrons.com> wrote:
> On Fri, Jun 17, 2016 at 12:34:44PM +0200, Michal Suchanek wrote:
>> Hello,
>>
>> On 13 June 2016 at 21:57, Maxime Ripard
>> <maxime.rip...@free-electrons.com> wrote:
>> > On Mon, Jun 13, 2016 at 05:46:48PM -, Michal Suchanek wrote:
>> >> Hello,
>> >>
>> >> This is update of the sunxi spi patches that should give full-featured SPI
>> >> driver.
>> >>
>> >> First three patches fix issues with the current driver and can be of use 
>> >> for
>> >> stable kernels so adding cc for those.
>> >>
>> >> I merged the sun4i and sun6i driver because there several issues that 
>> >> need to
>> >> be fixed in both separately and they are even out of sync wrt some fixes.
>> >> I guess some of the merge patches can be squashed.
>> >>
>> >> I tested this with A10s Olinuxino Micro. I have no sun6i device so I 
>> >> cannot
>> >> tell if that side was broken by this patchset - especially the last patch 
>> >> that
>> >> adds DMA was afaik never tested on sun6i.
>> >
>> >
>> > For the record, I'm still very much opposed to such a merge.
>>
>> What is the reason against the merge? I did not find the original
>> discussion.
>
> I really prefer some code that is concise and clear but a little
> duplicated over some code that shares every possible lines of code but
> is a giant mess impossible to understand.

Yes, it's been tried. In the case of this driver there is more duplication
than differences. Also bitrot due to different variants receiving different
updates and fixes crept in already.

Adding the remap layer certainly does not make the driver easier to
understand but it's not becoming giant mess either.

>
> I just came across the reg_field stuff in regmap that would allow to
> partially address that problem though, there's still the bit indices
> issue to overcome though.
>
>> I tried to rename everything in the drivers from sun4i and sun6i to
>> sunxi to look at a clean diff and found about 5 differences 2 of which
>> look like a bug.
>
> It's hard to tell without testing.

I tested the merged (and separate) driver on a H3 board and found a
type bug in the remap layer.

I also found I can transfer at most 68 bytes without DMA although
the manuals claim 128 byte FIFO. DMA transfers weren't very reliable
which may or may not be a wiring issue. I have seen similar issues
intermittently with SPI on A10s.

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] SPI NOR with jumper wires reliability?

[Michal Suchanek]

Hello,

I am using a w25q32 spi-nor flash (in a spring socket or on a tiny
board with pin headers) connected with jumper wires to the GPIO header
on an A10s OlinuXino Micro and now Orange Pi One.

The problem is that sometimes the flash works quite reliably at 40MHz
and at other times I cannot get reliably same data on repeated
readings at 1MHz. This is the case  with the Orange Pi One right now
and I never had this working previously.

Is there some way to improve reliability of this setup?

I had mixed success with making custom cables which basically boils
down to the same problem I suspect. The contact of jumper wires is not
always reliable.

Also is there some support for WP and and HOLD gpios?

I have currently WP floating and HOLD connected to a spare 3.3V pin
because the driver would not always probe with HOLD floating.

I used the i2c  pins for connecting WP and HOLD in the A10s OlinuXino
since these are pulled up by the board (and this is documented in the
manual).

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.

Re: [linux-sunxi] Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Michal Suchanek]

Hello,

On 15 July 2016 at 15:48, Ondřej Jirman  wrote:
>
>
> On 15.7.2016 15:27, Jean-Francois Moine wrote:
>> On Fri, 15 Jul 2016 12:38:54 +0200
>> Ondřej Jirman  wrote:
>>
 If so, then yes, trying to switch to the 24MHz oscillator before
 applying the factors, and then switching back when the PLL is stable
 would be a nice solution.

 I just checked, and all the SoCs we've had so far have that
 possibility, so if it works, for now, I'd like to stick to that.
>>>
>>> It would need to be tested. U-boot does the change only once, while the
>>> kernel would be doing it all the time and between various frequencies
>>> and PLL settings. So the issues may show up with this solution too.
>>
>> I don't think this is a good idea: the CPU clock may be changed at any
>> time with the CPUFreq governor. I don't see the system moving from
>> 1008MHz to 24MHz and then to 1200MHz when some computation is needed!
>
> PLL lock time is around 10-20us, I'd guess based on the number of loops
> in the PLL lock wait loop. So unless you'll be switching frequencies
> many times per second, this should be barely noticeable.
>
> But I'd like a different solution too.

Do you have a patch to test this?

For me changing CPU frequency on Orange Pi One always locks up the
system. I keep running it on the u-boot setup 1.08GHz at 1.1V

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.

Re: [linux-sunxi] Console on VGA and not on UART

[Michal Suchanek]

On 13 July 2016 at 16:01, dlbp <paolo.delucabo...@gmail.com> wrote:
> Hi!
> I have successfully changed the console and now i can see boot process on
> VGA.
> But there is another problem :D
>
> Now i need to see the kernel on VGA and not on UART.
>
> I read "Starting Kernel" on VGA but after i can't see anything. I think
> maybe the Linux Kernel is on UART.
> How can i modify it??
>
> Thanks
>
> Il giorno mercoledì 13 luglio 2016 08:29:46 UTC+2, Michal Suchanek ha
> scritto:
>>
>> http://linux-sunxi.org/Mainline_U-Boot
>> http://linux-sunxi.org/Mainline_Kernel_Howto#simplefb
>> http://linux-sunxi.org/Display

The above links should answer the question.

If not please specify what is unclear about the guides so they can be fixed.

Thanks

Michal

>>
>> On 12 July 2016 at 21:31, dlbp <paolo.de...@gmail.com> wrote:
>> > Thanks!
>> > I can change kernel configuration for Linux. What should i modify in the
>> > configuration?
>> >
>> > Thanks
>> >
>> > Il giorno martedì 12 luglio 2016 20:16:21 UTC+2, Michal Suchanek ha
>> > scritto:
>> >>
>> >> Hello,
>> >>
>> >> On 12 July 2016 at 19:57, dlbp <paolo.de...@gmail.com> wrote:
>> >> > Hello to everybody!!!
>> >> > I have tried to mount XEN on Cubietruck using this wiki (
>> >> >
>> >> >
>> >> > http://www.sourcediver.org/blog/2014/06/19/running-arch-linux-arm-with-xen-on-cubieboard-2/
>> >> > )
>> >> >
>> >> > But there is a big problem: i haven't now a UART-RS232 converter and
>> >> > i
>> >> > need
>> >> > test the system.
>> >> >
>> >> > Is there a method to see the console and boot process on VGA and not
>> >> > on
>> >> > UART?
>> >> >
>> >>
>> >> Recent u-boot should support console on VGA. You will have to change
>> >> your kernel configuration for Linux to also use VGA console which is
>> >> somewhat difficult without a console.
>> >>
>> >> If your system is networked you can try updating it remotely. If you
>> >> boot from a SD card you can also try removing the SD card and editing
>> >> the content offline on another machine until the console is working.
>> >> You can also enter FEL mode and boot a system over USB to test your
>> >> new u-boot and kernel configuration and/or boot a system that can
>> >> access the boot medium.
>> >>
>> >> HTH
>> >>
>> >> 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...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.

-- 
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] Console on VGA and not on UART

[Michal Suchanek]

http://linux-sunxi.org/Mainline_U-Boot
http://linux-sunxi.org/Mainline_Kernel_Howto#simplefb
http://linux-sunxi.org/Display

On 12 July 2016 at 21:31, dlbp <paolo.delucabo...@gmail.com> wrote:
> Thanks!
> I can change kernel configuration for Linux. What should i modify in the
> configuration?
>
> Thanks
>
> Il giorno martedì 12 luglio 2016 20:16:21 UTC+2, Michal Suchanek ha scritto:
>>
>> Hello,
>>
>> On 12 July 2016 at 19:57, dlbp <paolo.de...@gmail.com> wrote:
>> > Hello to everybody!!!
>> > I have tried to mount XEN on Cubietruck using this wiki (
>> >
>> > http://www.sourcediver.org/blog/2014/06/19/running-arch-linux-arm-with-xen-on-cubieboard-2/
>> > )
>> >
>> > But there is a big problem: i haven't now a UART-RS232 converter and i
>> > need
>> > test the system.
>> >
>> > Is there a method to see the console and boot process on VGA and not on
>> > UART?
>> >
>>
>> Recent u-boot should support console on VGA. You will have to change
>> your kernel configuration for Linux to also use VGA console which is
>> somewhat difficult without a console.
>>
>> If your system is networked you can try updating it remotely. If you
>> boot from a SD card you can also try removing the SD card and editing
>> the content offline on another machine until the console is working.
>> You can also enter FEL mode and boot a system over USB to test your
>> new u-boot and kernel configuration and/or boot a system that can
>> access the boot medium.
>>
>> HTH
>>
>> 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.

-- 
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] Console on VGA and not on UART

[Michal Suchanek]

Hello,

On 12 July 2016 at 19:57, dlbp  wrote:
> Hello to everybody!!!
> I have tried to mount XEN on Cubietruck using this wiki (
> http://www.sourcediver.org/blog/2014/06/19/running-arch-linux-arm-with-xen-on-cubieboard-2/
> )
>
> But there is a big problem: i haven't now a UART-RS232 converter and i need
> test the system.
>
> Is there a method to see the console and boot process on VGA and not on
> UART?
>

Recent u-boot should support console on VGA. You will have to change
your kernel configuration for Linux to also use VGA console which is
somewhat difficult without a console.

If your system is networked you can try updating it remotely. If you
boot from a SD card you can also try removing the SD card and editing
the content offline on another machine until the console is working.
You can also enter FEL mode and boot a system over USB to test your
new u-boot and kernel configuration and/or boot a system that can
access the boot medium.

HTH

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.

Re: [linux-sunxi] Boot failure on A33 powered tablet

[Michal Suchanek]

On 12 July 2016 at 13:14, Steven Saunderson <essat2...@gmail.com> wrote:
>
>
> On Monday, 11 July 2016 22:18:49 UTC+10, Steven Saunderson wrote:
>
>>
>> On Monday, 11 July 2016 21:32:36 UTC+10, Michal Suchanek wrote:
>
>
>>
>> Either way, you can try checking with a multimeter that the RX and TX
>>>
>>> pins of the serial port do not connect to the SD slot. Some tablets
>>> use SD uart with extra pads ..
>>
>> This sounds very relevant.  Thanks for the tip.  I'll check it out.
>
>
> The serial port is connected to the SD holder.  RX connects to SD holder pin
> 2 and TX connects to pin 5.  This does allow someone to insert a connector
> into the SD card holder and monitor the serial port output.  But it does
> make it impossible to use the serial port when booting from SD card.  I'm
> looking for a way to disconnect UART0 from the uSD socket but it doesn't
> seem easy so far.

It's probably not possible. They use SD uart so you either get SD or
uart. You can use FEL boot to test u-boot, kernel and devicetree until
the system works reliably enough to boot without a console.

HTH

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.

Re: [linux-sunxi] Re: USB OTG on Orange Pi PC

[Michal Suchanek]

On 1 July 2016 at 17:57, Ondřej Jirman <m...@xff.cz> wrote:
>
>
> On 1.7.2016 13:19, Michal Suchanek wrote:
>> On 1 July 2016 at 13:02, Michal Suchanek <hramr...@gmail.com> wrote:
>>> On 30 June 2016 at 22:30, Ondřej Jirman <m...@xff.cz> wrote:
>>>> On 30.6.2016 20:21, Michal Suchanek wrote:
>>>>> On 30 June 2016 at 20:06, Michal Suchanek <hramr...@gmail.com> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> On 30 June 2016 at 16:44, Ondřej Jirman <m...@xff.cz> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> hopefuly, it was the NPE that I fixed. It was specifically in the H3 usb
>>>>>>> phy code path for phy0. So I believe it was untested,
>>>>>>> because I didn't find any dts file that would use phy0.
>>>>>>>
>>>>>>
>>>>>> This WorksForMe(TM).
>>>>>
>>>>> There is still small problem left. When I boot with the USB cable
>>>>> connected I have to disconnect and reconnect the cable to get the
>>>>> gadget working.
>>>>>
>>>>
>>>> Good to know, I'll test this case. It will probably be something around
>>>> the iddet handling during phy0 initialization, which leads to the
>>>> connected cable being treated as OTG, which would turn the usb port into
>>>> host mode. You can verify that by looking into sysfs where there's an
>>>> attribute that tells the current mode (peripheral / host). I don't
>>>> rember where exactly it could be found.
>>>>
>>>
>>> This is interesting. The USB gadget works (from the start without 
>>> reconnecting)
>>> with one PC + hub and fails with other PC + hub. Both pretty much 100%
>>>
>>> Ironically the broken hub provides sound voltage above 5.1V and the working
>>> one should give about 4.75V given its 0.2V drop from the board power level.
>>
>> For the record
>>
>> /sys/devices/platform/soc/1c19000.usb/musb-hdrc.1.auto/mode is
>> b_idle when gadget is broken
>> b_peripherial when gadget is working
>
> Hi, you may try adding printks to sun4i_usb_phy0_id_vbus_det_scan in
> phy-sun4i-usb.c inside the if (id_notify) and if (vbus_notify), and try
> if you can observe any differences between the two hubs in dmesg output.

Hello,

I added the debug prints and now cannot reproduce the b_idle state.
This somewhat contributes to my suspicion that this is a race
with delivering the initial interrupt. Also the debug prints show
that the first (and only) irq is fired when the phy is not set up:

[1.546488] phy phy-1c19400.phy.0: usb phy0 handling irq
[1.599174] phy phy-1c19400.phy.0: usb phy0 init missing
[1.632560] phy phy-1c19400.phy.0: usb phy0 setting vbus_det to 1
[1.632569] phy phy-1c19400.phy.0: usb phy0 handling id_notify
[1.632678] phy phy-1c19400.phy.0: Faking usb phy0 id_det 1
[2.632988] phy phy-1c19400.phy.0: usb phy0 handling vbus_notify
[2.747815] phy phy-1c19400.phy.0: usb phy0 setting vbus_det to 1
[2.747824] phy phy-1c19400.phy.0: usb phy0 handling id_notify
[2.747833] phy phy-1c19400.phy.0: Faking usb phy0 id_det 1
[3.748917] phy phy-1c19400.phy.0: usb phy0 handling vbus_notify

No more messages are logged even unplugging and replugging the cable.

Also it seems that the detection depends on something dynamically
fabricated in the irq handler rather than examining the static phy state.

So if the interrupt is handled before musb is set up it may only see the static
state which is not all that useful.

>
> Or first, I'd suggest to add unconditional "return true" to
> sun4i_usb_phy0_poll, if that fixes anything. This will enable polling on
> the iddet gpio. (Perhaps gpio interrupts are not very reliable?)

That sounds like a good plan. However, it does not change anything.

Events are properly generated on connecting and disconnecting an
OTG cable. Connecting and disconnecting peripherial cable does
nothing in the phy at all. It does change something somewhere and
the gadget starts working, though.

Finally, I have seen the gadget broken with phy mode reporting
b_peripherial rather than b_idle.

In one state the gadget interface is up, has proper IP address set up, and
packets don't go through it. On the other side of the USB cable there is
no trace of the gadget interface. No interface, nothing in lsusb.
This particular state turns out to be a cable problem. The springs holding
the cable in the micro usb socket are worn down and it may
have bad contact.

Surprisingly, replacing the cable leads to another error state which is pretty
much what I have seen initially with the b

Re: [linux-sunxi] Re: USB OTG on Orange Pi PC

[Michal Suchanek]

On 1 July 2016 at 13:02, Michal Suchanek <hramr...@gmail.com> wrote:
> On 30 June 2016 at 22:30, Ondřej Jirman <m...@xff.cz> wrote:
>> On 30.6.2016 20:21, Michal Suchanek wrote:
>>> On 30 June 2016 at 20:06, Michal Suchanek <hramr...@gmail.com> wrote:
>>>> Hello,
>>>>
>>>> On 30 June 2016 at 16:44, Ondřej Jirman <m...@xff.cz> wrote:
>>>>> Hi,
>>>>>
>>>>> hopefuly, it was the NPE that I fixed. It was specifically in the H3 usb
>>>>> phy code path for phy0. So I believe it was untested,
>>>>> because I didn't find any dts file that would use phy0.
>>>>>
>>>>
>>>> This WorksForMe(TM).
>>>
>>> There is still small problem left. When I boot with the USB cable
>>> connected I have to disconnect and reconnect the cable to get the
>>> gadget working.
>>>
>>
>> Good to know, I'll test this case. It will probably be something around
>> the iddet handling during phy0 initialization, which leads to the
>> connected cable being treated as OTG, which would turn the usb port into
>> host mode. You can verify that by looking into sysfs where there's an
>> attribute that tells the current mode (peripheral / host). I don't
>> rember where exactly it could be found.
>>
>
> This is interesting. The USB gadget works (from the start without 
> reconnecting)
> with one PC + hub and fails with other PC + hub. Both pretty much 100%
>
> Ironically the broken hub provides sound voltage above 5.1V and the working
> one should give about 4.75V given its 0.2V drop from the board power level.

For the record

/sys/devices/platform/soc/1c19000.usb/musb-hdrc.1.auto/mode is
b_idle when gadget is broken
b_peripherial when gadget is working

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.

Re: [linux-sunxi] Re: USB OTG on Orange Pi PC

[Michal Suchanek]

On 30 June 2016 at 22:30, Ondřej Jirman <m...@xff.cz> wrote:
> On 30.6.2016 20:21, Michal Suchanek wrote:
>> On 30 June 2016 at 20:06, Michal Suchanek <hramr...@gmail.com> wrote:
>>> Hello,
>>>
>>> On 30 June 2016 at 16:44, Ondřej Jirman <m...@xff.cz> wrote:
>>>> Hi,
>>>>
>>>> hopefuly, it was the NPE that I fixed. It was specifically in the H3 usb
>>>> phy code path for phy0. So I believe it was untested,
>>>> because I didn't find any dts file that would use phy0.
>>>>
>>>
>>> This WorksForMe(TM).
>>
>> There is still small problem left. When I boot with the USB cable
>> connected I have to disconnect and reconnect the cable to get the
>> gadget working.
>>
>
> Good to know, I'll test this case. It will probably be something around
> the iddet handling during phy0 initialization, which leads to the
> connected cable being treated as OTG, which would turn the usb port into
> host mode. You can verify that by looking into sysfs where there's an
> attribute that tells the current mode (peripheral / host). I don't
> rember where exactly it could be found.
>

This is interesting. The USB gadget works (from the start without reconnecting)
with one PC + hub and fails with other PC + hub. Both pretty much 100%

Ironically the broken hub provides sound voltage above 5.1V and the working
one should give about 4.75V given its 0.2V drop from the board power level.

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.

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Michal Suchanek]

On 30 June 2016 at 17:50, Michal Suchanek <hramr...@gmail.com> wrote:
> On 30 June 2016 at 17:16, Michal Suchanek <hramr...@gmail.com> wrote:
>> On 30 June 2016 at 16:19, Ondřej Jirman <meg...@megous.com> wrote:
>>> Hello,
>>)k, so I tried>
>>> On 30.6.2016 13:13, Michal Suchanek wrote:
>>>> Hello,
>>>>
>>>> On 25 June 2016 at 05:45,  <meg...@megous.com> wrote:
>>>>> From: Ondrej Jirman <meg...@megous.com>
>>>>>
>>>>> Use Xulong Orange Pi One GPIO based regulator for
>>>>> passive cooling and thermal management.
>>>>>
>>>>> Signed-off-by: Ondrej Jirman <meg...@megous.com>
>>>>> ---
>>>>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>>>>> +
>>>>>  1 file changed, 39 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>>>>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>>>> index b1bd6b0..a38d871 100644
>>>>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>>>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>>>> @@ -109,6 +109,45 @@
>>>>> };
>>>>>  };
>>>>>
>>>>> + {
>>>>> +   operating-points = <
>>>>> +   /* kHzuV */
>>>>> +   1296000 130
>>>>> +   120 130
>>>>
>>>> First problem is that the board boots at 1008000 which is not listed
>>>> and the kernel complains.
>>>>
>>>> Second problem is that the board locks up during boot with this enabled.
>>>>
>>>> Do you have some suggestion for alternate configuration to test?
>>>
>>> Just to verify, did you test with the entire series applied? (especially
>>> the PLL1 clk application changes)
>>
>> Yes, I applied the whole series.
>>
>>>
>>> You may try dropping the highest operating point, it's probably overly
>>> optimistic for Orange Pi One.
>>>
>>> Is the power supply/cable you're using hard enough?
>>
>> I use a 7 port hub to power the board. It worked with some other small
>> devboards.
>>
>> The cable is some random Chinese USB to power jack adaptor with an
>> extra adaptor to fit the Pi socket. It looks ok but I did not test
>> this particular combination thoroughly.
>>
>>>
>>> Where during the boot process does it lock up?
>>
>> Usually sometime around enabling cpufreq  before getty starts.
>> Different runs and settings give slightly different results. In
>> particular adding the 1008000 point seems to make it go further.
>>
>> Removing all traces of the regulator, cpufreq and thermal I can boot
>> pretty much 100% to login prompt.
>>
>> I don't think the difference between 1GHz and 1.3GHz frequency on the
>> core would put much additional stress on the supply but I can try with
>> 35W PSU and some alternative cabling to be sure.
>>
>> I did some more tests and it seems 1008000@1.1V is fine but switching
>> to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
>> there is need for some delay somewhere for the regulator to get
>> stable?
>>
>
> Hm, the AW table shows 1008000@1.3V as supported state and it indeed
> works. So the voltage switching works or does nothing. Can I measure
> the regulator output somewhere? Clocking the chip higher does not
> work.
>
> I will try with another PSU later.
>

Ok, so I tried. The result is the same.

A Chinese USB power meter shows voltage 5.1V which drops to like 4.95V
when the board is running. The power draw is around 170mA and
about 200mA when switch to 1.3V is attempted.
The voltage drop is not nice and is probably due to excessive cabling used
to distribute power to multiple boards.
The USB hub starts at 5.2V and drops to something like 5.1V.

When the top frequency is 1008000@1.3V and governor is performance
the board keeps running 1008000@1.1V as set up by u-boot.

Changing the top point to 1008000@1.1V the board locks up as soon as
governor is changed to conservative. So any attempt at frequency scaling
crashes even without touching the regulator.

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.

Re: [linux-sunxi] Re: USB OTG on Orange Pi PC

[Michal Suchanek]

On 30 June 2016 at 20:06, Michal Suchanek <hramr...@gmail.com> wrote:
> Hello,
>
> On 30 June 2016 at 16:44, Ondřej Jirman <m...@xff.cz> wrote:
>> Hi,
>>
>> hopefuly, it was the NPE that I fixed. It was specifically in the H3 usb
>> phy code path for phy0. So I believe it was untested,
>> because I didn't find any dts file that would use phy0.
>>
>
> This WorksForMe(TM).

There is still small problem left. When I boot with the USB cable
connected I have to disconnect and reconnect the cable to get the
gadget working.

>
>>
>> On 30.6.2016 07:17, boob...@gmail.com wrote:
>>> Nice work.
>>> Sure i will try your path, last time i tried otg i had kernel exception 
>>> when loading musb driver.
>>> I would like setup usb otg in device mode as g_ether or cdrom drive 
>>> emulation to loading bootable iso with gpio sw for iso selection yes i 
>>> dream :)

Actually, the cdrom drive emulation is not out of question. You will
need to tune the linux mass storage gadget to identify as CD-rom
rather than USB stick. I wanted this for IDE CD-rom. The systems that
boot from USB CD-rom usually can do USB stick too.

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.

Re: [linux-sunxi] Re: USB OTG on Orange Pi PC

[Michal Suchanek]

Hello,

On 30 June 2016 at 16:44, Ondřej Jirman  wrote:
> Hi,
>
> hopefuly, it was the NPE that I fixed. It was specifically in the H3 usb
> phy code path for phy0. So I believe it was untested,
> because I didn't find any dts file that would use phy0.
>

This WorksForMe(TM).

I can ssh into OPi One over usb gadget. This gives way better terminal
capability than serial uart.

Maybe squashing the two code patches or using patch order marks would
be helpful here. When ordered by hash the first two patches are
reversed.

Thanks

Michal

>
> On 30.6.2016 07:17, boob...@gmail.com wrote:
>> Nice work.
>> Sure i will try your path, last time i tried otg i had kernel exception when 
>> loading musb driver.
>> I would like setup usb otg in device mode as g_ether or cdrom drive 
>> emulation to loading bootable iso with gpio sw for iso selection yes i dream 
>> :)
>>
>> But for now I try to translate audio codec driver from kernel 3.4,,,removing 
>> lot of config from fex file, remove undocumented R-PRCM (0x01f01400) 
>> read/Write (seem to be configuration area for current setting to restore 
>> after a reboot, not vital..), setup PLL2 (audio_pll) directly in driver 
>> since there isn't no clk driver PLL2 for now (I think it's related to I2S 
>> driver, and it's a complex clock with multi factor to adjust PLL frequency). 
>> For now i just configure it at 24.57Mhz/22.57Mhz and i have succes to have 
>> something in /sys/class/device/sunxi_codec/ and /sunxi-pcm-codec/, no kernel 
>> exception but no sound card available :(
>> When i see in sun4i audio driver, there is lot of new code to create card in 
>> /dev/snd/...
>> It's seem I'm lost deeply in nowhere for now, but I will try your work for 
>> sure (just one source of kernel opps at the same time!).
>>
>
> --
> 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.

-- 
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 v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Michal Suchanek]

On 30 June 2016 at 17:16, Michal Suchanek <hramr...@gmail.com> wrote:
> On 30 June 2016 at 16:19, Ondřej Jirman <meg...@megous.com> wrote:
>> Hello,
>>
>> On 30.6.2016 13:13, Michal Suchanek wrote:
>>> Hello,
>>>
>>> On 25 June 2016 at 05:45,  <meg...@megous.com> wrote:
>>>> From: Ondrej Jirman <meg...@megous.com>
>>>>
>>>> Use Xulong Orange Pi One GPIO based regulator for
>>>> passive cooling and thermal management.
>>>>
>>>> Signed-off-by: Ondrej Jirman <meg...@megous.com>
>>>> ---
>>>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>>>> +
>>>>  1 file changed, 39 insertions(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>>>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>>> index b1bd6b0..a38d871 100644
>>>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>>> @@ -109,6 +109,45 @@
>>>> };
>>>>  };
>>>>
>>>> + {
>>>> +   operating-points = <
>>>> +   /* kHzuV */
>>>> +   1296000 130
>>>> +   120 130
>>>
>>> First problem is that the board boots at 1008000 which is not listed
>>> and the kernel complains.
>>>
>>> Second problem is that the board locks up during boot with this enabled.
>>>
>>> Do you have some suggestion for alternate configuration to test?
>>
>> Just to verify, did you test with the entire series applied? (especially
>> the PLL1 clk application changes)
>
> Yes, I applied the whole series.
>
>>
>> You may try dropping the highest operating point, it's probably overly
>> optimistic for Orange Pi One.
>>
>> Is the power supply/cable you're using hard enough?
>
> I use a 7 port hub to power the board. It worked with some other small
> devboards.
>
> The cable is some random Chinese USB to power jack adaptor with an
> extra adaptor to fit the Pi socket. It looks ok but I did not test
> this particular combination thoroughly.
>
>>
>> Where during the boot process does it lock up?
>
> Usually sometime around enabling cpufreq  before getty starts.
> Different runs and settings give slightly different results. In
> particular adding the 1008000 point seems to make it go further.
>
> Removing all traces of the regulator, cpufreq and thermal I can boot
> pretty much 100% to login prompt.
>
> I don't think the difference between 1GHz and 1.3GHz frequency on the
> core would put much additional stress on the supply but I can try with
> 35W PSU and some alternative cabling to be sure.
>
> I did some more tests and it seems 1008000@1.1V is fine but switching
> to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
> there is need for some delay somewhere for the regulator to get
> stable?
>

Hm, the AW table shows 1008000@1.3V as supported state and it indeed
works. So the voltage switching works or does nothing. Can I measure
the regulator output somewhere? Clocking the chip higher does not
work.

I will try with another PSU later.

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.

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Michal Suchanek]

On 30 June 2016 at 16:19, Ondřej Jirman <meg...@megous.com> wrote:
> Hello,
>
> On 30.6.2016 13:13, Michal Suchanek wrote:
>> Hello,
>>
>> On 25 June 2016 at 05:45,  <meg...@megous.com> wrote:
>>> From: Ondrej Jirman <meg...@megous.com>
>>>
>>> Use Xulong Orange Pi One GPIO based regulator for
>>> passive cooling and thermal management.
>>>
>>> Signed-off-by: Ondrej Jirman <meg...@megous.com>
>>> ---
>>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>>> +
>>>  1 file changed, 39 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> index b1bd6b0..a38d871 100644
>>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>>> @@ -109,6 +109,45 @@
>>> };
>>>  };
>>>
>>> + {
>>> +   operating-points = <
>>> +   /* kHzuV */
>>> +   1296000 130
>>> +   120 130
>>
>> First problem is that the board boots at 1008000 which is not listed
>> and the kernel complains.
>>
>> Second problem is that the board locks up during boot with this enabled.
>>
>> Do you have some suggestion for alternate configuration to test?
>
> Just to verify, did you test with the entire series applied? (especially
> the PLL1 clk application changes)

Yes, I applied the whole series.

>
> You may try dropping the highest operating point, it's probably overly
> optimistic for Orange Pi One.
>
> Is the power supply/cable you're using hard enough?

I use a 7 port hub to power the board. It worked with some other small
devboards.

The cable is some random Chinese USB to power jack adaptor with an
extra adaptor to fit the Pi socket. It looks ok but I did not test
this particular combination thoroughly.

>
> Where during the boot process does it lock up?

Usually sometime around enabling cpufreq  before getty starts.
Different runs and settings give slightly different results. In
particular adding the 1008000 point seems to make it go further.

Removing all traces of the regulator, cpufreq and thermal I can boot
pretty much 100% to login prompt.

I don't think the difference between 1GHz and 1.3GHz frequency on the
core would put much additional stress on the supply but I can try with
35W PSU and some alternative cabling to be sure.

I did some more tests and it seems 1008000@1.1V is fine but switching
to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
there is need for some delay somewhere for the regulator to get
stable?

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.

Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Michal Suchanek]

Hello,

On 25 June 2016 at 05:45,   wrote:
> From: Ondrej Jirman 
>
> Use Xulong Orange Pi One GPIO based regulator for
> passive cooling and thermal management.
>
> Signed-off-by: Ondrej Jirman 
> ---
>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
> +
>  1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> index b1bd6b0..a38d871 100644
> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
> @@ -109,6 +109,45 @@
> };
>  };
>
> + {
> +   operating-points = <
> +   /* kHzuV */
> +   1296000 130
> +   120 130

First problem is that the board boots at 1008000 which is not listed
and the kernel complains.

Second problem is that the board locks up during boot with this enabled.

Do you have some suggestion for alternate configuration to test?

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.

Re: [linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Michal Suchanek]

Hello,

On 29 June 2016 at 23:11, Ondřej Jirman  wrote:
> On 29.6.2016 22:45, Maxime Ripard wrote:
>> Hi,
>>
>> On Sat, Jun 25, 2016 at 04:50:24PM +0200, Ondřej Jirman wrote:
>>> On 25.6.2016 09:02, Maxime Ripard wrote:
 On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman  wrote:
>> Hello,
>>
>> comments below.
>>
>> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>>> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
 From: Ondrej Jirman 

 Add label to the first cpu so that it can be referenced
 from derived dts files.

 Signed-off-by: Ondrej Jirman 
 ---
  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
 b/arch/arm/boot/dts/sun8i-h3.dtsi
 index 9938972..82faefc 100644
 --- a/arch/arm/boot/dts/sun8i-h3.dtsi
 +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
 @@ -52,7 +52,7 @@
 #address-cells = <1>;
 #size-cells = <0>;

 -   cpu@0 {
 +   cpu0: cpu@0 {
 compatible = "arm,cortex-a7";
 device_type = "cpu";
 reg = <0>;
>>>
>>> Can you also set the cpu clock here? It is part of the SoC
>>> and does not belong in the board DTS files.
>>
>> Do you mean operating-points, or something else? Different SBCs will
>> probably require different combinations of operating points just for
>> safety's sake, because they have different regulators and [some have
>> botched] thermal designs, so it might make sense to customize it for
>> differnt boards, and I don't feel adventurous enough setting it for all
>> H3 boards out there.
>
> I meant clocks = <...> and clock-latency = <...>.
>
> These 2 are part of the SoC.
>
> The OPP can stay in the board files. It's a pity there's no standard
> OPP table for H3 though. :(

 This has never been the case, and we always had some deviation in the
 FEX files for all the SoCs.

 If we could come up with standard OPPs that work for every one,
 there's no reason it can't happen here.

 I don't really see why the thermal design should change anything. If a
 boards heats faster, it will throttle down to a lower OPP faster, but
 those OPPs are not going to change.
>>>
>>> I've no way to test, but I've been told some Sinovoip boards are really
>>> bad in this regard (SoC is not even well thermally connected to the
>>> PCB/PCB not having copper layer to spread the heat). Thermal sensor
>>> readings happen at fixed intervals, so the question is if you can heat
>>> up the soc from say 80°C (first trip point) to over 110°C in less than
>>> that period (330ms currently).
>>>
>>> I say it shouldn't be a problem, if that small thing is drawing say 2W
>>> at max load. It will burn or trigger a second trip point before the
>>> first one has a chance to trigger and the kernel will shut down. I
>>> remember tkaiser saying that he has to run that board at 240MHz max. But
>>> perhaps I'm misremembering.
>>>
>>> I'm just speculating.
>>
>> Yes, but that's just poor thermal design. What I was saying is that
>> even if we really need to throttle the SoC to 240 MHz on that board
>> because it heats too much, the couple of the frequency and the voltage
>> will likely be the same across all boards. It's just the amount of
>> time we'll spend using it that will differ.
>>
>> But that's just my understanding, I might be speaking non-sense :)
>>
>> Maxime
>>
>
> You're probably right. Operating points should be part of h3.dtsi, and
> if some board is particularly bad, and can't handle being above certain
> frequency safely, due to thermal design issues, we can override
> operating points in its dts file.
>

Can you override them?

AFAIK you cannot replace a property set in SoC file in a board file.
If you can keep the operating point list and just add option which
selects acceptable subset for the board that should work. On some
boards this subset would be determined by regulator voltage
constraints but not sure how you would select the subset for the
boards with thermal problems.

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.

Re: [linux-sunxi] Unreliable boot on Mele-A2000

[Michal Suchanek]

Hello,

On 16 June 2016 at 18:36, Stefan Monnier  wrote:
>>> But this last step often fails with timeouts or bad CRC checksums or
>>> other errors (the exact errors vary from time to time).  I'd estimate
>>> that the boot succeeds about 1/3 of the time.
>> Could you post some logs on how it fails?
>
> Here's one example (hand-copied, so may include some typos):
>
> Scanning scsi 0:0...
> Found U-Boot script /boot.scr
> 853 bytes read in 21 ms
> ## Executing script at 4310
> scanning bus for devices...
>   Device 0: (0:0) Vendor: ATA Prod.: ST912082 Rev: 3.06
> Type: Hard Disk
> Capacity: 114473.4 MB = 111.7 GB
> Found 1 devic(s).
> timeout exit!
> timeout exit!
> 3636648 bytes read in 20153 ms (175.8 KiB/s)
> timout exit!
> bad MBR sector signature 0xf55a
> ** Invalid partition 1**
> timout exit!
> bad MBR sector signature 0x
> ** Invalid partition 1**
>

It looks like the disk is slow  to respond. Either U-boot does not
wait long enough to honor the spec (which may also somewhat vary per
disk ) or the disk really takes too long and Linux just covers that up
with numerous retries and longer timeouts (iirc it waits up to 10x 30s
for scsi device to send data).

So you probably want to extend the timeout and add more retries in
U-boot code if the disk works OK in Linux.

Also I think it looks like U-boot never received valid data from the
disk but interprets the buffer as a MBR nonetheless which is bogus.

HTH

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: [PATCH v3 00/13] sunxi spi fixes

[Michal Suchanek]

Hello,

On 13 June 2016 at 21:57, Maxime Ripard
<maxime.rip...@free-electrons.com> wrote:
> On Mon, Jun 13, 2016 at 05:46:48PM -0000, Michal Suchanek wrote:
>> Hello,
>>
>> This is update of the sunxi spi patches that should give full-featured SPI
>> driver.
>>
>> First three patches fix issues with the current driver and can be of use for
>> stable kernels so adding cc for those.
>>
>> I merged the sun4i and sun6i driver because there several issues that need to
>> be fixed in both separately and they are even out of sync wrt some fixes.
>> I guess some of the merge patches can be squashed.
>>
>> I tested this with A10s Olinuxino Micro. I have no sun6i device so I cannot
>> tell if that side was broken by this patchset - especially the last patch 
>> that
>> adds DMA was afaik never tested on sun6i.
>

>
> For the record, I'm still very much opposed to such a merge.
>

What is the reason against the merge? I did not find the original discussion.

I tried to rename everything in the drivers from sun4i and sun6i to
sunxi to look at a clean diff and found about 5 differences 2 of which
look like a bug.

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: [PATCH v3 00/13] sunxi spi fixes

[Michal Suchanek]

Hello,

On 13 June 2016 at 21:57, Maxime Ripard
<maxime.rip...@free-electrons.com> wrote:
> On Mon, Jun 13, 2016 at 05:46:48PM -0000, Michal Suchanek wrote:
>> Hello,
>>
>> This is update of the sunxi spi patches that should give full-featured SPI
>> driver.
>>
>> First three patches fix issues with the current driver and can be of use for
>> stable kernels so adding cc for those.
>>
>> I merged the sun4i and sun6i driver because there several issues that need to
>> be fixed in both separately and they are even out of sync wrt some fixes.
>> I guess some of the merge patches can be squashed.
>>
>> I tested this with A10s Olinuxino Micro. I have no sun6i device so I cannot
>> tell if that side was broken by this patchset - especially the last patch 
>> that
>> adds DMA was afaik never tested on sun6i.
>
> So, you didn't run that code through checkpatch and you rewrite the
> whole thing entirely without even testing it... Awesome.

Aside from the DMA part this is not a rewrite.

And I did run the code through checkpatch. It still gives some
warnings about BUG_ON and overly long lines, sure. II don't think
those are that serious or that fixing them would improve the code.

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.

Re: [linux-sunxi] [PATCH v3 07/13] spi: sunxi: rename constants to match between sun4i and sun6i

[Michal Suchanek]

Hello,

On 14 June 2016 at 01:31, Julian Calaby <julian.cal...@gmail.com> wrote:
> Hi Michal,
>
> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek <hramr...@gmail.com> wrote:
>> SUNXI_CTL_ -> SUNXI_TFR_CTL_
>> SUNXI_TFR_CTL_LMTF -> SUNXI_TFR_CTL_FBS
>
> I don't know these abbreviations, are they both referring to the same thing?
>
>> SUNXI_TFR_CTL_CS_ACTIVE_LOW -> SUNXI_TFR_CTL_SPOL
>
> It looks like you're making the constant name less descriptive here.
> Is the old version (CS_ACTIVE_LOW) incorrect?
>
>> and some SUNXI_???_CTL_ -> SUNXI_CTL_
>> for constants migrated to different registers between sun4i and sun6i
>>
>> No functional change.
>>
>>  #define SUNXI_INT_CTL_REG  0x0c
>> diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
>> index a27bf8f..f26b52a 100644
>> --- a/drivers/spi/spi-sun6i.c
>> +++ b/drivers/spi/spi-sun6i.c
>> @@ -26,9 +26,9 @@
>>  #define SUNXI_FIFO_DEPTH   128
>>
>>  #define SUNXI_GBL_CTL_REG  0x04
>> -#define SUNXI_GBL_CTL_BUS_ENABLE   BIT(0)
>> -#define SUNXI_GBL_CTL_MASTER   BIT(1)
>> -#define SUNXI_GBL_CTL_TP   BIT(7)
>> +#define SUNXI_CTL_ENABLE   BIT(0)
>> +#define SUNXI_CTL_MASTER   BIT(1)
>> +#define SUNXI_CTL_TP   BIT(7)
>
> If these are bit definitions for the GBL register, why throw that
> information away?

Those bits are on the TFR register in the earlier IP so it makes
perfect sense to me this way.

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.

Re: [linux-sunxi] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver

[Michal Suchanek]

Hello,

On 14 June 2016 at 01:43, Julian Calaby <julian.cal...@gmail.com> wrote:
> Hi Michal,
>
> On Tue, Jun 14, 2016 at 3:46 AM, Michal Suchanek <hramr...@gmail.com> wrote:
>> The drivers are very similar and share multiple flaws which needed
>> separate fixes for both drivers.
>>
>> Signed-off-by: Michal Suchanek <hramr...@gmail.com>
>> ---
>>  drivers/spi/Kconfig |   8 +-
>>  drivers/spi/Makefile|   1 -
>>  drivers/spi/spi-sun4i.c | 156 +++--
>>  drivers/spi/spi-sun6i.c | 598 
>> 
>>  4 files changed, 143 insertions(+), 620 deletions(-)
>>  delete mode 100644 drivers/spi/spi-sun6i.c
>>
>> diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
>> index 0b8e6c6..c76f8e4 100644
>> --- a/drivers/spi/spi-sun4i.c
>> +++ b/drivers/spi/spi-sun4i.c
>> @@ -279,9 +321,14 @@ static int sunxi_spi_transfer_one(struct spi_master 
>> *master,
>> reg = sunxi_spi_read(sspi, SUNXI_TFR_CTL_REG);
>>
>> /* Reset FIFOs */
>> -   sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG,
>> -   reg | sspi_bits(sspi, SUNXI_CTL_RF_RST) |
>> -   sspi_bits(sspi, SUNXI_CTL_TF_RST));
>> +   if (sspi->type == SPI_SUN4I)
>> +   sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG,
>> +   reg | sspi_bits(sspi, SUNXI_CTL_RF_RST) |
>> +   sspi_bits(sspi, SUNXI_CTL_TF_RST));
>> +   else
>> +   sunxi_spi_write(sspi, SUNXI_FIFO_CTL_REG,
>> +   sspi_bits(sspi, SUNXI_CTL_RF_RST) |
>> +   sspi_bits(sspi, SUNXI_CTL_TF_RST));
>
> If we're already doing different stuff for each generation of the IP,
> why not just use the register offsets and bit definitions directly?

Because having (*sspi->regmap)[SUNXI_FIFO_CTL_REG] all over the place
makes my eyes bleed and you cannot use the check that you are
accessing a register that actually exists.

>> @@ -491,10 +558,37 @@ static int sunxi_spi_probe(struct platform_device 
>> *pdev)
>> }
>>
>> sspi->master = master;
>> -   sspi->fifo_depth = SUN4I_FIFO_DEPTH;
>> -   sspi->type = SPI_SUN4I;
>> -   sspi->regmap = _regmap;
>> -   sspi->bitmap = _bitmap;
>> +   if (of_device_is_compatible(pdev->dev.of_node, SUN4I_COMPATIBLE)) {
>> +   sspi->fifo_depth = SUN4I_FIFO_DEPTH;
>> +   sspi->type = SPI_SUN4I;
>> +   sspi->regmap = _regmap;
>> +   sspi->bitmap = _bitmap;
>> +   } else if (of_device_is_compatible(pdev->dev.of_node,
>> +  SUN6I_COMPATIBLE)) {
>> +   sspi->fifo_depth = SUN6I_FIFO_DEPTH;
>> +   sspi->type = SPI_SUN6I;
>> +   sspi->regmap = _regmap;
>> +   sspi->bitmap = _bitmap;
>
> Can you store data in the match table instead of doing this?

That might be nicer. Will look into this.

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] [PATCH v3 12/13] spi: sunxi: remove CONFIG_SPI_SUN6I

[Michal Suchanek]

This is no longer used.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---
 arch/arm/configs/multi_v7_defconfig | 1 -
 arch/arm/configs/sunxi_defconfig| 1 -
 drivers/spi/Kconfig | 6 --
 3 files changed, 8 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 2823490..3196f04 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -362,7 +362,6 @@ CONFIG_SPI_SH_MSIOF=m
 CONFIG_SPI_SH_HSPI=y
 CONFIG_SPI_SIRF=y
 CONFIG_SPI_SUN4I=y
-CONFIG_SPI_SUN6I=y
 CONFIG_SPI_TEGRA114=y
 CONFIG_SPI_TEGRA20_SFLASH=y
 CONFIG_SPI_TEGRA20_SLINK=y
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 81a1b92..6d0c650 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -78,7 +78,6 @@ CONFIG_I2C_MV64XXX=y
 CONFIG_I2C_SUN6I_P2WI=y
 CONFIG_SPI=y
 CONFIG_SPI_SUN4I=y
-CONFIG_SPI_SUN6I=y
 CONFIG_GPIO_SYSFS=y
 CONFIG_POWER_SUPPLY=y
 CONFIG_AXP20X_POWER=y
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 1b5045b..52e588f 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -581,12 +581,6 @@ config SPI_SUN4I
help
  SPI driver for Allwinner sun4i, sun5i and sun7i SoCs
 
-config SPI_SUN6I
-   tristate "Allwinner A31 SPI controller (deprecated compatibility 
option)"
-   depends on ARCH_SUNXI || COMPILE_TEST
-   depends on RESET_CONTROLLER
-   select SPI_SUN4I
-
 config SPI_MXS
tristate "Freescale MXS SPI controller"
depends on ARCH_MXS
-- 
2.8.1

-- 
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] [PATCH v3 10/13] spi: sunxi: merge sun4i and sun6i SPI driver

[Michal Suchanek]

The drivers are very similar and share multiple flaws which needed
separate fixes for both drivers.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---
 drivers/spi/Kconfig |   8 +-
 drivers/spi/Makefile|   1 -
 drivers/spi/spi-sun4i.c | 156 +++--
 drivers/spi/spi-sun6i.c | 598 
 4 files changed, 143 insertions(+), 620 deletions(-)
 delete mode 100644 drivers/spi/spi-sun6i.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 9d8c84b..1b5045b 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -575,17 +575,17 @@ config SPI_ST_SSC4
  this option, support will be included for the SSC driven SPI.
 
 config SPI_SUN4I
-   tristate "Allwinner A10 SoCs SPI controller"
+   tristate "Allwinner A1X/A2X/A31 SoCs SPI controller"
depends on ARCH_SUNXI || COMPILE_TEST
+   depends on RESET_CONTROLLER
help
  SPI driver for Allwinner sun4i, sun5i and sun7i SoCs
 
 config SPI_SUN6I
-   tristate "Allwinner A31 SPI controller"
+   tristate "Allwinner A31 SPI controller (deprecated compatibility 
option)"
depends on ARCH_SUNXI || COMPILE_TEST
depends on RESET_CONTROLLER
-   help
- This enables using the SPI controller on the Allwinner A31 SoCs.
+   select SPI_SUN4I
 
 config SPI_MXS
tristate "Freescale MXS SPI controller"
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index fbb255c..b0387e8c 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -83,7 +83,6 @@ obj-$(CONFIG_SPI_SH_SCI)  += spi-sh-sci.o
 obj-$(CONFIG_SPI_SIRF) += spi-sirf.o
 obj-$(CONFIG_SPI_ST_SSC4)  += spi-st-ssc4.o
 obj-$(CONFIG_SPI_SUN4I)+= spi-sun4i.o
-obj-$(CONFIG_SPI_SUN6I)+= spi-sun6i.o
 obj-$(CONFIG_SPI_TEGRA114) += spi-tegra114.o
 obj-$(CONFIG_SPI_TEGRA20_SFLASH)   += spi-tegra20-sflash.o
 obj-$(CONFIG_SPI_TEGRA20_SLINK)+= spi-tegra20-slink.o
diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index 0b8e6c6..c76f8e4 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -86,6 +87,23 @@ static int sun4i_regmap[SUNXI_NUM_REGS] = {
 -1, -1, -1, -1
 };
 
+static int sun6i_regmap[SUNXI_NUM_REGS] = {
+/* SUNXI_RXDATA_REG */ 0x300,
+/* SUNXI_TXDATA_REG */ 0x200,
+/* SUNXI_TFR_CTL_REG */0x08,
+/* SUNXI_INT_CTL_REG */0x10,
+/* SUNXI_INT_STA_REG */0x14,
+/* SUNXI_WAIT_REG */   0x20,
+/* SUNXI_CLK_CTL_REG */0x24,
+/* SUNXI_BURST_CNT_REG */  0x30,
+/* SUNXI_XMIT_CNT_REG */   0x34,
+/* SUNXI_FIFO_STA_REG */   0x1c,
+/* SUNXI_VERSION_REG */0x00,
+/* SUNXI_GBL_CTL_REG */0x04,
+/* SUNXI_FIFO_CTL_REG */   0x18,
+/* SUNXI_BURST_CTL_CNT_REG */  0x38,
+};
+
 enum SUNXI_BITMAP_ENUM {
SUNXI_CTL_ENABLE,
SUNXI_CTL_MASTER,
@@ -125,6 +143,25 @@ static int sun4i_bitmap[SUNXI_BITMAP_SIZE] = {
 /* SUNXI_INT_CTL_TC */ BIT(16),
 };
 
+static int sun6i_bitmap[SUNXI_BITMAP_SIZE] = {
+/* SUNXI_CTL_ENABLE */ BIT(0),
+/* SUNXI_CTL_MASTER */ BIT(1),
+/* SUNXI_TFR_CTL_CPHA */   BIT(0),
+/* SUNXI_TFR_CTL_CPOL */   BIT(1),
+/* SUNXI_TFR_CTL_CS_ACTIVE_LOW */  BIT(2),
+/* SUNXI_TFR_CTL_FBS */BIT(12),
+/* SUNXI_CTL_TF_RST */ BIT(31),
+/* SUNXI_CTL_RF_RST */ BIT(15),
+/* SUNXI_TFR_CTL_XCH */BIT(31),
+/* SUNXI_TFR_CTL_CS_MASK */0x30,
+/* SUNXI_TFR_CTL_CS_SHIFT */   4,
+/* SUNXI_TFR_CTL_DHB */BIT(8),
+/* SUNXI_TFR_CTL_CS_MANUAL */  BIT(6),
+/* SUNXI_TFR_CTL_CS_LEVEL */   BIT(7),
+/* SUNXI_CTL_TP */ BIT(7),
+/* SUNXI_INT_CTL_TC */ BIT(12),
+};
+
 struct sunxi_spi {
struct spi_master   *master;
void __iomem*base_addr;
@@ -265,7 +302,12 @@ static int sunxi_spi_transfer_one(struct spi_master 
*master,
if (tfr->len > sspi->fifo_depth)
return -EMSGSIZE;
 
-   if (tfr->tx_buf && tfr->len >= sspi->fifo_depth)
+   /*
+* Filling the FIFO fully causes timeout for some reason
+* at least on spi2 on A10s
+*/
+   if ((sspi->type == SPI_SUN4I) &&
+   tfr->tx_buf && tfr->len >= sspi->fifo_depth)
return -EMSGSIZE;
 
reinit_completion(>done);
@@ -279,9 +321,14 @@ static int sunxi_spi_transfer_one(struct spi_master 
*master,
reg

[linux-sunxi] [PATCH v3 07/13] spi: sunxi: rename constants to match between sun4i and sun6i

[Michal Suchanek]

SUNXI_CTL_ -> SUNXI_TFR_CTL_
SUNXI_TFR_CTL_LMTF -> SUNXI_TFR_CTL_FBS
SUNXI_TFR_CTL_CS_ACTIVE_LOW -> SUNXI_TFR_CTL_SPOL
and some SUNXI_???_CTL_ -> SUNXI_CTL_
for constants migrated to different registers between sun4i and sun6i

No functional change.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---
 drivers/spi/spi-sun4i.c | 68 -
 drivers/spi/spi-sun6i.c | 14 +-
 2 files changed, 41 insertions(+), 41 deletions(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index 155d720..b7f8de1 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -28,21 +28,21 @@
 
 #define SUNXI_TXDATA_REG   0x04
 
-#define SUNXI_CTL_REG  0x08
+#define SUNXI_TFR_CTL_REG  0x08
 #define SUNXI_CTL_ENABLE   BIT(0)
 #define SUNXI_CTL_MASTER   BIT(1)
-#define SUNXI_CTL_CPHA BIT(2)
-#define SUNXI_CTL_CPOL BIT(3)
-#define SUNXI_CTL_CS_ACTIVE_LOWBIT(4)
-#define SUNXI_CTL_LMTF BIT(6)
+#define SUNXI_TFR_CTL_CPHA BIT(2)
+#define SUNXI_TFR_CTL_CPOL BIT(3)
+#define SUNXI_TFR_CTL_SPOL BIT(4)
+#define SUNXI_TFR_CTL_FBS  BIT(6)
 #define SUNXI_CTL_TF_RST   BIT(8)
 #define SUNXI_CTL_RF_RST   BIT(9)
-#define SUNXI_CTL_XCH  BIT(10)
-#define SUNXI_CTL_CS_MASK  0x3000
-#define SUNXI_CTL_CS(cs)   (((cs) << 12) & SUNXI_CTL_CS_MASK)
-#define SUNXI_CTL_DHB  BIT(15)
-#define SUNXI_CTL_CS_MANUALBIT(16)
-#define SUNXI_CTL_CS_LEVEL BIT(17)
+#define SUNXI_TFR_CTL_XCH  BIT(10)
+#define SUNXI_TFR_CTL_CS_MASK  0x3000
+#define SUNXI_TFR_CTL_CS(cs)   (((cs) << 12) & SUNXI_TFR_CTL_CS_MASK)
+#define SUNXI_TFR_CTL_DHB  BIT(15)
+#define SUNXI_TFR_CTL_CS_MANUALBIT(16)
+#define SUNXI_TFR_CTL_CS_LEVEL BIT(17)
 #define SUNXI_CTL_TP   BIT(18)
 
 #define SUNXI_INT_CTL_REG  0x0c
@@ -135,18 +135,18 @@ static void sunxi_spi_set_cs(struct spi_device *spi, bool 
enable)
struct sunxi_spi *sspi = spi_master_get_devdata(spi->master);
u32 reg;
 
-   reg = sunxi_spi_read(sspi, SUNXI_CTL_REG);
+   reg = sunxi_spi_read(sspi, SUNXI_TFR_CTL_REG);
 
-   reg &= ~SUNXI_CTL_CS_MASK;
-   reg |= SUNXI_CTL_CS(spi->chip_select);
+   reg &= ~SUNXI_TFR_CTL_CS_MASK;
+   reg |= SUNXI_TFR_CTL_CS(spi->chip_select);
 
/* We want to control the chip select manually */
-   reg |= SUNXI_CTL_CS_MANUAL;
+   reg |= SUNXI_TFR_CTL_CS_MANUAL;
 
if (enable)
-   reg |= SUNXI_CTL_CS_LEVEL;
+   reg |= SUNXI_TFR_CTL_CS_LEVEL;
else
-   reg &= ~SUNXI_CTL_CS_LEVEL;
+   reg &= ~SUNXI_TFR_CTL_CS_LEVEL;
 
/*
 * Even though this looks irrelevant since we are supposed to
@@ -160,11 +160,11 @@ static void sunxi_spi_set_cs(struct spi_device *spi, bool 
enable)
 * low.
 */
if (spi->mode & SPI_CS_HIGH)
-   reg &= ~SUNXI_CTL_CS_ACTIVE_LOW;
+   reg &= ~SUNXI_TFR_CTL_SPOL;
else
-   reg |= SUNXI_CTL_CS_ACTIVE_LOW;
+   reg |= SUNXI_TFR_CTL_SPOL;
 
-   sunxi_spi_write(sspi, SUNXI_CTL_REG, reg);
+   sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG, reg);
 }
 
 static size_t sunxi_spi_max_transfer_size(struct spi_device *spi)
@@ -199,10 +199,10 @@ static int sunxi_spi_transfer_one(struct spi_master 
*master,
sunxi_spi_write(sspi, SUNXI_INT_STA_REG, ~0);
 
 
-   reg = sunxi_spi_read(sspi, SUNXI_CTL_REG);
+   reg = sunxi_spi_read(sspi, SUNXI_TFR_CTL_REG);
 
/* Reset FIFOs */
-   sunxi_spi_write(sspi, SUNXI_CTL_REG,
+   sunxi_spi_write(sspi, SUNXI_TFR_CTL_REG,
reg | SUNXI_CTL_RF_RST | SUNXI_CTL_TF_RST);
 
/*
@@ -210,19 +210,19 @@ static int sunxi_spi_transfer_one(struct spi_master 
*master,
 * polarities, etc.
 */
if (spi->mode & SPI_CPOL)
-   reg |= SUNXI_CTL_CPOL;
+   reg |= SUNXI_TFR_CTL_CPOL;
else
-   reg &= ~SUNXI_CTL_CPOL;
+   reg &= ~SUNXI_TFR_CTL_CPOL;
 
if (spi->mode & SPI_CPHA)
-   reg |= SUNXI_CTL_CPHA;
+   reg |= SUNXI_TFR_CTL_CPHA;
else
-   reg &= ~SUNXI_CTL_CPHA;
+   reg &= ~SUNXI_TFR_CTL_CPHA;
 
if (spi->mode & SPI_LSB_FIRST)
-   reg |= SUNXI_CTL_LMTF;
+   reg |= SUNXI_TFR_CTL_FBS;
else
-   reg &= ~SUNXI_CTL_LMTF;
+   reg &= ~SUNXI_TFR_CTL_FBS;
 
 
/*
@@ -230,11 +230,11 @@ static int sunxi_spi_transfer_one(struct spi_master 
*master,
 * FIFO with bogus 

[linux-sunxi] [PATCH v3 11/13] dt: spi: sun4i: merge sun4i and sun6i binding doc

[Michal Suchanek]

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---
 .../devicetree/bindings/spi/spi-sun4i.txt  | 21 ++-
 .../devicetree/bindings/spi/spi-sun6i.txt  | 24 --
 2 files changed, 11 insertions(+), 34 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/spi/spi-sun6i.txt

diff --git a/Documentation/devicetree/bindings/spi/spi-sun4i.txt 
b/Documentation/devicetree/bindings/spi/spi-sun4i.txt
index de827f5..329e543 100644
--- a/Documentation/devicetree/bindings/spi/spi-sun4i.txt
+++ b/Documentation/devicetree/bindings/spi/spi-sun4i.txt
@@ -1,7 +1,8 @@
-Allwinner A10 SPI controller
+Allwinner A10/A31 SPI controller
 
 Required properties:
-- compatible: Should be "allwinner,sun4-a10-spi".
+- compatible: Should be one of "allwinner,sun4i-a10-spi" and
+   "allwinner,sun6i-a31-spi"
 - reg: Should contain register location and length.
 - interrupts: Should contain interrupt.
 - clocks: phandle to the clocks feeding the SPI controller. Two are
@@ -9,16 +10,16 @@ Required properties:
   - "ahb": the gated AHB parent clock
   - "mod": the parent module clock
 - clock-names: Must contain the clock names described just above
+- resets: (sun6i only) phandle to the reset controller asserting
+ this device in reset
 
 Example:
 
-spi1: spi@01c06000 {
-   compatible = "allwinner,sun4i-a10-spi";
-   reg = <0x01c06000 0x1000>;
-   interrupts = <11>;
-   clocks = <_gates 21>, <_clk>;
+spi1: spi@01c69000 {
+   compatible = "allwinner,sun6i-a31-spi";
+   reg = <0x01c69000 0x1000>;
+   interrupts = <0 66 4>;
+   clocks = <_gates 21>, <_clk>;
clock-names = "ahb", "mod";
-   status = "disabled";
-   #address-cells = <1>;
-   #size-cells = <0>;
+   resets = <_rst 21>;
 };
diff --git a/Documentation/devicetree/bindings/spi/spi-sun6i.txt 
b/Documentation/devicetree/bindings/spi/spi-sun6i.txt
deleted file mode 100644
index 21de73d..000
--- a/Documentation/devicetree/bindings/spi/spi-sun6i.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Allwinner A31 SPI controller
-
-Required properties:
-- compatible: Should be "allwinner,sun6i-a31-spi".
-- reg: Should contain register location and length.
-- interrupts: Should contain interrupt.
-- clocks: phandle to the clocks feeding the SPI controller. Two are
-  needed:
-  - "ahb": the gated AHB parent clock
-  - "mod": the parent module clock
-- clock-names: Must contain the clock names described just above
-- resets: phandle to the reset controller asserting this device in
-  reset
-
-Example:
-
-spi1: spi@01c69000 {
-   compatible = "allwinner,sun6i-a31-spi";
-   reg = <0x01c69000 0x1000>;
-   interrupts = <0 66 4>;
-   clocks = <_gates 21>, <_clk>;
-   clock-names = "ahb", "mod";
-   resets = <_rst 21>;
-};
-- 
2.8.1

-- 
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] [PATCH v3 09/13] spi: sunxi: use register map

[Michal Suchanek]

The driver code uses the fact that several bits are set in one register
to set them at once.

Between hardware revisions these bits might migrate to different
position or different register altogether but the logical bit groups
that are used together end up in the same register.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---
 drivers/spi/spi-sun4i.c | 227 ++--
 drivers/spi/spi-sun6i.c | 243 
 2 files changed, 322 insertions(+), 148 deletions(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index bbb0996..0b8e6c6 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -23,63 +23,118 @@
 
 #include 
 
-#define SUNXI_FIFO_DEPTH   64
+#define SUN4I_FIFO_DEPTH   64
+#define SUN6I_FIFO_DEPTH   128
 
-#define SUNXI_RXDATA_REG   0x00
+#define SUN4I_COMPATIBLE "allwinner,sun4i-a10-spi"
+#define SUN6I_COMPATIBLE "allwinner,sun6i-a31-spi"
 
-#define SUNXI_TXDATA_REG   0x04
+#define SUNXI_TFR_CTL_CS(bitmap, cs)   (((cs) << \
+ (bitmap)[SUNXI_TFR_CTL_CS_SHIFT]) \
+& (bitmap)[SUNXI_TFR_CTL_CS_MASK])
 
-#define SUNXI_TFR_CTL_REG  0x08
-#define SUNXI_CTL_ENABLE   BIT(0)
-#define SUNXI_CTL_MASTER   BIT(1)
-#define SUNXI_TFR_CTL_CPHA BIT(2)
-#define SUNXI_TFR_CTL_CPOL BIT(3)
-#define SUNXI_TFR_CTL_SPOL BIT(4)
-#define SUNXI_TFR_CTL_FBS  BIT(6)
-#define SUNXI_CTL_TF_RST   BIT(8)
-#define SUNXI_CTL_RF_RST   BIT(9)
-#define SUNXI_TFR_CTL_XCH  BIT(10)
-#define SUNXI_TFR_CTL_CS_MASK  0x3000
-#define SUNXI_TFR_CTL_CS(cs)   (((cs) << 12) & SUNXI_TFR_CTL_CS_MASK)
-#define SUNXI_TFR_CTL_DHB  BIT(15)
-#define SUNXI_TFR_CTL_CS_MANUALBIT(16)
-#define SUNXI_TFR_CTL_CS_LEVEL BIT(17)
-#define SUNXI_CTL_TP   BIT(18)
+#define SUNXI_CNT_MASK 0xff
+#define SUNXI_XMIT_CNT(cnt)((cnt) & SUNXI_CNT_MASK)
+#define SUNXI_BURST_CNT(cnt)   ((cnt) & SUNXI_CNT_MASK)
+#define SUNXI_BURST_CTL_CNT_STC(cnt)   ((cnt) & SUNXI_CNT_MASK)
 
-#define SUNXI_INT_CTL_REG  0x0c
-#define SUNXI_INT_CTL_TC   BIT(16)
-
-#define SUNXI_INT_STA_REG  0x10
-
-#define SUNXI_DMA_CTL_REG  0x14
-
-#define SUNXI_WAIT_REG 0x18
-
-#define SUNXI_CLK_CTL_REG  0x1c
+#define SUNXI_CLK_CTL_DRS  BIT(12)
 #define SUNXI_CLK_CTL_CDR2_MASK0xff
 #define SUNXI_CLK_CTL_CDR2(div)(((div) & 
SUNXI_CLK_CTL_CDR2_MASK) << 0)
 #define SUNXI_CLK_CTL_CDR1_MASK0xf
 #define SUNXI_CLK_CTL_CDR1(div)(((div) & 
SUNXI_CLK_CTL_CDR1_MASK) << 8)
-#define SUNXI_CLK_CTL_DRS  BIT(12)
-
-#define SUNXI_BURST_CNT_REG0x20
-#define SUNXI_BURST_CNT(cnt)   ((cnt) & 0xff)
 
-#define SUNXI_XMIT_CNT_REG 0x24
-#define SUNXI_XMIT_CNT(cnt)((cnt) & 0xff)
-
-#define SUNXI_FIFO_STA_REG 0x28
 #define SUNXI_FIFO_STA_RF_CNT_MASK 0x7f
 #define SUNXI_FIFO_STA_RF_CNT_BITS 0
 #define SUNXI_FIFO_STA_TF_CNT_MASK 0x7f
 #define SUNXI_FIFO_STA_TF_CNT_BITS 16
 
+enum SPI_SUNXI_TYPE {
+   SPI_SUN4I = 1,
+   SPI_SUN6I,
+};
+
+enum SUNXI_REG_ENUM {
+   SUNXI_RXDATA_REG,
+   SUNXI_TXDATA_REG,
+   SUNXI_TFR_CTL_REG,
+   SUNXI_INT_CTL_REG,
+   SUNXI_INT_STA_REG,
+   SUNXI_WAIT_REG,
+   SUNXI_CLK_CTL_REG,
+   SUNXI_BURST_CNT_REG,
+   SUNXI_XMIT_CNT_REG,
+   SUNXI_FIFO_STA_REG,
+   SUNXI_VERSION_REG,
+   SUNXI_GBL_CTL_REG,
+   SUNXI_FIFO_CTL_REG,
+   SUNXI_BURST_CTL_CNT_REG,
+   SUNXI_NUM_REGS
+};
+
+static int sun4i_regmap[SUNXI_NUM_REGS] = {
+/* SUNXI_RXDATA_REG */ 0x00,
+/* SUNXI_TXDATA_REG */ 0x04,
+/* SUNXI_TFR_CTL_REG */0x08,
+/* SUNXI_INT_CTL_REG */0x0c,
+/* SUNXI_INT_STA_REG */0x10,
+/* SUNXI_WAIT_REG */   0x18,
+/* SUNXI_CLK_CTL_REG */0x1c,
+/* SUNXI_BURST_CNT_REG */  0x20,
+/* SUNXI_XMIT_CNT_REG */   0x24,
+/* SUNXI_FIFO_STA_REG */   0x28,
+-1, -1, -1, -1
+};
+
+enum SUNXI_BITMAP_ENUM {
+   SUNXI_CTL_ENABLE,
+   SUNXI_CTL_MASTER,
+   SUNXI_TFR_CTL_CPHA,
+   SUNXI_TFR_CTL_CPOL,
+   SUNXI_TFR_CTL_CS_ACTIVE_LOW,
+   SUNXI_TFR_CTL_FBS,
+   SUNXI_CTL_TF_RST,
+   SUNXI_CTL_RF_RST,
+   SUNXI_TFR_CTL_XCH,
+   SUNXI_TFR_CTL_CS_MASK,
+   SUNXI_TFR_CTL_CS_SHIFT,
+   SUNXI_TFR_CTL_DHB,
+   SUNXI_TFR_CTL_CS_MANUAL,
+   SUNXI_TFR_CTL_CS_LEVEL,
+

[linux-sunxi] [PATCH v3 01/13] spi: sunxi: set maximum and minimum speed of SPI master

[Michal Suchanek]

The speed limits are unset in the sun4i and sun6i SPI drivers.

The maximum speed of SPI master is used when maximum speed of SPI slave
is not specified. Also the __spi_validate function should check that
transfer speeds do not exceed the master limits.

The user manual for A10 and A31 specifies maximum
speed of the SPI clock as 100MHz and minimum as 3kHz.

Setting the SPI clock to out-of-spec values can lock up the SoC.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
--
v2:
new patch
v3:
fix constant style
---
 drivers/spi/spi-sun4i.c | 2 ++
 drivers/spi/spi-sun6i.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index 1ddd9e2..4213508 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -387,6 +387,8 @@ static int sun4i_spi_probe(struct platform_device *pdev)
}
 
sspi->master = master;
+   master->max_speed_hz = 100 * 1000 * 1000;
+   master->min_speed_hz =  3 * 1000;
master->set_cs = sun4i_spi_set_cs;
master->transfer_one = sun4i_spi_transfer_one;
master->num_chipselect = 4;
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 42e2c4b..fe70695 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -386,6 +386,8 @@ static int sun6i_spi_probe(struct platform_device *pdev)
}
 
sspi->master = master;
+   master->max_speed_hz = 100 * 1000 * 1000;
+   master->min_speed_hz =  3 * 1000;
master->set_cs = sun6i_spi_set_cs;
master->transfer_one = sun6i_spi_transfer_one;
master->num_chipselect = 4;
-- 
2.8.1

-- 
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] [PATCH v3 08/13] spi: sunxi: synchronize whitespace, comments, struct

[Michal Suchanek]

Minimize differences between sun4i and sun6i driver without code
changes.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---
 drivers/spi/spi-sun4i.c | 11 ++-
 drivers/spi/spi-sun6i.c |  8 +++-
 2 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index b7f8de1..bbb0996 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -56,7 +57,7 @@
 
 #define SUNXI_CLK_CTL_REG  0x1c
 #define SUNXI_CLK_CTL_CDR2_MASK0xff
-#define SUNXI_CLK_CTL_CDR2(div)((div) & 
SUNXI_CLK_CTL_CDR2_MASK)
+#define SUNXI_CLK_CTL_CDR2(div)(((div) & 
SUNXI_CLK_CTL_CDR2_MASK) << 0)
 #define SUNXI_CLK_CTL_CDR1_MASK0xf
 #define SUNXI_CLK_CTL_CDR1(div)(((div) & 
SUNXI_CLK_CTL_CDR1_MASK) << 8)
 #define SUNXI_CLK_CTL_DRS  BIT(12)
@@ -78,6 +79,7 @@ struct sunxi_spi {
void __iomem*base_addr;
struct clk  *hclk;
struct clk  *mclk;
+   struct reset_control*rstc;
 
struct completion   done;
 
@@ -136,7 +138,6 @@ static void sunxi_spi_set_cs(struct spi_device *spi, bool 
enable)
u32 reg;
 
reg = sunxi_spi_read(sspi, SUNXI_TFR_CTL_REG);
-
reg &= ~SUNXI_TFR_CTL_CS_MASK;
reg |= SUNXI_TFR_CTL_CS(spi->chip_select);
 
@@ -198,7 +199,6 @@ static int sunxi_spi_transfer_one(struct spi_master *master,
/* Clear pending interrupts */
sunxi_spi_write(sspi, SUNXI_INT_STA_REG, ~0);
 
-
reg = sunxi_spi_read(sspi, SUNXI_TFR_CTL_REG);
 
/* Reset FIFOs */
@@ -224,7 +224,6 @@ static int sunxi_spi_transfer_one(struct spi_master *master,
else
reg &= ~SUNXI_TFR_CTL_FBS;
 
-
/*
 * If it's a TX only transfer, we don't want to fill the RX
 * FIFO with bogus data
@@ -248,7 +247,7 @@ static int sunxi_spi_transfer_one(struct spi_master *master,
 *
 * We have two choices there. Either we can use the clock
 * divide rate 1, which is calculated thanks to this formula:
-* SPI_CLK = MOD_CLK / (2 ^ (cdr + 1))
+* SPI_CLK = MOD_CLK / (2 ^ cdr)
 * Or we can use CDR2, which is calculated with the formula:
 * SPI_CLK = MOD_CLK / (2 * (cdr + 1))
 * Wether we use the former or the latter is set through the
@@ -352,6 +351,8 @@ static int sunxi_spi_runtime_resume(struct device *dev)
 
return 0;
 
+err2:
+   clk_disable_unprepare(sspi->mclk);
 err:
clk_disable_unprepare(sspi->hclk);
 out:
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index f26b52a..d14a953 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -29,7 +29,6 @@
 #define SUNXI_CTL_ENABLE   BIT(0)
 #define SUNXI_CTL_MASTER   BIT(1)
 #define SUNXI_CTL_TP   BIT(7)
-#define SUNXI_GBL_CTL_RST  BIT(31)
 
 #define SUNXI_TFR_CTL_REG  0x08
 #define SUNXI_TFR_CTL_CPHA BIT(0)
@@ -44,7 +43,6 @@
 #define SUNXI_TFR_CTL_XCH  BIT(31)
 
 #define SUNXI_INT_CTL_REG  0x10
-#define SUNXI_INT_CTL_RF_OVF   BIT(8)
 #define SUNXI_INT_CTL_TC   BIT(12)
 
 #define SUNXI_INT_STA_REG  0x14
@@ -200,7 +198,9 @@ static int sunxi_spi_transfer_one(struct spi_master *master,
/* Clear pending interrupts */
sunxi_spi_write(sspi, SUNXI_INT_STA_REG, ~0);
 
-   /* Reset FIFO */
+   reg = sunxi_spi_read(sspi, SUNXI_TFR_CTL_REG);
+
+   /* Reset FIFOs */
sunxi_spi_write(sspi, SUNXI_FIFO_CTL_REG,
SUNXI_CTL_RF_RST | SUNXI_CTL_TF_RST);
 
@@ -208,8 +208,6 @@ static int sunxi_spi_transfer_one(struct spi_master *master,
 * Setup the transfer control register: Chip Select,
 * polarities, etc.
 */
-   reg = sunxi_spi_read(sspi, SUNXI_TFR_CTL_REG);
-
if (spi->mode & SPI_CPOL)
reg |= SUNXI_TFR_CTL_CPOL;
else
-- 
2.8.1

-- 
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] [PATCH v3 05/13] spi: sun6i: update CS handling from spi-sun4i

[Michal Suchanek]

While trying to merge sun4i and sun6i spi drivers I noticed
the sun4i driver seems to have more reasonable CS handling.

Update sun6i to same.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---
 drivers/spi/spi-sun6i.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index bc29a98..06759d0 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -145,11 +145,30 @@ static void sun6i_spi_set_cs(struct spi_device *spi, bool 
enable)
reg &= ~SUN6I_TFR_CTL_CS_MASK;
reg |= SUN6I_TFR_CTL_CS(spi->chip_select);
 
+   /* We want to control the chip select manually */
+   reg |= SUN6I_TFR_CTL_CS_MANUAL;
+
if (enable)
reg |= SUN6I_TFR_CTL_CS_LEVEL;
else
reg &= ~SUN6I_TFR_CTL_CS_LEVEL;
 
+   /*
+* Even though this looks irrelevant since we are supposed to
+* be controlling the chip select manually, this bit also
+* controls the levels of the chip select for inactive
+* devices.
+*
+* If we don't set it, the chip select level will go low by
+* default when the device is idle, which is not really
+* expected in the common case where the chip select is active
+* low.
+*/
+   if (spi->mode & SPI_CS_HIGH)
+   reg &= ~SUN6I_TFR_CTL_SPOL;
+   else
+   reg |= SUN6I_TFR_CTL_SPOL;
+
sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
 }
 
@@ -215,9 +234,6 @@ static int sun6i_spi_transfer_one(struct spi_master *master,
else
reg |= SUN6I_TFR_CTL_DHB;
 
-   /* We want to control the chip select manually */
-   reg |= SUN6I_TFR_CTL_CS_MANUAL;
-
sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
 
/* Ensure that we have a parent clock fast enough */
-- 
2.8.1

-- 
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] [PATCH v3 03/13] spi: sun4i: fix FIFO limit

[Michal Suchanek]

When testing SPI without DMA I noticed that filling the FIFO on the
spi controller causes timeout.

Always leave room for one byte in the FIFO.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>

---
v2:
use EMSGSIZE instead of EINVAL
v3:
fix comment style
---
 drivers/spi/spi-sun4i.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index 0c2216a..f2848b7 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -180,7 +180,10 @@ static int sun4i_spi_transfer_one(struct spi_master 
*master,
 
/* We don't support transfer larger than the FIFO */
if (tfr->len > SUN4I_FIFO_DEPTH)
-   return -EINVAL;
+   return -EMSGSIZE;
+
+   if (tfr->tx_buf && tfr->len >= SUN4I_FIFO_DEPTH)
+   return -EMSGSIZE;
 
reinit_completion(>done);
sspi->tx_buf = tfr->tx_buf;
@@ -270,8 +273,12 @@ static int sun4i_spi_transfer_one(struct spi_master 
*master,
sun4i_spi_write(sspi, SUN4I_BURST_CNT_REG, SUN4I_BURST_CNT(tfr->len));
sun4i_spi_write(sspi, SUN4I_XMIT_CNT_REG, SUN4I_XMIT_CNT(tx_len));
 
-   /* Fill the TX FIFO */
-   sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH);
+   /*
+* Fill the TX FIFO
+* Filling the FIFO fully causes timeout for some reason
+* at least on spi2 on A10s
+*/
+   sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH - 1);
 
/* Enable the interrupts */
sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, SUN4I_INT_CTL_TC);
-- 
2.8.1

-- 
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] [PATCH v3 00/13] sunxi spi fixes

[Michal Suchanek]

Hello,

This is update of the sunxi spi patches that should give full-featured SPI
driver.

First three patches fix issues with the current driver and can be of use for
stable kernels so adding cc for those.

I merged the sun4i and sun6i driver because there several issues that need to
be fixed in both separately and they are even out of sync wrt some fixes.
I guess some of the merge patches can be squashed.

I tested this with A10s Olinuxino Micro. I have no sun6i device so I cannot
tell if that side was broken by this patchset - especially the last patch that
adds DMA was afaik never tested on sun6i.


Emilio López (1):
  spi: sun4i: add DMA support

Michal Suchanek (12):
  spi: sunxi: set maximum and minimum speed of SPI master
  spi: sunxi: fix transfer timeout
  spi: sun4i: fix FIFO limit
  spi: sunxi: expose maximum transfer size limit
  spi: sun6i: update CS handling from spi-sun4i
  spi: sunxi: rename sun4i,sun6i -> sunxi
  spi: sunxi: rename constants to match between sun4i and sun6i
  spi: sunxi: synchronize whitespace, comments, struct
  spi: sunxi: use register map
  spi: sunxi: merge sun4i and sun6i SPI driver
  dt: spi: sun4i: merge sun4i and sun6i binding doc
  spi: sunxi: remove CONFIG_SPI_SUN6I

 .../devicetree/bindings/spi/spi-sun4i.txt  |  21 +-
 .../devicetree/bindings/spi/spi-sun6i.txt  |  24 -
 arch/arm/configs/multi_v7_defconfig|   1 -
 arch/arm/configs/sunxi_defconfig   |   1 -
 drivers/spi/Kconfig|  10 +-
 drivers/spi/Makefile   |   1 -
 drivers/spi/spi-sun4i.c| 728 +
 drivers/spi/spi-sun6i.c| 482 --
 8 files changed, 600 insertions(+), 668 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/spi/spi-sun6i.txt
 delete mode 100644 drivers/spi/spi-sun6i.c

-- 
2.8.1

-- 
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] spidev on BananaPi R1 not working.

[Michal Suchanek]

Hello,

On 4 June 2016 at 19:26, 'Eckhardt Ulrich' via linux-sunxi
 wrote:
> Hi,
>
> I managed to get the SPI devices /dev/spidev0.0 and /dev/spidev0.1 to be
> visible using the mainline kernel 4.4.11 on my BananaPi R1 (Allwinner A20)
> with the attached patch to spidev.c and the dts. But the SPI device is not
> working. When I send some data for example with echo "test" > /dev/spidev0.0
> I could see some activity on both chip select lines SPI_CS0 and SPI_CS1, but
> no reaction on SPI0_CLK. Is this a bug somewhere or is there additional
> tweaking in the dts required?
>

There is a comment in the SPI driver regarding CS polarity which boils
down to 'changing CS polarity affects all CS lines'. I cannot test
this on the board I am working with since it has only one CS
available.

You can always try to export all the SPI pins as GPIO and change the
level on them using sysfs for testing. Also writing to spidev probably
does not necessarily cause a transfer. SPI transfers are ordinarily
done with an IOCTL. Even if you send a few bytes it might be
challenging to measure the level change unless you are using an
oscilloscope.

Finally, the driver in 4.4.11 is likely broken and will do nothing or
lock up if you send more than 63 bytes at once. Try to modify the
testprogramm to not do that of STFW for a patch that adds support for
arbitrarily long transfers. There are a few floating around.

HTH

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.

Re: [linux-sunxi] Re: [PATCH 5/5] RFC spi: sun4i: add DMA support

[Michal Suchanek]

On 2 June 2016 at 16:26, Mark Brown <broo...@kernel.org> wrote:
> On Thu, Jun 02, 2016 at 02:14:26PM +0200, Michal Suchanek wrote:
>> On 2 June 2016 at 06:42, Priit Laes <pl...@plaes.org> wrote:
>> > On Wed, 2016-06-01 at 20:00 +0200, Maxime Ripard wrote:
>
>> > Actually it non-DMA case works fine if you don't need SPI transfers
>> > larger than SUN4I_FIFO_DEPTH - 1, which is 63 bytes.
>
>> > This was addressed by this patch, but was never applied:
>> > http://permalink.gmane.org/gmane.linux.kernel.spi.devel/18950
>
>> And the code added in that patch will never run unless you
>
>> 1) use long spi transfers
>> 2) compile in/load SPI without DMA support
>
>> There is no reason for doing 2) since we have do DMA support for sunxi.
>
> Well, presumably such code exists and is being worked on?

Which code are you referring to?

This is a reply to patch which adds DMA support to the SPI driver so
that it can work for arbitrarily long transfers.

So there is code for fully working driver.

>
>> So that's another code path that needs maintenance and testing and
>> likely will not get it.
>
> Oh, come on.  You might not want to use it yourself but the chances are
> that someone will want to use it just like the situation with all the
> other SPI drivers.  It's a perfectly reasonable and sensible feature to
> support upstream.

Is it?

Once we have *one* driver that works for arbitrarily long transfers
and it works out of the box with the board defconfig 99% of people who
will use the SPI driver for anything will use this driver. Any other
variant will go untested.

And for the driver to also work without DMA you have to *tell* it to
probe without DMA because it cannot know you are not going to load a
DMA driver later.

>
> I really do not understand why there is such a strong desire to have
> these devices be a special snowflake here, the worst that's likely to
> happen here is that you're going to end up having to either remove the
> DMA controller from the DT or load the driver for it neither of which
> seem like the end of the world.

Why would you do that?

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.

Re: [linux-sunxi] Re: [PATCH 5/5] RFC spi: sun4i: add DMA support

[Michal Suchanek]

On 2 June 2016 at 06:42, Priit Laes <pl...@plaes.org> wrote:
> On Wed, 2016-06-01 at 20:00 +0200, Maxime Ripard wrote:
>> Hi,
>>
>> On Mon, May 30, 2016 at 04:50:16PM +0100, Mark Brown wrote:
>> >
>> > On Mon, May 30, 2016 at 05:28:10PM +0200, Michal Suchanek wrote:
>> > >
>> > > On 30 May 2016 at 17:03, Mark Brown <broo...@kernel.org> wrote:
>> > >
>> > > >
>> > > > I really don't think it's worth caring too much about cases
>> > > > where the
>> > > > DMA driver hasn't been compiled in, it's not like SPI is the
>> > > > only thing
>> > >
>> > > It's what the driver did to start with and it was requested to
>> > > fall
>> > > back to non-DMA in the case DMA is not available.
>> > Why?  I really can't see any sensible use case for this that
>> > doesn't
>> > have a better solution available.
>> SPI works just fine without DMA, which might just be considered an
>> (optional) optimisation.
>>
>> We've been using it without DMA for years now, and it was working
>> just
>> fine, and it will work even better with the other patches in this
>> serie. There's no reason to add a hard dependency on something that
>> we
>> don't really need.
>>
>
> Actually it non-DMA case works fine if you don't need SPI transfers
> larger than SUN4I_FIFO_DEPTH - 1, which is 63 bytes.
>
> This was addressed by this patch, but was never applied:
> http://permalink.gmane.org/gmane.linux.kernel.spi.devel/18950

And the code added in that patch will never run unless you

1) use long spi transfers
2) compile in/load SPI without DMA support

There is no reason for doing 2) since we have do DMA support for sunxi.

So that's another code path that needs maintenance and testing and
likely will not get it.

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: [PATCH 5/5] RFC spi: sun4i: add DMA support

[Michal Suchanek]

On 31 May 2016 at 15:27, Mark Brown <broo...@kernel.org> wrote:
> On Tue, May 31, 2016 at 12:44:54PM +0200, Michal Suchanek wrote:
>> On 30 May 2016 at 17:50, Mark Brown <broo...@kernel.org> wrote:
>> > On Mon, May 30, 2016 at 05:28:10PM +0200, Michal Suchanek wrote:
>
>> >> It's what the driver did to start with and it was requested to fall
>> >> back to non-DMA in the case DMA is not available.
>
>> > Why?  I really can't see any sensible use case for this that doesn't
>> > have a better solution available.
>
>> Of course, the solution is to compile in the DMA driver.
>
>> It's been argued that some drivers which use only short transfers will
>> just work.
>
> With nothing else in the system that needs DMA?  It's making the
> performance of the system less reliable for the benefit of a very narrow
> use case.

Some of the platform devices have dedicated DMA *controller* built
into the device IP so the DMA engine really is optional on many sunxi
devices. Besides SPI you definitely need the DMA engine for audio. You
probably don't need it for storage and graphics. I don't have any idea
if it's used for USB and Ethernet.

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.

Re: [linux-sunxi] [PATCH 1/5] spi: sunxi: fix transfer timeout

[Michal Suchanek]

Hello

On 30 May 2016 at 13:23, Mark Brown <broo...@kernel.org> wrote:
> On Fri, May 27, 2016 at 03:10:11PM +1000, Julian Calaby wrote:
>> On Fri, May 27, 2016 at 3:05 PM, Michal Suchanek <hramr...@gmail.com> wrote:
>
>> >> Also, should the changes for the drivers be in two separate patches also?
>
>> > That's basically the same driver with different constants so I guess not.
>
>> Fair enough, I withdraw my comment then.
>
> If it's the same driver with different constants it should really
> actually be the same driver - I did ask this when the drivers were
> originally merged...

There are some slight differences and the constants really are
different for each driver.

You would need a register remap adaptation layer and a few qirks for
each revision of the driver.

It's certainly possible to merge them but I am not sure if that gives
easier to maintain code.

On the other hand, comparing the drivers there is different comment
anout clock calculation arithmetic and the code is the same :S

Thanks

Michal

--- spi-sun4i.c2016-05-31 13:19:27.076510421 +0200
+++ spi-sun6i.c2016-05-31 13:26:58.123580382 +0200
@@ -19,65 +19,72 @@
 #include 
 #include 
 #include 
+#include 

 #include 

-#define SUNXI_FIFO_DEPTH64
+#define SUNXI_FIFO_DEPTH128

-#define SUNXI_RXDATA_REG0x00
+#define SUNXI_TXDATA_REG0x200

-#define SUNXI_TXDATA_REG0x04
+#define SUNXI_RXDATA_REG0x300

 #define SUNXI_TFR_CTL_REG0x08
-#define SUNXI_TFR_CTL_ENABLEBIT(0)
-#define SUNXI_TFR_CTL_MASTERBIT(1)
-#define SUNXI_TFR_CTL_CPHABIT(2)
-#define SUNXI_TFR_CTL_CPOLBIT(3)
-#define SUNXI_TFR_CTL_CS_ACTIVE_LOWBIT(4)
-#define SUNXI_TFR_CTL_LMTFBIT(6)
-#define SUNXI_TFR_CTL_TF_RSTBIT(8)
-#define SUNXI_TFR_CTL_RF_RSTBIT(9)
-#define SUNXI_TFR_CTL_XCHBIT(10)
-#define SUNXI_TFR_CTL_CS_MASK0x3000
-#define SUNXI_TFR_CTL_CS(cs)(((cs) << 12) & SUNXI_TFR_CTL_CS_MASK)
-#define SUNXI_TFR_CTL_DHBBIT(15)
-#define SUNXI_TFR_CTL_CS_MANUALBIT(16)
-#define SUNXI_TFR_CTL_CS_LEVELBIT(17)
-#define SUNXI_TFR_CTL_TPBIT(18)
+#define SUNXI_TFR_CTL_CPHABIT(0)
+#define SUNXI_TFR_CTL_CPOLBIT(1)
+#define SUNXI_TFR_CTL_SPOLBIT(2)
+#define SUNXI_TFR_CTL_CS_MASK0x30
+#define SUNXI_TFR_CTL_CS(cs)(((cs) << 4) & SUNXI_TFR_CTL_CS_MASK)
+#define SUNXI_TFR_CTL_CS_MANUALBIT(6)
+#define SUNXI_TFR_CTL_CS_LEVELBIT(7)
+#define SUNXI_TFR_CTL_DHBBIT(8)
+#define SUNXI_TFR_CTL_FBSBIT(12)
+#define SUNXI_TFR_CTL_XCHBIT(31)

-#define SUNXI_INT_CTL_REG0x0c
-#define SUNXI_INT_CTL_TCBIT(16)
+#define SUNXI_INT_CTL_REG0x10
+#define SUNXI_INT_CTL_RF_OVFBIT(8)
+#define SUNXI_INT_CTL_TCBIT(12)

-#define SUNXI_INT_STA_REG0x10
+#define SUNXI_INT_STA_REG0x14

-#define SUNXI_DMA_CTL_REG0x14
+#define SUNXI_FIFO_CTL_REG0x18
+#define SUNXI_FIFO_CTL_RF_RSTBIT(15)
+#define SUNXI_FIFO_CTL_TF_RSTBIT(31)

-#define SUNXI_CLK_CTL_REG0x1c
+#define SUNXI_CLK_CTL_REG0x24
 #define SUNXI_CLK_CTL_CDR2_MASK0xff
 #define SUNXI_CLK_CTL_CDR2(div)(((div) &
SUNXI_CLK_CTL_CDR2_MASK) << 0)
 #define SUNXI_CLK_CTL_CDR1_MASK0xf
 #define SUNXI_CLK_CTL_CDR1(div)(((div) &
SUNXI_CLK_CTL_CDR1_MASK) << 8)
 #define SUNXI_CLK_CTL_DRSBIT(12)

-#define SUNXI_BURST_CNT_REG0x20
+#define SUNXI_BURST_CNT_REG0x30
 #define SUNXI_BURST_CNT(cnt)((cnt) & 0xff)

-#define SUNXI_XMIT_CNT_REG0x24
+#define SUNXI_XMIT_CNT_REG0x34
 #define SUNXI_XMIT_CNT(cnt)((cnt) & 0xff)

-#define SUNXI_FIFO_STA_REG0x28
+#define SUNXI_FIFO_STA_REG0x1c
 #define SUNXI_FIFO_STA_RF_CNT_MASK0x7f
 #define SUNXI_FIFO_STA_RF_CNT_BITS0
 #define SUNXI_FIFO_STA_TF_CNT_MASK0x7f
 #define SUNXI_FIFO_STA_TF_CNT_BITS16

-#define SUNXI_WAIT_REG0x18
+#define SUNXI_BURST_CTL_CNT_REG0x38
+#define SUNXI_BURST_CTL_CNT_STC(cnt)((cnt) & 0xff)
+
+#define SUNXI_GBL_CTL_REG0x04
+#define SUNXI_GBL_CTL_BUS_ENABLEBIT(0)
+#define SUNXI_GBL_CTL_MASTERBIT(1)
+#define SUNXI_GBL_CTL_TPBIT(7)
+#define SUNXI_GBL_CTL_RSTBIT(31)

 struct sunxi_spi {
 struct spi_master*master;
 void __iomem*base_addr;
 struct clk*hclk;
 struct clk*mclk;
+struct reset_control*rstc;

 struct completiondone;

@@ -136,37 +14

[linux-sunxi] Re: [PATCH 5/5] RFC spi: sun4i: add DMA support

[Michal Suchanek]

On 30 May 2016 at 17:50, Mark Brown <broo...@kernel.org> wrote:
> On Mon, May 30, 2016 at 05:28:10PM +0200, Michal Suchanek wrote:
>> On 30 May 2016 at 17:03, Mark Brown <broo...@kernel.org> wrote:
>
>> > I really don't think it's worth caring too much about cases where the
>> > DMA driver hasn't been compiled in, it's not like SPI is the only thing
>
>> It's what the driver did to start with and it was requested to fall
>> back to non-DMA in the case DMA is not available.
>
> Why?  I really can't see any sensible use case for this that doesn't
> have a better solution available.

Of course, the solution is to compile in the DMA driver.

It's been argued that some drivers which use only short transfers will
just work.

>
>> It's possible to add a parameter like require_dma which could be used
>> to load the driver without dma if unset. If it was set by default then
>> driver ordering is not important so long as dma driver is loaded
>> eventually. Also an informative print that such parameter exists when
>> probing the driver is deferred would be helpful. It would probably
>> create quite a bit of log spam, however. The driver can be deferred
>> several times during boot.
>
> That seems fairly hacky, if we were going to do anything like that it
> should be the other way around so that we default to trying to use
> resources and even then it seems like something that should be handled
> at a framework level rather than having random options in individual
> drivers to ignore things.  Having things behave inconsistently between
> different drivers is going to lead to a worse user experience and if
> this is a good idea for one driver it seems like it'd be a good idea for
> all of them.

Hacky but doable if desirable. It's awesome for testing SPI transfer
fragmentation with different drivers ;-)

The previous discussion of this driver is here
http://thread.gmane.org/gmane.linux.kernel/2162327

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: [PATCH 5/5] RFC spi: sun4i: add DMA support

[Michal Suchanek]

Hello,

On 30 May 2016 at 17:03, Mark Brown <broo...@kernel.org> wrote:
> On Mon, May 30, 2016 at 02:11:51PM +0200, Geert Uytterhoeven wrote:
>> On Mon, May 30, 2016 at 1:26 PM, Mark Brown <broo...@kernel.org> wrote:
>> > On Thu, May 26, 2016 at 07:25:25PM -, Michal Suchanek wrote:
>> >>  - fallback to previous behaviour when DMA initialization fails
>> >>
>> >>+ this has the problem that when the driver happens to load before the 
>> >> dma
>> >>  driver it will not use dma - can be addressed with a module parameter
>
>> > No, you should pay attention to the error you are getting and let probe
>> > deferral happen if that's the error you get.
>
>> Unfortunately DMA is an optional feature.
>
>> There's no way to distinguish between -EPROBE_DEFER due to the SPI master
>> driver being probed before the DMA engine driver, and -EPROBE_DEFER due to
>> support for the DMA engine not having been compiled in.
>
> I really don't think it's worth caring too much about cases where the
> DMA driver hasn't been compiled in, it's not like SPI is the only thing
> that's going to be using it.  I really think it's better to defer the
> problem - not getting DMA (or worse, only getting DMA on some boots) is
> not great and if people are optimising on that level my feeling is that
> they're probably going to be OK with customizing DT to match.  Ideally
> we would have something a bit nicer than deferred probe but right now
> this seems the more helpful option.

It's what the driver did to start with and it was requested to fall
back to non-DMA in the case DMA is not available.

We get to the much discussed problem that it's never possible to tell
if a driver is available or not.

It's possible to add a parameter like require_dma which could be used
to load the driver without dma if unset. If it was set by default then
driver ordering is not important so long as dma driver is loaded
eventually. Also an informative print that such parameter exists when
probing the driver is deferred would be helpful. It would probably
create quite a bit of log spam, however. The driver can be deferred
several times during boot.

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: [PATCH 3/5] spi: sunxi: expose maximum transfer size limit

[Michal Suchanek]

Hello,

On 30 May 2016 at 10:37, Maxime Ripard <maxime.rip...@free-electrons.com> wrote:
> On Thu, May 26, 2016 at 07:25:24PM -0000, Michal Suchanek wrote:
>> The sun4i spi hardware can trasfer at most 63 bytes of data without DMA
>> support so report the limitation. Same on sun6i.
>
> Is it? Is there timeouts on the A31 and later SoCs?
>

I have no sun6i hardware to test with.

This is an advisory limit you can query and it better be smaller
rather than unreliable. The hard limit in the driver is still
SUN6I_FIFO_DEPTH (which is 128 bytes on sun6i).

You can test his without any actual SPI device. Unused pins you can
multiplex as SPI suffice.

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.

Re: [linux-sunxi] [PATCH 1/5] spi: sunxi: fix transfer timeout

[Michal Suchanek]

On 27 May 2016 at 04:05, Julian Calaby <julian.cal...@gmail.com> wrote:
> Hi Michal,
>
> On Fri, May 27, 2016 at 5:25 AM, Michal Suchanek <hramr...@gmail.com> wrote:
>> The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over
>> 1MHz SPI bus takes way longer than that. Calculate the timeout from the
>> actual time the transfer is supposed to take and multiply by 2 for good
>> measure.
>>
>> Signed-off-by: Michal Suchanek <hramr...@gmail.com>
>> ---
>>
>> v2:
>> - fix build error
>> - use unsigned instead of int in max_t
>> - use tfr->speed_hz instead of sspi->max_speed_hz
>> ---
>>  drivers/spi/spi-sun4i.c | 11 ++-
>>  drivers/spi/spi-sun6i.c | 11 ++-
>>  2 files changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
>> index 1ddd9e2..fe63bbd 100644
>> --- a/drivers/spi/spi-sun4i.c
>> +++ b/drivers/spi/spi-sun4i.c
>> @@ -173,6 +173,7 @@ static int sun4i_spi_transfer_one(struct spi_master 
>> *master,
>>  {
>> struct sun4i_spi *sspi = spi_master_get_devdata(master);
>> unsigned int mclk_rate, div, timeout;
>> +   unsigned int start, end, tx_time;
>> unsigned int tx_len = 0;
>> int ret = 0;
>> u32 reg;
>> @@ -279,9 +280,17 @@ static int sun4i_spi_transfer_one(struct spi_master 
>> *master,
>> reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
>> sun4i_spi_write(sspi, SUN4I_CTL_REG, reg | SUN4I_CTL_XCH);
>>
>> +   tx_time = max_t(unsigned, tfr->len * 8 * 2 / (tfr->speed_hz / 1000),
>
> You should probably use "unsigned int" instead of just "unsigned" here.
>
>> +   100);

Or just 100U constant and avoid max_t altogether.

>> +   start = jiffies;
>> timeout = wait_for_completion_timeout(>done,
>> - msecs_to_jiffies(1000));
>> + msecs_to_jiffies(tx_time));
>> +   end = jiffies;
>> if (!timeout) {
>> +   dev_warn(>dev,
>> +"%s: timeout transferring %u bytes@%iHz for 
>> %i(%i)ms",
>> +dev_name(>dev), tfr->len, tfr->speed_hz,
>> +jiffies_to_msecs(end - start), tx_time);
>
> Should the debug changes be in a separate patch?

Is this so big of a change that it needs to be split?

>
>> ret = -ETIMEDOUT;
>> goto out;
>> }
>> diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
>> index 42e2c4b..8be5c5c 100644
>> --- a/drivers/spi/spi-sun6i.c
>> +++ b/drivers/spi/spi-sun6i.c
>> @@ -162,6 +162,7 @@ static int sun6i_spi_transfer_one(struct spi_master 
>> *master,
>> unsigned int mclk_rate, div, timeout;
>> unsigned int tx_len = 0;
>> int ret = 0;
>> +   unsigned int start, end, tx_time;
>> u32 reg;
>>
>> /* We don't support transfer larger than the FIFO */
>> @@ -269,9 +270,17 @@ static int sun6i_spi_transfer_one(struct spi_master 
>> *master,
>> reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
>> sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg | SUN6I_TFR_CTL_XCH);
>>
>> +   tx_time = max_t(unsigned, tfr->len * 8 * 2 / (tfr->speed_hz / 1000),
>
> Ditto, "unsigned int" instead of "unsigned"?
>
>> +   100);
>> +   start = jiffies;
>> timeout = wait_for_completion_timeout(>done,
>> - msecs_to_jiffies(1000));
>> + msecs_to_jiffies(tx_time));
>> +   end = jiffies;
>> if (!timeout) {
>> +   dev_warn(>dev,
>> +"%s: timeout transferring %u bytes@%iHz for 
>> %i(%i)ms",
>> +dev_name(>dev), tfr->len, tfr->speed_hz,
>> +jiffies_to_msecs(end - start), tx_time);
>
> Ditto, separate patch?
>
> Also, should the changes for the drivers be in two separate patches also?

That's basically the same driver with different constants so I guess not.

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] [PATCH 4/5] spi: sunxi: set maximum and minimum speed of SPI master

[Michal Suchanek]

The maximum speed of SPI master is used when maximum speed of SPI slave
is not specified. Also the __spi_validate function should check that
transfer speeds do not exceed the master limits.

The user manual for A10 and A31 specifies maximum
speed of the SPI clock as 100MHz and minimum as 3kHz.

Setting the SPI clock to out-of-spec values can lock up the SoC.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---
 drivers/spi/spi-sun4i.c | 2 ++
 drivers/spi/spi-sun6i.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index bf52b09..e1a75dd6 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -405,6 +405,8 @@ static int sun4i_spi_probe(struct platform_device *pdev)
}
 
sspi->master = master;
+   master->max_speed_hz = 100*1000*1000;
+   master->min_speed_hz =3*1000;
master->set_cs = sun4i_spi_set_cs;
master->transfer_one = sun4i_spi_transfer_one;
master->num_chipselect = 4;
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 1952956..0c378ff 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -400,6 +400,8 @@ static int sun6i_spi_probe(struct platform_device *pdev)
}
 
sspi->master = master;
+   master->max_speed_hz = 100*1000*1000;
+   master->min_speed_hz =3*1000;
master->set_cs = sun6i_spi_set_cs;
master->transfer_one = sun6i_spi_transfer_one;
master->num_chipselect = 4;
-- 
2.8.1

-- 
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] [PATCH 0/5] sunxi spi fixes

[Michal Suchanek]

Hello,

This series addresses some issues with sunxi SPI drivers.

The last patch adding DMA support is not completed. It addresses some issues
with the previous version of the patch and it works in practice but some issues
still remain.

Thanks

Michal

Emilio López (1):
  RFC spi: sun4i: add DMA support

Michal Suchanek (4):
  spi: sunxi: fix transfer timeout
  spi: sun4i: fix FIFO limit
  spi: sunxi: expose maximum transfer size limit
  spi: sunxi: set maximum and minimum speed of SPI master

 drivers/spi/spi-sun4i.c | 186 +---
 drivers/spi/spi-sun6i.c |  20 +-
 2 files changed, 194 insertions(+), 12 deletions(-)

-- 
2.8.1

-- 
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] [PATCH 3/3] ARM: dts: sun5i: Add spi2 alias on A10s Olinuxino

[Michal Suchanek]

spi2 is available on the UEXT connector

The bus is named spi2 in the A10s manual and Olinuxino manual so it is
pointless to alias it to something else like spi0.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index 7d2ff60..9729c37 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -58,6 +58,7 @@
serial0 = 
serial1 = 
serial2 = 
+   spi2 = 
};
 
chosen {
-- 
2.8.1

-- 
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] [PATCH 1/5] spi: sunxi: fix transfer timeout

[Michal Suchanek]

The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over
1MHz SPI bus takes way longer than that. Calculate the timeout from the
actual time the transfer is supposed to take and multiply by 2 for good
measure.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---

v2:
- fix build error
- use unsigned instead of int in max_t
- use tfr->speed_hz instead of sspi->max_speed_hz
---
 drivers/spi/spi-sun4i.c | 11 ++-
 drivers/spi/spi-sun6i.c | 11 ++-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index 1ddd9e2..fe63bbd 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -173,6 +173,7 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
 {
struct sun4i_spi *sspi = spi_master_get_devdata(master);
unsigned int mclk_rate, div, timeout;
+   unsigned int start, end, tx_time;
unsigned int tx_len = 0;
int ret = 0;
u32 reg;
@@ -279,9 +280,17 @@ static int sun4i_spi_transfer_one(struct spi_master 
*master,
reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
sun4i_spi_write(sspi, SUN4I_CTL_REG, reg | SUN4I_CTL_XCH);
 
+   tx_time = max_t(unsigned, tfr->len * 8 * 2 / (tfr->speed_hz / 1000),
+   100);
+   start = jiffies;
timeout = wait_for_completion_timeout(>done,
- msecs_to_jiffies(1000));
+ msecs_to_jiffies(tx_time));
+   end = jiffies;
if (!timeout) {
+   dev_warn(>dev,
+"%s: timeout transferring %u bytes@%iHz for %i(%i)ms",
+dev_name(>dev), tfr->len, tfr->speed_hz,
+jiffies_to_msecs(end - start), tx_time);
ret = -ETIMEDOUT;
goto out;
}
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 42e2c4b..8be5c5c 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -162,6 +162,7 @@ static int sun6i_spi_transfer_one(struct spi_master *master,
unsigned int mclk_rate, div, timeout;
unsigned int tx_len = 0;
int ret = 0;
+   unsigned int start, end, tx_time;
u32 reg;
 
/* We don't support transfer larger than the FIFO */
@@ -269,9 +270,17 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg | SUN6I_TFR_CTL_XCH);
 
+   tx_time = max_t(unsigned, tfr->len * 8 * 2 / (tfr->speed_hz / 1000),
+   100);
+   start = jiffies;
timeout = wait_for_completion_timeout(>done,
- msecs_to_jiffies(1000));
+ msecs_to_jiffies(tx_time));
+   end = jiffies;
if (!timeout) {
+   dev_warn(>dev,
+"%s: timeout transferring %u bytes@%iHz for %i(%i)ms",
+dev_name(>dev), tfr->len, tfr->speed_hz,
+jiffies_to_msecs(end - start), tx_time);
ret = -ETIMEDOUT;
goto out;
}
-- 
2.8.1

-- 
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] [PATCH 3/5] spi: sunxi: expose maximum transfer size limit

[Michal Suchanek]

The sun4i spi hardware can trasfer at most 63 bytes of data without DMA
support so report the limitation. Same on sun6i.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---
 drivers/spi/spi-sun4i.c | 6 ++
 drivers/spi/spi-sun6i.c | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index 04f1b77..bf52b09 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -167,6 +167,11 @@ static void sun4i_spi_set_cs(struct spi_device *spi, bool 
enable)
sun4i_spi_write(sspi, SUN4I_CTL_REG, reg);
 }
 
+static size_t sun4i_spi_max_transfer_size(struct spi_device *spi)
+{
+   return SUN4I_FIFO_DEPTH - 1;
+}
+
 static int sun4i_spi_transfer_one(struct spi_master *master,
  struct spi_device *spi,
  struct spi_transfer *tfr)
@@ -407,6 +412,7 @@ static int sun4i_spi_probe(struct platform_device *pdev)
master->bits_per_word_mask = SPI_BPW_MASK(8);
master->dev.of_node = pdev->dev.of_node;
master->auto_runtime_pm = true;
+   master->max_transfer_size = sun4i_spi_max_transfer_size;
 
sspi->hclk = devm_clk_get(>dev, "ahb");
if (IS_ERR(sspi->hclk)) {
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 8954a62..f491a41 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -154,6 +154,11 @@ static void sun6i_spi_set_cs(struct spi_device *spi, bool 
enable)
 }
 
 
+static size_t sun6i_spi_max_transfer_size(struct spi_device *spi)
+{
+   return SUN6I_FIFO_DEPTH - 1;
+}
+
 static int sun6i_spi_transfer_one(struct spi_master *master,
  struct spi_device *spi,
  struct spi_transfer *tfr)
@@ -418,6 +423,7 @@ static int sun6i_spi_probe(struct platform_device *pdev)
master->bits_per_word_mask = SPI_BPW_MASK(8);
master->dev.of_node = pdev->dev.of_node;
master->auto_runtime_pm = true;
+   master->max_transfer_size = sun6i_spi_max_transfer_size;
 
sspi->hclk = devm_clk_get(>dev, "ahb");
if (IS_ERR(sspi->hclk)) {
-- 
2.8.1

-- 
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] [PATCH 2/5] spi: sun4i: fix FIFO limit

[Michal Suchanek]

When testing SPI without DMA I noticed that filling the FIFO on the
spi controller causes timeout.

Always leave room for one byte in the FIFO.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>

---
v2:
use EMSGSIZE instead of EINVAL
---
 drivers/spi/spi-sun4i.c | 8 ++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index fe63bbd..04f1b77 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -180,7 +180,9 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
 
/* We don't support transfer larger than the FIFO */
if (tfr->len > SUN4I_FIFO_DEPTH)
-   return -EINVAL;
+   return -EMSGSIZE;
+   if (tfr->tx_buf && tfr->len >= SUN4I_FIFO_DEPTH)
+   return -EMSGSIZE;
 
reinit_completion(>done);
sspi->tx_buf = tfr->tx_buf;
@@ -271,7 +273,9 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
sun4i_spi_write(sspi, SUN4I_XMIT_CNT_REG, SUN4I_XMIT_CNT(tx_len));
 
/* Fill the TX FIFO */
-   sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH);
+   /* Filling the FIFO fully causes timeout for some reason
+* at least on spi2 on A10s */
+   sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH - 1);
 
/* Enable the interrupts */
sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, SUN4I_INT_CTL_TC);

-- 
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] [PATCH 5/5] RFC spi: sun4i: add DMA support

[Michal Suchanek]

From: Emilio López <emi...@elopez.com.ar>

This patch adds support for 64 byte or bigger transfers on the
sun4i SPI controller. Said transfers will be performed via DMA.

Signed-off-by: Emilio López <emi...@elopez.com.ar>
Signed-off-by: Michal Suchanek <hramr...@gmail.com>

---
v2:
 - fallback to previous behaviour when DMA initialization fails

   + this has the problem that when the driver happens to load before the dma
 driver it will not use dma - can be addressed with a module parameter
 + the issue with dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL; ...
   dma_wait_for_async_tx(desc_rx); remains unaddressed

---
 drivers/spi/spi-sun4i.c | 171 
 1 file changed, 158 insertions(+), 13 deletions(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index e1a75dd6..ed2269c 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -34,6 +36,7 @@
 #define SUN4I_CTL_CPHA BIT(2)
 #define SUN4I_CTL_CPOL BIT(3)
 #define SUN4I_CTL_CS_ACTIVE_LOWBIT(4)
+#define SUN4I_CTL_DMAMC_DEDICATED  BIT(5)
 #define SUN4I_CTL_LMTF BIT(6)
 #define SUN4I_CTL_TF_RST   BIT(8)
 #define SUN4I_CTL_RF_RST   BIT(9)
@@ -51,6 +54,8 @@
 #define SUN4I_INT_STA_REG  0x10
 
 #define SUN4I_DMA_CTL_REG  0x14
+#define SUN4I_DMA_CTL_RF_READY BIT(0)
+#define SUN4I_DMA_CTL_TF_NOT_FULL  BIT(10)
 
 #define SUN4I_WAIT_REG 0x18
 
@@ -130,6 +135,13 @@ static inline void sun4i_spi_fill_fifo(struct sun4i_spi 
*sspi, int len)
}
 }
 
+static bool sun4i_spi_can_dma(struct spi_master *master,
+ struct spi_device *spi,
+ struct spi_transfer *tfr)
+{
+   return tfr->len >= SUN4I_FIFO_DEPTH;
+}
+
 static void sun4i_spi_set_cs(struct spi_device *spi, bool enable)
 {
struct sun4i_spi *sspi = spi_master_get_devdata(spi->master);
@@ -177,17 +189,20 @@ static int sun4i_spi_transfer_one(struct spi_master 
*master,
  struct spi_transfer *tfr)
 {
struct sun4i_spi *sspi = spi_master_get_devdata(master);
+   struct dma_async_tx_descriptor *desc_tx = NULL, *desc_rx = NULL;
unsigned int mclk_rate, div, timeout;
unsigned int start, end, tx_time;
unsigned int tx_len = 0;
+   u32 reg, trigger = 0;
int ret = 0;
-   u32 reg;
 
-   /* We don't support transfer larger than the FIFO */
-   if (tfr->len > SUN4I_FIFO_DEPTH)
-   return -EMSGSIZE;
-   if (tfr->tx_buf && tfr->len >= SUN4I_FIFO_DEPTH)
-   return -EMSGSIZE;
+   if (!master->can_dma) {
+   /* We don't support transfer larger than the FIFO */
+   if (tfr->len > SUN4I_FIFO_DEPTH)
+   return -EMSGSIZE;
+   if (tfr->tx_buf && tfr->len >= SUN4I_FIFO_DEPTH)
+   return -EMSGSIZE;
+   }
 
reinit_completion(>done);
sspi->tx_buf = tfr->tx_buf;
@@ -277,14 +292,67 @@ static int sun4i_spi_transfer_one(struct spi_master 
*master,
sun4i_spi_write(sspi, SUN4I_BURST_CNT_REG, SUN4I_BURST_CNT(tfr->len));
sun4i_spi_write(sspi, SUN4I_XMIT_CNT_REG, SUN4I_XMIT_CNT(tx_len));
 
-   /* Fill the TX FIFO */
-   /* Filling the FIFO fully causes timeout for some reason
-* at least on spi2 on A10s */
-   sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH - 1);
-
/* Enable the interrupts */
sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, SUN4I_INT_CTL_TC);
 
+   if (sun4i_spi_can_dma(master, spi, tfr)) {
+   dev_dbg(>master->dev, "Using DMA mode for transfer\n");
+
+   if (sspi->tx_buf) {
+   desc_tx = dmaengine_prep_slave_sg(master->dma_tx,
+   tfr->tx_sg.sgl, tfr->tx_sg.nents,
+   DMA_TO_DEVICE,
+   DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   if (!desc_tx) {
+   dev_err(>master->dev,
+   "Couldn't prepare dma slave\n");
+   return -EIO;
+   }
+
+   trigger |= SUN4I_DMA_CTL_TF_NOT_FULL;
+
+   dmaengine_submit(desc_tx);
+   dma_async_issue_pending(master->dma_tx);
+
+   }
+
+   if (sspi->rx_buf) {
+   desc_rx = dmaengine_prep_slave_sg(master->dma_rx,
+   tfr->

[linux-sunxi] [PATCH 2/3] ARM: dts: sun5i: add spi2 on A10s Olinuxino Micro

[Michal Suchanek]

spi2 is available on the UEXT connector

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index 86d046a..7d2ff60 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -192,6 +192,13 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>,
+   <_cs0_pins_a>;
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.8.1

-- 
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] [PATCH] usb: select NOP_USB_XCEIV by drivers that require it

[Michal Suchanek]

Hello,

I was updating my config by make oldconfig for a while and noticed that my USB
OTG controller is not working. Apparently it grew dependency on NOP_USB_XCEIV
over time.

Looking through defconfigs some have it included and some which seem in need of
it don't.

Since the dependency is not obvious I think it would be better to select it
where possible.

Attaching a patch.

Thanks

Michal

8<--
NOP_USB_XCEIV is non-obvious dependency for MUSB and other drivers.

This is a virtual driver in the sense that there is no actual piece of
hardware you can point at and say you did not include driver for this so
it won't work.

So just change all depends on it to select.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---
 drivers/usb/chipidea/Kconfig |  3 ++-
 drivers/usb/musb/Kconfig | 19 +--
 drivers/usb/phy/Kconfig  |  2 ++
 3 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index 3644a35..8d08ebd 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -19,7 +19,8 @@ config USB_CHIPIDEA_OF
 config USB_CHIPIDEA_PCI
tristate
depends on PCI
-   depends on NOP_USB_XCEIV
+   select NOP_USB_XCEIV
+   select USB_PHY
default USB_CHIPIDEA
 
 config USB_CHIPIDEA_UDC
diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 886526b..91717b9 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -66,7 +66,8 @@ comment "Platform Glue Layer"
 config USB_MUSB_SUNXI
tristate "Allwinner (sunxi)"
depends on ARCH_SUNXI
-   depends on NOP_USB_XCEIV
+   select NOP_USB_XCEIV
+   select USB_PHY
depends on PHY_SUN4I_USB
depends on EXTCON
depends on GENERIC_PHY
@@ -75,13 +76,15 @@ config USB_MUSB_SUNXI
 config USB_MUSB_DAVINCI
tristate "DaVinci"
depends on ARCH_DAVINCI_DMx
-   depends on NOP_USB_XCEIV
+   select NOP_USB_XCEIV
+   select USB_PHY
depends on BROKEN
 
 config USB_MUSB_DA8XX
tristate "DA8xx/OMAP-L1x"
depends on ARCH_DAVINCI_DA8XX
-   depends on NOP_USB_XCEIV
+   select NOP_USB_XCEIV
+   select USB_PHY
depends on BROKEN
 
 config USB_MUSB_TUSB6010
@@ -89,6 +92,7 @@ config USB_MUSB_TUSB6010
depends on HAS_IOMEM
depends on ARCH_OMAP2PLUS || COMPILE_TEST
depends on NOP_USB_XCEIV = USB_MUSB_HDRC # both built-in or both modules
+   # cannot select NOP_USB_XCEIV because of the dependency above
 
 config USB_MUSB_OMAP2PLUS
tristate "OMAP2430 and onwards"
@@ -99,7 +103,8 @@ config USB_MUSB_OMAP2PLUS
 config USB_MUSB_AM35X
tristate "AM35x"
depends on ARCH_OMAP
-   depends on NOP_USB_XCEIV
+   select NOP_USB_XCEIV
+   select USB_PHY
 
 config USB_MUSB_DSPS
tristate "TI DSPS platforms"
@@ -110,7 +115,8 @@ config USB_MUSB_DSPS
 config USB_MUSB_BLACKFIN
tristate "Blackfin"
depends on (BF54x && !BF544) || (BF52x && ! BF522 && !BF523)
-   depends on NOP_USB_XCEIV
+   select NOP_USB_XCEIV
+   select USB_PHY
 
 config USB_MUSB_UX500
tristate "Ux500 platforms"
@@ -118,7 +124,8 @@ config USB_MUSB_UX500
 
 config USB_MUSB_JZ4740
tristate "JZ4740"
-   depends on NOP_USB_XCEIV
+   select NOP_USB_XCEIV
+   select USB_PHY
depends on MACH_JZ4740 || COMPILE_TEST
depends on USB_MUSB_GADGET
depends on USB_OTG_BLACKLIST_HUB
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index c690474..a0bdfd3 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -57,6 +57,8 @@ config NOP_USB_XCEIV
  built-in with usb ip or which are autonomous and doesn't require any
  phy programming such as ISP1x04 etc.
 
+ Should be automatically selected by the relevant driver.
+
 config AM335X_CONTROL_USB
tristate
 
-- 
2.8.1

-- 
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] [PATCH 1/3] ARM: dts: sun5i: a10s: add spi2 pins

[Michal Suchanek]

Used on A10s Olinuxino.

Signed-off-by: Michal Suchanek <hramr...@gmail.com>
---
 arch/arm/boot/dts/sun5i-a10s.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index bddd0de..651837c 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -241,6 +241,20 @@
allwinner,drive = ;
allwinner,pull = ;
};
+
+   spi2_pins_a: spi2@0 {
+   allwinner,pins = "PB12", "PB13", "PB14";
+   allwinner,function = "spi2";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   spi2_cs0_pins_a: spi2_cs0@0 {
+   allwinner,pins = "PB11";
+   allwinner,function = "spi2";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
 };
 
 _a {
-- 
2.8.1

-- 
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] A20 NAND BAD block issue

[Michal Suchanek]

Hello,

On 24 May 2016 at 11:29, Zaahir Khan  wrote:
>
> Hi All,
>
>  We are using customized A20 based on Cubie2 Board. Android 4.2.2 Source
> from third party "a20_sdk30".
>
>  Using SK Hynix NAND  H27UCG8T2BTR 8GB.
>
> Board was not booting up, so when tried to re-flash using Livesuite could
> find the large number of Bad block, livesuite serial log snip below.
...
>
> Noticed that when frequently using h/w reset(100-500 times) there is rise in
> Bad Block count.

That's definitely not good for the nand. Losing power during write
should not cause permanent damage beyond normal wear but it can
corrupt the filesystem and cause it to detect blocks as bad or create
random bit patterns looking like whatever the Allwinner driver uses as
bad block markers.

If you see corruption there is some problem with the reset although
the board itself does not lose power. Maybe the nand loses power/is
reset early during the boot sequence.

>
> Need some help to resolve this issue.

Use a SD card. It can be replaced when it wears down. It uses it's own
internal wear levelling. It may even be faster if you get a decent
quality one.

Another alternative is to net-boot or attach some additional storage
if you need the SD slot for your application.

Note that using the nand read-only for booting and then loading the
system from other storage not supported by the SoC bootloader is ok.
Writing to it causes problems.

>
> What can be the possible reason for rise in Bad block?
>
> For testing purpose modified the Boot1 code with NAND_EraseChip() API call,
> could find reduction in bad block count when using LiveSuit next time. So my
> guess is these Bad Block count is not the actual one.
>
> Is it possible to clear bad block?

You can overwrite the markers and cause the bad blocks to be
re-detected during normal use. You also lose erase counts (hopefully
the Allwinner code has some) so that's not awesome either.

HTH

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.

Re: [linux-sunxi] Stability problems on A20 (lime2)

[Michal Suchanek]

On 24 May 2016 at 11:27, Olliver Schinagl <oli...@schinagl.nl> wrote:
> Hey Michal,
>
> On 24-05-16 11:21, Michal Suchanek wrote:
>>
>> Hello,
>>

>> 1) built new kernel. locked up by running a spidev test program
>
> ironically, i do have the spidev module loaded, but i don't think it does
> much as it is the older version that refuses to load?

It does nothing unless you open the device and perform an ioctl on it.

>>
>> 2) found that commit that propagates speed setting from the spidev
>> ioctl causes the lockup
>> 3) found that due to a calculation error the spidev test program
>> requests 1GHz spi speed  - this was previously ignored but now the spi
>> driver attempted to set it on the spi clock
>> 4) shortly after attempt to program the 1GHz spi speed (resulting in
>> actual 432MHz or so) board locks up - serial and networking
>> unresponsive
>
> So you suggest that clocks are not properly set everywhere in the stack?

Everything appears set properly in this scenario as far as debug
prints show before the board locks up. It's just the 100MHz limit on
spi clock from the A10 manual is not set anywhere and apparently the
SoC does not like the out-of-spec speed there for some reason.

>>
>>
>> So this clearly shows that not all limits of clocks (at the very
>> least) are known and it may take userspace action *and* kernel
>> responding to the action to trigger an issue.
>>
>> I have no idea about a20, though. I recently use mostly the Olinuxino
>> due to the 2.54mm headers which make connecting hardware easy.
>
> that is true, so you use olinuxino a10 then? (there are olinuxino's a20's
> :p)

It's the A10s one :)

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.

Re: [linux-sunxi] Stability problems on A20 (lime2)

[Michal Suchanek]

Hello,

On 24 May 2016 at 10:09, Olliver Schinagl  wrote:

> The weirdest thing happend last week however, when in the course of 5 days,
> first 8 and then 15 lime2's all crashed within seconds of each-other. Like
> clockwork.
>
> Talking to Olimex, that say they had a 'similar' issue and said it may have
> started with 3.4.103. Mainline kernel is also said to suffer from this. What
> surprised me was that they said they had no problems with wheezy, but it
> started with jessie. So a combination of kernel + userspace? (systemd?)
>
> So first my question is, has anybody noticed this (even on other boards) or
> am I after old facts and has this already been solved? Is it somewhat
> reproducible (I have not found a method yet)? And if I even could reproduce
> it, how would I figure out on what causes it.
>

I saw somewhat similar problem when testing spi-nor on A10s Olinuxino.
Here the problem was reproducible reliably so I can say it went like
this

1) built new kernel. locked up by running a spidev test program
2) found that commit that propagates speed setting from the spidev
ioctl causes the lockup
3) found that due to a calculation error the spidev test program
requests 1GHz spi speed  - this was previously ignored but now the spi
driver attempted to set it on the spi clock
4) shortly after attempt to program the 1GHz spi speed (resulting in
actual 432MHz or so) board locks up - serial and networking
unresponsive

So this clearly shows that not all limits of clocks (at the very
least) are known and it may take userspace action *and* kernel
responding to the action to trigger an issue.

I have no idea about a20, though. I recently use mostly the Olinuxino
due to the 2.54mm headers which make connecting hardware easy.

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: sunxi spi clock problem

[Michal Suchanek]

On 22 May 2016 at 18:41, Michal Suchanek <hramr...@gmail.com> wrote:
> Hello,
>
> The debugfs output shows that spi2 is reparented under pll5 and the
> pll5 frequency remains unchanged.
>
> The request to get a 2GHz clock for spi is fulfilled on best-effort
> basis by giving the 864MHz pll5 clock which should theoretically
> result in 432MHz SPI clock.
>
> On 22 May 2016 at 16:58, Chen-Yu Tsai <w...@csie.org> wrote:
>> Hi,
>>
>> On Sun, May 22, 2016 at 10:18 PM, Michal Suchanek <hramr...@gmail.com> wrote:
>>> Hello,
>>>
>>> I tried running a spidev test program on linux 4.6 and I uncovered a
>>> problem with the sunxi clk framework.
>>>
>>> Basically the system would lock up after running the test program.
>>>
>>> Digging deeper I found that it locks up with commit
>>> [47284e3e0f3c427c93f8583549b6c938e8a18015] spi: sun4i: allow transfers
>>> to set transmission speed
>>>
>>> This exposes a problem with the test program. I try to set the SPI
>>> sped to 1MHz but at other place the speed is multiplied by 1000 to
>>> save typing zeros so the actual requested speed is 1GHz. This commit
>>> probably allows that request to propagate leading to the observed
>>> system lockup.
>>>
>>> Given the parents OSC24M, pll6 and pll5 one of pll6 and pll5 is
>>> probably set up at 2GHz (or both in turn because due to some rounding
>>> neither goes fully up to 2GHz resulting in 86400 SPI clock). Then
>>> the system locks up.
>>
>> IIRC the mod clock does not propagate rate changes up the tree.
>> But some output from the debugfs would be helpful. See below.
>>
>>>
>>> I can limit the speed in the SPI driver which is rated at 100MHz in
>>> SoC manual (giving 200MHz pll) but the clk driver should probably
>>> limit the clock setting to sane speeds itself.
>>>
>>> I am not familiar with the sunxi-clk code and it has unfortunately no
>>> debug prints which would show what is programmed to what speed.
>>
>> You can use /sys/kernel/debug/clk/clk_summary, provided you have
>> debugfs built in and mounted.
>
> root@a10s:~/spidisp# ./spitest -d -s 100 /dev/spidev2.0
> Debug mode.
> /dev/spidev2.0: spi mode 0x0, 8 bits per word, 10 Hz max
> Sending 00
>clock enable_cnt  prepare_cntrate
> accuracy   phase
> 
>  osc32k   00   32768
>0 0
>  osc24M   662400
>0 0
> ir0   002400
>0 0
> spi2  002400
>0 0
> spi1  002400
>0 0
> spi0  002400
>0 0
> ...
> spi_master spi2: spi2.0: timeout transferring 1 bytes@10Hz for
> 100(100)ms
> spidev spi2.0: SPI transfer failed: -110
> spi_master spi2: failed to transfer one message from queue
> ...
> pll5  11   86400
>0 0
>pll5_other 00   86400
>0 0
>pll5_ddr   11   43200
>0 0
> ...
> xfer: Connection timed out
> buffer size: 1, result -110
> buffer size: 1, result -110, Connection timed out
> Sending
>clock enable_cnt  prepare_cntrate
> accuracy   phase
> 
>  osc32k   00   32768
>0 0
>  osc24M   662400
>0 0
> ir0   002400
>0 0
> spi1  002400
>0 0
> spi0  002400
>0 0
> ss002400
>0 0
> ...
> pll5  11   86400
>0 0
>pll5_other 00   86400
>0 0
>   spi200   86400
>0 0
>pll5_ddr   11   4320

[linux-sunxi] Re: sunxi spi clock problem

[Michal Suchanek]

Hello,

The debugfs output shows that spi2 is reparented under pll5 and the
pll5 frequency remains unchanged.

The request to get a 2GHz clock for spi is fulfilled on best-effort
basis by giving the 864MHz pll5 clock which should theoretically
result in 432MHz SPI clock.

On 22 May 2016 at 16:58, Chen-Yu Tsai <w...@csie.org> wrote:
> Hi,
>
> On Sun, May 22, 2016 at 10:18 PM, Michal Suchanek <hramr...@gmail.com> wrote:
>> Hello,
>>
>> I tried running a spidev test program on linux 4.6 and I uncovered a
>> problem with the sunxi clk framework.
>>
>> Basically the system would lock up after running the test program.
>>
>> Digging deeper I found that it locks up with commit
>> [47284e3e0f3c427c93f8583549b6c938e8a18015] spi: sun4i: allow transfers
>> to set transmission speed
>>
>> This exposes a problem with the test program. I try to set the SPI
>> sped to 1MHz but at other place the speed is multiplied by 1000 to
>> save typing zeros so the actual requested speed is 1GHz. This commit
>> probably allows that request to propagate leading to the observed
>> system lockup.
>>
>> Given the parents OSC24M, pll6 and pll5 one of pll6 and pll5 is
>> probably set up at 2GHz (or both in turn because due to some rounding
>> neither goes fully up to 2GHz resulting in 86400 SPI clock). Then
>> the system locks up.
>
> IIRC the mod clock does not propagate rate changes up the tree.
> But some output from the debugfs would be helpful. See below.
>
>>
>> I can limit the speed in the SPI driver which is rated at 100MHz in
>> SoC manual (giving 200MHz pll) but the clk driver should probably
>> limit the clock setting to sane speeds itself.
>>
>> I am not familiar with the sunxi-clk code and it has unfortunately no
>> debug prints which would show what is programmed to what speed.
>
> You can use /sys/kernel/debug/clk/clk_summary, provided you have
> debugfs built in and mounted.

root@a10s:~/spidisp# ./spitest -d -s 100 /dev/spidev2.0
Debug mode.
/dev/spidev2.0: spi mode 0x0, 8 bits per word, 10 Hz max
Sending 00
   clock enable_cnt  prepare_cntrate
accuracy   phase

 osc32k   00   32768
   0 0
 osc24M   662400
   0 0
ir0   002400
   0 0
spi2  002400
   0 0
spi1  002400
   0 0
spi0  002400
   0 0
...
spi_master spi2: spi2.0: timeout transferring 1 bytes@10Hz for
100(100)ms
spidev spi2.0: SPI transfer failed: -110
spi_master spi2: failed to transfer one message from queue
...
pll5  11   86400
   0 0
   pll5_other 00   86400
   0 0
   pll5_ddr   11   43200
   0 0
...
xfer: Connection timed out
buffer size: 1, result -110
buffer size: 1, result -110, Connection timed out
Sending
   clock enable_cnt  prepare_cntrate
accuracy   phase

 osc32k   00   32768
   0 0
 osc24M   662400
   0 0
ir0   002400
   0 0
spi1  002400
   0 0
spi0  002400
   0 0
ss002400
   0 0
...
pll5  11   86400
   0 0
   pll5_other 00   86400
   0 0
  spi200   86400
   0 0
   pll5_ddr   11   43200
   0 0
...
maximum buffer size: 0
Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
pll5  11   86400
   0 0
   pll5_other 00   86400
   0 0
  spi200   86400
   0 0
   pll5_ddr   11   43200
   0 0
pll4  00   38400
   0 0
pll2-prediv   0

The system locks up here

[linux-sunxi] sunxi spi clock problem

[Michal Suchanek]

Hello,

I tried running a spidev test program on linux 4.6 and I uncovered a
problem with the sunxi clk framework.

Basically the system would lock up after running the test program.

Digging deeper I found that it locks up with commit
[47284e3e0f3c427c93f8583549b6c938e8a18015] spi: sun4i: allow transfers
to set transmission speed

This exposes a problem with the test program. I try to set the SPI
sped to 1MHz but at other place the speed is multiplied by 1000 to
save typing zeros so the actual requested speed is 1GHz. This commit
probably allows that request to propagate leading to the observed
system lockup.

Given the parents OSC24M, pll6 and pll5 one of pll6 and pll5 is
probably set up at 2GHz (or both in turn because due to some rounding
neither goes fully up to 2GHz resulting in 86400 SPI clock). Then
the system locks up.

I can limit the speed in the SPI driver which is rated at 100MHz in
SoC manual (giving 200MHz pll) but the clk driver should probably
limit the clock setting to sane speeds itself.

I am not familiar with the sunxi-clk code and it has unfortunately no
debug prints which would show what is programmed to what speed.

Thanks

Michal

root@a10s:~/spidisp# ./spitest -r 50 -d -s 100 /dev/spidev2.0
Debug mode.
spidev spi2.0: setup mode 0, 8 bits/w, 4000 Hz max --> 0
spidev spi2.0: spi mode 0
spidev spi2.0: setup mode 0, 8 bits/w, 4000 Hz max --> 0
spidev spi2.0: msb first
spidev spi2.0: setup mode 0, 8 bits/w, 4000 Hz max --> 0
spidev spi2.0: 0 bits per word
spidev spi2.0: setup mode 0, 8 bits/w, 10 Hz max --> 0
/dev/spidev2.0: spi mode 0x0, 8 bits per word, 10 Hz maxspidev
spi2.0: mclk spi2 (2400)

Sending 00
spidev spi2.0: mclk spi2 setting rate 20Hz
spidev spi2.0: mclk spi2 (86400)
spidev spi2.0: clkdiv 0 CDR2 0 regval 4096
spi_master spi2: spi2.0: timeout transferring 1 bytes@10Hz for
100(100)ms
spidev spi2.0: SPI transfer failed: -110
spi_master spi2: failed to transfer one message from queue
xfer: Connection timed out
buffer size: 1, result -110
buffer size: 1, result -110, Connection timed out
Sending
maximum buffer size: 0
Using gpio 50.
Writing gpio export 50 to /sys/class/gpio/export.
Reading gpio direction from /sys/class/gpio/gpio50/direction: in

Reading gpio inversion from /sys/class/gpio/gpio50/active_low: 0

Writing gpio direction in to /sys/class/gpio/gpio50/direction.
Reading gpio value from /sys/class/gpio/gpio50/value: 1

Writing gpio direction out to /sys/class/gpio/gpio50/direction.
Writing gpio value 0 to /sys/class/gpio/gpio50/value.
Writing gpio value 1 to /sys/class/gpio/gpio50/value.
Writing gpio value 0 to /sys/class/gpio/gpio50/value.
Writing gpio value 1 to /sys/class/gpio/gpio50/value.
Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
spidev spi2.0: mclk spi2 (86400)
spidev spi2.0: mclk spi2 setting rate 20Hz
spidev spi2.0: mclk spi2 (86400)
spidev spi2.0: clkdiv 0 CDR2 0 regval 4096

-- 
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: [PATCH 4/9] spi: sun4i: add DMA support

[Michal Suchanek]

On 20 August 2015 at 16:56, Maxime Ripard
 wrote:

>> + /* Enable Dedicated DMA requests */
>> + reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
>> + reg |= SUN4I_CTL_DMAMC_DEDICATED;
>> + sun4i_spi_write(sspi, SUN4I_CTL_REG, reg);
>> + sun4i_spi_write(sspi, SUN4I_DMA_CTL_REG, trigger);
>> + } else {
>> + dev_dbg(>master->dev, "Using PIO mode for transfer\n");
>> +
>> + /* Disable DMA requests */
>> + reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
>> + sun4i_spi_write(sspi, SUN4I_CTL_REG,
>> + reg & ~SUN4I_CTL_DMAMC_DEDICATED);
>> + sun4i_spi_write(sspi, SUN4I_DMA_CTL_REG, 0);
>> +
>> + /* Fill the TX FIFO */
>> + /* Filling the fifo fully causes timeout for some reason
>> +  * at least on spi2 on a10s */
>> + sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH - 1);
>> + }
>> +
>>   /* Start the transfer */
>>   reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
>>   sun4i_spi_write(sspi, SUN4I_CTL_REG, reg | SUN4I_CTL_XCH);
>> @@ -303,7 +363,12 @@ static int sun4i_spi_transfer_one(struct spi_master 
>> *master,
>>   goto out;
>>   }
>>
>> - sun4i_spi_drain_fifo(sspi, SUN4I_FIFO_DEPTH);
>> + if (sun4i_spi_can_dma(master, spi, tfr) && desc_rx) {
>> + /* The receive transfer should be the last one to finish */
>> + dma_wait_for_async_tx(desc_rx);
>
> Nope, this is only meant for async_tx. You should register a callback
> in your transfer that will mark the completion structure as completed,
> and then drain the FIFO only if not using DMA.

What exactly is wrong with this?

I did not observe data corruption. Passing desc_rx to
dma_wait_for_async_tx looks odd on closer inspection, though. Will
look through some other spi driver code.

>> - init_completion(>done);
>> + master->dma_tx = dma_request_slave_channel_reason(>dev, "tx");
>> + if (IS_ERR(master->dma_tx)) {
>> + dev_err(>dev, "Unable to acquire DMA channel TX\n");
>> + ret = PTR_ERR(master->dma_tx);
>> + goto err_free_master;
>> + }
>> +
>> + dma_sconfig.direction = DMA_MEM_TO_DEV;
>> + dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
>> + dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
>> + dma_sconfig.dst_addr = res->start + SUN4I_TXDATA_REG;
>> + dma_sconfig.src_maxburst = 1;
>> + dma_sconfig.dst_maxburst = 1;
>> +
>> + ret = dmaengine_slave_config(master->dma_tx, _sconfig);
>> + if (ret) {
>> + dev_err(>dev, "Unable to configure TX DMA slave\n");
>> + goto err_tx_dma_release;
>> + }
>> +
>> + master->dma_rx = dma_request_slave_channel_reason(>dev, "rx");
>> + if (IS_ERR(master->dma_rx)) {
>> + dev_err(>dev, "Unable to acquire DMA channel RX\n");
>> + ret = PTR_ERR(master->dma_rx);
>> + goto err_tx_dma_release;
>> + }
>> +
>> + dma_sconfig.direction = DMA_DEV_TO_MEM;
>> + dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
>> + dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE;
>> + dma_sconfig.src_addr = res->start + SUN4I_RXDATA_REG;
>> + dma_sconfig.src_maxburst = 1;
>> + dma_sconfig.dst_maxburst = 1;
>
> We can't use a higher bust size?

Who actually does?

It accomplishes the transfer with burst size of 1 so that's good enough.

Researching alignment requirements and other oddities of Chinese
controllers when larger burst size is used can be topic for another
patch.


On 20 August 2015 at 20:58, Mark Brown  wrote:
> On Thu, Aug 20, 2015 at 02:19:46PM -, Emilio López wrote:
>
>> - sun4i_spi_drain_fifo(sspi, SUN4I_FIFO_DEPTH);
>> + if (sun4i_spi_can_dma(master, spi, tfr) && desc_rx) {
>> + /* The receive transfer should be the last one to finish */
>> + dma_wait_for_async_tx(desc_rx);
>
> What if it's a transmit only transfer?  We'll fall over to this...
>
>> + } else {
>> + sun4i_spi_drain_fifo(sspi, SUN4I_FIFO_DEPTH);
>> + }
>
> ...which manually reads data from the FIFO which doesn't seem like what
... which should be empty since RX is not enabled.
> we want, won't it conflict with the DMA?
It does not seem to conflict in practice.


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.

Re: [linux-sunxi] All Allwinner kernels rootable with an echo

[Michal Suchanek]

On 10 May 2016 at 10:07, Benjamin Henrion  wrote:
> All Allwinner kernels rootable with an echo:
>
> https://olimex.wordpress.com/2016/05/10/how-to-root-any-allwinner-device-running-android-and-most-of-the-chinese-pi-clones-which-bet-on-allwinner-android-linux-kernel/
>
> Insane!
>

Awesome!

I wish my phone had this :)

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.

Re: [linux-sunxi] [PATCH] musb: sunxi: Ignore VBus errors in host-only mode

[Michal Suchanek]

On 14 September 2015 at 22:25, Maxime Ripard
 wrote:
> On Thu, Sep 10, 2015 at 08:38:38PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 10-09-15 20:30, Maxime Ripard wrote:
>> >On Thu, Sep 10, 2015 at 08:23:23PM +0200, Hans de Goede wrote:
>> >>Hi,
>> >>
>> >>On 04-09-15 08:43, Olliver Schinagl wrote:
>> >>>Hey Hans,
>> >>>
>> >>>On 07-08-15 10:45, Olliver Schinagl wrote:
>> 
>> >If you change the dr_mode to host then you _must_ also remove any 
>> >id_det and vbus_det
>> >gpio settings from the usb_phy node in the dts, as the sun4i phy code 
>> >detects
>> >host vs otg mode by checking for the presence of these.
>> Yes, this fixes it and makes it work. Thanks.
>> 
>> >>>I've been going back to this and am wondering if this is something I can 
>> >>>look into to fix properly? E.g. if the dts sets dr_mode = host, can we 
>> >>>simply ignore the pins and treat them as unset?
>> >>
>> >>AFAIK you cannot unset something in dts. The only solution I
>> >>can comeup with is to add a dr_mode argument to the phy like
>> >>we already have for the otg controller itself.
>> >>
>> >>This is something which we likely need to do anyways to add
>> >>support for peripheral only mode, which we seem to need for
>> >>some "hdmi sticks".
>> >
>> >I haven't really followed the rest of the discussion, so sorry if you
>> >already talked about that, but why can't you just set the dr_mode to
>> >peripheral in such a case?
>>
>> This is about the usbphy code not the musb-controller code, which are
>> 2 different dts nodes, atm only the musb-controller node has a
>> dr_mode property, and the phy code decides between host-only
>> and otg mode based on whether an id pin is assigned or not.
>>
>> My proposal is to get rid of the id-pin hack to determine the mode
>> and add a dr_mode property to the usbphy dts node.
>
> I agree that we should get rid of that hack, especially since a lack
> of an ID pin might also be used on a peripheral-only device.
>
> However, we already have that information in the musb node, and
> duplicating the info seems error prone. We already have a custom
> function, maybe that's a case for another one, and that would allow to
> handle "hard" cases more easily (like CONFIG_USB_MUSB_HOST selected,
> with the otg node set to otg).
>

Hello,

was this solved somehow?

What problem is there with referencing the phy node?

Just like pinmux setting nodes and whatnot it can be named and
referenced by name.

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.

Re: [linux-sunxi] Re: random decryption errors with sun4i-ss on dm-crypt

[Michal Suchanek]

Hello,

On 14 March 2016 at 07:58, Corentin LABBE  wrote:
> Le 13/03/2016 23:35, Timo S. a écrit :
>> Hi Corentin,
>>
>> Am 13.03.2016 17:32 schrieb "Corentin LABBE" > >:
>>>
>>> Le 13/03/2016 16:21, txsan...@gmail.com  a écrit 
>>> :
>>> > http://irclog.whitequark.org/linux-sunxi/2016-03-11
>>> >
>>> > Chat from timestamp 18:25
>>> >
>>>
>>> Hello
>>>
>>> And I have just sent an email asking for help 
>>> https://lkml.org/lkml/2016/3/13/64.
>>>

Since you can reproduce the issue it might be worth trying to mod
sun4i-ss to also process the same data with software crypto in
parallel and log any differences the moment they appear together with
some data like the input to the crypto device and the number of
encrypted/decrypted/total processed blocks so far.

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.

Re: [linux-sunxi] reason for Allwinner SoC specific pinctrl drivers?

[Michal Suchanek]

On 5 January 2016 at 13:05, Andre Przywara <andre.przyw...@arm.com> wrote:
> Hi Michal,
>
> thanks for your input!
>
> On 04/01/16 21:36, Michal Suchanek wrote:
>> Hello,
>>
>> On 4 January 2016 at 18:27, Vishnu Patekar <vishnupatekar0...@gmail.com> 
>> wrote:
>>> Hello Andre,
>>> This is something we can do for future SOCs.
>>>
>>> On 4 Jan 2016 19:02, "Andre Przywara" <andre.przyw...@arm.com> wrote:
>>>>

>>>>
>>>> uart0_pins_a: uart0@0 {
>>>> allwinner,pins =   "PB22", "PB23";
>>>> +   allwinner,muxval = <0x020x02>;
>>>> allwinner,function = "uart0";
>>
>> As I understand it
>>
>> 1) uart0 is basically a mnemonic for muxval 2
>
> Not really. At the moment uart0 is used to lookup the (hard-coded) table
> entry for pins PB22 and PB23, which returns the said value of 0x02 (in
> this example, cf. line 246 in pinctrl-sun7i-a20.c).
> But if there are other pins where UART0 can be muxed too, there is
> another node describing them (cf. uart3_pins_a and uart3_pins_b in
> sun7i-a20.dtsi). This one uses the "uart0" name as well, but the muxval
> returned for _those pins_ can be different. So the string only makes
> sense in connection with a certain pin.
>
>> 2) if you try to mux uart0 on pins for which it is not in the table it fails
>
> How would you mux them if they are not in the table?

You cannot. The muxing fails because you request a function that is
not in the table for that pin - as opposed to muxing some other random
function on the pin silently.

>
>> So it makes no sense to have both function and muxval - this is redundant.
>
> Kind of, but not if we want to keep compatibility with older and newer
> DTs and older and newer kernels (drivers, really) - which is my goal.
> So we just _add_ the muxval values. The existing chip-specific drivers
> would naturally ignore the values and just use their built-in table for
> lookup. The generic driver on the other hand would use the DT
> information. An appropriate compatible string could then be added to
> refer to the generic driver as a fallback.
> For (future) SoCs (which would not have a specific driver) we could omit
> the function string (if this isn't needed elsewhere, I have to check).
> So I don't see how the redundancy would be an issue here.

The function string is needed for the setting to make any sense.

As you have pointed out yourself the function name may resolve to
different muxval for different pins.

You need those SoC pin tables so you know what you multiplexed to
what. They are in the kernel where they IMHO belong. Not having them
at all is a no-go because then you have no idea what functions you
have enabled on the SoC.

What you suggest is adding duplicate lower level information in the DT
so higher level pinmux driver uses symbolic function name and lower
level driver using raw mux number. This means that maintenance
problems increase with these low level and high level pin mux
descriptions potentially going out of sync in the DT.

>
>> And it does not make sense to move from function to muxval - it's like
>> moving from assembly programing to raw machine code programming.
>
> But it removes the requirement of relying on the built-in lookup table.
> So by using a more readable uart0 "mnemonic" we rely on some hardcoded,
> chip specific table in each kernel, which is just wrong IMHO. Other DT
> users (be it Xen or *BSD, for instance) would have to replicate this
> table and since it's really SoC specific, it does not make any sense to
> me to keep it separate. After all this DT node is SoC specific as well,
> so I don't see the point of abstracting this with some string lookup.
>
> So to stay with your comparison: Yes, we move from assembly to machine
> code, but we get rid of the need for a SoC specific assembler, which is
> maintained separately.

We cannot get rid of it. And really, the assembly is the same for all
the SoCs. It's the machine code which isn't and which the assembly
abstracts.

>
>> For compatibility it's not possible to move the table to the shared
>> SoC DT
>
> Why is that? We have the actual pin tables in the shared SoC DT, each
> board specific DT just refers to the actually connected pins by
> reference. That wouldn't change at all. So the above example for
> instance is from sun7i-a20.dtsi, board specific .dts files just use:
> pinctrl-0 = <_pins_a>;

Except as has been pointed out in DT unused features are not to be
included so you would lose the functions which are included in the
in-kernel tables but are not wired on any support

Re: [linux-sunxi] Re: [PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants

[Michal Suchanek]

On 4 January 2016 at 21:39, Philipp Zabel  wrote:
> Am Samstag, den 19.12.2015, 11:55 +0100 schrieb Hans de Goede:
>> On 18-12-15 12:08, Maxime Ripard wrote:

>> >  - If the reset line is in a !exclusive use with more than 1 user,
>> >the refcount is modified and an error is returned to notify that
>> >it didn't happen.
>>
>> Also ack, except for returning the error, if a driver has used
>> reset_control_get_shared, it should simply be aware that doing an assert
>> might not necessarily actually assert the line, just like doing a clk-disable
>> does not really necessary disable the clock, etc. If a driver is not prepared
>> to deal with this, it should simply not use reset_control_get_shared.
>>
>> I see returning an error if the assert did not happen due to other users /
>> deassert_count != 0 as inconsistent compared to how clks, regulators and phys
>> handle this, these all simply return success in this case.
>
> I wouldn't want drivers to have to differentiate between relevant and
> irrelevant error codes, so in the clock-like refcounting use case
> reset_assert should not return an error if it just correctly decremented
> the refcount. I'd still prefer to have separate API for the counted
> must_deassert/may_assert vs the exclusive must_assert/must_deassert use
> cases, but I just can't think of a good name.
>

Maybe something along the lines of assert_now or assert_sync. It
should be possible to call on shared line and then get an error when
the operation is blocked by other user.

The driver may not really care. Depending on the hardware the line can
be shared on one device and exclusive on another. The driver may just
let the line go when the device is powered off. And it may require a
reset cycle when it detects the device is hosed and return an error
when the reset fails for whatever reason.

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.

Re: [linux-sunxi] reason for Allwinner SoC specific pinctrl drivers?

[Michal Suchanek]

Hello,

On 4 January 2016 at 18:27, Vishnu Patekar  wrote:
> Hello Andre,
> This is something we can do for future SOCs.
>
> On 4 Jan 2016 19:02, "Andre Przywara"  wrote:
>>
>> Hi,
>>
>> while looking at the Allwinner A64 SoC support, I was wondering why we
>> would actually need a pinctrl driver (file) for each and every Allwinner
>> SoC that we support.
>> Looking at both the A20 and the A64 doc I don't see any differences in
>> the port controller implementation apart from the actual
>> muxval <-> subsystem assignment, which is just data, right?
>> Comparing the code files in drivers/pinctrl/sunxi seems to support this,
>> as those drivers only consist of the table and some boilerplate code.
>>
>> Now I was wondering whether we could get away with one generic Allwinner
>> pinctrl driver and put the SoC specific pin assignments in DT instead.
>> It looks like adding an "allwinner,muxval" property in addition to the
>> existing "allwinner,function" in the SoC's .dtsi would give us all the
>> information we need. This could look like:
>>
>> uart0_pins_a: uart0@0 {
>> allwinner,pins =   "PB22", "PB23";
>> +   allwinner,muxval = <0x020x02>;
>> allwinner,function = "uart0";

As I understand it

1) uart0 is basically a mnemonic for muxval 2
2) if you try to mux uart0 on pins for which it is not in the table it fails

So it makes no sense to have both function and muxval - this is redundant.

And it does not make sense to move from function to muxval - it's like
moving from assembly programing to raw machine code programming.

For compatibility it's not possible to move the table to the shared
SoC DT although it would be possible to have the pin tables in DT.
However, it would inflate the DT and make working in u-boot (SPL)
where full DT parser is not available problematic.

What might be possible is merging the different pinmux drivers in one.
Instead of replicating some pinmux boilerplate you will probably end
up with lots of ifdefs so only tables for SoC support compiled in the
kernel are built into the driver.
I am not sure how large the tables are and if anybody should care but
you might be also missing some symbols for them.

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.

Re: [linux-sunxi] [PATCH 1/2] spi: sun4i: add DMA support

[Michal Suchanek]

On 7 December 2015 at 16:46, Maxime Ripard
<maxime.rip...@free-electrons.com> wrote:
> Hi,
>
> On Sat, Dec 05, 2015 at 07:01:36PM +0100, Michal Suchanek wrote:
>> Hello,
>>
>> On 30 May 2014 at 22:27, Emilio López <emi...@elopez.com.ar> wrote:
>> > This patch adds support for 64 byte or bigger transfers on the
>> > sun4i SPI controller. Said transfers will be performed via DMA.
>> >
>> > Signed-off-by: Emilio López <emi...@elopez.com.ar>
>> > Tested-by: Michal Suchanek <hramr...@gmail.com>
>>
>> looks like this patch was dropped.
>>
>> sun4i still does not have SPI DMA.
>>
>> anyone picking it up or should I try to refresh it?
>
> If you don't send it to the relevant maintainers, no one will pick it
> up.
>

I am posting here to get some idea if somebody is working on including
this patch in the kernel.

If not I can send it to relevant maintainers.

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.

Re: [linux-sunxi] [PATCH 1/2] spi: sun4i: add DMA support

[Michal Suchanek]

Hello,

On 30 May 2014 at 22:27, Emilio López <emi...@elopez.com.ar> wrote:
> This patch adds support for 64 byte or bigger transfers on the
> sun4i SPI controller. Said transfers will be performed via DMA.
>
> Signed-off-by: Emilio López <emi...@elopez.com.ar>
> Tested-by: Michal Suchanek <hramr...@gmail.com>

looks like this patch was dropped.

sun4i still does not have SPI DMA.

anyone picking it up or should I try to refresh it?

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] [PATCH 9/9] ARM: dts: sunxi: Add SPI aliases on A10s Olinuxino.

[Michal Suchanek]

SPI aliases give nicer spidev device node names.

Signed-off-by: Michal Suchanek hramr...@gmail.com
---
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index b546fc2..1a0e0c0 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -58,6 +58,9 @@
serial0 = uart0;
serial1 = uart2;
serial2 = uart3;
+   spi0 = spi0;
+   spi1 = spi1;
+   spi2 = spi2;
};
 
chosen {
-- 
2.1.4

-- 
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] [PATCH 1/9] spi: sunxi: fix transfer timeout

[Michal Suchanek]

The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over
1MHz SPI bus takes way longer than that. Calculate the timeout from the
actual time the transfer is supposed to take and multiply by 2 for good
measure.

Signed-off-by: Michal Suchanek hramr...@gmail.com
---
 drivers/spi/spi-sun4i.c | 10 +-
 drivers/spi/spi-sun6i.c | 10 +-
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index fbb0a4d..48532ec 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -170,6 +170,7 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
 {
struct sun4i_spi *sspi = spi_master_get_devdata(master);
unsigned int mclk_rate, div, timeout;
+   unsigned int start, end, tx_time;
unsigned int tx_len = 0;
int ret = 0;
u32 reg;
@@ -279,9 +280,16 @@ static int sun4i_spi_transfer_one(struct spi_master 
*master,
reg = sun4i_spi_read(sspi, SUN4I_CTL_REG);
sun4i_spi_write(sspi, SUN4I_CTL_REG, reg | SUN4I_CTL_XCH);
 
+   tx_time = max_t(int, tfr-len * 8 * 2 / (speed / 1000), 100);
+   start = jiffies;
timeout = wait_for_completion_timeout(sspi-done,
- msecs_to_jiffies(1000));
+ msecs_to_jiffies(tx_time));
+   end = jiffies;
if (!timeout) {
+   dev_warn(master-dev,
+%s: timeout transferring %u bytes@%iHz for %i(%i)ms,
+dev_name(spi-dev), tfr-len, speed,
+jiffies_to_msecs(end - start), tx_time);
ret = -ETIMEDOUT;
goto out;
}
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index ac48f59..3d0f66c 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -162,6 +162,7 @@ static int sun6i_spi_transfer_one(struct spi_master *master,
unsigned int mclk_rate, div, timeout;
unsigned int tx_len = 0;
int ret = 0;
+   unsigned int start, end, tx_time;
u32 reg;
 
/* We don't support transfer larger than the FIFO */
@@ -269,9 +270,16 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg | SUN6I_TFR_CTL_XCH);
 
+   tx_time = max_t(int, tfr-len * 8 * 2 / (speed / 1000), 100);
+   start = jiffies;
timeout = wait_for_completion_timeout(sspi-done,
- msecs_to_jiffies(1000));
+ msecs_to_jiffies(tx_time));
+   end = jiffies;
if (!timeout) {
+   dev_warn(master-dev,
+%s: timeout transferring %u bytes@%iHz for %i(%i)ms,
+dev_name(spi-dev), tfr-len, speed,
+jiffies_to_msecs(end - start), tx_time);
ret = -ETIMEDOUT;
goto out;
}
-- 
2.1.4

-- 
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] [PATCH 7/9] ARM: dts: sun5i: add SPI pins on A13 and A10s

[Michal Suchanek]

According to datasheet some pins are available on A10s only while others
are shared with A13.

Signed-off-by: Michal Suchanek hramr...@gmail.com
---
This time add all spi pins and make the CS pins separate as is seen with
current sun4i DTs
---
 arch/arm/boot/dts/sun5i-a10s.dtsi | 21 +
 arch/arm/boot/dts/sun5i.dtsi  | 49 +++
 2 files changed, 70 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index f11efb7..d9610fa 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -201,6 +201,27 @@
allwinner,drive = SUN4I_PINCTRL_30_MA;
allwinner,pull = SUN4I_PINCTRL_NO_PULL;
};
+
+   spi1_cs1_pins_a: spi1_cs1@0 {
+   allwinner,pins = PG13;
+   allwinner,function = spi1;
+   allwinner,drive = SUN4I_PINCTRL_10_MA;
+   allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+   };
+
+   spi2_pins_a: spi2@0 {
+   allwinner,pins = PB12, PB13, PB14;
+   allwinner,function = spi1;
+   allwinner,drive = SUN4I_PINCTRL_10_MA;
+   allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+   };
+
+   spi2_cs0_pins_a: spi2_cs0@0 {
+   allwinner,pins = PB11;
+   allwinner,function = spi1;
+   allwinner,drive = SUN4I_PINCTRL_10_MA;
+   allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+   };
 };
 
 sram_a {
diff --git a/arch/arm/boot/dts/sun5i.dtsi b/arch/arm/boot/dts/sun5i.dtsi
index 54b0978..7d32d49 100644
--- a/arch/arm/boot/dts/sun5i.dtsi
+++ b/arch/arm/boot/dts/sun5i.dtsi
@@ -516,6 +516,55 @@
allwinner,drive = SUN4I_PINCTRL_30_MA;
allwinner,pull = SUN4I_PINCTRL_PULL_UP;
};
+
+   spi0_pins_a: spi0@0 {
+   allwinner,pins = PC00, PC01, PC02;
+   allwinner,function = spi0;
+   allwinner,drive = SUN4I_PINCTRL_10_MA;
+   allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+   };
+
+   spi0_cs0_pins_a: spi0_cs0@0 {
+   allwinner,pins = PC03;
+   allwinner,function = spi0;
+   allwinner,drive = SUN4I_PINCTRL_10_MA;
+   allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+   };
+
+   spi1_pins_a: spi1@0 {
+   allwinner,pins = PG10, PG11, PG12;
+   allwinner,function = spi1;
+   allwinner,drive = SUN4I_PINCTRL_10_MA;
+   allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+   };
+
+   spi1_cs0_pins_a: spi1_cs0@0 {
+   allwinner,pins = PG09;
+   allwinner,function = spi1;
+   allwinner,drive = SUN4I_PINCTRL_10_MA;
+   allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+   };
+
+   spi2_pins_b: spi2@1 {
+   allwinner,pins = PE01, PE02, PE03;
+   allwinner,function = spi2;
+   allwinner,drive = SUN4I_PINCTRL_10_MA;
+   allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+   };
+
+   spi2_cs0_pins_b: spi2_cs1@1 {
+   allwinner,pins = PE00;
+   allwinner,function = spi2;
+   allwinner,drive = SUN4I_PINCTRL_10_MA;
+   allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+   };
+
+   spi2_cs1_pins_a: spi2_cs1@0 {
+   allwinner,pins = PB10;
+   allwinner,function = spi2;
+   allwinner,drive = SUN4I_PINCTRL_10_MA;
+   allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+   };
};
 
timer@01c20c00 {
-- 
2.1.4

-- 
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] [PATCH 3/9] spi: sunxi: check that transfer speed is non-zero

[Michal Suchanek]

When the maximum transfer speed is not set for a SPI slave the value
remains 0 and the code in sunxi SPI divides by it. Use an arbitrary
speed instead in that case.

Signed-off-by: Michal Suchanek hramr...@gmail.com
---
 drivers/spi/spi-sun4i.c | 15 ++-
 drivers/spi/spi-sun6i.c | 15 ++-
 2 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index 707f61b..4dda366 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -169,7 +169,7 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
  struct spi_transfer *tfr)
 {
struct sun4i_spi *sspi = spi_master_get_devdata(master);
-   unsigned int mclk_rate, div, timeout;
+   unsigned int speed, mclk_rate, div, timeout;
unsigned int start, end, tx_time;
unsigned int tx_len = 0;
int ret = 0;
@@ -230,10 +230,15 @@ static int sun4i_spi_transfer_one(struct spi_master 
*master,
 
sun4i_spi_write(sspi, SUN4I_CTL_REG, reg);
 
+   speed = spi-max_speed_hz;
+   if (!speed) {
+   speed = 10;
+   dev_warn(spi-dev, SPI speed not set. Using %uHz., speed);
+   }
/* Ensure that we have a parent clock fast enough */
mclk_rate = clk_get_rate(sspi-mclk);
-   if (mclk_rate  (2 * spi-max_speed_hz)) {
-   clk_set_rate(sspi-mclk, 2 * spi-max_speed_hz);
+   if (mclk_rate  (2 * speed)) {
+   clk_set_rate(sspi-mclk, 2 * speed);
mclk_rate = clk_get_rate(sspi-mclk);
}
 
@@ -251,14 +256,14 @@ static int sun4i_spi_transfer_one(struct spi_master 
*master,
 * First try CDR2, and if we can't reach the expected
 * frequency, fall back to CDR1.
 */
-   div = mclk_rate / (2 * spi-max_speed_hz);
+   div = mclk_rate / (2 * speed);
if (div = (SUN4I_CLK_CTL_CDR2_MASK + 1)) {
if (div  0)
div--;
 
reg = SUN4I_CLK_CTL_CDR2(div) | SUN4I_CLK_CTL_DRS;
} else {
-   div = ilog2(mclk_rate) - ilog2(spi-max_speed_hz);
+   div = ilog2(mclk_rate) - ilog2(speed);
reg = SUN4I_CLK_CTL_CDR1(div);
}
 
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
index 3d0f66c..cf6a33e 100644
--- a/drivers/spi/spi-sun6i.c
+++ b/drivers/spi/spi-sun6i.c
@@ -159,7 +159,7 @@ static int sun6i_spi_transfer_one(struct spi_master *master,
  struct spi_transfer *tfr)
 {
struct sun6i_spi *sspi = spi_master_get_devdata(master);
-   unsigned int mclk_rate, div, timeout;
+   unsigned int speed, mclk_rate, div, timeout;
unsigned int tx_len = 0;
int ret = 0;
unsigned int start, end, tx_time;
@@ -216,10 +216,15 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
 
sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
 
+   speed = spi-max_speed_hz;
+   if(!speed) {
+   speed = 10;
+   dev_warn(spi-dev, SPI speed not set. Using %uHz., speed);
+   }
/* Ensure that we have a parent clock fast enough */
mclk_rate = clk_get_rate(sspi-mclk);
-   if (mclk_rate  (2 * spi-max_speed_hz)) {
-   clk_set_rate(sspi-mclk, 2 * spi-max_speed_hz);
+   if (mclk_rate  (2 * speed)) {
+   clk_set_rate(sspi-mclk, 2 * speed);
mclk_rate = clk_get_rate(sspi-mclk);
}
 
@@ -237,14 +242,14 @@ static int sun6i_spi_transfer_one(struct spi_master 
*master,
 * First try CDR2, and if we can't reach the expected
 * frequency, fall back to CDR1.
 */
-   div = mclk_rate / (2 * spi-max_speed_hz);
+   div = mclk_rate / (2 * speed);
if (div = (SUN6I_CLK_CTL_CDR2_MASK + 1)) {
if (div  0)
div--;
 
reg = SUN6I_CLK_CTL_CDR2(div) | SUN6I_CLK_CTL_DRS;
} else {
-   div = ilog2(mclk_rate) - ilog2(spi-max_speed_hz);
+   div = ilog2(mclk_rate) - ilog2(speed);
reg = SUN6I_CLK_CTL_CDR1(div);
}
 
-- 
2.1.4

-- 
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] [PATCH 6/9] ARM: dts: sunxi: add spi aliases on cubieboards

[Michal Suchanek]

Aliases give nicer device node names.

Signed-off-by: Michal Suchanek hramr...@gmail.com
---
 arch/arm/boot/dts/sun4i-a10-cubieboard.dts  | 1 +
 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts 
b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
index 9afb4e0..ba02f3b 100644
--- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
+++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
@@ -54,6 +54,7 @@
 
aliases {
serial0 = uart0;
+   spi0 = spi0;
};
 
chosen {
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts 
b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index 9861304..4c952a2 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -56,6 +56,7 @@
 
aliases {
serial0 = uart0;
+   spi0 = spi0;
};
 
chosen {
-- 
2.1.4

-- 
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] [PATCH 8/9] ARM: dts: sunxi: A10s Olinuxino Micro: add spi2.

[Michal Suchanek]

spi2 is exposed on the UEXT connector.

Signed-off-by: Michal Suchanek hramr...@gmail.com
---
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index a7e19e4..b546fc2 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -185,6 +185,13 @@
status = okay;
 };
 
+spi2 {
+   pinctrl-names = default;
+   pinctrl-0 = spi2_pins_a,
+   spi2_cs0_pins_a;
+   status = okay;
+};
+
 ohci0 {
status = okay;
 };
-- 
2.1.4

-- 
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] [PATCH 0/9] spi/sunxi patches

[Michal Suchanek]

Hello,

Since the sun4i dmaengine and DT label conversion patches are in this should be
now workable.

 - fix some minor issues with the spi driver
 - add spi dt nodes on some boards
 - include the DMA patch which depends on the dmaengine

Thanks

Michal

Emilio López (1):
  spi: sun4i: add DMA support

Michal Suchanek (8):
  spi: sunxi: fix transfer timeout
  spi: sun4i: fix FIFO limit
  spi: sunxi: check that transfer speed is non-zero
  ARM: dts: sun7i: cubieboard2: Enable SPI0
  ARM: dts: sunxi: add spi aliases on cubieboards
  ARM: dts: sun5i: add SPI pins on A13 and A10s
  ARM: dts: sunxi: A10s Olinuxino Micro: add spi2.
  ARM: dts: sunxi: Add SPI aliases on A10s Olinuxino.

 arch/arm/boot/dts/sun4i-a10-cubieboard.dts   |   1 +
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts |  10 ++
 arch/arm/boot/dts/sun5i-a10s.dtsi|  21 +++
 arch/arm/boot/dts/sun5i.dtsi |  49 +++
 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts  |   8 ++
 drivers/spi/spi-sun4i.c  | 166 ---
 drivers/spi/spi-sun6i.c  |  25 +++-
 7 files changed, 257 insertions(+), 23 deletions(-)

-- 
2.1.4

-- 
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] [PATCH 5/9] ARM: dts: sun7i: cubieboard2: Enable SPI0

[Michal Suchanek]

Only SPI0 is enabled. The schematic denotes it as the only SPI bus.
Other SPI pins are reserved for different peripherals.

Signed-off-by: Michal Suchanek hramr...@gmail.com
---
 arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts 
b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index 39a51d5..9861304 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -198,6 +198,13 @@
status = okay;
 };
 
+spi0 {
+   pinctrl-names = default;
+   pinctrl-0 = spi0_pins_a,
+   spi0_cs0_pins_a;
+   status = okay;
+};
+
 uart0 {
pinctrl-names = default;
pinctrl-0 = uart0_pins_a;
-- 
2.1.4

-- 
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] [PATCH 2/9] spi: sun4i: fix FIFO limit

[Michal Suchanek]

When testing SPI without DMA I noticed that filling the FIFO on the
spi controller causes timeout.

Always leave room for one byte in the FIFO.

Signed-off-by: Michal Suchanek hramr...@gmail.com
---
 drivers/spi/spi-sun4i.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
index 48532ec..707f61b 100644
--- a/drivers/spi/spi-sun4i.c
+++ b/drivers/spi/spi-sun4i.c
@@ -178,6 +178,8 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
/* We don't support transfer larger than the FIFO */
if (tfr-len  SUN4I_FIFO_DEPTH)
return -EINVAL;
+   if (tfr-tx_buf  tfr-len = SUN4I_FIFO_DEPTH)
+   return -EINVAL;
 
reinit_completion(sspi-done);
sspi-tx_buf = tfr-tx_buf;
@@ -271,7 +273,9 @@ static int sun4i_spi_transfer_one(struct spi_master *master,
sun4i_spi_write(sspi, SUN4I_XMIT_CNT_REG, SUN4I_XMIT_CNT(tx_len));
 
/* Fill the TX FIFO */
-   sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH);
+   /* Filling the fifo fully causes timeout for some reason
+* at least on spi2 on a10s */
+   sun4i_spi_fill_fifo(sspi, SUN4I_FIFO_DEPTH - 1);
 
/* Enable the interrupts */
sun4i_spi_write(sspi, SUN4I_INT_CTL_REG, SUN4I_INT_CTL_TC);
-- 
2.1.4

-- 
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: [PATCH RESEND v5] ARM: sun4i: spi: Allow transfers larger than FIFO size

[Michal Suchanek]

Hello,

On 14 August 2015 at 01:08, Alex G. mr.nuke...@gmail.com wrote:
 On 08/10/2015 07:54 AM, Michal Suchanek wrote:
 On 10 August 2015 at 15:44, Olliver Schinagl oliver+l...@schinagl.nl wrote:
 Hey Michal,

 As without this patch, we cannot use something like mmc-spi due to the
 restriction of packet size iirc.

 With DMA we can. And since DMA will be enabled most of the time the
 non-DMA code will receive little or no testing.

 That was also an objection over a year ago, when this patch was first
 ready, and still, no DMA support is implemented. It would be amazing to
 have a way to run larger transfers _today_ :) .

The dmaengine patch should get into 4.3 probably.

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: [PATCH 3/9] spi: sunxi: check that transfer speed is non-zero

[Michal Suchanek]

On 20 August 2015 at 16:48, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
 On Thu, Aug 20, 2015 at 02:19:46PM -, Michal Suchanek wrote:
 When the maximum transfer speed is not set for a SPI slave the value
 remains 0 and the code in sunxi SPI divides by it. Use an arbitrary
 speed instead in that case.

 Signed-off-by: Michal Suchanek hramr...@gmail.com

 spi-max_speed_hz is set using the spi-max-frequency property, and
 spi-will error out if that property isn't set. What am I missing?


Spidev I guess.

You can set the speed to arbitrary value from userspace at any time
using the spidev ioctls.

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: [PATCH 2/3] mmc: dw_mmc: simplify the SDMMC_CLKEN_LOW_PWR logic

[Michal Suchanek]

 Hello,

On 17 August 2015 at 16:42, Alim Akhtar alim.akh...@gmail.com wrote:
 HI

 On Mon, Aug 17, 2015 at 4:56 PM, Jaehoon Chung jh80.ch...@samsung.com wrote:
 On 08/17/2015 02:52 PM, Michal Suchanek wrote:
 Hello,

 On 17 August 2015 at 03:55, Jaehoon Chung jh80.ch...@samsung.com wrote:
 Hi, Michal.

 On 08/12/2015 09:23 PM, Michal Suchanek wrote:
 The driver has open-coded test for SDIO cards. Use the mmc core provided
 MMC_QUIRK_BROKEN_CLK_GATING flag instead.

 Did you use the clock-gating for SDIO cards?
 Doesn't MMC_CAP_SDIO_IRQ bit set? Which case is broken?
 Could you explain to me more?

 The core flag for disabling power saving is MMC_QUIRK_BROKEN_CLK_GATING.

 I understood your intention. And i read the comment into mmc/core/quirks.c
 I will test SDIO card with this patch. Thanks.

 When you test, please check if SDIO IRQ still works, we need to put
 dw_mmc in low_power mode otherwise SDIO IRQ will be not be generated
 by dw_mmc host controller.


As far as I understand the logic which is removed in this patch and
the core logic which replaces it is the same -  low power by means of
clock gating is *not* enabled for SDIO cards in either case.

The original code also checks for SDIO IRQ and disables clock gating
regardless of card type which is probably redundant. If not it should
be fixed in mmc core.

My recent kernel builds which I run on a system with mwifiex card
probably include this patch.

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.

Re: [linux-sunxi] Re: ARM: sunxi: Experiences NAND flash

[Michal Suchanek]

Hello

On 17 August 2015 at 09:34, Boris Brezillon
boris.brezil...@free-electrons.com wrote:
 Hi Oliver,

 Sorry for the late reply (I was in vacation for the last 2 weeks)

 On Tue, 11 Aug 2015 14:16:52 +0200
 Olliver Schinagl oliver+l...@schinagl.nl wrote:



 Now I know that the mtd stuff is all very new and all very untested,
 what I am curious about is a) have other people actually tried the mtd
 stuff on Allwinner hardware, and b) has anybody encountered this issue
 as well?

 Yes we did. So far we're using the NAND in SLC mode to address this
 problem. It seems to work, but you also loose half the NAND capacity.



What is needed to use the NAND in SLC mode?

Presumably you need to know something about its organizetion?

Is this data available for chips commonly used on sunxi devices?

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: [PATCH 2/3] mmc: dw_mmc: simplify the SDMMC_CLKEN_LOW_PWR logic

[Michal Suchanek]

Hello,

On 17 August 2015 at 03:55, Jaehoon Chung jh80.ch...@samsung.com wrote:
 Hi, Michal.

 On 08/12/2015 09:23 PM, Michal Suchanek wrote:
 The driver has open-coded test for SDIO cards. Use the mmc core provided
 MMC_QUIRK_BROKEN_CLK_GATING flag instead.

 Did you use the clock-gating for SDIO cards?
 Doesn't MMC_CAP_SDIO_IRQ bit set? Which case is broken?
 Could you explain to me more?

The core flag for disabling power saving is MMC_QUIRK_BROKEN_CLK_GATING.

It may coincide with MMC_CAP_SDIO_IRQ but that's different flag for
different purpose.

MMC_QUIRK_BROKEN_CLK_GATING is currently set for all SDIO cards except
for cards on a whitelist.

I don't know any particular SDIO card that has problems when the clock
is off and does not use an IRQ.

Thanks

Michal


 Best Regards,
 Jaehoon Chung


 As a bonus this may enable clock gating on SDIO cards that are known to
 work with it.

 Signed-off-by: Michal Suchanek hramr...@gmail.com
 ---
  drivers/mmc/host/dw_mmc.c | 33 +++--
  1 file changed, 15 insertions(+), 18 deletions(-)

 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index 40e9d8e..3bc9fd7 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -1335,27 +1335,24 @@ static void dw_mci_init_card(struct mmc_host *mmc, 
 struct mmc_card *card)
* description of the CLKENA register we should disable low power mode
* for SDIO cards if we need SDIO interrupts to work.
*/
 - if (mmc-caps  MMC_CAP_SDIO_IRQ) {
 - const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR  slot-id;
 - u32 clk_en_a_old;
 - u32 clk_en_a;
 + const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR  slot-id;
 + u32 clk_en_a_old;
 + u32 clk_en_a;

 - clk_en_a_old = mci_readl(host, CLKENA);
 + clk_en_a_old = mci_readl(host, CLKENA);

 - if (card-type == MMC_TYPE_SDIO ||
 - card-type == MMC_TYPE_SD_COMBO) {
 - set_bit(DW_MMC_CARD_NO_LOW_PWR, slot-flags);
 - clk_en_a = clk_en_a_old  ~clken_low_pwr;
 - } else {
 - clear_bit(DW_MMC_CARD_NO_LOW_PWR, slot-flags);
 - clk_en_a = clk_en_a_old | clken_low_pwr;
 - }
 + if (card-quirks  MMC_QUIRK_BROKEN_CLK_GATING) {
 + set_bit(DW_MMC_CARD_NO_LOW_PWR, slot-flags);
 + clk_en_a = clk_en_a_old  ~clken_low_pwr;
 + } else {
 + clear_bit(DW_MMC_CARD_NO_LOW_PWR, slot-flags);
 + clk_en_a = clk_en_a_old | clken_low_pwr;
 + }

 - if (clk_en_a != clk_en_a_old) {
 - mci_writel(host, CLKENA, clk_en_a);
 - mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
 -  SDMMC_CMD_PRV_DAT_WAIT, 0);
 - }
 + if (clk_en_a != clk_en_a_old) {
 + mci_writel(host, CLKENA, clk_en_a);
 + mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
 + SDMMC_CMD_PRV_DAT_WAIT, 0);
   }
  }




-- 
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] [PATCH 2/3] mmc: dw_mmc: simplify the SDMMC_CLKEN_LOW_PWR logic

[Michal Suchanek]

The driver has open-coded test for SDIO cards. Use the mmc core provided
MMC_QUIRK_BROKEN_CLK_GATING flag instead.

As a bonus this may enable clock gating on SDIO cards that are known to
work with it.

Signed-off-by: Michal Suchanek hramr...@gmail.com
---
 drivers/mmc/host/dw_mmc.c | 33 +++--
 1 file changed, 15 insertions(+), 18 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 40e9d8e..3bc9fd7 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1335,27 +1335,24 @@ static void dw_mci_init_card(struct mmc_host *mmc, 
struct mmc_card *card)
 * description of the CLKENA register we should disable low power mode
 * for SDIO cards if we need SDIO interrupts to work.
 */
-   if (mmc-caps  MMC_CAP_SDIO_IRQ) {
-   const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR  slot-id;
-   u32 clk_en_a_old;
-   u32 clk_en_a;
+   const u32 clken_low_pwr = SDMMC_CLKEN_LOW_PWR  slot-id;
+   u32 clk_en_a_old;
+   u32 clk_en_a;
 
-   clk_en_a_old = mci_readl(host, CLKENA);
+   clk_en_a_old = mci_readl(host, CLKENA);
 
-   if (card-type == MMC_TYPE_SDIO ||
-   card-type == MMC_TYPE_SD_COMBO) {
-   set_bit(DW_MMC_CARD_NO_LOW_PWR, slot-flags);
-   clk_en_a = clk_en_a_old  ~clken_low_pwr;
-   } else {
-   clear_bit(DW_MMC_CARD_NO_LOW_PWR, slot-flags);
-   clk_en_a = clk_en_a_old | clken_low_pwr;
-   }
+   if (card-quirks  MMC_QUIRK_BROKEN_CLK_GATING) {
+   set_bit(DW_MMC_CARD_NO_LOW_PWR, slot-flags);
+   clk_en_a = clk_en_a_old  ~clken_low_pwr;
+   } else {
+   clear_bit(DW_MMC_CARD_NO_LOW_PWR, slot-flags);
+   clk_en_a = clk_en_a_old | clken_low_pwr;
+   }
 
-   if (clk_en_a != clk_en_a_old) {
-   mci_writel(host, CLKENA, clk_en_a);
-   mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
-SDMMC_CMD_PRV_DAT_WAIT, 0);
-   }
+   if (clk_en_a != clk_en_a_old) {
+   mci_writel(host, CLKENA, clk_en_a);
+   mci_send_cmd(slot, SDMMC_CMD_UPD_CLK |
+   SDMMC_CMD_PRV_DAT_WAIT, 0);
}
 }
 
-- 
2.1.4

-- 
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] [PATCH 3/3] mmc: sunxi: use controller automatic clock gating.

[Michal Suchanek]

When core does not set the MMC_QUIRK_BROKEN_CLK_GATING flag enable
automatic hardware controlled clock gating on the mmc interface.

Signed-off-by: Michal Suchanek hramr...@gmail.com
---
 drivers/mmc/host/sunxi-mmc.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index f808a02..443cab5 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -601,8 +601,13 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host 
*host, u32 oclk_en)
rval = mmc_readl(host, REG_CLKCR);
rval = ~(SDXC_CARD_CLOCK_ON | SDXC_LOW_POWER_ON);
 
-   if (oclk_en)
+   if (oclk_en) {
rval |= SDXC_CARD_CLOCK_ON;
+   if (!host-mmc-card ||
+!(host-mmc-card-quirks  MMC_QUIRK_BROKEN_CLK_GATING))
+
+   rval |= SDXC_LOW_POWER_ON;
+   }
 
start = jiffies;
end = start + msecs_to_jiffies(750);
-- 
2.1.4

-- 
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] [PATCH resend 1/3] mmc: sunxi: fix timeout in sunxi_mmc_oclk_onoff

[michal . suchanek]

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 hramr...@gmail.com

--

 - fix formatting
---
 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..f808a02 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));
return -EIO;
+   } else {
+   int msecs = jiffies_to_msecs(end - start);
+   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);
}
 
return 0;
-- 
2.1.4

-- 
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] MMC clock gating broken on a20

[Michal Suchanek]

On 12 August 2015 at 13:55, Olliver Schinagl oliver+l...@schinagl.nl wrote:
 Actually, I've reverted hans's

 mmc: sunxi: Don't start commands while the card is busy

 and that makes it disapear as well. So it looks like that patch triggers the
 aggressiveness more?

It probably inserts delays which trigger the mmc power saving.

Still the delay should not be needed on the mmc interface which is
connected to the card slot, should it?

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] [PATCH 0/3] misc MMC fixes

[Michal Suchanek]

Hello,

The first sunxi patch from this series was rejected on the basis that this clock
gating functionality is obsolete and should be eventually removed.

However, the function still exists in the current code and until removed it
should be corrected to work properly. Turning off the clock may be used for
something other than the clock gating feature, too.

The next sunxi patch is for automatic clock gating on the controller which
should replace the in-kernel mmc clock gating we have now.

I looked at dw_mmc for how this is supposed to work and it turns out it's not
exactly clean there either.

Thanks

Michal

Michal Suchanek (3):
  mmc: sunxi: fix timeout in sunxi_mmc_oclk_onoff
  mmc: dw_mmc: simplify the SDMMC_CLKEN_LOW_PWR logic
  mmc: sunxi: use controller automatic clock gating.

 drivers/mmc/host/dw_mmc.c| 33 +++--
 drivers/mmc/host/sunxi-mmc.c | 29 +
 2 files changed, 40 insertions(+), 22 deletions(-)

-- 
2.1.4

-- 
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] MMC clock gating broken on a20

[Michal Suchanek]

Hello,

On 12 August 2015 at 13:40, Olliver Schinagl oliver+l...@schinagl.nl wrote:
 Hey all,

 I'm noticing the exact same thing using hans's sunxi-wip from a few days
 ago.

 I did see a patch from you about this very issue I belive
 mmc: sunxi: fix timeout in sunxi_mmc_oclk_onoff

 but can't find it in any of the repo's. Has it been merged yet and did that
 actually solve the problem eventually?

It fixes the problem for me.

The patch was not applied since the functionality is scheduled for removal.

I will resend the mmc patches I guess.

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] [PATCH v3 1/3] mmc: sunxi: fix timeout in sunxi_mmc_oclk_onoff

[Michal Suchanek]

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.

Signed-off-by: Michal Suchanek hramr...@gmail.com

---
v3
 - remove debug message
v2
 - fix formatting
---
 drivers/mmc/host/sunxi-mmc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 4d3e1ff..a7b7a67 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 expire = jiffies + msecs_to_jiffies(750);
u32 rval;
 
rval = mmc_readl(host, REG_CLKCR);
-- 
2.1.4

-- 
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 3/3] mmc: sunxi: use controller automatic clock gating.

[Michal Suchanek]

On 12 August 2015 at 15:19, Olliver Schinagl oliver+l...@schinagl.nl wrote:
 Hey,

 On 12-08-15 14:35, Hans de Goede wrote:

 Hi,

 On 12-08-15 14:23, Michal Suchanek wrote:

 When core does not set the MMC_QUIRK_BROKEN_CLK_GATING flag enable
 automatic hardware controlled clock gating on the mmc interface.

 Signed-off-by: Michal Suchanek hramr...@gmail.com


 In general this looks good, but I wonder how intensively this has
 been tested ?

 It doesn't matter actually, it took some time longer, but the mmc still
 craps out even with Michal's 3 patches. I'll revert hans's earlier patch
 again and do a bit more extensive testing.

Does the oclk switch timeout even after 750ms?

In some earlier tests I tried to enable/disable the clock repeatedly
when it failed but it seemed to have little effect on the total time
it took to disable the clock in the end.

Maybe it would be worh trying to set the timeout to some insanely long
value and test stability with that. I picked 750 as around twice the
maximum time it ever took on my board.

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.

Re: [linux-sunxi] Re: [PATCH RESEND v5] ARM: sun4i: spi: Allow transfers larger than FIFO size

[Michal Suchanek]

On 10 August 2015 at 15:44, Olliver Schinagl oliver+l...@schinagl.nl wrote:
 Hey Michal,


 On 10-08-15 13:07, Michal Suchanek wrote:

 Hello,

 On 08-08-15 20:45, Olliver Schinagl wrote:

 Hey all,

 Alexandru Gagniuc mr.nuke.me@... writes:

 SPI transfers were limited to one FIFO depth, which is 64 bytes.
 This was an artificial limitation, however, as the hardware can handle
 much larger bursts. To accommodate this, we enable the interrupt when
 the Rx FIFO is 3/4 full, and drain the FIFO within the interrupt
 handler. The 3/4 ratio was chosen arbitrarily, with the intention to
 reduce the potential number of interrupts.

 Since the SUN4I_CTL_TP bit is set, the hardware will pause
 transmission whenever the FIFO is full, so there is no risk of losing
 data if we can't service the interrupt in time.

 For the Tx side, enable and use the Tx FIFO 3/4 empty interrupt to
 replenish the FIFO on large SPI bursts. This requires more care in
 when the interrupt is left enabled, as this interrupt will continually
 trigger when the FIFO is less than 1/4 full, even though we
 acknowledge it.

 Signed-off-by: Alexandru Gagniuc mr.nuke.me@...
 Acked-by: Maxime Ripard maxime.ripard@...

 This patch was posted more then a year ago and I think several tree's
 carry it.

 I've used this patch in combination with the mmc-spi driver and found no
 problems with it in the past year.

 So have my Tested-by: Olliver Schinagl oli...@schinagl.nl

 and lets get this patch merged!

 P.S. I have the original patch and can resend it if needed.
 snip

 There are basically two issues with this

 1) it conflicts with DMA support. Do we want this when there is DMA
 support almost complete?

 Well this would affect PIO mode in all cases, so do we want this? I would
 think yet in case DMA is not available/disabled?

When will that happen?


 As without this patch, we cannot use something like mmc-spi due to the
 restriction of packet size iirc.

With DMA we can. And since DMA will be enabled most of the time the
non-DMA code will receive little or no testing.



 2) it adds support on sun4i but not sun6i. Unfortunately, I do not
 have any sun6i hardware. sun6i has dmaengine in mainline but not the
 dma support in spi.

 Well yeah, I don't have sun6i either so we can't merge something nobody has
 tested yet ;)


 That aside,

 have you tested this for small transfers that would not trigger the
 fifo 3/4 full interrupt?

 Well the mmc-spi would also have small transfers, no? I mean it's a little
 bit of everything I imagine?

I have no idea about mmc spi tbh. I have some mmc sockets lying around
but did not try using them and did not look at the protocol.

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.

Re: [linux-sunxi] [PATCH v2 1/3] ARM: dts: sun5i: Enable USB DRC on A10s OLinuxIno Micro

[Michal Suchanek]

Hello,

On 31 July 2015 at 14:53, Hans de Goede hdego...@redhat.com wrote:
 Enable the otg/drc usb controller on the A10s OLinuxIno Micro.

 Note the A10s OlinuxIno Micro always has some voltage on its otg power
 pin, even if the usb-vbus0-regulator is disabled, the leaked voltage is
 enough to make vbus-det always report 1, so we do not use vbus-det on
 this board.

What board revision do you have?

Also does this not go down when you connect a device which draws power?

It is useless for self-powered device detection, though :-s

Still the Olinuxino is not battery powered normally so powering the
bus at all times is probably ok.

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: [PATCH 4/4] mtd: nand: print full chip ID

[Michal Suchanek]

Hello,

On 30 July 2015 at 09:17, Boris Brezillon
boris.brezil...@free-electrons.com wrote:
 Hans, Michal,

 On Wed, 29 Jul 2015 19:53:54 +0200
 Hans de Goede hdego...@redhat.com wrote:

 From: Michal Suchanek hramr...@gmail.com

 Full chip ID is printed so user has data to paste from syslog in case
 of chip misidentification.

 Signed-off-by: Michal Suchanek hramr...@gmail.com
 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  drivers/mtd/nand/nand_base.c | 28 +++-
  1 file changed, 23 insertions(+), 5 deletions(-)

 diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
 index e2e2690..13e9938 100644
 --- a/drivers/mtd/nand/nand_base.c
 +++ b/drivers/mtd/nand/nand_base.c
 @@ -4243,7 +4243,7 @@ static inline bool is_full_id_nand(struct 
 nand_flash_dev *type)
  }

  static bool find_full_id_nand(struct mtd_info *mtd, struct nand_chip *chip,
 -struct nand_flash_dev *type, u8 *id_data, int *busw)
 +struct nand_flash_dev *type, const u8 *id_data, int *busw)
  {
   if (!strncmp(type-id, id_data, type-id_len)) {
   mtd-writesize = type-pagesize;
 @@ -4269,6 +4269,26 @@ static bool find_full_id_nand(struct mtd_info *mtd, 
 struct nand_chip *chip,
  }

  /*
 + * Print full detail of chip ID read from chip.
 + */
 +static void print_nand_chip_info(int maf_id, int dev_id, u8 id_data[8])
 +{
 + u8 delim[8] = { [0 ... 7] = ',' };
 +
 + pr_info(device found, Manufacturer ID: 0x%02x, Chip ID: 0x%02x\n,
 + maf_id, dev_id);
 +
 + delim[7] = ' ';
 + delim[nand_id_len(id_data, 8) - 1] = ';';
 +
 + pr_info(chip id data: 0x%02x%c 0x%02x%c 0x%02x%c 0x%02x%c 0x%02x%c 
 0x%02x%c 0x%02x%c 0x%02x%c\n,
 + id_data[0], delim[0], id_data[1], delim[1],
 + id_data[2], delim[2], id_data[3], delim[3],
 + id_data[4], delim[4], id_data[5], delim[5],
 + id_data[6], delim[6], id_data[7], delim[7]);

 This looks like debug information to me, how about using pr_debug ?


This is informative message saying that a device was detected. The
only change is that full id is printed as part of the message. The
same message is printed when the device fails to identify so it should
probably be shown by default. Maybe joining it into one line to avoid
excessive spam would be better.

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.

Re: [linux-sunxi] [PATCH 4/4] mtd: nand: print full chip ID

[Michal Suchanek]

On 30 July 2015 at 01:37, Julian Calaby julian.cal...@gmail.com wrote:
 Hi Hans, Michal,

 On Thu, Jul 30, 2015 at 3:53 AM, Hans de Goede hdego...@redhat.com wrote:
 From: Michal Suchanek hramr...@gmail.com

 Full chip ID is printed so user has data to paste from syslog in case
 of chip misidentification.

 Signed-off-by: Michal Suchanek hramr...@gmail.com
 Signed-off-by: Hans de Goede hdego...@redhat.com
 ---
  drivers/mtd/nand/nand_base.c | 28 +++-
  1 file changed, 23 insertions(+), 5 deletions(-)

 diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
 index e2e2690..13e9938 100644
 --- a/drivers/mtd/nand/nand_base.c
 +++ b/drivers/mtd/nand/nand_base.c
 @@ -4243,7 +4243,7 @@ static inline bool is_full_id_nand(struct 
 nand_flash_dev *type)
  }

  static bool find_full_id_nand(struct mtd_info *mtd, struct nand_chip *chip,
 -  struct nand_flash_dev *type, u8 *id_data, int *busw)
 +  struct nand_flash_dev *type, const u8 *id_data, int *busw)

 Should this be in another patch?


Yes, that's not needed here.

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: [PATCH v2 2/2] mfd: ax20x: Add axp152 support

[Michal Suchanek]

Hello,

I see missing 'p' in axp20x in the subject u.u

Please fix before merging this anywhere.

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.

Re: [linux-sunxi] Further Allwinner misbehaviour.

[Michal Suchanek]

Hello,

On 25 June 2015 at 11:56, 'Simos Xenitellis' via linux-sunxi
linux-sunxi@googlegroups.com wrote:

 The way I see the whole situation is this: It is true that Allwinner
 did not make effort over the years
 for mainline Linux kernel support. Whatever support is there for the
 A10, A13, A20, etc,
 is the result of the hard work of this community. Working on mainline
 support is initially expensive
 in terms of resources but builds an ecosystem and opens up markets. It
 makes business sense.

 As a community, we need to figure out what we need from Allwinner.
 Do we need specific SoC information so that we do the mainline effort
 on our own? And among all things that can be asked,
 we prioritize to those that are really needed at the moment.
 Do we need Allwinner to fund some developers so that they work
 full-time on this? We would need to start talking about goals and
 targets.


The goal in general is to get enough information and/or opensource
properly licensed code to run GNU/Linux and *BSD on the allwinner SoCs
with full feature support on current and future versions of these
systems.

Given that we have reverse-engineered documentation for Cedar there is
really not much technical benefit in Allwinner releasing the Cedar
driver source with proper licensing so it can be reused as-is. It
might be mere convenience to reuse some of the code.

On the other hand, given the documentation exists there is little
reason for Allwinner to pretend there are secrets protected by not
releasing the code.

There is also legal obligation to release the source of the binaries
of ffmepg which is (L)GPL even after adding the proprietary bits. That
said the ffmpeg author(s) do not seem to press the legal issue.

Overall the Cedar discussion is pretty much pointless. It only
restarts for no good when somebody (from Allwinner or otherwise)
points at the repo and says Look, allwinner released the Cedar
sources and then there is half of the implementation or binary blob.

So to say it clearly:

To fulfill the legal obligations to the letter allwinner has to
release the full source under (L)GPL compatible license of all the
Cedar codec binaries it released in the past since it has been pointed
out that these binaries contain substantial portions of ffmpeg which
is (L)GPL licensed. Using (L)GPL code brings this obligation.

To fulfill the obligation in spirit without possibly infringing on
license of some third party proprietary modules linked into said
ffmpeg binaries Allwinner could release an alternative fully
opensource and (L)GPL compatible codec implementing all the features
of those binaries.

Given that this isn't really needed for the goal of getting full
support for Allwinner SoCs I personally do not really care if such
thing happens or not. It might change for future revisions of the
codec with new features, though.

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.