Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
On Mon, Jan 27, 2014 at 3:31 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/26/2014 05:58 PM, Chen-Yu Tsai wrote: Hi, On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/24/2014 04:38 AM, Chen-Yu Tsai wrote: snip Quick update, I've just tested: https://github.com/wens/linux/commits/wip/sunxi-next-wifi About this, I would like to move WiFi power control to a regulator, and controlled by sunxi-mci via vmmc-supply (not supported ATM) Actually the sunxi-mci.c driver already has support for an optional regulator called vmmc. I like this idea, I've done a version of the dt patch using a regulator instead of rfkill here: https://github.com/jwrdegoede/linux-sunxi/commit/8d200113b573549cdcdc1b2d5a5a1cad15cfbe07 This works as advertised and IMHO is the better solution. I have a version in another branch I haven't pushed. I had it using an always-on regulator. I can adjust it to use vmmc. BTW, I'd like to do a patch for sunxi-mci to use the DT parsing code in mmc core. We should re-use code if possible, wouldn't you agree? I would agree, except that mmc_regulator_get_supply makes vmmc mandatory, it will log and return an error when it is not there, and it will not set ocr_avail. Almost all Allwinnner boards don't have a separate vmmc, so making vmmc mandatory just leads to devicetree containing unnecessary fixed regulators for this. I suppose we could still reuse all the property parsing bits in mmc_of_parse(). This one handles the GPIOs, bus width and host capabilities. About the oob interrupt stuff not working, AFAIK you should set a pinctrl function (not input, but a function like mmc is a function) on the pin in question for it to work as external interrupt, I believe you're not doing so in your dts. The pinctrl driver seems to set the function when the interrupt is enabled. Unfortunately we don't have any documentation/examples on how to use them. I will look into that later. Hmm, but you also have a pinctrl entry in the dts setting it up as gpio-input, maybe that conflicts ? I made a version with pinctrl entry setup as irq, got an interrupt, but then the whole thing hung. Great, that sounds like progress to me :) I think it was a fluke. Now I'm not getting any interrupts. :( Anyway, I am resuming work on musb. I'll get back to this once 3.14-rc1 is out, and sunxi-devel is rebased. I can probably use OTG ID pin to test external interrupts. Cheers, ChenYu Looks like pinctrl irqchip was not properly handling chained interrupts. I have done a simple fix, and I hope to test it tomorrow. Then I'll do some more testing with different configurations and hopefully write some documents. Thanks for working on this. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
Hi, On 01/27/2014 09:14 AM, Chen-Yu Tsai wrote: On Mon, Jan 27, 2014 at 3:31 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/26/2014 05:58 PM, Chen-Yu Tsai wrote: Hi, On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/24/2014 04:38 AM, Chen-Yu Tsai wrote: snip Quick update, I've just tested: https://github.com/wens/linux/commits/wip/sunxi-next-wifi About this, I would like to move WiFi power control to a regulator, and controlled by sunxi-mci via vmmc-supply (not supported ATM) Actually the sunxi-mci.c driver already has support for an optional regulator called vmmc. I like this idea, I've done a version of the dt patch using a regulator instead of rfkill here: https://github.com/jwrdegoede/linux-sunxi/commit/8d200113b573549cdcdc1b2d5a5a1cad15cfbe07 This works as advertised and IMHO is the better solution. I have a version in another branch I haven't pushed. I had it using an always-on regulator. I can adjust it to use vmmc. BTW, I'd like to do a patch for sunxi-mci to use the DT parsing code in mmc core. We should re-use code if possible, wouldn't you agree? I would agree, except that mmc_regulator_get_supply makes vmmc mandatory, it will log and return an error when it is not there, and it will not set ocr_avail. Almost all Allwinnner boards don't have a separate vmmc, so making vmmc mandatory just leads to devicetree containing unnecessary fixed regulators for this. I suppose we could still reuse all the property parsing bits in mmc_of_parse(). This one handles the GPIOs, bus width and host capabilities. Ah, I did not know about that one, yes that seems like a good idea. About the oob interrupt stuff not working, AFAIK you should set a pinctrl function (not input, but a function like mmc is a function) on the pin in question for it to work as external interrupt, I believe you're not doing so in your dts. The pinctrl driver seems to set the function when the interrupt is enabled. Unfortunately we don't have any documentation/examples on how to use them. I will look into that later. Hmm, but you also have a pinctrl entry in the dts setting it up as gpio-input, maybe that conflicts ? I made a version with pinctrl entry setup as irq, got an interrupt, but then the whole thing hung. Great, that sounds like progress to me :) I think it was a fluke. Now I'm not getting any interrupts. :( Anyway, I am resuming work on musb. I'll get back to this once 3.14-rc1 is out, and sunxi-devel is rebased. I can probably use OTG ID pin to test external interrupts. If you do a patch for mmc to use mmc_of_parse you will end up using external interrupts for sdcard detection by default (which should work on most boards, but has never been tested AFAIK), which would be another way to check the external interrupt functionality. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
On 01/27/2014 01:20 AM, Tomasz Figa wrote: Hi Chen-Yu, Arend, On 26.01.2014 22:39, Arend van Spriel wrote: On 01/26/2014 05:58 PM, Chen-Yu Tsai wrote: Hi, On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/24/2014 04:38 AM, Chen-Yu Tsai wrote: snip Quick update, I've just tested: https://github.com/wens/linux/commits/wip/sunxi-next-wifi About this, I would like to move WiFi power control to a regulator, and controlled by sunxi-mci via vmmc-supply (not supported ATM) Actually the sunxi-mci.c driver already has support for an optional regulator called vmmc. I like this idea, I've done a version of the dt patch using a regulator instead of rfkill here: https://github.com/jwrdegoede/linux-sunxi/commit/8d200113b573549cdcdc1b2d5a5a1cad15cfbe07 This works as advertised and IMHO is the better solution. I have a version in another branch I haven't pushed. I had it using an always-on regulator. I can adjust it to use vmmc. BTW, I'd like to do a patch for sunxi-mci to use the DT parsing code in mmc core. We should re-use code if possible, wouldn't you agree? About the oob interrupt stuff not working, AFAIK you should set a pinctrl function (not input, but a function like mmc is a function) on the pin in question for it to work as external interrupt, I believe you're not doing so in your dts. The pinctrl driver seems to set the function when the interrupt is enabled. Unfortunately we don't have any documentation/examples on how to use them. I will look into that later. Hmm, but you also have a pinctrl entry in the dts setting it up as gpio-input, maybe that conflicts ? I made a version with pinctrl entry setup as irq, got an interrupt, but then the whole thing hung. Looks like pinctrl irqchip was not properly handling chained interrupts. I have done a simple fix, and I hope to test it tomorrow. Then I'll do some more testing with different configurations and hopefully write some documents. Hi Chen-Yu, I had a look at github tree from Hans with your DT support patch for brcmfmac. I applied it to my 3.14 tree and modified it a little. I guess the bindings are still experimental, but I would prefer you to use brcm instead of broadcom in the 'compatible' entry as found in Documentation/devicetree/bindings/vendor-prefixes.txt. There is an exception to this rule in the bindings (in net/broadcom-bcm87xx.txt), but I guess that train has left and it is tricky to change it now. In the brcmfmac patch you also use multiple of_device ids. Could we make it more generic, ie. compatible = brcm,brcmfmac or brcm,wifi-fullmac or whatever... brcmfmac and wifi-fullmac strings sound to generic for me. What happens if an incompatible brcmfmac chip shows up? I'd rather use something like bcm43xx to cover existing chip family, if all the bcm43xx chips are compatible, or something more specific otherwise. The brcmfmac driver that consumes these DT nodes will have a closer look at the device obtaining the chipid during the probe and determine if it can support it. So the compatible string indicates that the device needs a so-called fullmac wireless driver opposed to a mac80211 aka. softmac wireless driver. By the way, you might find this thread interesting: http://thread.gmane.org/gmane.linux.kernel.mmc/24728/focus=24783 In addition to the general idea of handling power control, I have also posted a link to my patch adding DT support to brcmfmac driver. You peaked my interest and I will catch up reading the thread. Regards, Arend -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH v5 07/14] ahci-platform: Library-ise ahci_probe functionality
Hi,
On 01/22/2014 09:04 PM, Hans de Goede wrote:
ahci_probe consists of 3 steps:
1) Get resources (get mmio, clks, regulator)
2) Enable resources, handled by ahci_platform_enable_resouces
3) The more or less standard ahci-host controller init sequence
This commit refactors step 1 and 3 into separate functions, so the platform
drivers for AHCI implementations which need a specific order in step 2,
and / or need to do some custom register poking at some time, can re-use
ahci-platform.c code without needing to copy and paste it.
Note that ahci_platform_init_host's prototype takes the 3 non function
members of ahci_platform_data as arguments, the idea is that drivers using
the new exported utility functions will not use ahci_platform_data at all,
and hopefully in the future ahci_platform_data can go away entirely.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/ata/ahci_platform.c | 158
--
include/linux/ahci_platform.h | 14
2 files changed, 106 insertions(+), 66 deletions(-)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 1cce7a2..b260ebe 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -150,60 +150,31 @@ void ahci_platform_disable_resources(struct
ahci_host_priv *hpriv)
EXPORT_SYMBOL_GPL(ahci_platform_disable_resources);
-static void ahci_put_clks(struct ahci_host_priv *hpriv)
-{
- int c;
-
- for (c = 0; c AHCI_MAX_CLKS hpriv-clks[c]; c++)
- clk_put(hpriv-clks[c]);
-}
-
-static int ahci_probe(struct platform_device *pdev)
+struct ahci_host_priv *ahci_platform_get_resources(
+ struct platform_device *pdev)
{
struct device *dev = pdev-dev;
- struct ahci_platform_data *pdata = dev_get_platdata(dev);
- const struct platform_device_id *id = platform_get_device_id(pdev);
- struct ata_port_info pi = ahci_port_info[id ? id-driver_data : 0];
- const struct ata_port_info *ppi[] = { pi, NULL };
struct ahci_host_priv *hpriv;
- struct ata_host *host;
- struct resource *mem;
struct clk *clk;
- int i, irq, max_clk, n_ports, rc;
-
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!mem) {
- dev_err(dev, no mmio space\n);
- return -EINVAL;
- }
-
- irq = platform_get_irq(pdev, 0);
- if (irq = 0) {
- dev_err(dev, no irq\n);
- return -EINVAL;
- }
-
- if (pdata pdata-ata_port_info)
- pi = *pdata-ata_port_info;
+ int i, max_clk, rc;
hpriv = devm_kzalloc(dev, sizeof(*hpriv), GFP_KERNEL);
if (!hpriv) {
dev_err(dev, can't alloc ahci_host_priv\n);
- return -ENOMEM;
+ return ERR_PTR(-ENOMEM);
}
- hpriv-flags |= (unsigned long)pi.private_data;
-
- hpriv-mmio = devm_ioremap(dev, mem-start, resource_size(mem));
+ hpriv-mmio = devm_ioremap_resource(dev,
+ platform_get_resource(pdev, IORESOURCE_MEM, 0));
if (!hpriv-mmio) {
- dev_err(dev, can't map %pR\n, mem);
- return -ENOMEM;
+ dev_err(dev, no mmio space\n);
+ return ERR_PTR(-EINVAL);
}
hpriv-target_pwr = devm_regulator_get_optional(dev, target);
if (IS_ERR(hpriv-target_pwr)) {
if (PTR_ERR(hpriv-target_pwr) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
+ return ERR_PTR(-EPROBE_DEFER);
hpriv-target_pwr = NULL;
}
@@ -223,27 +194,48 @@ static int ahci_probe(struct platform_device *pdev)
hpriv-clks[i] = clk;
}
- rc = ahci_platform_enable_resources(hpriv);
- if (rc)
- goto free_clk;
+ return hpriv;
- /*
- * Some platforms might need to prepare for mmio region access,
- * which could be done in the following init call. So, the mmio
- * region shouldn't be accessed before init (if provided) has
- * returned successfully.
- */
- if (pdata pdata-init) {
- rc = pdata-init(dev, hpriv);
- if (rc)
- goto disable_resources;
- }
+free_clk:
+ while (--i = 0)
+ clk_put(hpriv-clks[i]);
+ return ERR_PTR(rc);
+}
+EXPORT_SYMBOL_GPL(ahci_platform_get_resources);
+
+void ahci_platform_put_resources(struct ahci_host_priv *hpriv)
+{
+ int c;
+
+ for (c = 0; c AHCI_MAX_CLKS hpriv-clks[c]; c++)
+ clk_put(hpriv-clks[c]);
+}
+EXPORT_SYMBOL_GPL(ahci_platform_put_resources);
+
+
+int ahci_platform_init_host(struct platform_device *pdev,
+ struct ahci_host_priv *hpriv,
+ const struct ata_port_info *pi_template,
+ unsigned int force_port_map,
+ unsigned int mask_port_map)
+{
[linux-sunxi] Re: [PATCH v5 07/14] ahci-platform: Library-ise ahci_probe functionality
Hi,
On 01/27/2014 11:39 AM, Roger Quadros wrote:
Hi,
On 01/22/2014 09:04 PM, Hans de Goede wrote:
snip
--- a/include/linux/ahci_platform.h
+++ b/include/linux/ahci_platform.h
@@ -20,7 +20,13 @@
struct device;
struct ata_port_info;
struct ahci_host_priv;
+struct platform_device;
+/*
+ * Note ahci_platform_data is deprecated. New drivers which need to override
+ * any of these, should instead declare there own platform_driver struct, and
+ * use ahci_platform* functions in their own probe, suspend and resume methods.
+ */
struct ahci_platform_data {
int (*init)(struct device *dev, struct ahci_host_priv *hpriv);
void (*exit)(struct device *dev);
@@ -35,5 +41,13 @@ int ahci_platform_enable_clks(struct ahci_host_priv *hpriv);
void ahci_platform_disable_clks(struct ahci_host_priv *hpriv);
int ahci_platform_enable_resources(struct ahci_host_priv *hpriv);
void ahci_platform_disable_resources(struct ahci_host_priv *hpriv);
+struct ahci_host_priv *ahci_platform_get_resources(
+ struct platform_device *pdev);
Why not use 'struct device' as the argument?
Because of calls to platform_get_resource inside the function.
+void ahci_platform_put_resources(struct ahci_host_priv *hpriv);
Can we have 'struct device' as the argument? Else it becomes
impossible to get 'struct device' from 'hpriv' if we need to call e.g.
pm_runtime_*() APIs.
The plan for is for this function to go away once we have a
devm version of of_clk_get, so if you need to put pm_runtime_calls
somewhere, please don't put them here. This sounds like something which
should go in enable / disable resources instead ?
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v5 07/14] ahci-platform: Library-ise ahci_probe functionality
On 01/27/2014 12:51 PM, Hans de Goede wrote:
Hi,
On 01/27/2014 11:39 AM, Roger Quadros wrote:
Hi,
On 01/22/2014 09:04 PM, Hans de Goede wrote:
snip
--- a/include/linux/ahci_platform.h
+++ b/include/linux/ahci_platform.h
@@ -20,7 +20,13 @@
struct device;
struct ata_port_info;
struct ahci_host_priv;
+struct platform_device;
+/*
+ * Note ahci_platform_data is deprecated. New drivers which need to
override
+ * any of these, should instead declare there own platform_driver struct,
and
+ * use ahci_platform* functions in their own probe, suspend and resume
methods.
+ */
struct ahci_platform_data {
int (*init)(struct device *dev, struct ahci_host_priv *hpriv);
void (*exit)(struct device *dev);
@@ -35,5 +41,13 @@ int ahci_platform_enable_clks(struct ahci_host_priv
*hpriv);
void ahci_platform_disable_clks(struct ahci_host_priv *hpriv);
int ahci_platform_enable_resources(struct ahci_host_priv *hpriv);
void ahci_platform_disable_resources(struct ahci_host_priv *hpriv);
+struct ahci_host_priv *ahci_platform_get_resources(
+struct platform_device *pdev);
Why not use 'struct device' as the argument?
Because of calls to platform_get_resource inside the function.
+void ahci_platform_put_resources(struct ahci_host_priv *hpriv);
Can we have 'struct device' as the argument? Else it becomes
impossible to get 'struct device' from 'hpriv' if we need to call e.g.
pm_runtime_*() APIs.
The plan for is for this function to go away once we have a
devm version of of_clk_get, so if you need to put pm_runtime_calls
somewhere, please don't put them here. This sounds like something which
should go in enable / disable resources instead ?
OK. I need to add pm_runtime_enable() + pm_runtime_get_sync() during
initialization and pm_runtime_put_sync() + pm_runtime_disable() during cleanup.
If ahci_platform_enable/disable_resources is the right place then we must be
able to access struct device from there.
Is it a good to add 'struct device *dev' into the 'struct ahci_host_priv'?
Then you can leave this series as is and i'll add a new patch for that.
If there is a better way, please let me know.
cheers,
-roger
--
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/groups/opt_out.
[linux-sunxi] Re: [PATCH v5 07/14] ahci-platform: Library-ise ahci_probe functionality
Hi,
On 01/27/2014 12:03 PM, Roger Quadros wrote:
On 01/27/2014 12:51 PM, Hans de Goede wrote:
Hi,
On 01/27/2014 11:39 AM, Roger Quadros wrote:
Hi,
On 01/22/2014 09:04 PM, Hans de Goede wrote:
snip
--- a/include/linux/ahci_platform.h
+++ b/include/linux/ahci_platform.h
@@ -20,7 +20,13 @@
struct device;
struct ata_port_info;
struct ahci_host_priv;
+struct platform_device;
+/*
+ * Note ahci_platform_data is deprecated. New drivers which need to override
+ * any of these, should instead declare there own platform_driver struct, and
+ * use ahci_platform* functions in their own probe, suspend and resume methods.
+ */
struct ahci_platform_data {
int (*init)(struct device *dev, struct ahci_host_priv *hpriv);
void (*exit)(struct device *dev);
@@ -35,5 +41,13 @@ int ahci_platform_enable_clks(struct ahci_host_priv *hpriv);
void ahci_platform_disable_clks(struct ahci_host_priv *hpriv);
int ahci_platform_enable_resources(struct ahci_host_priv *hpriv);
void ahci_platform_disable_resources(struct ahci_host_priv *hpriv);
+struct ahci_host_priv *ahci_platform_get_resources(
+struct platform_device *pdev);
Why not use 'struct device' as the argument?
Because of calls to platform_get_resource inside the function.
+void ahci_platform_put_resources(struct ahci_host_priv *hpriv);
Can we have 'struct device' as the argument? Else it becomes
impossible to get 'struct device' from 'hpriv' if we need to call e.g.
pm_runtime_*() APIs.
The plan for is for this function to go away once we have a
devm version of of_clk_get, so if you need to put pm_runtime_calls
somewhere, please don't put them here. This sounds like something which
should go in enable / disable resources instead ?
OK. I need to add pm_runtime_enable() + pm_runtime_get_sync() during
initialization and pm_runtime_put_sync() + pm_runtime_disable() during cleanup.
Note that enable / disable resources will get called by (the default
implementations
of) suspend / resume too.
If that is undesirable then I take back what I said before and
ahci_platform_put_resources' prototype should be changed to:
void ahci_platform_put_resources(struct device *dev, struct ahci_host_priv
*hpriv);
And we will need to keep it around even after we get devm_of_clk_get.
If ahci_platform_enable/disable_resources is the right place then we must be
able to access struct device from there.
Right, and if not we need to access it from ahci_platform_put_resources(),
which is in essence the same problem.
Is it a good to add 'struct device *dev' into the 'struct ahci_host_priv'?
Then you can leave this series as is and i'll add a new patch for that.
Normally we get a device * as argument, and get to hpriv like this:
struct ata_host *host = dev_get_drvdata(dev);
struct ahci_host_priv *hpriv = host-private_data;
So having a dev * in hpriv is normally not useful.
But the ata_host gets allocated after the first ahci_platform_enable_resources
call, so we cannot use this there. Likewise disable_resources / put_resources
is used in error handling paths in probe where we don't have an ata_host yet,
so my vote goes to adding a struct device *dev as first argument, like I
suggested above for ahci_platform_put_resources.
This can be done as an add-on patch (if you do don't forget to also fix
ahci_sunxi.c and ahci_imx.c), or I can respin my series to have this from
day one.
If you want me to do a respin, please let me know which fix you'll need
(the put_resources or the enable/disable one).
Thanks Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] sun5i serial driver kills serial output
On 27-01-14 13:38, jonsm...@gmail.com wrote: Are you running the Fedora image? console doesn't work for me on the Fedora image but it works fine on a Linaro image. I haven't checked but Fedora image probably isn't starting getty on the console. Can't even interact with u-boot etc oliver On Mon, Jan 27, 2014 at 5:23 AM, Olliver Schinagl oliver+l...@schinagl.nl wrote: On 26-01-14 21:50, Michal Suchanek wrote: Hello, I set up a13 with the SD breakout board and while u-boot console and early kernel messages show fine initializing the sunxi serial driver stops any kernel messages from appearing. Disabling the serial driver in script.bin solves the issue but does not allow for communicating with the Linux system over the serial port. Anyone else is seeing such issue? Yes, I noticed the exact same thing on an A13 tablet, it was spewing all the debug stuff as usual, but wouldn't respond to input. I wasn't overly interested so gave up, this was using the mUSB breakout board. oliver 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/groups/opt_out. -- 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/groups/opt_out.
Re[2]: [linux-sunxi] Re: sun7i_tvd and cubietruck A20
Hi masters. Thanks for reply, even so sad. Yes information is weak, and one that is available, morely puts questions rather than gets answers. Had you tried to get more documentation from Allwinner ? Is it realistic ? I have wrote them but no reply ( yet ? ). Vladimir. Четверг, 23 января 2014, 7:27 -08:00 от Rosimildo DaSilva rosimi...@gmail.com: As Enrico said earlier in this thread, it is pointless to start any work without a working setup, even if using blobs from AW drops and using their distro. All we have are 4 pins that we don't even know if more than a resistor and a connector is required, which TV modes are supported, etc. Without a proper documentation and a working system, it is hard to start. The boards providers should at least provide examples of working prototypes, even if crap drivers... but not even that is provided. R On Thursday, January 23, 2014 3:59:16 AM UTC-6, Olliver Schinagl wrote: Hey vladimir On 23-01-14 05:06, za...@mail.ru wrote: Hi masters. I'd like to ask you about your progress with a sun7i_tvd driver none, nobody is working on it. I tried but haven't got any answer from A20-boards suppliers. They dont' know, nor care about customers; they just sell you their crap; and that's that. They rely on Allwinner supplied BBSP. The strange situations... as usual :) ( I don't found the driver in linux-sunxi-sunxi 3.4, only in ...linux-sunxi-import-lichee-3.3-a20-dev. sunxi-3.4 is our community maintained driver; lichee-3.3 is allwinner supplied BSP driver, they have a driver, we don't What means that in forther release it was removed ?? ) No, that means, we haven't ported their driver yet. We'll be looking forward for your patch :) So what do you think is it a chance to get a working TVins in Allwinner (the only interesting feature of this SoC) ? 0 - 100 %. If you put in the effort in porting it; we can add it and it's good. Otherwise, it requires someone interested to port the driver. Best regards, Vladimir. Make sure to check out the community wiki, http://linux-sunxi.org Oliver -- You received this message because you are subscribed to a topic in the Google Groups linux-sunxi group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/linux-sunxi/9dAldgInrkw/unsubscribe . To unsubscribe from this group and all of its topics, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out . -- Vova Brovkovich -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH v5 07/14] ahci-platform: Library-ise ahci_probe functionality
On 01/27/2014 01:28 PM, Hans de Goede wrote:
Hi,
On 01/27/2014 12:03 PM, Roger Quadros wrote:
On 01/27/2014 12:51 PM, Hans de Goede wrote:
Hi,
On 01/27/2014 11:39 AM, Roger Quadros wrote:
Hi,
On 01/22/2014 09:04 PM, Hans de Goede wrote:
snip
--- a/include/linux/ahci_platform.h
+++ b/include/linux/ahci_platform.h
@@ -20,7 +20,13 @@
struct device;
struct ata_port_info;
struct ahci_host_priv;
+struct platform_device;
+/*
+ * Note ahci_platform_data is deprecated. New drivers which need to
override
+ * any of these, should instead declare there own platform_driver
struct, and
+ * use ahci_platform* functions in their own probe, suspend and resume
methods.
+ */
struct ahci_platform_data {
int (*init)(struct device *dev, struct ahci_host_priv *hpriv);
void (*exit)(struct device *dev);
@@ -35,5 +41,13 @@ int ahci_platform_enable_clks(struct ahci_host_priv
*hpriv);
void ahci_platform_disable_clks(struct ahci_host_priv *hpriv);
int ahci_platform_enable_resources(struct ahci_host_priv *hpriv);
void ahci_platform_disable_resources(struct ahci_host_priv *hpriv);
+struct ahci_host_priv *ahci_platform_get_resources(
+struct platform_device *pdev);
Why not use 'struct device' as the argument?
Because of calls to platform_get_resource inside the function.
+void ahci_platform_put_resources(struct ahci_host_priv *hpriv);
Can we have 'struct device' as the argument? Else it becomes
impossible to get 'struct device' from 'hpriv' if we need to call e.g.
pm_runtime_*() APIs.
The plan for is for this function to go away once we have a
devm version of of_clk_get, so if you need to put pm_runtime_calls
somewhere, please don't put them here. This sounds like something which
should go in enable / disable resources instead ?
OK. I need to add pm_runtime_enable() + pm_runtime_get_sync() during
initialization and pm_runtime_put_sync() + pm_runtime_disable() during
cleanup.
Note that enable / disable resources will get called by (the default
implementations
of) suspend / resume too.
If that is undesirable then I take back what I said before and
ahci_platform_put_resources' prototype should be changed to:
void ahci_platform_put_resources(struct device *dev, struct ahci_host_priv
*hpriv);
And we will need to keep it around even after we get devm_of_clk_get.
If ahci_platform_enable/disable_resources is the right place then we must be
able to access struct device from there.
Right, and if not we need to access it from ahci_platform_put_resources(),
which is in essence the same problem.
Is it a good to add 'struct device *dev' into the 'struct ahci_host_priv'?
Then you can leave this series as is and i'll add a new patch for that.
Normally we get a device * as argument, and get to hpriv like this:
struct ata_host *host = dev_get_drvdata(dev);
struct ahci_host_priv *hpriv = host-private_data;
So having a dev * in hpriv is normally not useful.
But the ata_host gets allocated after the first ahci_platform_enable_resources
call, so we cannot use this there. Likewise disable_resources / put_resources
is used in error handling paths in probe where we don't have an ata_host yet,
so my vote goes to adding a struct device *dev as first argument, like I
suggested above for ahci_platform_put_resources.
This can be done as an add-on patch (if you do don't forget to also fix
ahci_sunxi.c and ahci_imx.c), or I can respin my series to have this from
day one.
If you want me to do a respin, please let me know which fix you'll need
(the put_resources or the enable/disable one).
For now I'm using get/put_resources to enable runtime PM and enable the device
like in the below patch.
I'll make the necessary changes to ahci_platform_put_resources();
cheers,
-roger
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 5ec6fe6..965f4b4 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -23,6 +23,7 @@
#include linux/platform_device.h
#include linux/libata.h
#include linux/ahci_platform.h
+#include linux/pm_runtime.h
#include ahci.h
static void ahci_host_stop(struct ata_host *host);
@@ -233,6 +234,9 @@ struct ahci_host_priv *ahci_platform_get_resources(
}
}
+ pm_runtime_enable(dev);
+ pm_runtime_get_sync(dev);
+
return hpriv;
free_clk:
@@ -246,6 +250,9 @@ void ahci_platform_put_resources(struct ahci_host_priv
*hpriv)
{
int c;
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
+
for (c = 0; c AHCI_MAX_CLKS hpriv-clks[c]; c++)
clk_put(hpriv-clks[c]);
}
@@ -478,6 +485,11 @@ int ahci_platform_resume(struct device *dev)
if (rc)
goto disable_resources;
+ /* We resumed so update PM runtime state */
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
[linux-sunxi] Re: [PATCH] sunxi: dts: add a note that memory size is adjusted by boot loader.
Hi Ian, Hans, On Sat, Jan 25, 2014 at 12:03:16PM +0100, Hans de Goede wrote: Hmm, I've no idea what the default / preferred way of handling this is, I assume Maxime knows, so lets wait for his input on this. I got the habit of setting the memory node to the max size the RAM controller can handle from previous work on imx, but I don't really have a preferrence here. If that confuses people, we can just remove it from the DTSI altogether. It will be patched by u-boot anyway, and we won't have to create DTS variants this way. Just don't do it for the A31 for the moment, since we don't have DT-enabled u-boot for now. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v2 0/5] ARM: sun6i: Add support for the A31 I2C controller
Hi Wolfram, On Mon, Jan 13, 2014 at 11:34:48AM +0100, Maxime Ripard wrote: Hi everyone, This patchset adds support the A31 i2c controller. This is mostly the same controller as the one found in the other Allwinner SoCs, except for the interrupts acking. On the other SoCs using this driver, the interrupts are acked by clearing the INT_FLAG bit in the control register, while on the A31, the interrupt is acked by writing that bit into the control register. The other difference is that the I2C IP is maintained in reset by a reset controller, so we're adding optionnal support for the reset framework in the driver to deassert the device from reset. Do you have any comments on this? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v2 2/5] clk: sunxi: Add USB clock register defintions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 01/27/2014 03:43 PM, Maxime Ripard wrote:
Hi Hans,
Mostly looking good, but I have a few comments below.
On Wed, Jan 22, 2014 at 10:36:24PM +0100, Hans de Goede wrote:
From: Roman Byshko rbys...@gmail.com
Add register definitions for the usb-clk register found on sun4i, sun5i and
sun7i SoCs.
Signed-off-by: Roman Byshko rbys...@gmail.com Signed-off-by: Hans de Goede
hdego...@redhat.com --- Documentation/devicetree/bindings/clock/sunxi.txt
| 5 + drivers/clk/sunxi/clk-sunxi.c | 12
2 files changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt index 79c7197..8bccb6a
100644 --- a/Documentation/devicetree/bindings/clock/sunxi.txt +++
b/Documentation/devicetree/bindings/clock/sunxi.txt @@ -37,6 +37,8 @@
Required properties: allwinner,sun6i-a31-apb2-gates-clk - for the APB2
gates on A31 allwinner,sun4i-mod0-clk - for the module 0 family of clocks
allwinner,sun7i-a20-out-clk - for the external output clocks +
allwinner,sun4i-usb-gates-clk - for usb gates + resets on A10 / A20 +
allwinner,sun5i-a13-usb-gates-clk - for usb gates + resets on A13
Maybe we can just remove the gates from there? Even though they are gates,
they are also (a bit) more than that.
To be clear you mean s/usb-gates-clk/usb-clk/ right ?
That sounds reasonable :)
Required properties for all clocks: - reg : shall be the control register
address for the clock. @@ -49,6 +51,9 @@ Required properties for all clocks:
Additionally, allwinner,*-gates-clk clocks require: - clock-output-names :
the corresponding gate names that the clock controls
+And allwinner,*-usb-gates-clk clocks also require: +- reset-cells : shall
be set to 1 +
You should also document what value we should put in the cells, and where to
refer to to find the right one.
Ok.
Clock consumers should specify the desired clocks they use with a clocks
phandle cell. Consumers that are using a gated clock should provide an
additional ID in their clock property. This ID is the diff --git
a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c index
f1a147c..18cbc3c 100644 --- a/drivers/clk/sunxi/clk-sunxi.c +++
b/drivers/clk/sunxi/clk-sunxi.c @@ -813,6 +813,16 @@ static const struct
gates_data sun4i_ahb_gates_data __initconst = { .mask = {0x7F77FFF,
0x14FB3F}, };
+static const struct gates_data sun4i_usb_gates_data __initconst = { +
.mask = {0x1C0}, + .reset_mask = 0x07, +}; + +static const struct
gates_data sun5i_a13_usb_gates_data __initconst = { +.mask = {0x140}, +
.reset_mask = 0x03, +}; +
I guess that means that we will have the OHCI0 gate declared with
...-gates-clk 6, while it's actually the first gate for this clock?
Correct.
Maybe introducing an offset field in the gates_data would be a good idea, so
that we always start from indexing the gates from 0 in the DT?
Well for the other gates type clks we also have holes in the range, and
we always refer to the clk with the bit number in the reg as the clock-cell
value.
Here the hole just happens to be at the start, but it seems best to me
to be consistent and keep using the bit nr inside the reg as clock-cell
value, without an offset.
static const struct gates_data sun5i_a10s_ahb_gates_data __initconst = {
.mask = {0x147667e7, 0x185915}, }; @@ -1159,6 +1169,8 @@ static const struct
of_device_id clk_gates_match[] __initconst = { {.compatible =
allwinner,sun6i-a31-apb1-gates-clk, .data = sun6i_a31_apb1_gates_data,},
{.compatible = allwinner,sun7i-a20-apb1-gates-clk, .data =
sun7i_a20_apb1_gates_data,}, {.compatible =
allwinner,sun6i-a31-apb2-gates-clk, .data = sun6i_a31_apb2_gates_data,},
+ {.compatible = allwinner,sun4i-usb-gates-clk, .data =
sun4i_usb_gates_data,}, + {.compatible =
allwinner,sun5i-a13-usb-gates-clk, .data = sun5i_a13_usb_gates_data,}, {}
};
Thanks a lot! Maxime
Regards,
Hans
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLmcxYACgkQF3VEtJrzE/vjVgCfT8pMd/WAl2lr5HVURDcr6zz6
pDsAnjStUQa3j6WGOHPstjO2kV3WwkKO
=ozuq
-END PGP SIGNATURE-
--
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/groups/opt_out.
[linux-sunxi] Re: [PATCH v2 0/5] clk: sunxi: Add support for USB clocks and reset bits
On Wed, Jan 22, 2014 at 10:36:22PM +0100, Hans de Goede wrote: Hi Emilio, Maxime, et al, Emilio, here is v2 of my patch-set adding support for sunxi-clk USB clocks and reset bits. This addresses all your review comments from v1. Can you add the first 2 patches to your queue of patches for Mike for 3.15 ? Maxime, can you add patch 3-5 which add the dt bindings for this to your tree please ? Apart from the comments I had on patch 2, it looks good for me. Once we agree on something, you have my Acked-by. Thanks for working on this! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
Hi, On Fri, Jan 17, 2014 at 02:47:29PM +0800, Chen-Yu Tsai wrote: Signed-off-by: Chen-Yu Tsai w...@csie.org --- .../devicetree/bindings/rfkill/rfkill-gpio.txt | 26 ++ net/rfkill/rfkill-gpio.c | 23 +++ 2 files changed, 49 insertions(+) create mode 100644 Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt new file mode 100644 index 000..8a07ea4 --- /dev/null +++ b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt @@ -0,0 +1,26 @@ +GPIO controlled RFKILL devices + +Required properties: +- compatible : Must be rfkill-gpio. +- rfkill-name: Name of RFKILL device +- rfkill-type: Type of RFKILL device: 1 for WiFi, 2 for BlueTooth +- NAME_shutdown-gpios: GPIO phandle to shutdown control + (phandle must be the second) Can't it be handled by a regulator? +- NAME_reset-gpios : GPIO phandle to reset control And this one using the reset framework? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] 24-bit Audio Isn't Working
Yes we did and we're submitting our kernel patches. Right now we're only submitting changes for HDMI since that is all we have tested. The code changes can be easily applied to I2S and S/PDIF and when I get a chance I'll yest that hardware and submit more patches. On Jan 27, 2014 6:13 AM, turker...@gmail.com wrote: On Friday, January 17, 2014 9:16:18 PM UTC+4, George Ioakimedes wrote: We're getting closer. I was able to meet briefly with Allwinner at CES and they are helping us now. We are very close now I think and with some luck we may solve this over the weekend. Hi George. Could you manage to get 24-bit audio? Regards, Ali -- You received this message because you are subscribed to a topic in the Google Groups linux-sunxi group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/linux-sunxi/BylDdcI-2HA/unsubscribe. To unsubscribe from this group and all of its topics, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH 1/4] clk: sunxi: Add support for PLL6 on the A31
Hi Mike, On Fri, Jan 17, 2014 at 02:14:02PM -0800, Mike Turquette wrote: Quoting Maxime Ripard (2014-01-16 09:11:22) The A31 has a slightly different PLL6 clock. Add support for this new clock in our driver. Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com This looks good to me. I guess it will be going in for 3.15 based on the comments in the coverletter. Yes, indeed it is 3.15 materials. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Re: Passing the platform data for SPI device
Em quinta-feira, 23 de janeiro de 2014 17h24min27s UTC-3, Tomas Novotny
escreveu:
On Thu, 23 Jan 2014 19:11:32 +0100, Gustavo Zamboni
gustavozamb...@gmail.com wrote:
Hi Gustavo,
Why dont you just add the device to the fex file ??
activate your spix_para parameters
and add something like:
|[spi_devices]|
spi_dev_num=1
|[spi_board0]|
|modalias| |= |||mcp251x
|max_speed_hz| |= ||1200|
|bus_num| |= ||1|
|chip_select| |= ||0|
|mode| |= ||3|
|full_duplex| |= ||0|
|manual_cs| |= ||0|
With spidev it works well with modalias spidev.
yes, this is exactly what I did. I was trying both spidev and mcp251x. There
is no problem with spidev (it is currently working) but for mcp251x I need to
pass (very simple) platform data with oscillator frequency. The mcp251x is
being initialized during boot but it fails because of missing platform data.
I don't know if there is some clean way how to pass platform data
of the mcp251x driver. I think that FEX is not able to do that (there is no
handling in sunxi spi).
Thanks for you answer,
Tomas
Gustavo Zamboni
Le 23/01/2014 18:03, vinicius...@gmail.com a écrit :
Em quinta-feira, 23 de janeiro de 2014 13h59min19s UTC-3,
vinic...@gmail.com escreveu:
Em terça-feira, 21 de janeiro de 2014 08h44min19s UTC-3, Tomas Novotny
escreveu:
Hi All,
I'm trying to use some SPI devices on A10s OLinuXino. It was flawless
for
simple MCU driven by spidev (everything needed is defined in FEX). Now
I'm
trying to connect external CAN over SPI (MCP2515).
The mcp251x driver needs to pass oscillator frequency through
the
mcp251x_platform_data structure. Is there any clean way how to do it on
3.4
linux-sunxi? It seems that platform data for SPI board aren't passed by
sunxi
SPI driver.
I'm using Debian image with custom built 3.4.61 linux-sunxi.
Thanks to all,
Tomas
You can change by yourself spi_sunxi.c, something like that:
diff --git a/drivers/spi/spi_sunxi.c b/drivers/spi/spi_sunxi.c
index a3792fd..2f0ab7c 100644
--- a/drivers/spi/spi_sunxi.c
+++ b/drivers/spi/spi_sunxi.c
@@ -28,6 +28,7 @@
#include linux/spi/spi.h
#include linux/spi/spi_bitbang.h
+#include linux/can/platform/mcp251x.h
#include asm/io.h
#include plat/dma.h
@@ -134,6 +135,10 @@ struct sunxi_spi {
int cs_bitmap;/* cs0- 0x1; cs1-0x2, cs0cs1-0x3. */
};
+static struct mcp251x_platform_data mcp251x_info = {
+ .oscillator_frequency = 800,
+};
+
Sorry, something like that:
diff --git a/drivers/spi/spi_sunxi.c b/drivers/spi/spi_sunxi.c
index a3792fd..2f0ab7c 100644
--- a/drivers/spi/spi_sunxi.c
+++ b/drivers/spi/spi_sunxi.c
@@ -28,6 +28,7 @@
#include linux/spi/spi.h
#include linux/spi/spi_bitbang.h
+#include linux/can/platform/mcp251x.h
#include asm/io.h
#include plat/dma.h
@@ -134,6 +135,10 @@ struct sunxi_spi {
int cs_bitmap;/* cs0- 0x1; cs1-0x2, cs0cs1-0x3. */
};
+static struct mcp251x_platform_data mcp251x_info = {
+ .oscillator_frequency = 800,
+};
+
/* config chip select */
s32 aw_spi_set_cs(u32 chipselect, void *base_addr)
{
@@ -1922,6 +1927,7 @@ int __devinit spi_sunxi_register_spidev(void)
{
board = spi_boards[i];
sprintf(spi_board_name, spi_board%d, i);
+board-platform_data = mcp251x_info;
ret = script_parser_fetch(spi_board_name, modalias,
(void*)board-modalias, sizeof(char*));
if(ret != SCRIPT_PARSER_OK) {
spi_msg(Get spi devices modalias failed\n);
Hi Tomas,
your fex is ok, now you just change spi_sunxi.c as suggested or the way you
think best, that is enough.
--
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/groups/opt_out.
Re: [linux-sunxi] 24-bit Audio Isn't Working
I've just submitted the patch. Pat On Monday, January 27, 2014 7:33:07 AM UTC-5, turk...@gmail.com wrote: On Friday, January 17, 2014 9:16:18 PM UTC+4, George Ioakimedes wrote: We're getting closer. I was able to meet briefly with Allwinner at CES and they are helping us now. We are very close now I think and with some luck we may solve this over the weekend. Hi George. Could you manage to get 24-bit audio? Regards, Ali -- 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/groups/opt_out.
[linux-sunxi] [PATCH 3.4] sunxi-hdmiaudio: Enable 32-bit audio
The original modifications for this patch originate from some custom
changes made to the 3.3 Android kernel by huangxin at allwinnertech.com.
The A10/A20 DMA engine for HDMI audio only supports 16 or 32-bit
transfers. The documentation says 16, 20, and 24 bits, but I have not
been able to get 24-bit audio, ether 3-bytes (PCM_FMTBIT_24_3LE) or
4-bytes (PCM_FMTBIT_24_LE) to work.
This patch removes the non-working PCM formats, PCM_FMTBIT_S18_3LE
and PCM_FMTBIT_S20_3LE, and PCM_FMTBIT_S24_LE and adds suppor for
32-bit HDMI audio (PCM_FMTBIT_S32_LE). It's possible that other 32-bit
formats, like PCM_FMTBIT_U32_LE or PCM_FMTBIT_FLOAT_LE might work, but
couldn't be tested.
This patch was tested with 24-bit and 32-bit .wav files and the ALSA
plughw plugin (for upconverting the 24-bit audio files to 23-bits)
with aplay -v to verify that the target format was S32_LE.
Signed-off-by: Patrick Wood patrickhw...@gmail.com
---
drivers/video/sunxi/hdmi/drv_hdmi.c |6 ++
drivers/video/sunxi/hdmi/hdmi_core.c| 30 +--
drivers/video/sunxi/hdmi/hdmi_core.h|1 +
include/linux/drv_hdmi.h|1 +
sound/soc/sunxi/hdmiaudio/sndhdmi.c | 16 +-
sound/soc/sunxi/hdmiaudio/sunxi-hdmiaudio.c |6 --
sound/soc/sunxi/hdmiaudio/sunxi-hdmipcm.c |3 ++-
7 files changed, 53 insertions(+), 10 deletions(-)
diff --git a/drivers/video/sunxi/hdmi/drv_hdmi.c
b/drivers/video/sunxi/hdmi/drv_hdmi.c
index a8d3cef..283d2ae 100644
--- a/drivers/video/sunxi/hdmi/drv_hdmi.c
+++ b/drivers/video/sunxi/hdmi/drv_hdmi.c
@@ -208,6 +208,12 @@ static __s32 Hdmi_Set_Audio_Para(hdmi_audio_t *audio_para)
if (!audio_para)
return -1;
+ if (audio_para-sample_bit != audio_info.sample_bit) {
+ if (hdmi_state = HDMI_State_Audio_config)
+ hdmi_state = HDMI_State_Audio_config;
+ audio_info.sample_bit = audio_para-sample_bit;
+ }
+
if (audio_para-sample_rate != audio_info.sample_rate) {
audio_info.sample_rate = audio_para-sample_rate;
change = audio_info.audio_en;
diff --git a/drivers/video/sunxi/hdmi/hdmi_core.c
b/drivers/video/sunxi/hdmi/hdmi_core.c
index c1c4c9c..a6dd01f 100644
--- a/drivers/video/sunxi/hdmi/hdmi_core.c
+++ b/drivers/video/sunxi/hdmi/hdmi_core.c
@@ -580,8 +580,14 @@ __s32 audio_config(void)
return 0;
if (audio_info.channel_num == 1) {
- /* audio fifo rst and select ddma, 2 ch 16bit pcm */
- writel(0x, HDMI_AUDIO_UNKNOWN_0);
+ if (audio_info.sample_bit == 32) {
+ /* audio fifo rst and select ddma, 2 ch 32bit pcm */
+ writel(0x000e, HDMI_AUDIO_UNKNOWN_0);
+ } else {
+ /* audio fifo rst and select ddma, 2 ch 16bit pcm */
+ writel(0x, HDMI_AUDIO_UNKNOWN_0);
+ }
+
/* ddma,pcm layout0 1ch */
writel(0x, HDMI_AUDIO_LAYOUT);
writel(0x76543200, HDMI_AUDIO_UNKNOWN_1);
@@ -592,8 +598,14 @@ __s32 audio_config(void)
writel(0x, HDMI_AUDIO_INFOFRAME + 8);
writel(0x, HDMI_AUDIO_INFOFRAME + 12);
} else if (audio_info.channel_num == 2) {
- /* audio fifo rst and select ddma, 2 ch 16bit pcm */
- writel(0x, HDMI_AUDIO_UNKNOWN_0);
+ if (audio_info.sample_bit == 32) {
+ /* audio fifo rst and select ddma, 2 ch 32bit pcm */
+ writel(0x000e, HDMI_AUDIO_UNKNOWN_0);
+ } else {
+ /* audio fifo rst and select ddma, 2 ch 16bit pcm */
+ writel(0x, HDMI_AUDIO_UNKNOWN_0);
+ }
+
/* ddma,pcm layout0 2ch */
writel(0x0001, HDMI_AUDIO_LAYOUT);
writel(0x76543210, HDMI_AUDIO_UNKNOWN_1);
@@ -604,8 +616,14 @@ __s32 audio_config(void)
writel(0x, HDMI_AUDIO_INFOFRAME + 8);
writel(0x, HDMI_AUDIO_INFOFRAME + 12);
} else if (audio_info.channel_num == 8) {
- /* audio fifo rst and select ddma, 2 ch 16bit pcm */
- writel(0x, HDMI_AUDIO_UNKNOWN_0);
+ if (audio_info.sample_bit == 32) {
+ /* audio fifo rst and select ddma, 2 ch 32bit pcm */
+ writel(0x000e, HDMI_AUDIO_UNKNOWN_0);
+ } else {
+ /* audio fifo rst and select ddma, 2 ch 16bit pcm */
+ writel(0x, HDMI_AUDIO_UNKNOWN_0);
+ }
+
/* ddma,pcm layout1 8ch */
writel(0x000f, HDMI_AUDIO_LAYOUT);
writel(0x76543210, HDMI_AUDIO_UNKNOWN_1);
diff --git a/drivers/video/sunxi/hdmi/hdmi_core.h
Re: [linux-sunxi] Re: Passing the platform data for SPI device
On Mon, 27 Jan 2014 08:42:51 -0800 (PST), vinicius...@gmail.com
vinicius...@gmail.com wrote:
Em quinta-feira, 23 de janeiro de 2014 17h24min27s UTC-3, Tomas Novotny
escreveu:
On Thu, 23 Jan 2014 19:11:32 +0100, Gustavo Zamboni
gustavozamb...@gmail.com wrote:
Hi Gustavo,
Why dont you just add the device to the fex file ??
activate your spix_para parameters
and add something like:
|[spi_devices]|
spi_dev_num=1
|[spi_board0]|
|modalias| |= |||mcp251x
|max_speed_hz| |= ||1200|
|bus_num| |= ||1|
|chip_select| |= ||0|
|mode| |= ||3|
|full_duplex| |= ||0|
|manual_cs| |= ||0|
With spidev it works well with modalias spidev.
yes, this is exactly what I did. I was trying both spidev and mcp251x. There
is no problem with spidev (it is currently working) but for mcp251x I need
to
pass (very simple) platform data with oscillator frequency. The mcp251x is
being initialized during boot but it fails because of missing platform data.
I don't know if there is some clean way how to pass platform data
of the mcp251x driver. I think that FEX is not able to do that (there is no
handling in sunxi spi).
Thanks for you answer,
Tomas
Gustavo Zamboni
Le 23/01/2014 18:03, vinicius...@gmail.com a écrit :
Em quinta-feira, 23 de janeiro de 2014 13h59min19s UTC-3,
vinic...@gmail.com escreveu:
Em terça-feira, 21 de janeiro de 2014 08h44min19s UTC-3, Tomas Novotny
escreveu:
Hi All,
I'm trying to use some SPI devices on A10s OLinuXino. It was flawless
for
simple MCU driven by spidev (everything needed is defined in FEX).
Now I'm
trying to connect external CAN over SPI (MCP2515).
The mcp251x driver needs to pass oscillator frequency through
the
mcp251x_platform_data structure. Is there any clean way how to do it
on 3.4
linux-sunxi? It seems that platform data for SPI board aren't passed
by sunxi
SPI driver.
I'm using Debian image with custom built 3.4.61 linux-sunxi.
Thanks to all,
Tomas
You can change by yourself spi_sunxi.c, something like that:
diff --git a/drivers/spi/spi_sunxi.c b/drivers/spi/spi_sunxi.c
index a3792fd..2f0ab7c 100644
--- a/drivers/spi/spi_sunxi.c
+++ b/drivers/spi/spi_sunxi.c
@@ -28,6 +28,7 @@
#include linux/spi/spi.h
#include linux/spi/spi_bitbang.h
+#include linux/can/platform/mcp251x.h
#include asm/io.h
#include plat/dma.h
@@ -134,6 +135,10 @@ struct sunxi_spi {
int cs_bitmap;/* cs0- 0x1; cs1-0x2, cs0cs1-0x3. */
};
+static struct mcp251x_platform_data mcp251x_info = {
+ .oscillator_frequency = 800,
+};
+
Sorry, something like that:
diff --git a/drivers/spi/spi_sunxi.c b/drivers/spi/spi_sunxi.c
index a3792fd..2f0ab7c 100644
--- a/drivers/spi/spi_sunxi.c
+++ b/drivers/spi/spi_sunxi.c
@@ -28,6 +28,7 @@
#include linux/spi/spi.h
#include linux/spi/spi_bitbang.h
+#include linux/can/platform/mcp251x.h
#include asm/io.h
#include plat/dma.h
@@ -134,6 +135,10 @@ struct sunxi_spi {
int cs_bitmap;/* cs0- 0x1; cs1-0x2, cs0cs1-0x3. */
};
+static struct mcp251x_platform_data mcp251x_info = {
+ .oscillator_frequency = 800,
+};
+
/* config chip select */
s32 aw_spi_set_cs(u32 chipselect, void *base_addr)
{
@@ -1922,6 +1927,7 @@ int __devinit spi_sunxi_register_spidev(void)
{
board = spi_boards[i];
sprintf(spi_board_name, spi_board%d, i);
+board-platform_data = mcp251x_info;
ret = script_parser_fetch(spi_board_name, modalias,
(void*)board-modalias, sizeof(char*));
if(ret != SCRIPT_PARSER_OK) {
spi_msg(Get spi devices modalias failed\n);
Hi Tomas,
your fex is ok, now you just change spi_sunxi.c as suggested or the way you
think best, that is enough.
Hi Vinicius,
finally the osc frequency was harcoded to mcp251x driver and the device is
now being initialized. I was just curious if there is some clean way.
Unfortunately mcp chip is not working yet as there is some problem
with communication over spi. I will check spi with some analyzer soon. But
this is different story...
Thanks
[linux-sunxi] [PATCH 3.4] sunxi:axp20x: Enable internal thermal monitoring
Enable the internal thermal monitoring support of AXP20X chips
Cherry-picked from:
https://github.com/cubieboard/linux-sunxi/commit/e4144b3ce62b1d7014fee36b84bc65c812469822
Creates the sysfs file temp1_input in the sunxi-i2c tree that reports the
AXP's temperature in degrees C.
According to the AXP202's datasheet, this port outputs a 12-bit value
where 0x000 == -144.7C and 0xfff == 264.8C in 0.1 degree C increments.
Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com
Signed-off-by: Hans de Goede hdego...@redhat.com
Signed-off-by: Patrick Wood patrickhw...@gmail.com
---
drivers/power/axp_power/Kconfig |5 ++
drivers/power/axp_power/axp-mfd.c |7 +++
drivers/power/axp_power/axp20-mfd.h | 112 +++
include/linux/mfd/axp-mfd.h |7 +++
4 files changed, 130 insertions(+)
diff --git a/drivers/power/axp_power/Kconfig b/drivers/power/axp_power/Kconfig
index 039679f..b76f517 100644
--- a/drivers/power/axp_power/Kconfig
+++ b/drivers/power/axp_power/Kconfig
@@ -36,4 +36,9 @@ config AXP_CHGCHANGE
bool AXP charging current set when suspend\resume\shutdown
default y
+config AXP_HWMON
+ depends on HWMON
+ bool Enable the internal thermal monitoring support of AXP20X chips
+ default y
+
endif # !AW_AXP
diff --git a/drivers/power/axp_power/axp-mfd.c
b/drivers/power/axp_power/axp-mfd.c
index 9af0257..cfa894a 100644
--- a/drivers/power/axp_power/axp-mfd.c
+++ b/drivers/power/axp_power/axp-mfd.c
@@ -363,6 +363,13 @@ static int __devexit axp_mfd_remove(struct i2c_client
*client)
pm_power_off = NULL;
axp = NULL;
+#ifdef CONFIG_AXP_HWMON
+ if (chip-itm_enabled == 1) {
+ hwmon_device_unregister(chip-hwmon_dev);
+ sysfs_remove_group(client-dev.kobj, axp20_group);
+ }
+#endif
+
axp_mfd_remove_subdevs(chip);
kfree(chip);
return 0;
diff --git a/drivers/power/axp_power/axp20-mfd.h
b/drivers/power/axp_power/axp20-mfd.h
index 1c7a41b..214856e 100644
--- a/drivers/power/axp_power/axp20-mfd.h
+++ b/drivers/power/axp_power/axp20-mfd.h
@@ -22,6 +22,83 @@
#include axp-rw.h
+#ifdef CONFIG_AXP_HWMON
+
+#include linux/hwmon-sysfs.h
+#include linux/hwmon.h
+#include linux/err.h
+
+static struct axp_mfd_chip *axp20_update_device(struct device *dev);
+
+static ssize_t
+show_temp(struct device *dev, struct device_attribute *devattr, char *buf)
+{
+ struct sensor_device_attribute *attr = to_sensor_dev_attr(devattr);
+ struct axp_mfd_chip *data = axp20_update_device(dev);
+ if (attr-index == 1)
+ return sprintf(buf, 264800\n);
+ if (attr-index == 2)
+ return sprintf(buf, -144700\n);
+ return sprintf(buf, %d\n, data-temperature * 100);
+}
+
+
+static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp, NULL, 0);
+static SENSOR_DEVICE_ATTR(temp1_max, S_IRUGO, show_temp, NULL, 1);
+static SENSOR_DEVICE_ATTR(temp1_min, S_IRUGO, show_temp, NULL, 2);
+
+static struct attribute *axp20_attributes[] = {
+ sensor_dev_attr_temp1_input.dev_attr.attr,
+ sensor_dev_attr_temp1_min.dev_attr.attr,
+ sensor_dev_attr_temp1_max.dev_attr.attr,
+ NULL
+};
+
+static const struct attribute_group axp20_group = {
+ .attrs = axp20_attributes,
+};
+
+
+/*
+ * * function that update the status of the chips (temperature)
+ * */
+static struct axp_mfd_chip *axp20_update_device(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct axp_mfd_chip *data = i2c_get_clientdata(client);
+ int err;
+ u8 high, low;
+
+ mutex_lock(data-lock);
+
+ if (time_after(jiffies, data-last_updated + HZ * 2)
+ || !data-valid) {
+ dev_dbg(client-dev, Updating axp20 data\n);
+ /* AXP202 datasheet page 25, 0x000 means -144.7,
+* 0xfff means 264.8, 4096 steps of 0.1 degress */
+ err = __axp_read(client, 0x5E, high);
+ if (err) {
+ dev_err(dev, AXP Error while reading high\n);
+ high = 0;
+ }
+
+ err = __axp_read(client, 0x5F, low);
+ if (err) {
+ dev_err(dev, AXP Error while reading low\n);
+ low = 0;
+ }
+
+ data-temperature = -1447 + ((high 4) + (low 0x0F));
+ data-last_updated = jiffies;
+ data-valid = 1;
+ }
+
+ mutex_unlock(data-lock);
+ return data;
+}
+
+#endif
+
static int __devinit axp20_init_chip(struct axp_mfd_chip *chip)
{
@@ -33,6 +110,9 @@ static int __devinit axp20_init_chip(struct axp_mfd_chip
*chip)
POWER20_INTSTS3, 0xff, POWER20_INTSTS4, 0xff,
POWER20_INTSTS5, 0xff };
int err;
+#ifdef CONFIG_AXP_HWMON
+ u8 enabled;
+#endif
/*read chip id*/
err = __axp_read(chip-client, POWER20_IC_TYPE,
[linux-sunxi] Re: [PATCH 3.4 00/11] sunxi-disp: hotplug + dpms support
Hans,
I still have trouble getting the HDMI monitor to come out of suspend
running linaro on CT.
Removing the lines that switch the clock off and back on again seems to
sort the problem. There is probably a deeper underlying issue tho.
Interested if you have any thoughts.
Kind regards,
Phil
diff --git a/drivers/video/sunxi/disp/dev_disp.c
b/drivers/video/sunxi/disp/dev_disp.c
index 9b59810..7463318 100644
--- a/drivers/video/sunxi/disp/dev_disp.c
+++ b/drivers/video/sunxi/disp/dev_disp.c
@@ -548,7 +548,9 @@ int disp_suspend(int clk, int status)
else if (suspend_output_type[i] == DISP_OUTPUT_TYPE_HDMI)
BSP_disp_hdmi_close(i);
}
- BSP_disp_clk_off(clk);
+
+// Dont turn off the clock as it wont start again
+// BSP_disp_clk_off(clk);
suspend_status |= status;
return 0;
@@ -560,7 +562,8 @@ int disp_resume(int clk, int status)
__inf(disp_resume clk %d status %d call\n, clk, status);
- BSP_disp_clk_on(clk);
+// This does not seem to restart the clock
+// BSP_disp_clk_on(clk);
if (clk != 1)
for (i = 0; i 2; i++) {
On Tuesday, 12 February 2013 10:57:33 UTC, Hans de Goede wrote:
This patchset combines the best of Michal Suchanek's, Floris Bos' and my
patches to fix various issues with hotplugging hdmi and adds dpms support.
After this the only remaining known issue is the following
1) If EDID is used, and no EDID is found on bootup so the fallback mode is
selected; and
2) A hdmi/dvi monitor gets plugged in, and its EDID does not advertise
the fallback mode; and
3) X is running
Then the fbcon code will change the mode underneath X to a supported mode,
and
X will show a garbled display. This can be worked around by switching to a
text VC and restarting X. This is more of an Xorg bug then a bug of the
sunxi
fb driver.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] sunxi 3.4: stuttering video playback
Video playback in linaro using cedar and libhybris stutters and sometimes the
frame rate drops very low.
There may be an issue in disp_video.c as the included changes sort the issue
for me.
My possibly flawed reasoning goes something like...
Its not a good idea to update display_cnt in Hal_Set_Frame called during
blanking and BSP_disp_video_set_fb which is called from an IOCTL. The value is
incremented in Hal_Set_Frame and may have been updated (to 0) by a call to
BSP_disp_video_set_fb. The result is calls to ioctl(fd,
DISP_CMD_VIDEO_GET_FRAME_ID, args) never returning the updated frame number
(this I have observed).
Hope this is of some help.
Any thoughts appreciated.
Kind regards,
Phil
diff --git a/drivers/video/sunxi/disp/disp_video.c
b/drivers/video/sunxi/disp/disp_video.c
index aa07364..460def8 100644
--- a/drivers/video/sunxi/disp/disp_video.c
+++ b/drivers/video/sunxi/disp/disp_video.c
@@ -144,11 +144,19 @@ static inline __s32 Hal_Set_Frame(__u32 sel, __u32
tcon_index, __u32 id)
return DIS_FAIL;
}
- if (g_video[sel][id].display_cnt == 0) {
+ __u32 new_id = g_video[sel][id].video_new.id;
+ __u32 cur_id = g_video[sel][id].video_cur.id;
+
+// if (g_video[sel][id].display_cnt == 0) {
+ if (cur_id != new_id) {
g_video[sel][id].pre_frame_addr0 =
g_video[sel][id].video_cur.addr[0];
+
+g_video[sel][id].video_new.id = cur_id;
+
memcpy(g_video[sel][id].video_cur, g_video[sel][id].video_new,
sizeof(__disp_video_fb_t));
+ g_video[sel][id].display_cnt = 0;
}
if (gdisp.screen[sel].layer_manage[id].para.mode ==
@@ -382,6 +390,9 @@ static inline __s32 Hal_Set_Frame(__u32 sel, __u32
tcon_index, __u32 id)
g_video[sel][id].video_cur.addr_right[1];
gdisp.screen[sel].layer_manage[id].para.fb.trd_right_addr[2] =
g_video[sel][id].video_cur.addr_right[2];
+
+ g_video[sel][id].video_cur.id = new_id;
+
return DIS_SUCCESS;
}
@@ -408,7 +419,7 @@ __s32 BSP_disp_video_set_fb(__u32 sel, __u32 hid,
__disp_video_fb_t *in_addr)
memcpy(g_video[sel][hid].video_new, in_addr,
sizeof(__disp_video_fb_t));
g_video[sel][hid].have_got_frame = TRUE;
- g_video[sel][hid].display_cnt = 0;
+// g_video[sel][hid].display_cnt = 0;
return DIS_SUCCESS;
} else
@@ -462,6 +473,7 @@ __s32 BSP_disp_video_start(__u32 sel, __u32 hid)
if (gdisp.screen[sel].layer_manage[hid].status LAYER_USED) {
memset(g_video[sel][hid], 0, sizeof(frame_para_t));
g_video[sel][hid].video_cur.id = -1;
+ g_video[sel][hid].video_new.id = -1;
g_video[sel][hid].enable = TRUE;
video_enhancement_start(sel, hid);
--
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/groups/opt_out.
[linux-sunxi] Re: How to port ubuntu in my A20 board.
Hi Patrick, I downloaded rootfs from this link for armhf . http://cdimage.ubuntu.com/ubuntu-core/releases/13.10/release/ but once i boot i got struck here. 6Freeing init memory: 212K [6.629097] Freeing init memory: 212K 6Write protecting the kernel text section c0008000 - c07d2000 [6.638421] Write protecting the kernel text section c0008000 - c07d2000 30systemd-udevd[165]: starting version 204 4init: plymouth main process (78) killed by ABRT signal 4init: plymouth-splash main process (202) terminated with status 2 4init: failsafe main process (225) killed by TERM signal 4init: plymouth-stop pre-start process (303) terminated with status 1 Regards Punith -- 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/groups/opt_out.
[linux-sunxi] Re: How to port ubuntu in my A20 board.
i downloaded fallowing package. ubuntu-core-13.10-core-armhf.tar.gz Regards Punith -- 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/groups/opt_out.
Re: [linux-sunxi] [PATCH 3.4] sunxi-hdmiaudio: enable low sample-rate HDMI audi
Am 27.01.2014 21:54, schrieb Phil Scull: Low sample rate audio was not playing on patrickhwood/linux-sunxi/tree/pat-3.4.75-ct over HDMI. The following changes result in sound being played, which can be demonstrated with speaker-test. On which devcie did you try ? AFAIK, the HDMI spec does not allow rates below 32kHz. So if that works, it's just good luck. My Yamaha AVR for example would not accept anything these rates. Not even on S/PDIF. -- Ruediger Rudi Ihle -- 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/groups/opt_out.
