Re: NAS for recording DVB-S2
Hi, Am 22.10.2013 10:24, schrieb JPT: I want my NAS to record from USB DVB-S2. [...] I should buy either a Tevii S660 or a Terratec Cynergy S2 Stick. I don't want to have another power supply, so I am going to steal the power from the nas somehow. The Tevii uses 7,5 V which is odd... I cannot find the voltage the Terratec requires. Does anyone own one? Yesterday I recommended the Technisat SkyStar USB HD to s.o. else on this list. Though I'm not beeing employed by or affiliated with Technisat, you might also want to consider it: http://www.linuxtv.org/wiki/index.php/Technisat_SkyStar_USB_HD The driver is in mainline kernel (no patching' around), should work well with ARM (If you want me to test it, I could. There are several ARM-boards (armv6j-hf, armv7-hf) floating around here, I just didn't yet bother to try). The power-supply reads 12V, 1.5A for one device. As you didn't state at what voltage your NAS runs at, it might just fit or be too high (the 12 Volts) for your application. I have a slightly larger NAS (more a less a full blown PC with low-enery components) and I power two of the technisat's off the PC's power supply's 12V rail. And about the price: it looks like that one is even cheaper than the two you proposed. Best regards, Jannis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NAS for recording DVB-S2
2013/10/25 Jannis jannis-li...@kripserver.net: Hi, Am 22.10.2013 10:24, schrieb JPT: I want my NAS to record from USB DVB-S2. [...] I should buy either a Tevii S660 or a Terratec Cynergy S2 Stick. I don't want to have another power supply, so I am going to steal the power from the nas somehow. The Tevii uses 7,5 V which is odd... I cannot find the voltage the Terratec requires. Does anyone own one? Yesterday I recommended the Technisat SkyStar USB HD to s.o. else on this list. Though I'm not beeing employed by or affiliated with Technisat, you might also want to consider it: http://www.linuxtv.org/wiki/index.php/Technisat_SkyStar_USB_HD The driver is in mainline kernel (no patching' around), should work well with ARM (If you want me to test it, I could. There are several ARM-boards (armv6j-hf, armv7-hf) floating around here, I just didn't yet bother to try). From linux perspective, the ARM architecture is very stable. At least I have never had any problem running anything on linux-arm devices. For you solution you have to check if USB subsystem on your device is working stable enough, especially if you are sharing the same USB bus with other speedy devices (like external hard drive or so). /Honza -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
hitel ajánlat
Springleaf Financial Services ®, adunk egy alacsony kamat 3 %-os kölcsönt. Egy jó hírű, jogos és elismert pénzt hitelezési Company.We kölcsön pénzt a pénzügyi segítségnyújtásra szoruló személyek. Van egy rossz hitel, vagy van szükségük a pénzt fizetni a számlákat? Azt akarjuk, hogy használja ezt a médiumot, hogy tájékoztatni Önt megbízható kedvezményezett segítséget is nyújtanak, mint mi felajánljuk Önnek a hitel lesz. Alapján választ akkor postázzuk a hitel jelentkezési lapot kitölteni. Nincs társadalombiztosítási és no credit check, 100 %-os garantált. Mi előre lehetővé teszi számomra, hogy a szolgáltatás az Ön megjelenés. SZÜKSÉGES INFORMÁCIÓK * A nevek: Cím: Telefonszám: Szükséges összeg: Időtartam: Havi jövedelmi szint: Ország: Postai irányítószám: Frederick W. Geissinger. Telefon: +447035993973 Vagy írjon nekünk az: springl...@manager.in.th -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] saa7164: fix return value check in saa7164_initdev()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the function kthread_run() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/media/pci/saa7164/saa7164-core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/saa7164/saa7164-core.c
b/drivers/media/pci/saa7164/saa7164-core.c
index d37ee37..896bd8b 100644
--- a/drivers/media/pci/saa7164/saa7164-core.c
+++ b/drivers/media/pci/saa7164/saa7164-core.c
@@ -1354,9 +1354,11 @@ static int saa7164_initdev(struct pci_dev *pci_dev,
if (fw_debug) {
dev-kthread = kthread_run(saa7164_thread_function, dev,
saa7164 debug);
- if (!dev-kthread)
+ if (IS_ERR(dev-kthread)) {
+ dev-kthread = NULL;
printk(KERN_ERR %s() Failed to create
debug kernel thread\n, __func__);
+ }
}
} /* != BOARD_UNKNOWN */
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: NAS for recording DVB-S2
Am 25.10.2013 09:46, schrieb Honza Petrouš: 2013/10/25 Jannis jannis-li...@kripserver.net: Hi, Am 22.10.2013 10:24, schrieb JPT: I want my NAS to record from USB DVB-S2. [...] I should buy either a Tevii S660 or a Terratec Cynergy S2 Stick. I don't want to have another power supply, so I am going to steal the power from the nas somehow. The Tevii uses 7,5 V which is odd... I cannot find the voltage the Terratec requires. Does anyone own one? Yesterday I recommended the Technisat SkyStar USB HD to s.o. else on this list. Though I'm not beeing employed by or affiliated with Technisat, you might also want to consider it: http://www.linuxtv.org/wiki/index.php/Technisat_SkyStar_USB_HD The driver is in mainline kernel (no patching' around), should work well with ARM (If you want me to test it, I could. There are several ARM-boards (armv6j-hf, armv7-hf) floating around here, I just didn't yet bother to try). Thanks, I will give it a try. This device wasn't listed at my favorite price comparison agent, only the successor TechniSat SkyStar USB 2 HD CI (which doesn't work with linux) at nearly double price. I think I will trust both your statements that it's likeley to work, so it's not necessary to test. Thanks. :) The power-supply reads 12V, 1.5A for one device. As you didn't state at what voltage your NAS runs at, it might just fit or be too high (the 12 Volts) for your application. I have a slightly larger NAS (more a less a full blown PC with low-enery components) and I power two of the technisat's off the PC's power supply's 12V rail. 12 V should be fine. Any device powering hard-drives should offer 12 V somewhere. From linux perspective, the ARM architecture is very stable. At least I have never had any problem running anything on linux-arm devices. For you solution you have to check if USB subsystem on your device is working stable enough, especially if you are sharing the same USB bus with other speedy devices (like external hard drive or so). great, thanks! I won't have any other devices attached that generate a lot of traffic. I believe USB 2.0 and USB 3.0 busses are separate, so it would be a good solution to use one for DVB and the other for anything else in case problems occur. Currently there doesn't exist a kernel for the NAS yet, so I cannot test. regars, Jan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] experimental: arm: dts: dra7xx: Add a DT node for VPE
Hi Laurent,
Sorry about the late response, I had scrapped the DT patch out of the
VPE series since there were dependencies on crossbar drivers and some
other baseport stuff. Comments below.
On Friday 09 August 2013 03:41 AM, Laurent Pinchart wrote:
Hi Archit,
Thank you for the patch.
On Friday 02 August 2013 19:33:43 Archit Taneja wrote:
Add a DT node for VPE in dra7.dtsi. This is experimental because we might
need to split the VPE address space a bit more, and also because the IRQ
line described is accessible the IRQ crossbar driver is added for DRA7XX.
Cc: Rajendra Nayak rna...@ti.com
Cc: Sricharan R r.sricha...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 11 +++
Documentation is missing :-) As this is an experimental patch you can probably
document the bindings later.
Yes, I will work on that.
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ce9a0f0..3237972 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -484,6 +484,17 @@
dmas = sdma 70, sdma 71;
dma-names = tx0, rx0;
};
+
+ vpe {
+ compatible = ti,vpe;
+ ti,hwmods = vpe;
+ reg = 0x489d 0xd000, 0x489dd000 0x400;
+ reg-names = vpe, vpdma;
+ interrupts = 0 159 0x4;
+ #address-cells = 1;
+ #size-cells = 0;
Are #address-cells and #size-cells really needed ?
These aren't needed, vpe derives the address info from it's parent(ocp).
I didn't know that the child nodes inherit these params from the parent.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFR 2/2] drm/panel: Add simple panel support
On 10/24/2013 12:52 PM, Tomi Valkeinen wrote:
On 24/10/13 13:40, Laurent Pinchart wrote:
panel {
remote =remote-endpoint;
common-video-property =asd;
};
panel {
port {
endpoint {
remote =remote-endpoint;
common-video-property =asd;
};
};
};
Please note that the common video properties would be in the panel node, not
in the endpoint node (unless you have specific requirements to do so, which
isn't the common case).
Hmm, well, the panel driver must look for its properties either in the
panel node, or in the endpoint node (I guess it could look them from
both, but that doesn't sound good).
Presumably the OS could be searching for port node and any endpoint node
inside it first. If that's not found then it could be parsing the panel
node.
Please note that a port node may be required even if there is only one
port, when there are multiple physical bus interfaces, e.g. at an LCD
controller and only one of them is used. The reg property would select
the physical bus interface.
I wonder if a property like #video-port or #video-endpoint could be used
to indicate that a node contains video bus properties. Probably it's too
late to introduce it now and make it a required property for the endpoint
nodes or nodes containing the common video properties.
If you write the panel driver, and in all your cases the properties work
fine in the panel node, does that mean they'll work fine with everybody?
It's likely not safe to assume so. In V4L data bus properties are specified
a both the receiver and the transmitter endpoint nodes separately.
I guess there are different kinds of properties. Something like a
regulator is obviously property of the panel. But anything related to
the video itself, like DPI's bus width, or perhaps even something like
orientation if the panel supports such, could need to be in the
endpoint node.
If we use port/endpoint nodes it all seems clear, the video bus properties
are put in an endpoint node.
But since we are considering a simplified binding all the properties would
be placed in the panel or display controller node.
But yes, I understand what you mean. With common-video-property I
meant common properties like DPI bus width.
If that can be supported in the SW by adding complexity to a few functions,
and it covers practically all the panels, isn't it worth it?
Note that I have not tried this, so I don't know if there are issues.
It's just a thought. Even if there's need for a endpoint node, perhaps
the port node can be made optional.
It can be worth it, as long as we make sure that simplified bindings cover the
needs of the generic code.
We could assume that, if the port subnode isn't present, the device will have
a single port, with a single endpoint. However, isn't the number of endpoints
Right.
a system property rather than a device property ? If a port of a device is
Yes.
connected to two remote ports it will require two endpoints. We could select
the simplified or full bindings based on the system topology though.
Yes, I guess it's all about the system topology. Any simplified binding
would
work only for very simple configuration like single-output LCD
controller with
single panel attached to it.
The drivers should not know about simplified/normal bindings. They
should use CDF DT helper functions to get the port and endpoint
information. The helper functions would do the assuming.
Yes, anyway all the parsing is supposed to be done within the helpers.
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
